掌握Pod-Pod调度策略
- 2019 年 11 月 22 日
- 笔记
一 Pod生命周期管理
1.1 Pod生命周期
Pod在整个生命周期过程中被系统定义了如下各种状态。
|
状态值 |
描述 |
|---|---|
|
Pending |
API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。 |
|
Running |
Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。 |
|
Succeeded |
Pod内所有容器均成功执行退出，且不会重启。 |
|
Failed |
Pod内所有容器均已退出，但至少有一个容器退出为失败状态。 |
|
Unknown |
由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。 |
1.2 Pod重启策略
Pod重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应操作。
Pod的重启策略包括Always、OnFailure和Never，默认值为Always。
- Always：当容器失效时，由kubelet自动重启该容器；
- OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器；
- Never：不论容器运行状态如何，kubelet都不会重启该容器。
kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1/2/4/8倍等，最长延时5min，并且在成功重启后的10min后重置该时间。
Pod的重启策略与控制方式关联，当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理（静态Pod）。
不同控制器的重启策略限制如下：
- RC和DaemonSet：必须设置为Always，需要保证该容器持续运行；
- Job：OnFailure或Never，确保容器执行完成后不再重启；
- kubelet：在Pod失效时重启，不论将RestartPolicy设置为何值，也不会对Pod进行健康检查。
|
Pod包含的容器数 |
Pod当前的状态 |
发生事件 |
Pod的结果状态 |
||
|---|---|---|---|---|---|
|
RestartPolicy=Always |
RestartPolicy=OnFailure |
RestartPolicy=Never |
|||
|
包含1个容器 |
Running |
容器成功退出 |
Running |
Succeeded |
Succeeded |
|
包含1个容器 |
Running |
容器失败退出 |
Running |
Running |
Failed |
|
包括两个容器 |
Running |
1个容器失败退出 |
Running |
Running |
Running |
|
包括两个容器 |
Running |
容器被OOM杀掉 |
Running |
Running |
Failed |
1.3 Pod健康检查
对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。
LivenessProbe探针：用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe探针，kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。
ReadineeProbe探针：用于判断容器是否启动完成（ready状态）。如果ReadinessProbe探针探测到失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。
kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式：
- ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。
示例：通过执行"cat /tmp/health"命令判断一个容器运行是否正常。容器初始化并创建该文件，10s后删除该文件，15s秒通过命令判断，由于该文件已被删除，因此判断该容器Fail，导致kubelet杀掉该容器并重启。
1 [root@uk8s-m-01 study]# vi dapi-liveness.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dapi-liveness-pod 6 labels: 7 test: liveness-exec 8 spec: 9 containers: 10 - name: dapi-liveness 11 image: busybox 12 args: 13 - /bin/sh 14 - -c 15 - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600 16 livenessProbe: 17 exec: 18 command: 19 - cat 20 - /tmp/health 21 22 [root@uk8s-m-01 study]# kubectl describe pod dapi-liveness-pod
- TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。
示例：
1 [root@uk8s-m-01 study]# vi dapi-tcpsocket.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: dapi-healthcheck-tcp 6 spec: 7 containers: 8 - name: nginx 9 image: nginx 10 ports: 11 - containerPort: 80 12 livenessProbe: 13 tcpSocket: 14 port: 80 15 initialDelaySeconds: 30 16 timeoutSeconds: 1 17 18 [root@uk8s-m-01 study]# kubectl create -f dapi-tcpsocket.yaml
提示：对于每种探测方式，都需要设置如下两个参数，其包含的含义如下：
initialDelaySeconds：启动容器后进行首次健康检查的等待时间，单位为s；
timeoutSeconds：健康检查发送请求后等待响应的超时时间，单位为s，当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。
二 Pod调度
Kubernetes中，Pod通常是容器的载体，一般需要通过Deployment、DaemonSet、RC、Job等对象来完成一组Pod的调度与自动控制功能。
2.1 Depolyment/RC自动调度
Deployment或RC的主要功能之一就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
示例：
1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml 2 apiVersion: apps/v1beta1 3 kind: Deployment 4 metadata: 5 name: nginx-deployment-01 6 spec: 7 replicas: 3 8 template: 9 metadata: 10 labels: 11 app: nginx 12 spec: 13 containers: 14 - name: nginx 15 image: nginx:1.7.9 16 ports: 17 - containerPort: 80 18 19 [root@uk8s-m-01 study]# kubectl get deployments 20 NAME READY UP-TO-DATE AVAILABLE AGE 21 nginx-deployment-01 3/3 3 3 30s 22 [root@uk8s-m-01 study]# kubectl get rs 23 NAME DESIRED CURRENT READY AGE 24 nginx-deployment-01-5754944d6c 3 3 3 75s 25 [root@uk8s-m-01 study]# kubectl get pod | grep nginx 26 nginx-deployment-01-5754944d6c-hmcpg 1/1 Running 0 84s 27 nginx-deployment-01-5754944d6c-mcj8q 1/1 Running 0 84s 28 nginx-deployment-01-5754944d6c-p42mh 1/1 Running 0 84s
2.2 NodeSelector定向调度
当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配。
# kubectl label nodes <node-name> <label-key>=<label-value>
node节点创建对应的label后，可通过在定义Pod的时候加上nodeSelector的设置实现指定的调度。
示例：
1 [root@uk8s-m-01 study]# kubectl label nodes 172.24.9.14 speed=io 2 node/172.24.9.14 labeled 3 [root@uk8s-m-01 study]# vi nginx-master-controller.yaml 4 kind: ReplicationController 5 metadata: 6 name: nginx-master 7 labels: 8 name: nginx-master 9 spec: 10 replicas: 1 11 selector: 12 name: nginx-master 13 template: 14 metadata: 15 labels: 16 name: nginx-master 17 spec: 18 containers: 19 - name: master 20 image: nginx:1.7.9 21 ports: 22 - containerPort: 80 23 nodeSelector: 24 speed: io 25 26 [root@uk8s-m-01 study]# kubectl create -f nginx-master-controller.yaml 27 [root@uk8s-m-01 study]# kubectl get pods -o wide 28 NAME READY STATUS RESTARTS AGE IP NODE 29 nginx-master-7fjgj 1/1 Running 0 82s 172.24.9.71 172.24.9.14
提示：可以将集群中具有不同特点的Node贴上不同的标签，实现在部署时就可以根据应用的需求设置NodeSelector来进行指定Node范围的调度。
注意：若在定义Pod中指定了NodeSelector条件，但集群中不存在符合该标签的Node，即使集群有其他可供使用的Node，Pod也无法被成功调度。
2.3 NodeAffinity亲和性调度
亲和性调度机制极大的扩展了Pod的调度能力，主要增强功能如下：
- 更具表达力，即更精细的力度控制；
- 可以使用软限制、优先采用等限制方式，即调度器在无法满足优先需求的情况下，会使用其他次条件进行满足；
- 可以依据节点上正在运行的其他Pod的标签来进行限制，而非节点本身的标签，从而实现Pod之间的亲和或互斥关系。
目前有两种节点亲和力表达：
requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）。
preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值。
IgnoredDuringExecution指：如果一个Pod所在的节点在Pod运行期间标签发生了变化，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label的变化，该Pod能继续在该节点运行。
示例：
条件1：只运行在amd64的节点上；尽量运行在ssd节点上。
1 [root@uk8s-m-01 study]# vi nodeaffinity-pod.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: with-node-affinity 6 spec: 7 affinity: 8 nodeAffinity: 9 requiredDuringSchedulingIgnoredDuringExecution: 10 nodeSelectorTerms: 11 - matchExpressions: 12 - key: kubernetes.io/arch 13 operator: In 14 values: 15 - amd64 16 preferredDuringSchedulingIgnoredDuringExecution: 17 - weight: 1 18 preference: 19 matchExpressions: 20 - key: disk-type 21 operator: In 22 values: 23 - ssd 24 containers: 25 - name: with-node-affinity 26 image: gcr.azk8s.cn/google_containers/pause:2.0
NodeAffinity操作语法；In、NotIn、Exists、DoesNotExist、Gt、Lt。NotIn和DoesNotExist可以实现互斥功能。
NodeAffinity规则设置注意事项：
- 若同时定义nodeSelector和nodeAffinity，则必须两个条件都满足，Pod才能最终运行指定在Node上；；
- 若nodeAffinity指定多个nodeSelectorTerms，则只需要其中一个能够匹配成功即可；
- 若nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有matchExpressions才能运行该Pod。
2.4 PodAffinity亲和性调度
PodAffinity根据节点上正在运行的Pod标签而不是Node标签来判断和调度，要求对节点和Pod两个条件进行匹配。
规则描述为：若在具有标签X的Node上运行了一个或多个符合条件Y的Pod，则Pod应该（或者不应该）运行在这个Node上。
X通常为Node节点的机架、区域等概念，Pod是属于某个命名空间，所以条件Y表达的是一个或全部命名空间中的一个Label Selector。
Pod亲和性定义与PodSpec的affinity字段下的podAffinity字段里，互斥性定义于同一层次的podAntiAffinity子字段中。
举例：
1 [root@uk8s-m-01 study]# vi nginx-flag.yaml #创建名为pod-flag，带有两个标签的Pod 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: pod-affinity 6 spec: 7 affinity: 8 podAffinity: 9 requiredDuringSchedulingIgnoredDuringExecution: 10 - labelSelector: 11 matchExpressions: 12 - key: security 13 operator: In 14 values: 15 - S1 16 topologyKey: kubernetes.io/hostname 17 containers: 18 - name: with-pod-affinity 19 image: gcr.azk8s.cn/google_containers/pause:2.0
1 [root@uk8s-m-01 study]# vi nginx-affinity-in.yaml #创建定义标签security=S1，对应如上Pod “Pod-flag”。 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: pod-affinity 6 spec: 7 affinity: 8 podAffinity: 9 requiredDuringSchedulingIgnoredDuringExecution: 10 - labelSelector: 11 matchExpressions: 12 - key: security 13 operator: In 14 values: 15 - S1 16 topologyKey: kubernetes.io/hostname 17 containers: 18 - name: with-pod-affinity 19 image: gcr.azk8s.cn/google_containers/pause:2.0 20 21 [root@uk8s-m-01 study]# kubectl create -f nginx-affinity-in.yaml 22 [root@uk8s-m-01 study]# kubectl get pods -o wide
提示：由上Pod亲和力可知，两个Pod处于同一个Node上。
1 [root@uk8s-m-01 study]# vi nginx-affinity-out.yaml #创建不能与参照目标Pod运行在同一个Node上的调度策略 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: anti-affinity 6 spec: 7 affinity: 8 podAffinity: 9 requiredDuringSchedulingIgnoredDuringExecution: 10 - labelSelector: 11 matchExpressions: 12 - key: security 13 operator: In 14 values: 15 - S1 16 topologyKey: failure-domain.beta.kubernetes.io/zone 17 podAntiAffinity: 18 requiredDuringSchedulingIgnoredDuringExecution: 19 - labelSelector: 20 matchExpressions: 21 - key: security 22 operator: In 23 values: 24 - nginx 25 topologyKey: kubernetes.io/hostname 26 containers: 27 - name: anti-affinity 28 image: gcr.azk8s.cn/google_containers/pause:2.0 29 30 [root@uk8s-m-01 study]# kubectl get pods -o wide #验证
2.5 Taints和Tolerations（污点和容忍）
Taint：使Node拒绝特定Pod运行；
Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node。
Taint语法：$ kubectl taint node node1 key=value:NoSchedule
解释：为node1加上一个Taint，该Taint的键为key，值为value，Taint的效果为NoSchedule。即除非特定声明可以容忍此Taint，否则不会调度至node1上。
Toleration示例：
1 tolerations: 2 - key: "key" 3 operator: "Equal" 4 value: "value" 5 effect: "NoSchedule"
或
1 tolerations: 2 - key: "key" 3 operator: "Exists" 4 effect: "NoSchedule"
注意：Pod的Toleration声明中的key和effect需要与Taint的设置保持一致，并且满足以下条件：
- operator的值是Exists（无须指定value）；
- operator的值是Equal并且value相等；
- 空的key配合Exists操作符能够匹配所有的键和值；
- 空的effect匹配所有的effect。
若不指定operator，则默认值为Equal。
taint说明：系统允许在同一个Node上设置多个taint，也可以在Pod上设置多个toleration。Kubernetes调度器处理多个taint和toleration的逻辑顺序：首先列出节点中所有的taint，然后忽略pod的toleration能够匹配的部分，剩下的没有忽略掉的taint就是对pod的效果。以下是几种特殊情况：
若剩余的taint中存在effect=NoSchedule，则调度器不会把该Pod调度到这一节点上；
若剩余的taint中没有NoSchedule效果，但有PreferNoSchedule效果，则调度器会尝试不把这个Pod指派到此节点；
若剩余taint的效果有NoSchedule，并且这个Pod已经在该节点上运行，则会被驱逐，若没有在该节点上运行，也不会再被调度到该节点上。
示例：
1 $ kubectl taint node node1 key=value1:NoSchedule 2 $ kubectl taint node node1 key=value1:NoExecute 3 $ kubectl taint node node1 key=value2:NoSchedule 4 tolerations: 5 - key: "key1" 6 operator: "Equal" 7 value: "value" 8 effect: "NoSchedule" 9 tolerations: 10 - key: "key1" 11 operator: "Equal" 12 value: "value1" 13 effect: "NoExecute"
释义：此Pod声明了两个容忍，且能匹配Node1的taint，但是由于没有能匹配第三个taint的toleration，因此此Pod依旧不能调度至此Node。若该Pod已经在node1上运行了，那么在运行时设置了第3个taint，它还能继续在node1上运行，这是因为Pod可以容忍前两个taint。
通常，若node加上effect=NoExecute的taint，那么该Node上正在运行的所有无对应toleration的Pod都会被立刻驱逐，而具有相应toleration的Pod则永远不会被驱逐。同时，系统可以给具有NoExecute效果的toleration加入一个可选的tolerationSeconds字段，表明Pod可以在taint添加到Node之后还能在此Node运行多久。
1 tolerations: 2 - key: "key1" 3 operator: "Equal" 4 value: "value" 5 effect: "NoSchedule" 6 tolerationSeconds： 3600
释义：若Pod正在运行，所在节点被加入一个匹配的taint，则这个pod会持续在该节点运行3600s后被驱逐。若在此期限内，taint被移除，则不会触发驱逐事件。
Taints和Tolerations常用场景：
- 独占节点：
给特定的节点运行特定应用。
$ kubectl taint nodes 【nodename】 dedicated=groupName:NoSchedule
同时在Pod中设置对应的toleration配合，带有合适toleration的Pod允许同时使用其他节点一样使用有taint的节点。
- 具有特殊硬件设备的节点
集群中部分特殊硬件（如安装了GPU），则可以把不需要占用GPU的Pod禁止在此Node上调度。
1 $ kubectl taint nodes 【nodename】 special=true:NoSchedule 2 $ kubectl taint nodes 【nodename】 special=true:PreferNoSchedule
- 定义Pod驱逐行为
NoExecute的taint对节点上正在运行的Pod有以下影响：
- 没有设置toleration的pod会被立刻驱逐；
- 配置了对应toleration的pod，若没有为tolerationSeconds赋值，则会一直保留在此节点中；
- 配置了对应toleration的pod，且为tolerationSeconds赋值，则在指定时间后驱逐。
2.6 DaemonSet
DaemonSet是在每个Node上调度一个Pod的资源对象，用于管理集群中每个Node仅运行一份Pod的副本实例。
常见场景：
在每个Node上运行一个GlusterFS存储的Daemon进程；
在每个Node上运行一个日志采集程序，例如Fluentd；
在每个Node上运行一个性能监控程序，采集该Node的运行性能数据，例如Prometheus。
示例：
1 [root@uk8s-m-01 study]# vi fluentd-ds.yaml 2 apiVersion: extensions/v1beta1 3 kind: DaemonSet 4 metadata: 5 name: fluentd-cloud-logging 6 namespace: kube-system 7 labels: 8 k8s-app: fluentd-cloud-logging 9 spec: 10 template: 11 metadata: 12 namespace: kube-system 13 labels: 14 k8s-app: fluentd-cloud-logging 15 spec: 16 containers: 17 - name: fluentd-cloud-logging 18 image: gcr.azk8s.cn/google_containers/fluentd-elasticsearch:1.17 19 resources: 20 limits: 21 cpu: 100m 22 memory: 200Mi 23 env: 24 - name: FLUENTD_ARGS 25 value: -q 26 volumeMounts: 27 - name: varlog 28 mountPath: /var/log 29 readOnly: false 30 - name: containers 31 mountPath: /var/lib/docker/containers 32 readOnly: false 33 volumes: 34 - name: containers 35 hostPath: 36 path: /var/lib/docker/containers 37 - name: varlog 38 hostPath: 39 path: /var/log
2.7 Job批处理调度
通过Kubernetes Job资源对象可以定义并启动一个批处理任务，批处理任务通过并行（或者串行）启动多个计算进程去处理一批工作项。根据批处理方式不同，批处理任务可以分为如下几种模式：
Job Template Expansion模式：一个Job对象对应一个待处理的Work item，有几个work item就产生几个独立的Job。通常适合Work item数量少、每个Work item要处理的数据量比较大的场景。
Queue with Pod Per Work Item模式：采用一个任务队列存放Work item，一个Job对象作为消费者去完成这些Work item。此模式下，Job会启动N个Pod，每个Pod都对应一个Work item。
Queue with Variable Pod Count模式：采用一个任务队列存放Work item，一个Job对象作为消费者去完成这些Work item，但此模式下Job启动的数量是可变的。
Kubernetes将Job氛围以下三类：
- Non-parallel Jobs
通常一个Job只启动一个Pod，除非Pod异常，才会重启该Pod，一旦此Pod正常结束，Job将结束。
- Parallel Jobs with a fixed completion count
并行Job会启动多个Pod，此时需要设定Job的.spec.completions参数为一个正数，当正常结束的Pod数量达至此参数设定的值后，Job结束。同时.spec.parallelism参数用来控制并行度，即同时启动几个Job来处理Work Item。
- Parallel Jobs with a work queue
任务队列方式的并行Job需要一个独立的Queue，Work Item都在一个Queue中存放，不能设置Job的.spec.completions参数，此时Job具有以下特性：
- 每个Pod都能独立判断和决定是否还有任务项需要处理；
- 如果某个Pod正常结束，则Job不会再启动新的Pod；
- 如果一个Pod成功结束，则此时应该不存在其他Pod还在工作的情况。它们应该都处于即将结束、退出的状态；
- 如果所有Pod都结束了，且至少有一个Pod成功结束，则整个Jod成功结束。
2.8 Cronjob定时任务
表达式：Minutes Hours DayofMonth Month DayofWeek Year
Minutes:可出现","、"_"、"*"、"/"，有效范围为0~59的整数；
Hours:出现","、"_"、"*"、"/"，有效范围为0~23的整数；
DayofMonth:出现","、"_"、"*"、"/"、"L"、"W"、"C"，有效范围为0~31的整数；
Month:可出现","、"_"、"*"、"/"，有效范围为1~12的整数或JAN~DEC；
DayofWeek:出现","、"_"、"*"、"/"、"L"、"W"、"C"、"#"，有效范围为1~7的整数或SUN~SAT；
*： 表示匹配该域的任意值， 假如在Minutes域使用“*”， 则表示每分钟都会触发事件。
/： 表示从起始时间开始触发， 然后每隔固定时间触发一次，例如在Minutes域设置为5/20， 则意味着第1次触发在第5min时， 接下来每20min触发一次， 将在第25min、 第45min等时刻分别触发。
示例：*/1 * * * * #每隔1min执行一次任务
1 [root@uk8s-m-01 study]# vi cron.yaml 2 apiVersion: batch/v2alpha1 3 kind: CronJob 4 metadata: 5 name: hello 6 spec: 7 schedule: "*/1 * * * *" 8 jobTemplate: 9 spec: 10 template: 11 spec: 12 containers: 13 - name: hello 14 image: busybox 15 args: 16 - /bin/sh 17 - -c 18 - date; echo Hello from the Kubernetes cluster 19 restartPolicy: OnFailure
1 [root@master study]# kubectl create -f cron.yaml 2 [root@master study]# kubectl get cronjob hello 3 NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE 4 hello */1 * * * * False 0 <none> 29s 5 [root@master study]# kubectl get pods 6 NAME READY STATUS RESTARTS AGE 7 hello-1573378080-zvvm5 0/1 Completed 0 68s 8 hello-1573378140-9pmwz 0/1 Completed 0 8s 9 [root@node1 ~]# docker logs c7 #node节点查看日志 10 Sun Nov 10 09:31:13 UTC 2019 11 Hello from the Kubernetes cluster 12 [root@master study]# kubectl get jobs #查看任务 13 NAME COMPLETIONS DURATION AGE 14 hello-1573378500 1/1 8s 3m7s 15 hello-1573378560 1/1 4s 2m7s 16 hello-1573378620 1/1 6s 67s 17 hello-1573378680 1/1 4s 7s 18 [root@master study]# kubectl get pods -o wide | grep hello-1573378680 #以job任务查看对应的pod 19 [root@master study]# kubectl delete cj hello #删除cronjob
2.9 初始化容器
在很多应用场景中， 应用在启动之前都需要进行如下初始化操作。
- 等待其他关联组件正确运行（ 例如数据库或某个后台服务） 。
- 基于环境变量或配置模板生成配置文件。
- 从远程数据库获取本地所需配置， 或者将自身注册到某个中央数据库中。
- 下载相关依赖包， 或者对系统进行一些预配置操作。
示例：以Nginx应用为例， 在启动Nginx之前， 通过初始化容器busybox为Nginx创建一个index.html主页文件。同时init container和Nginx设置了一个共享的Volume， 以供Nginx访问init container设置的index.html文件。
1 [root@uk8s-m-01 study]# vi nginx-init-containers.yaml 2 apiVersion: v1 3 kind: Pod 4 metadata: 5 name: nginx 6 annotations: 7 spec: 8 initContainers: 9 - name: install 10 image: busybox 11 command: 12 - wget 13 - "-O" 14 - "/work-dir/index.html" 15 - http://kubernetes.io 16 volumeMounts: 17 - name: workdir 18 mountPath: "/work-dir" 19 containers: 20 - name: nginx 21 image: nginx:1.7.9 22 ports: 23 - containerPort: 80 24 volumeMounts: 25 - name: workdir 26 mountPath: /usr/share/nginx/html 27 dnsPolicy: Default 28 volumes: 29 - name: workdir 30 emptyDir: {}
1 [root@uk8s-m-01 study]# kubectl get pods 2 NAME READY STATUS RESTARTS AGE 3 nginx 0/1 Init:0/1 0 2s 4 [root@uk8s-m-01 study]# kubectl get pods 5 NAME READY STATUS RESTARTS AGE 6 nginx 1/1 Running 0 13s 7 [root@uk8s-m-01 study]# kubectl describe pod nginx #查看事件可知会先创建init容器，名为install
init容器与应用容器的区别如下。
（1） init container的运行方式与应用容器不同， 它们必须先于应用容器执行完成， 当设置了多个init container时， 将按顺序逐个运行， 并且只有前一个init container运行成功后才能运行后一个init container。 当所有init container都成功运行后， Kubernetes才会初始化Pod的各种信息， 并开始创建和运行应用容器。
（2） 在init container的定义中也可以设置资源限制、 Volume的使用和安全策略， 等等。 但资源限制的设置与应用容器略有不同。
- 如果多个init container都定义了资源请求/资源限制， 则取最大的值作为所有init container的资源请求值/资源限制值。
- Pod的有效（effective） 资源请求值/资源限制值取以下二者中的较大值。
- 所有应用容器的资源请求值/资源限制值之和。
- init container的有效资源请求值/资源限制值。
- 调度算法将基于Pod的有效资源请求值/资源限制值进行计算，即init container可以为初始化操作预留系统资源， 即使后续应用容器无须使用这些资源。
- Pod的有效QoS等级适用于init container和应用容器。
- 资源配额和限制将根据Pod的有效资源请求值/资源限制值计算生效。
- Pod级别的cgroup将基于Pod的有效资源请求/限制， 与调度机制
一致。
（3） init container不能设置readinessProbe探针， 因为必须在它们成功运行后才能继续运行在Pod中定义的普通容器。在Pod重新启动时， init container将会重新运行， 常见的Pod重启场景如下。
- init container的镜像被更新时， init container将会重新运行， 导致Pod重启。 仅更新应用容器的镜像只会使得应用容器被重启。
- Pod的infrastructure容器更新时， Pod将会重启。
- 若Pod中的所有应用容器都终止了， 并且RestartPolicy=Always， 则Pod会重启。
