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的限制和请求。