04-初始化容器

初始化容器

容器的健康检查的两个探针：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的生命周期范畴之内的。

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

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

Init容器与普通容器区别：

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

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

Init容器的优势：

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

Init容器应用场景：

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

示例：

[root@k8s-master ~]# vim init-pod.yaml
[root@k8s-master ~]# cat init-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp-pod
spec:
  containers:
    - name: myapp-pod
      image: busybox
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:   #定义初始化容器
  - name: init-myservice    #初始化容器名称
    image: busybox            #初始化容器使用的镜像
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  #执行until循环语句，每隔两秒中使用nslookup进行解析myservice,如果解析成功则输出waiting for myservice，如果解析不成功，则一直进行循环
  - name: init-mydb         #初始化容器名称
    image: busybox      #初始化容器使用的镜像
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
 #执行until循环语句，每隔两秒中使用nslookup进行解析mydb,如果解析成功则输出waiting for mydb，如果解析不成功，则一直进行循环

运行yaml文件

[root@k8s-master ~]# kubectl create -f init-pod.yaml
pod/myapp-pod created
[root@k8s-master ~]# kubectl get pod
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:0/2   0          5m10s
#此时查看到的状态为初始化程序进行等待，两个初始化容器，当前执行完成0个
[root@k8s-master ~]# kubectl describe pod myapp-pod
#上方内容略.......
Events:
  Type    Reason     Age   From                 Message
  ----    ------     ----  ----                 -------
  Normal  Scheduled  7m4s  default-scheduler    Successfully assigned default/myapp-pod to k8s-node02
  Normal  Pulling    7m3s  kubelet, k8s-node02  Pulling image "busybox"
  Normal  Pulled     7m1s  kubelet, k8s-node02  Successfully pulled image "busybox"
  Normal  Created    7m1s  kubelet, k8s-node02  Created container init-myservice
  Normal  Started    7m1s  kubelet, k8s-node02  Started container init-myservice
#此时通过查看信息第一个初始化容器已经创建成功->运行成功，但是没有执行完毕，所以不会执行后面的初始化容器和主容器
[root@k8s-master ~]# kubectl logs myapp-pod -c init-myservice --tail=20 -f
#查看myapp-pod的init-myservice的日志，并进行实时更新，因为没有解析，初始化容器会一直进行解析，不会完成

编写myservice.yaml

创建一个空的service提供给初始化程序解析，使初始化容器进行解析，并完成解析后退出此初始化程序

[root@k8s-master ~]# vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

创建

[root@k8s-master ~]# kubectl  create -f myservice.yaml
service/myservice created
#查看service
[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   6d23h
myservice    ClusterIP   10.108.227.53   <none>        80/TCP    25s
#等待几分钟后进行查看容器状态
[root@k8s-master ~]# kubectl get pod
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:1/2   0          29m
#此时初始化容器已经成功执行一个，因为初始化容器成功解析到对应的域名ip，完成后退出了初始化容器，开始进行下一个初始化容器

创建第二个初始化容器所需的解析

[root@k8s-master ~]# vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

创建

[root@k8s-master ~]# kubectl create -f mydb.yaml
service/mydb created
#创建完成后等待2-3分钟进行查看pod的状态
[root@k8s-master ~]# kubectl get po
NAME        READY   STATUS    RESTARTS   AGE
myapp-pod   1/1     Running   0          35m
#此时两个初始化容器都已经执行完成，主容器运行，状态已经为running状态

容器特殊说明

• 在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容器名称必须唯一；与任何其他容器共享同一个名称，会在验证时抛出错误。