主頁 > 作業系統 > 021.Kubernetes掌握Pod-Pod調度策略

021.Kubernetes掌握Pod-Pod調度策略

2020-10-04 11:28: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
clipboard
  • 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
clipboard 提示：由上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的副本實體， clipboard 常見場景： 在每個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
clipboard

2.7 Job批處理調度

clipboard 通過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會重啟，

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/154252.html

標籤：Linux

上一篇：一步一步創建聊天程式1-利用行程和共享記憶體來創建簡易聊天程式

下一篇：Linux Ctrl + Alt + Fx | (x = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • CA和證書

    1、在 CentOS7 中使用 gpg 創建 RSA 非對稱密鑰對 gpg --gen-key #Centos上生成公鑰/密鑰對（存放在家目錄.gnupg/） 2、將 CentOS7 匯出的公鑰，拷貝到 CentOS8 中，在 CentOS8 中使用 CentOS7 的公鑰加密一個檔案 gpg -a ......

    uj5u.com 2020-09-10 00:09:53 more
  • Kubernetes K8S之資源控制器Job和CronJob詳解

    Kubernetes的資源控制器Job和CronJob詳解與示例 ......

    uj5u.com 2020-09-10 00:10:45 more
  • VMware下安裝CentOS

    VMware下安裝CentOS 一、軟硬體準備 1 Centos鏡像準備 1.1 CentOS鏡像下載地址 下載地址 1.2 CentOS鏡像下載程序 點擊下載地址進入如下圖的網站，選擇需要下載的版本，這里選擇的是Centos8，點擊如圖所示。 決定選擇Centos8后，選擇想要的鏡像源進行下載，此 ......

    uj5u.com 2020-09-10 00:12:10 more
  • 如何使用Grep命令查找多個字串

    如何使用Grep 命令查找多個字串 大家好，我是良許！ 今天向大家介紹一個非常有用的技巧，那就是使用 grep 命令查找多個字串。 簡單介紹一下，grep 命令可以理解為是一個功能強大的命令列工具，可以用它在一個或多個輸入檔案中搜索與正則運算式相匹配的文本，然后再將每個匹配的文本用標準輸出的格式 ......

    uj5u.com 2020-09-10 00:12:28 more
  • git配置http代理

    git配置http代理 經常遇到克隆 github 慢的問題，這里記錄一下幾種配置 git 代理的方法，解決 clone github 過慢。 目錄 git配置代理 git單獨配置github代理 git配置全域代理 配置終端環境變數 git配置代理 主要使用 git config 命令 git單獨 ......

    uj5u.com 2020-09-10 00:12:33 more
  • Linux npm install 裝包時提示Error EACCES permission denied解

    npm install 裝包時提示Error EACCES permission denied解決辦法 ......

    uj5u.com 2020-09-10 00:12:53 more
  • Centos 7下安裝nginx，使用yum install nginx，提示沒有可用的軟體包

    Centos 7下安裝nginx，使用yum install nginx，提示沒有可用的軟體包。 18 (flaskApi) [root@67 flaskDemo]# yum -y install nginx 19 已加載插件：fastestmirror, langpacks 20 Loading ......

    uj5u.com 2020-09-10 00:13:13 more
  • Linux查看服務器暴力破解ssh IP

    在公網的服務器上經常遇到別人爆破你服務器的22埠，用來挖礦或者干其他嘿嘿嘿的事情~ 這種情況下正確的做法是： 修改默認ssh的22埠 使用設定密鑰登錄或者白名單ip登錄 建議服務器密碼為復雜密碼 創建普通用戶登錄服務器（root權限過大） 建立堡壘機，實作統一管理服務器 統計爆破IP [root ......

    uj5u.com 2020-09-10 00:13:17 more
  • CentOS 7系統常見快捷鍵操作方式

    Linux系統中一些常見的快捷方式，可有效提高操作效率，在某些時刻也能避免操作失誤帶來的問題。 ......

    uj5u.com 2020-09-10 00:13:31 more
  • CentOS 7作業系統目錄結構介紹

    作業系統存在著大量的資料檔案資訊，相應檔案資訊會存在于系統相應目錄中，為了更好的管理資料資訊，會將系統進行一些目錄規劃，不同目錄存放不同的資源。 ......

    uj5u.com 2020-09-10 00:13:35 more
最新发布
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中，用的編輯器命令，比如移動游標，洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反（大多數編輯器默認模式為插入模式）。 2. 插入模式在這個模式中，大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:43:21 more
  • vim的常用命令

    Vim的6種基本模式 1. 普通模式在普通模式中，用的編輯器命令，比如移動游標，洗掉文本等等。這也是Vim啟動后的默認模式。這正好和許多新用戶期待的操作方式相反（大多數編輯器默認模式為插入模式）。 2. 插入模式在這個模式中，大多數按鍵都會向文本緩沖中插入文本。大多數新用戶希望文本編輯器編輯程序中一 ......

    uj5u.com 2023-04-20 08:42:36 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜，傳統發布專案一個只需要一個jar包，運行環境需要單獨部署。而通過Docker可將jar包和相關環境（如jdk，redis，Hadoop...）等打包到docker鏡像里，將鏡像發布到Docker倉庫，部署時下載發布的鏡像，直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:26:53 more
  • 設定Windows主機的瀏覽器為wls2的默認瀏覽器

    這里以Chrome為例。 1. 準備作業 wsl是可以使用Windows主機上安裝的exe程式，出于安全考慮，默認情況下改功能是無法使用。要使用的話，終端需要以管理員權限啟動。 我這里以Windows Terminal為例，介紹如何默認使用管理員權限打開終端，具體操作如下圖所示： 2. 操作 wsl ......

    uj5u.com 2023-04-19 09:25:49 more
  • docker學習

    ###Docker概述 真實專案部署環境可能非常復雜，傳統發布專案一個只需要一個jar包，運行環境需要單獨部署。而通過Docker可將jar包和相關環境（如jdk，redis，Hadoop...）等打包到docker鏡像里，將鏡像發布到Docker倉庫，部署時下載發布的鏡像，直接運行發布的鏡像即可。 ......

    uj5u.com 2023-04-19 09:19:04 more
  • Linux學習筆記

    IP地址和主機名 IP地址 ifconfig可以用來查詢本機的IP地址，如果不能使用，可以通過install net-tools安裝。 Centos系統下ens33表示主網卡；inet后表示IP地址；lo表示本地回環網卡； 127.0.0.1表示代指本機；0.0.0.0可以用于代指本機，同時在放行設 ......

    uj5u.com 2023-04-18 06:52:01 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題：專案麒麟系統服務器的kdump服務無法啟動，沒有相關日志無法定位問題。 1、查看服務狀態是關閉的，重啟系統也無法啟動 systemctl status kdump 2、修改grub引數，修改“crashkernel”為“512M（有的機器數值太大太小都會導致報錯，建議從128M開始試，或者加個 ......

    uj5u.com 2023-04-12 09:59:50 more
  • 解決linux系統的kdump服務無法啟動的問題

    問題：專案麒麟系統服務器的kdump服務無法啟動，沒有相關日志無法定位問題。 1、查看服務狀態是關閉的，重啟系統也無法啟動 systemctl status kdump 2、修改grub引數，修改“crashkernel”為“512M（有的機器數值太大太小都會導致報錯，建議從128M開始試，或者加個 ......

    uj5u.com 2023-04-12 09:59:01 more
  • 你是不是暴露了？

    作者：袁首京 原創文章，轉載時請保留此宣告，并給出原文連接。 如果您是計算機相關從業人員，那么應該經歷不止一次網路安全專項檢查了，你肯定是收到過資訊系統技術檢測報告，要求你加強風險監測，確保你提供的系統服務堅實可靠了。 沒檢測到問題還好，檢測到問題的話，有些處理起來還是挺麻煩的，尤其是線上正在運行的 ......

    uj5u.com 2023-04-05 16:52:56 more
  • 細節拉滿，80 張圖帶你一步一步推演 slab 記憶體池的設計與實作

    1. 前文回顧 在之前的幾篇記憶體管理系列文章中，筆者帶大家從宏觀角度完整地梳理了一遍 Linux 記憶體分配的整個鏈路，本文的主題依然是記憶體分配，這一次我們會從微觀的角度來探秘一下 Linux 內核中用于零散小記憶體塊分配的記憶體池 —— slab 分配器。 在本小節中，筆者還是按照以往的風格先帶大家簡單 ......

    uj5u.com 2023-04-05 16:44:11 more

Copyright © 2010-2020 有解無憂