021.掌握Pod-Pod調度策略

一 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的調度能力，主要加強功能以下：

1. 更具表達力，即更精細的力度控制；
2. 可使用軟限制、優先採用等限制方式，即調度器在沒法知足優先需求的狀況下，會使用其餘次條件進行知足；
3. 能夠依據節點上正在運行的其餘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有如下影響：

1. 沒有設置toleration的pod會被馬上驅逐；
2. 配置了對應toleration的pod，若沒有爲tolerationSeconds賦值，則會一直保留在此節點中；
3. 配置了對應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具備如下特性：

1. 每一個Pod都能獨立判斷和決定是否還有任務項須要處理；
2. 若是某個Pod正常結束，則Job不會再啓動新的Pod；
3. 若是一個Pod成功結束，則此時應該不存在其餘Pod還在工做的狀況。它們應該都處於即將結束、退出的狀態；
4. 若是全部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會重啓。