k8s:初始化容器

初始化容器

Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动。一个Pod里面的所有容器是共享数据卷和网络命名空间的，所以Init Container里面产生的数据可以被主容器使用到的。

Init Container和之前的钩子函数有点类似，只是是在容器执行前来做一些工作，从直观的角度看上去的话，初始化容器的确有点像PreStart，但是钩子函数和我们的InitContainer是处在不同的阶段的，我们可以通过下面的图来了解：

在这里插入图片描述
从上面这张图我们可以直观的看到PostStart和PreStop包括liveness和readiness是属于主容器的生命周期范围内的，而Init Container是独立于主容器之外的，当然他们都属于Pod的生命周期范畴之内的。

另外我们可以看到上面我们的Pod右边还有一个infra的容器，我们可以在集群环境中去查看下任意一个Pod对应的运行的Docker容器，可以发现每一个Pod下面都包含了一个pause-amd64的镜像，这个就是我们的infra镜像，我们知道Pod下面的所有容器是共享同一个网络命名空间的，这个镜像就是来做这个事情的，所以每一个Pod当中都会包含一个这个镜像。

很多 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来，所以需要提前拉取到节点上面。

Init容器与普通容器区别：

Init容器总是运行到成功为止。
每个Init容器都必须在下一个Init容器启动之前成功完成。

如果Pod的Init容器失败，Kubenetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy为Never，它不会重新启动。

Init容器的优势：

它可以包含并运行实用工具。出于安全考虑，不建议在应用程序容器镜像中包含这些实用工具的。
他们可以包含使用工具和定制代码来安装，但是不能出现在应用程序容器镜像中。例如：创建镜像没有必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
应用程序容器镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，Init容器能够具有Secret的权限，而应用程序容器则不能。
它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供一种简单的阻塞或延迟应用程序容器的启动方法，直到满足先决条件。

Init容器应用场景：

等待其他模块Ready：可以用来解决服务之间的依赖问题，比如我们有一个 Web服务，该服务又依赖于另外一个数据库服务，但是在我们启动这个 Web服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了，所以可能会出现一段时间内 Web服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个nitContainer，在这个初始化容器中去检查数据库是否已经准备好了，准备好了过后初始化容器就结束退出，然后我们的主容器 Web服务被启动起来，这个时候去连接数据库就不会有问题了。
做初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。
其它场景：如将 pod 注册到一个中央数据库、配置中心等。

示例

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
  labels:
    demo: init-demo
spec:
  containers:
  - name: init-demo
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-demo1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice;sleep 2; done;']
  - name: init-demo2
    image: busybox
    command: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2;done;']
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - port: 1234
    targetPort: 4567
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 4321
    targetPort: 7654
    protocol: TCP
[root@master ~]# kubectl  get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 0/1     Init:0/2    0          6s

[root@master ~]# kubectl get pods
NAME                                      READY   STATUS      RESTARTS   AGE
init-demo                                 1/1     Running     0          4m24s

[root@master ~]# kubectl get service
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        13d
myservice    ClusterIP   10.108.202.229   <none>        1234/TCP       4m40s
mysql        ClusterIP   10.110.222.227   <none>        4321/TCP       4m39s

[root@master ~]# kubectl  logs init-demo
the app is running1

容器特殊说明

在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
如果由于运行时或失败退出，将导致容器启动失败，它会根据 PodrestartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会RestartPolicy策略。
在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
如果Pod重启，所有的Init容器必须重新执行
对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的Image字段，等价于重启该Pod。
Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成(completion)的就绪(readiness)之外的其他状态。这会在验证过程中强制执行。
在Pod中的每个app和Init容器名称必须唯一；与任何其他容器共享同一个名称，会在验证时抛出错误。

初始化容器

Init容器与普通容器区别：

Init容器的优势：

Init容器应用场景：

示例

容器特殊说明

猜你喜欢