网站建设需注意的,网站开发用户需求分析,网页翻译网站,网站建设问题新闻资讯初始化容器
之前了解了容器的健康检查的两个探针#xff1a;liveness probe#xff08;存活探针#xff09;和readiness probe#xff08;可读性探针#xff09;的使用方法#xff0c;我们说在这两个探针是可以影响容器的生命周期的#xff0c;包括我们之前提到的容器的…初始化容器
之前了解了容器的健康检查的两个探针liveness probe存活探针和readiness probe可读性探针的使用方法我们说在这两个探针是可以影响容器的生命周期的包括我们之前提到的容器的两个钩子函数PostStart和PreStop。现在来介绍一下Init Container初始化容器。
Init Container就是用来做初始化工作的容器可以是一个或者多个如果有多个的话这些容器会按定义的顺序依次执行只有所有的Init Container执行完后主容器才会被启动。我们知道一个Pod里面的所有容器是共享数据卷和网络命名空间的所以Init Container里面产生的数据可以被主容器使用到的。
是不是感觉Init Container和之前的钩子函数有点类似啊只是是在容器执行前来做一些工作是吧从直观的角度看上去的话初始化容器的确有点像PreStart但是钩子函数和我们的Init Container是处在不同的阶段的我们可以通过下面的图来了解下
从上面这张图我们可以直观的看到PostStart和PreStop包括liveness和readiness是属于主容器的生命周期范围内的而Init Container是独立于主容器之外的当然他们都属于Pod的生命周期范畴之内的现在我们应该明白Init Container和钩子函数之类的区别了吧。
另外我们可以看到上面我们的Pod右边还有一个infra的容器这是一个什么容器呢我们可以在集群环境中去查看下人任意一个Pod对应的运行的Docker容器我们可以发现每一个Pod下面都包含了一个pause-amd64的镜像这个就是我们的infra镜像我们知道Pod下面的所有容器是共享同一个网络命名空间的这个镜像就是来做这个事情的所以每一个Pod当中都会包含一个这个镜像。 最开始 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来因为默认该镜像是需要到谷歌服务器上拉取的所以需要提前拉取到节点上面。 我们说Init Container主要是来做初始化容器工作的那么他有哪些应用场景呢
等待其他模块Ready这个可以用来解决服务之间的依赖问题比如我们有一个 Web 服务该服务又依赖于另外一个数据库服务但是在我们启动这个 Web 服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了所以可能会出现一段时间内 Web 服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个 InitContainer在这个初始化容器中去检查数据库是否已经准备好了准备好了过后初始化容器就结束退出然后我们的主容器 Web 服务被启动起来这个时候去连接数据库就不会有问题了。做初始化配置比如集群里检测所有已经存在的成员节点为主容器准备好集群的配置信息这样主容器起来后就能用这个配置信息加入集群。其它场景如将 pod 注册到一个中央数据库、配置中心等。
先来演示下服务依赖的场景下初始化容器的使用方法如下Pod的定义方法
apiVersion: v1
kind: Pod
metadata:name: init-pod1labels:app: init
spec:containers:- name: init-containerimage: busyboxcommand: [sh, -c, echo The app is running! sleep 3600]initContainers:- name: init-myserviceimage: busyboxcommand: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;]- name: init-mydbimage: busyboxcommand: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;]Service的对应YAML内容
kind: Service
apiVersion: v1
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 6376
---
kind: Service
apiVersion: v1
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 6377我们可以先创建上面的Pod然后查看下Pod的状态然后再创建下面的Service对比下前后状态。
在Pod启动过程中初始化容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。如果由于运行时或失败退出导致容器启动失败它会根据Pod的restartPolicy指定的策略进行重试。 然而如果 Pod 的 restartPolicy 设置为 AlwaysInit 容器失败时会使用 RestartPolicy 策略。
在所有的初始化容器没有成功之前Pod将不会变成 Ready状态。正在初始化中的Pod处于Pending状态但应该会将条件Initializing设置为 true。
接下来我们再来尝试创建一个做初始化配置工作的Pod
apiVersion: v1
kind: Pod
metadata:name: init-demo
spec:containers:- name: nginximage: nginxports:- containerPort: 80volumeMounts:- name: workdirmountPath: /usr/share/nginx/htmlinitContainers:- name: installimage: busyboxcommand:- wget- -O- /work-dir/index.html- http://www.baidu.comvolumeMounts:- name: workdirmountPath: /work-dirvolumes:- name: workdiremptyDir: {}可以看到这里又出现了volumesspec.volumes指的是Pod中的卷spec.containers.volumeMounts是将指定的卷 mount 到容器指定的位置相当于docker里面的-v 宿主机目录容器目录前面用到过hostPath这里使用的是emptyDir{}这个就相当于一个共享卷是一个临时的目录生命周期等同于Pod的生命周期。
初始化容器执行完会下载一个 html 文件映射到emptyDir{}而主容器也是和 spec.volumes 里的emptyDir{} 进行映射所以nginx容器的/usr/share/nginx/html目录下会映射 index.html 文件。
我们来创建下该Pod然后验证nginx容器是否运行:
$ kubectl get pod init-demo输出显示了nginx容器正在运行
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 43m在 init-demo 容器里的 nginx 容器打开一个 shell
$ kubectl exec -it init-demo -- /bin/bash在Shell里直接查看下 index.html 的内容
rootnginx:~# cat /usr/share/nginx/html/index.html如果我们看到有百度相关的信息那么证明我们上面的初始化的工作就完成了。
这就是初始化容器的使用方法到这里我们就把Pod的整个生命周期当中的几个主要阶段讲完了第一个是容器的两个钩子函数PostStart和PreStop还有就是容器健康检查的两个探针liveness probe和readiness probe以及这节课的Init Container。
