八、kubernetes Pod控制器
生活随笔
收集整理的這篇文章主要介紹了
八、kubernetes Pod控制器
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
Pod 控制器
文章目錄
- Pod 控制器
- 1. ReplicaSet(RS)
- 2. Deployment(Deploy)
- 3. Horizontal Pod Autoscaler(HPA)
- 4. DaemonSet(DS)
- 5. Job
- 6. CronJob(CJ)
Pod是kubernetes的最小管理單元，在kubernetes中，按照pod的創建方式可以將其分為兩類：
-
自主式pod：kubernetes直接創建出來的Pod，這種pod刪除后就沒有了，也不會重建
-
控制器創建的pod：kubernetes通過控制器創建的pod，這種pod刪除了之后還會自動重建
什么是Pod控制器
? Pod控制器是管理pod的中間層，使用Pod控制器之后，只需要告訴Pod控制器，想要多少個什么樣的Pod就可以了，它會創建出滿足條件的Pod并確保每一個Pod資源處于用戶期望的目標狀態。如果Pod資源在運行中出現故障，它會基于指定策略重新編排Pod。
在kubernetes中，有很多類型的pod控制器，每種都有自己的適合的場景，常見的有下面這些：
-
ReplicationController：比較原始的pod控制器，已經被廢棄，由ReplicaSet替代
-
ReplicaSet：保證副本數量一直維持在期望值，并支持pod數量擴縮容，鏡像版本升級
-
Deployment：通過控制ReplicaSet來控制Pod，并支持滾動升級、回退版本
-
Horizontal Pod Autoscaler：可以根據集群負載自動水平調整Pod的數量，實現削峰填谷
-
DaemonSet：在集群中的指定Node上運行且僅運行一個副本，一般用于守護進程類的任務
-
Job：它創建出來的pod只要完成任務就立即退出，不需要重啟或重建，用于執行一次性任務
-
Cronjob：它創建的Pod負責周期性任務控制，不需要持續后臺運行
-
StatefulSet：管理有狀態應用
1. ReplicaSet(RS)
ReplicaSet的主要作用是保證一定數量的pod正常運行，它會持續監聽這些Pod的運行狀態，一旦Pod發生故障，就會重啟或重建。同時它還支持對pod數量的擴縮容和鏡像版本的升降級。
ReplicaSet的資源清單文件：
在這里面，需要新了解的配置項就是spec下面幾個選項：
-
replicas：指定副本數量，其實就是當前rs創建出來的pod的數量，默認為1
-
selector：選擇器，它的作用是建立pod控制器和pod之間的關聯關系，采用的Label Selector機制，在pod模板上定義label，在控制器上定義選擇器，就可以表明當前控制器能管理哪些pod了
-
template：模板，就是當前控制器創建pod所使用的模板板，里面其實就是前一章學過的pod的定義
創建ReplicaSet
創建pc-replicaset.yaml文件，內容如下：
apiVersion: apps/v1 kind: ReplicaSet metadata:name: pc-replicasetnamespace: dev spec:replicas: 3selector: matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1 # 創建rs [root@master ~]# kubectl create -f pc-replicaset.yaml replicaset.apps/pc-replicaset created# 查看rs # DESIRED:期望副本數量 # CURRENT:當前副本數量 # READY:已經準備好提供服務的副本數量 [root@master ~]# kubectl get rs pc-replicaset -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR pc-replicaset 3 3 3 22s nginx nginx:1.17.1 app=nginx-pod# 查看當前控制器創建出來的pod # 這里發現控制器創建出來的pod的名稱是在控制器名稱后面拼接了-xxxxx隨機碼 [root@master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 1/1 Running 0 54s pc-replicaset-fmb8f 1/1 Running 0 54s pc-replicaset-snrk2 1/1 Running 0 54s擴縮容
# 編輯rs的副本數量，修改spec:replicas: 6即可 [root@master ~]# kubectl edit rs pc-replicaset -n dev replicaset.apps/pc-replicaset edited# 查看pod [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 1/1 Running 0 114m pc-replicaset-cftnp 1/1 Running 0 10s pc-replicaset-fjlm6 1/1 Running 0 10s pc-replicaset-fmb8f 1/1 Running 0 114m pc-replicaset-s2whj 1/1 Running 0 10s pc-replicaset-snrk2 1/1 Running 0 114m# 當然也可以直接使用命令實現 # 使用scale命令實現擴縮容， 后面--replicas=n直接指定目標數量即可 [root@master ~]# kubectl scale rs pc-replicaset --replicas=2 -n dev replicaset.apps/pc-replicaset scaled# 命令運行完畢，立即查看，發現已經有4個開始準備退出了 [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 0/1 Terminating 0 118m pc-replicaset-cftnp 0/1 Terminating 0 4m17s pc-replicaset-fjlm6 0/1 Terminating 0 4m17s pc-replicaset-fmb8f 1/1 Running 0 118m pc-replicaset-s2whj 0/1 Terminating 0 4m17s pc-replicaset-snrk2 1/1 Running 0 118m#稍等片刻，就只剩下2個了 [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-fmb8f 1/1 Running 0 119m pc-replicaset-snrk2 1/1 Running 0 119m鏡像升級
# 編輯rs的容器鏡像 - image: nginx:1.17.2 [root@master ~]# kubectl edit rs pc-replicaset -n dev replicaset.apps/pc-replicaset edited# 再次查看，發現鏡像版本已經變更了 [root@master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES ... pc-replicaset 2 2 2 140m nginx nginx:1.17.2 ...# 同樣的道理，也可以使用命令完成這個工作 # kubectl set image rs rs名稱 容器=鏡像版本 -n namespace [root@master ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev replicaset.apps/pc-replicaset image updated# 再次查看，發現鏡像版本已經變更了 [root@master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES ... pc-replicaset 2 2 2 145m nginx nginx:1.17.1 ...刪除ReplicaSet
# 使用kubectl delete命令會刪除此RS以及它管理的Pod # 在kubernetes刪除RS前，會將RS的replicasclear調整為0，等待所有的Pod被刪除后，在執行RS對象的刪除 [root@master ~]# kubectl delete rs pc-replicaset -n dev replicaset.apps "pc-replicaset" deleted [root@master ~]# kubectl get pod -n dev -o wide No resources found in dev namespace.# 如果希望僅僅刪除RS對象（保留Pod），可以使用kubectl delete命令時添加--cascade=false選項（不推薦）。 [root@master ~]# kubectl delete rs pc-replicaset -n dev --cascade=false replicaset.apps "pc-replicaset" deleted [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-cl82j 1/1 Running 0 75s pc-replicaset-dslhb 1/1 Running 0 75s# 也可以使用yaml直接刪除(推薦) [root@master ~]# kubectl delete -f pc-replicaset.yaml replicaset.apps "pc-replicaset" deleted2. Deployment(Deploy)
為了更好的解決服務編排的問題，kubernetes在V1.2版本開始，引入了Deployment控制器。值得一提的是，這種控制器并不直接管理pod，而是通過管理ReplicaSet來簡介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加強大。
Deployment主要功能有下面幾個：
- 支持ReplicaSet的所有功能
- 支持發布的停止、繼續
- 支持滾動升級和回滾版本
Deployment的資源清單文件：
apiVersion: apps/v1 # 版本號 kind: Deployment # 類型 metadata: # 元數據name: # rs名稱 namespace: # 所屬命名空間 labels: #標簽controller: deploy spec: # 詳情描述replicas: 3 # 副本數量revisionHistoryLimit: 3 # 保留歷史版本paused: false # 暫停部署，默認是falseprogressDeadlineSeconds: 600 # 部署超時時間（s），默認是600strategy: # 策略type: RollingUpdate # 滾動更新策略rollingUpdate: # 滾動更新maxSurge: 30% # 最大額外可以存在的副本數，可以為百分比，也可以為整數maxUnavailable: 30% # 最大不可用狀態的 Pod 的最大值，可以為百分比，也可以為整數selector: # 選擇器，通過它指定該控制器管理哪些podmatchLabels: # Labels匹配規則app: nginx-podmatchExpressions: # Expressions匹配規則- {key: app, operator: In, values: [nginx-pod]}template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80創建deployment
創建pc-deployment.yaml，內容如下：
apiVersion: apps/v1 kind: Deployment metadata:name: pc-deploymentnamespace: dev spec: replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1 # 創建deployment [root@master ~]# kubectl create -f pc-deployment.yaml --record=true deployment.apps/pc-deployment created# 查看deployment # UP-TO-DATE 最新版本的pod的數量 # AVAILABLE 當前可用的pod的數量 [root@master ~]# kubectl get deploy pc-deployment -n dev NAME READY UP-TO-DATE AVAILABLE AGE pc-deployment 3/3 3 3 15s# 查看rs # 發現rs的名稱是在原來deployment的名字后面添加了一個10位數的隨機串 [root@master ~]# kubectl get rs -n dev NAME DESIRED CURRENT READY AGE pc-deployment-6696798b78 3 3 3 23s# 查看pod [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-deployment-6696798b78-d2c8n 1/1 Running 0 107s pc-deployment-6696798b78-smpvp 1/1 Running 0 107s pc-deployment-6696798b78-wvjd8 1/1 Running 0 107s擴縮容
# 變更副本數量為5個 [root@master ~]# kubectl scale deploy pc-deployment --replicas=5 -n dev deployment.apps/pc-deployment scaled# 查看deployment [root@master ~]# kubectl get deploy pc-deployment -n dev NAME READY UP-TO-DATE AVAILABLE AGE pc-deployment 5/5 5 5 2m# 查看pod [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-deployment-6696798b78-d2c8n 1/1 Running 0 4m19s pc-deployment-6696798b78-jxmdq 1/1 Running 0 94s pc-deployment-6696798b78-mktqv 1/1 Running 0 93s pc-deployment-6696798b78-smpvp 1/1 Running 0 4m19s pc-deployment-6696798b78-wvjd8 1/1 Running 0 4m19s# 編輯deployment的副本數量，修改spec:replicas: 4即可 [root@master ~]# kubectl edit deploy pc-deployment -n dev deployment.apps/pc-deployment edited# 查看pod [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-deployment-6696798b78-d2c8n 1/1 Running 0 5m23s pc-deployment-6696798b78-jxmdq 1/1 Running 0 2m38s pc-deployment-6696798b78-smpvp 1/1 Running 0 5m23s pc-deployment-6696798b78-wvjd8 1/1 Running 0 5m23s鏡像更新
deployment支持兩種更新策略:重建更新和滾動更新,可以通過strategy指定策略類型,支持兩個屬性:
strategy：指定新的Pod替換舊的Pod的策略， 支持兩個屬性：type：指定策略類型，支持兩種策略Recreate：在創建出新的Pod之前會先殺掉所有已存在的PodRollingUpdate：滾動更新，就是殺死一部分，就啟動一部分，在更新過程中，存在兩個版本PodrollingUpdate：當type為RollingUpdate時生效，用于為RollingUpdate設置參數，支持兩個屬性：maxUnavailable：用來指定在升級過程中不可用Pod的最大數量，默認為25%。maxSurge： 用來指定在升級過程中可以超過期望的Pod的最大數量，默認為25%。重建更新
編輯pc-deployment.yaml,在spec節點下添加更新策略
spec:strategy: # 策略type: Recreate # 重建更新創建deploy進行驗證
# 變更鏡像 [root@master ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev deployment.apps/pc-deployment image updated# 觀察升級過程 [root@master ~]# kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE pc-deployment-5d89bdfbf9-65qcw 1/1 Running 0 31s pc-deployment-5d89bdfbf9-w5nzv 1/1 Running 0 31s pc-deployment-5d89bdfbf9-xpt7w 1/1 Running 0 31spc-deployment-5d89bdfbf9-xpt7w 1/1 Terminating 0 41s pc-deployment-5d89bdfbf9-65qcw 1/1 Terminating 0 41s pc-deployment-5d89bdfbf9-w5nzv 1/1 Terminating 0 41spc-deployment-675d469f8b-grn8z 0/1 Pending 0 0s pc-deployment-675d469f8b-hbl4v 0/1 Pending 0 0s pc-deployment-675d469f8b-67nz2 0/1 Pending 0 0spc-deployment-675d469f8b-grn8z 0/1 ContainerCreating 0 0s pc-deployment-675d469f8b-hbl4v 0/1 ContainerCreating 0 0s pc-deployment-675d469f8b-67nz2 0/1 ContainerCreating 0 0spc-deployment-675d469f8b-grn8z 1/1 Running 0 1s pc-deployment-675d469f8b-67nz2 1/1 Running 0 1s pc-deployment-675d469f8b-hbl4v 1/1 Running 0 2s滾動更新
編輯pc-deployment.yaml，在spec節點下添加更新策略
spec:strategy: # 策略type: RollingUpdate # 滾動更新策略rollingUpdate:maxSurge: 25% maxUnavailable: 25%創建deploy進行驗證
滾動更新的過程：
鏡像更新中rs的變化:
版本回退
deployment支持版本升級過程中的暫停、繼續功能以及版本回退等諸多功能，下面具體來看.
kubectl rollout： 版本升級相關功能，支持下面的選項：
-
status 顯示當前升級狀態
-
history 顯示 升級歷史記錄
-
pause 暫停版本升級過程
-
resume 繼續已經暫停的版本升級過程
-
restart 重啟版本升級過程
-
undo 回滾到上一級版本（可以使用–to-revision回滾到指定版本）
金絲雀發布
Deployment控制器支持控制更新過程中的控制，如“暫停(pause)”或“繼續(resume)”更新操作。
? 比如有一批新的Pod資源創建完成后立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應用，繼續觀察能否穩定地按期望的方式運行。確定沒問題之后再繼續完成余下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發布。
# 更新deployment的版本，并配置暫停deployment [root@master ~]# kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev deployment.apps/pc-deployment image updated deployment.apps/pc-deployment paused#觀察更新狀態 [root@master ~]# kubectl rollout status deploy pc-deployment -n dev Waiting for deployment "pc-deployment" rollout to finish: 2 out of 4 new replicas have been updated...# 監控更新的過程，可以看到已經新增了一個資源，但是并未按照預期的狀態去刪除一個舊的資源，就是因為使用了pause暫停命令[root@master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 3 3 3 19m nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 14m nginx nginx:1.17.2 pc-deployment-6c9f56fcfb 2 2 2 3m16s nginx nginx:1.17.4 [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-deployment-5d89bdfbf9-rj8sq 1/1 Running 0 7m33s pc-deployment-5d89bdfbf9-ttwgg 1/1 Running 0 7m35s pc-deployment-5d89bdfbf9-v4wvc 1/1 Running 0 7m34s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 3m31s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 3m31s# 確保更新的pod沒問題了，繼續更新 [root@master ~]# kubectl rollout resume deploy pc-deployment -n dev deployment.apps/pc-deployment resumed# 查看最后的更新情況 [root@master ~]# kubectl get rs -n dev -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES pc-deployment-5d89bdfbf9 0 0 0 21m nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 16m nginx nginx:1.17.2 pc-deployment-6c9f56fcfb 4 4 4 5m11s nginx nginx:1.17.4 [root@master ~]# kubectl get pods -n dev NAME READY STATUS RESTARTS AGE pc-deployment-6c9f56fcfb-7bfwh 1/1 Running 0 37s pc-deployment-6c9f56fcfb-996rt 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-j2gtj 1/1 Running 0 5m27s pc-deployment-6c9f56fcfb-rf84v 1/1 Running 0 37s刪除Deployment
# 刪除deployment，其下的rs和pod也將被刪除 [root@master ~]# kubectl delete -f pc-deployment.yaml deployment.apps "pc-deployment" deleted3. Horizontal Pod Autoscaler(HPA)
在前面的內容中，我們已經可以實現通過手工執行kubectl scale命令實現Pod擴容或縮容，但是這顯然不符合Kubernetes的定位目標–自動化、智能化。 Kubernetes期望可以實現通過監測Pod的使用情況，實現pod數量的自動調整，于是就產生了Horizontal Pod Autoscaler（HPA）這種控制器。
? HPA可以獲取每個Pod利用率，然后和HPA中定義的指標進行對比，同時計算出需要伸縮的具體值，最后實現Pod的數量的調整。其實HPA與之前的Deployment一樣，也屬于一種Kubernetes資源對象，它通過追蹤分析RC控制的所有目標Pod的負載變化情況，來確定是否需要針對性地調整目標Pod的副本數，這是HPA的實現原理。
接下來，我們來做一個實驗
1 安裝metrics-server
metrics-server可以用來收集集群中的資源使用情況
# 安裝git [root@master ~]# yum install git -y # 獲取metrics-server, 注意使用的版本 [root@master ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server # 修改deployment, 注意修改的是鏡像和初始化參數 [root@master ~]# cd /root/metrics-server/deploy/1.8+/ [root@master 1.8+]# vim metrics-server-deployment.yaml 按圖中添加下面選項 hostNetwork: true image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6 args: - --kubelet-insecure-tls - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP # 安裝metrics-server [root@master 1.8+]# kubectl apply -f ./# 查看pod運行情況 [root@master 1.8+]# kubectl get pod -n kube-system metrics-server-6b976979db-2xwbj 1/1 Running 0 90s# 使用kubectl top node 查看資源使用情況 [root@master 1.8+]# kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% master 98m 4% 1067Mi 62% node1 27m 1% 727Mi 42% node2 34m 1% 800Mi 46% [root@master 1.8+]# kubectl top pod -n kube-system NAME CPU(cores) MEMORY(bytes) coredns-6955765f44-7ptsb 3m 9Mi coredns-6955765f44-vcwr5 3m 8Mi etcd-master 14m 145Mi ... # 至此,metrics-server安裝完成2 準備deployment和servie
為了操作簡單,直接使用命令
# 創建deployment [root@master 1.8+]# kubectl run nginx --image=nginx:latest --requests=cpu=100m -n dev # 創建service [root@master 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev# 查看 [root@master 1.8+]# kubectl get deployment,pod,svc -n dev NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx 1/1 1 1 47sNAME READY STATUS RESTARTS AGE pod/nginx-7df9756ccc-bh8dr 1/1 Running 0 47sNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx NodePort 10.109.57.248 <none> 80:31136/TCP 35s3 部署HPA
創建pc-hpa.yaml
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata:name: pc-hpanamespace: dev spec:minReplicas: 1 #最小pod數量maxReplicas: 10 #最大pod數量targetCPUUtilizationPercentage: 3 # CPU使用率指標scaleTargetRef: # 指定要控制的nginx信息apiVersion: apps/v1kind: Deployment name: nginx # 創建hpa [root@master 1.8+]# kubectl create -f pc-hpa.yaml horizontalpodautoscaler.autoscaling/pc-hpa created# 查看hpa [root@master 1.8+]# kubectl get hpa -n dev NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE pc-hpa Deployment/nginx 0%/3% 1 10 1 62s4 測試
使用壓測工具對service地址192.168.109.100:31136進行壓測，然后通過控制臺查看hpa和pod的變化
hpa變化
[root@master ~]# kubectl get hpa -n dev -w NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE pc-hpa Deployment/nginx 0%/3% 1 10 1 4m11s pc-hpa Deployment/nginx 0%/3% 1 10 1 5m19s pc-hpa Deployment/nginx 22%/3% 1 10 1 6m50s pc-hpa Deployment/nginx 22%/3% 1 10 4 7m5s pc-hpa Deployment/nginx 22%/3% 1 10 8 7m21s pc-hpa Deployment/nginx 6%/3% 1 10 8 7m51s pc-hpa Deployment/nginx 0%/3% 1 10 8 9m6s pc-hpa Deployment/nginx 0%/3% 1 10 8 13m pc-hpa Deployment/nginx 0%/3% 1 10 1 14mdeployment變化
[root@master ~]# kubectl get deployment -n dev -w NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 11m nginx 1/4 1 1 13m nginx 1/4 1 1 13m nginx 1/4 1 1 13m nginx 1/4 4 1 13m nginx 1/8 4 1 14m nginx 1/8 4 1 14m nginx 1/8 4 1 14m nginx 1/8 8 1 14m nginx 2/8 8 2 14m nginx 3/8 8 3 14m nginx 4/8 8 4 14m nginx 5/8 8 5 14m nginx 6/8 8 6 14m nginx 7/8 8 7 14m nginx 8/8 8 8 15m nginx 8/1 8 8 20m nginx 8/1 8 8 20m nginx 1/1 1 1 20mpod變化
[root@master ~]# kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE nginx-7df9756ccc-bh8dr 1/1 Running 0 11m nginx-7df9756ccc-cpgrv 0/1 Pending 0 0s nginx-7df9756ccc-8zhwk 0/1 Pending 0 0s nginx-7df9756ccc-rr9bn 0/1 Pending 0 0s nginx-7df9756ccc-cpgrv 0/1 ContainerCreating 0 0s nginx-7df9756ccc-8zhwk 0/1 ContainerCreating 0 0s nginx-7df9756ccc-rr9bn 0/1 ContainerCreating 0 0s nginx-7df9756ccc-m9gsj 0/1 Pending 0 0s nginx-7df9756ccc-g56qb 0/1 Pending 0 0s nginx-7df9756ccc-sl9c6 0/1 Pending 0 0s nginx-7df9756ccc-fgst7 0/1 Pending 0 0s nginx-7df9756ccc-g56qb 0/1 ContainerCreating 0 0s nginx-7df9756ccc-m9gsj 0/1 ContainerCreating 0 0s nginx-7df9756ccc-sl9c6 0/1 ContainerCreating 0 0s nginx-7df9756ccc-fgst7 0/1 ContainerCreating 0 0s nginx-7df9756ccc-8zhwk 1/1 Running 0 19s nginx-7df9756ccc-rr9bn 1/1 Running 0 30s nginx-7df9756ccc-m9gsj 1/1 Running 0 21s nginx-7df9756ccc-cpgrv 1/1 Running 0 47s nginx-7df9756ccc-sl9c6 1/1 Running 0 33s nginx-7df9756ccc-g56qb 1/1 Running 0 48s nginx-7df9756ccc-fgst7 1/1 Running 0 66s nginx-7df9756ccc-fgst7 1/1 Terminating 0 6m50s nginx-7df9756ccc-8zhwk 1/1 Terminating 0 7m5s nginx-7df9756ccc-cpgrv 1/1 Terminating 0 7m5s nginx-7df9756ccc-g56qb 1/1 Terminating 0 6m50s nginx-7df9756ccc-rr9bn 1/1 Terminating 0 7m5s nginx-7df9756ccc-m9gsj 1/1 Terminating 0 6m50s nginx-7df9756ccc-sl9c6 1/1 Terminating 0 6m50s4. DaemonSet(DS)
DaemonSet類型的控制器可以保證在集群中的每一臺（或指定）節點上都運行一個副本。一般適用于日志收集、節點監控等場景。也就是說，如果一個Pod提供的功能是節點級別的（每個節點都需要且只需要一個），那么這類Pod就適合使用DaemonSet類型的控制器創建。
DaemonSet控制器的特點：
- 每當向集群中添加一個節點時，指定的 Pod 副本也將添加到該節點上
- 當節點從集群中移除時，Pod 也就被垃圾回收了
下面先來看下DaemonSet的資源清單文件
apiVersion: apps/v1 # 版本號 kind: DaemonSet # 類型 metadata: # 元數據name: # rs名稱 namespace: # 所屬命名空間 labels: #標簽controller: daemonset spec: # 詳情描述revisionHistoryLimit: 3 # 保留歷史版本updateStrategy: # 更新策略type: RollingUpdate # 滾動更新策略rollingUpdate: # 滾動更新maxUnavailable: 1 # 最大不可用狀態的 Pod 的最大值，可以為百分比，也可以為整數selector: # 選擇器，通過它指定該控制器管理哪些podmatchLabels: # Labels匹配規則app: nginx-podmatchExpressions: # Expressions匹配規則- {key: app, operator: In, values: [nginx-pod]}template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80創建pc-daemonset.yaml，內容如下：
apiVersion: apps/v1 kind: DaemonSet metadata:name: pc-daemonsetnamespace: dev spec: selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1 # 創建daemonset [root@master ~]# kubectl create -f pc-daemonset.yaml daemonset.apps/pc-daemonset created# 查看daemonset [root@master ~]# kubectl get ds -n dev -o wide NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES pc-daemonset 2 2 2 2 2 24s nginx nginx:1.17.1 # 查看pod,發現在每個Node上都運行一個pod [root@master ~]# kubectl get pods -n dev -o wide NAME READY STATUS RESTARTS AGE IP NODE pc-daemonset-9bck8 1/1 Running 0 37s 10.244.1.43 node1 pc-daemonset-k224w 1/1 Running 0 37s 10.244.2.74 node2 # 刪除daemonset [root@master ~]# kubectl delete -f pc-daemonset.yaml daemonset.apps "pc-daemonset" deleted5. Job
Job，主要用于負責批量處理(一次要處理指定數量任務)短暫的一次性(每個任務僅運行一次就結束)任務。Job特點如下：
- 當Job創建的pod執行成功結束時，Job將記錄成功結束的pod數量
- 當成功結束的pod達到指定的數量時，Job將完成執行
Job的資源清單文件：
創建pc-job.yaml，內容如下：
apiVersion: batch/v1 kind: Job metadata:name: pc-jobnamespace: dev spec:manualSelector: trueselector:matchLabels:app: counter-podtemplate:metadata:labels:app: counter-podspec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"] # 創建job [root@master ~]# kubectl create -f pc-job.yaml job.batch/pc-job created# 查看job [root@master ~]# kubectl get job -n dev -o wide -w NAME COMPLETIONS DURATION AGE CONTAINERS IMAGES SELECTOR pc-job 0/1 21s 21s counter busybox:1.30 app=counter-pod pc-job 1/1 31s 79s counter busybox:1.30 app=counter-pod# 通過觀察pod狀態可以看到，pod在運行完畢任務后，就會變成Completed狀態 [root@master ~]# kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE pc-job-rxg96 1/1 Running 0 29s pc-job-rxg96 0/1 Completed 0 33s# 接下來，調整下pod運行的總數量和并行數量 即：在spec下設置下面兩個選項 # completions: 6 # 指定job需要成功運行Pods的次數為6 # parallelism: 3 # 指定job并發運行Pods的數量為3 # 然后重新運行job，觀察效果，此時會發現，job會每次運行3個pod，總共執行了6個pod [root@master ~]# kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE pc-job-684ft 1/1 Running 0 5s pc-job-jhj49 1/1 Running 0 5s pc-job-pfcvh 1/1 Running 0 5s pc-job-684ft 0/1 Completed 0 11s pc-job-v7rhr 0/1 Pending 0 0s pc-job-v7rhr 0/1 Pending 0 0s pc-job-v7rhr 0/1 ContainerCreating 0 0s pc-job-jhj49 0/1 Completed 0 11s pc-job-fhwf7 0/1 Pending 0 0s pc-job-fhwf7 0/1 Pending 0 0s pc-job-pfcvh 0/1 Completed 0 11s pc-job-5vg2j 0/1 Pending 0 0s pc-job-fhwf7 0/1 ContainerCreating 0 0s pc-job-5vg2j 0/1 Pending 0 0s pc-job-5vg2j 0/1 ContainerCreating 0 0s pc-job-fhwf7 1/1 Running 0 2s pc-job-v7rhr 1/1 Running 0 2s pc-job-5vg2j 1/1 Running 0 3s pc-job-fhwf7 0/1 Completed 0 12s pc-job-v7rhr 0/1 Completed 0 12s pc-job-5vg2j 0/1 Completed 0 12s# 刪除job [root@master ~]# kubectl delete -f pc-job.yaml job.batch "pc-job" deleted6. CronJob(CJ)
CronJob控制器以Job控制器資源為其管控對象，并借助它管理pod資源對象，Job控制器定義的作業任務在其控制器資源創建之后便會立即執行，但CronJob可以以類似于Linux操作系統的周期性任務作業計劃的方式控制其運行時間點及重復運行的方式。也就是說，CronJob可以在特定的時間點(反復的)去運行job任務。
CronJob的資源清單文件：
創建pc-cronjob.yaml，內容如下：
apiVersion: batch/v1beta1 kind: CronJob metadata:name: pc-cronjobnamespace: devlabels:controller: cronjob spec:schedule: "*/1 * * * *"jobTemplate:metadata:spec:template:spec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"] # 創建cronjob [root@master ~]# kubectl create -f pc-cronjob.yaml cronjob.batch/pc-cronjob created# 查看cronjob [root@master ~]# kubectl get cronjobs -n dev NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE pc-cronjob */1 * * * * False 0 <none> 6s# 查看job [root@master ~]# kubectl get jobs -n dev NAME COMPLETIONS DURATION AGE pc-cronjob-1592587800 1/1 28s 3m26s pc-cronjob-1592587860 1/1 28s 2m26s pc-cronjob-1592587920 1/1 28s 86s# 查看pod [root@master ~]# kubectl get pods -n dev pc-cronjob-1592587800-x4tsm 0/1 Completed 0 2m24s pc-cronjob-1592587860-r5gv4 0/1 Completed 0 84s pc-cronjob-1592587920-9dxxq 1/1 Running 0 24s# 刪除cronjob [root@master ~]# kubectl delete -f pc-cronjob.yaml cronjob.batch "pc-cronjob" deleted總結
以上是生活随笔為你收集整理的八、kubernetes Pod控制器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android开发技术周报 Issue#
- 下一篇： Golang 高效编程 godoc 包注