K8s系列之：Init Container初始化容器

在很多应用场景中，应用在启动之前都需要进行如下初始化操作。

• 等待其他关联组件正确运行（例如数据库或某个后台服务）
• 基于环境变量或配置模版生成配置文件
• 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中
• 下载相关依赖包，或者对系统进行一些预配置操作

一、认识Init container

Init container用于在启动应用容器之前启动一个或多个初始化容器，完成应用容器所需的预置条件。

• Init container与应用容器本质上是一样的，是仅运行一次就结束的任务，并且必须在成功执行完成后，系统才能继续执行下一个容器。
• 根据Pod的重启策略，当init container执行失败，在设置了RestartPolicy=Never时，Pod将会启动失败，而设置RestartPolicy=Always时，Pod将会被系统自动重启。

二、Init Container应用实例

下面以Nginx应用为例，在启动Nginx之前，通过初始化容器busybox为Nginx创建一个index.html主页文件。这里为init container和Nginx设置了一个共享的volume，以供Nginx访问init container设置的index.html文件

nginx-init-containers.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  annotations: initial container
spec:
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
    containers:
    - name: nginx
      image: nginx
      ports: 
      - containerPort: 80
      volumeMounts:
      - name: workdir
        mountPath: /usr/share/nginx/html
      dnsPolicy: Default
      volumes:
      - name: workdir
        emptyDir: {}

创建这个Pod

kubectl create -f nginx-init-containers.yaml
Pod "nginx" created

在运行init container的过程中，查看Pod的状态，可见init过程还未完成：

kubectl get pods
NAME   READY    STATUS       RESTARTS       AGE
nginx   0/1       Init:0/1      0            1m

在init container成功执行完成后，系统继续启动Nginx容器，再次查看Pod的状态：

kubectl get pods
NAME         READY         STATUS        RESTARTS       AGE
nginx         1/1          Running          0            7s 

查看Pod的事件，可以看到系统首先创建并运行init container容器（名为install），成功后继续创建和运行Nginx容器

kubectl describe pod nginx

启动成功后，登陆进Nginx容器，可以查看到/usr/share/nginx/html目录下的index.html文件为init container所生成。

三、init container与应用容器的区别

init container与应用容器的区别如下：

• init container的运行方式与应用容器不同，必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后，K8s才会初始化Pod的各种信息，并开始创建和运行应用容器。

• 在init container的定义中也可以设置资源限制、volume的使用和安全策略等。但资源限制的设置与应用容器略有不同。

• 多个init container都定义了资源请求和资源限制，则取最大的值作为所有init container的资源请求值/资源限制值。

• Pod的有效(effective)资源请求值/资源限制值取以下二者中的较大值。所有应用容器的资源请求值/资源限制值之和。init container的有效资源请求值/资源限制值。

• 调度算法将基于Pod的有效资源请求值/资源限制值进行计算，也就是说init container可以为初始化操作预留系统资源，即使后续应用容器无须使用这些资源。

• Pod的有效Qos等级适用于init container和应用容器

• 资源配额和限制将根据Pod的有效资源请求值/资源限制值计算生效。

• Pod级别的cgroup将基于Pod的有效资源请求/限制，与调度机制一致。

• init container不能设置readinessProbe探针，必须在成功运行后才能继续运行Pod中定义的普通容器。

• 在Pod重新启动(Restart)时，init container将会重新运行，常见的Pod重启场景如下。

• init container的镜像被更新时，init container将会重新运行，导致Pod重启。

• 仅更新应用容器的镜像只会使得应用容器被重启。

• Pod的infrastructure容器(pause)更新时，Pod将会重启。

• 若Pod中的所有应用容器都终止了，并且RestartPolicy=Always，则Pod将会重启。

四、相关拓展知识cgroups和Qos

1.cgroups

• cgroups名称源自控制组群（英语：control groups）的简写，是Linux内核的一个功能，用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。
• 通过设置CGroup，可以达到对资源的控制，例如限制内存、CPU的使用。在k8s中，对pod的资源限制就是通过CGroup这个技术来实现的。

2.Qos

在k8s中，会为pod设置不同的QoS类型，以保证pod的资源可用，其中QoS有三个类型：

• Guaranteed：Pod中的所有容器（包括init容器）都必须设置内存和CPU的请求(limit)和限制(request)，且请求和限制的值要相等。（如果只设置limit，则默认request=limit）；
• Burstable：Pod中至少有一个容器设置了内存和CPU请求，且不符合Guaranteed QoS类型的标准；
• BestEffort：Pod中所有的容器都没有设置任何内存和CPU的限制和请求。