Kubernetes学习(六)—— Pod控制器
生活随笔
收集整理的這篇文章主要介紹了
Kubernetes学习(六)—— Pod控制器
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
本章節主要介紹常用的Pod控制器。
1. Pod控制器介紹
在kubernetes中，按照pod的創建安方式可以將其分為兩類：
- 自主式pod：kubernetes直接創建出來的pod，這種pod刪除后就沒有了，也不會重建
- 控制器創建的pod：通過控制器創建的pod，這種pod刪除了之后還會自動重建
什么是Pod控制器
Pod控制器是管理pod的中間層，使用了pod控制器之后，我們只需要告訴pod控制器，想要多少個什么樣的pod就可以了，它就會創建出滿足條件的pod并確保每個pod處于用戶期望的狀態，如果pod在運行中出現故障，控制器會基于指定策略重啟動或者重建pod。
在kubernetes中，有很多類型的pod控制器，每種都有自己的適合的場景，常見的有下面這些：
- ReplicationController：比較原始的pod控制器，已經被廢棄，由ReplicaSet替代
- ReplicaSet：保證指定數量的pod運行，并支持pod數量變更，鏡像版本變更
- Depployment：通過控制ReplicaSet來控制pod，并支持滾動升級、版本回退
- Horizontal Pod AutoScaler：可以根據集群負載自動調整Pod的數量，熟悉愛你削峰填谷
- DaemonSet：在集群中的指定Node上運行一個副本，一般用于守護進程類的任務
- Job：它創建出來的pod只要完成任務就立即退出，用于執行一次性任務
- Cronjob：他創建的pod會周期性的執行，用于執行周期任務
2. ReplicaSet
ReplicaSet的主要作用是保證一定數量的pod能夠正常運行，它會持續監聽這些pod的運行狀態，一旦pod發生故障，就會重啟或重建。同時它還支持對pod數量的擴縮容和版本鏡像的升級。
ReplicaSet的資源清單文件：
apiVersion: v1 kind: ReplicaSet # 類型 metadata: # name: # rs名稱namespace: # 所屬命名空間labels: # 標簽controller: rs spec: # 詳情描述replicas: 3 # 副本數量selector: # 選擇器，通過它指定該控制器管理那些podmatchLabels: # Labels匹配規則app: nginx-podmatchExpressions: # Expression匹配規則- {key: app, operator: In, values: [nginx-pod]}template: # 模本，當副本數量不足時，會根據下面的模板創建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80在這里面，需要新了解的配置項即使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 CORRENT READY AGE CONTAINERS IMAGES SELECTOR pc-replicaset 3 3 3 22s nginx nginx:1.17.1 app=nginx-pod# 查看當前控制器創建出來的pod # 這里發現控制器創建出來的pod的名稱是在控制器名稱后面拼接了-xxxx隨機碼 [root@master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 1/1 Running 0 54s pc-replicaset-fm8f 1/1 Running 0 54s pc-replicaset-snrk 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 pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 1/1 Running 0 114s pc-replicaset-cftnp 1/1 Running 0 10s pc-replicaset-fjlm6 1/1 Running 0 10s pc-replicaset-fmb8f 1/1 Running 0 114s pc-replicaset-s2whj 1/1 Running 0 10s pc-replicaset-snrk2 1/1 Running 0 114s# 當然也可以直接使用命令實現 # 使用scale命令實現擴縮容，后面--replias=n直接指定目標數量即可 [root@master ~]# kubectl scale rs pc-replicaset --replicas=2 -n dev replicaset.apps/pc-replicaset scale# 命令運行完畢，立即查看，發現已經有4個開始準備退出了 [root@master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-6vmvt 0/1 Terminatin 0 118s pc-replicaset-cftnp 0/1 Terminatin 0 4m17 pc-replicaset-fjlm6 0/1 Terminatin 0 4m17 pc-replicaset-fmb8f 1/1 Running 0 118s pc-replicaset-s2whj 0/1 Terminatin 0 4m17 pc-replicaset-snrk2 1/1 Running 0 118s# 稍等片刻，就只剩下2個了 [root@master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-replicaset-fmb8f 1/1 Running 0 119s pc-replicaset-snrk2 1/1 Running 0 119s鏡像升級
# 編輯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 CORRENT 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# 再次查看，發現鏡像版本已經變更了 [root@master ~]# kubectl get rs pc-replicaset -n dev -o wide NAME DESIRED CORRENT READY AGE CONTAINERS IMAGES pc-replicaset 2 2 2 145m nginx nginx:1.17.1刪除ReplicaSet
# 使用kubectl delete命令會刪除此RS以及它管理的pod # 在kubernetes刪除RS前，會將RS的replicascalear調整為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-fslhb 1/1 Running 0 75s# 也可以使用yaml直接刪除(推薦) [root@master ~]# kubectl delete -f pc-replicaset.yaml replicaset.apps "pc-replicaset" deleted3. Deployment
為了更好的解決服務編排的問題，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 # 保留歷史版本，默認為是10pause: false # 暫停部署，默認是falseprogressDeadlineSeconds: 600 # 部署超時時間(s),默認是600strategy: # 策略type: RollingUpdate # 滾動更新策略rollingUpdate: # 滾動更新maxSurge: 30% # 最大額外可以存在的副本數，可以為百分比，也可以為整數maxUnavailable: 30% # 最大不可用狀態的Pod的最大值，可以為百分比，也可以為整數selector: # 選擇器，通過他指定該控制器管理哪些PodmatchLabels: # Labels匹配規則app: nginx-poxmatchExpressions: # 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 # --record=true 記錄每次的版本變化 # 創建rs [root@master ~]# kubectl create -f pc-deployment.yaml replicaset.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 pod -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 replicaset.apps/pc-deployment scale# 查看deployment [root@master ~]# kubectl get deploy pc-deployment -n dev NAME READY UP-TO-DATE AVAILABLE AGE pc-deployment 5/5 5 5 15s# 查看pod [root@master ~]# kubectl get pod -n dev NAME READY STATUS RESTARTS AGE pc-deployment-6696798B78-d2c8n 1/1 Running 0 107s 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 107s pc-deployment-6696798B78-wvjd8 1/1 Running 0 107s# 編輯deployment的副本數量，修改spec:replicas: 4 即可 [root@master ~]# kubectl edit deploy pc-deployment -n dev replicaset.apps/pc-deployment edited# 查看pod [root@master ~]# kubectl get pod -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%重建更新
1）編輯pc-deployment.yaml,在spec節點下添加更新策略
spec: strategy: # 策略type: Recreate: # 重建更新策略2）創建deploy進行驗證
# 變更鏡像 [root@master ~]# kubectl set image deployment pc-deployment nginx-nginx:1.17.2 -n dev replicaset.apps/pc-deployment image updated# 觀察升級過程 [root@master ~]# kubectl get pods -n dev -w NAME READY STATUS RESTARTS AGE pc-deployment-5d89bdfbf9-cl82j 1/1 Running 0 78s pc-deployment-5d89bdfbf9-kkhr9 1/1 Running 0 78s pc-deployment-5d89bdfbf9-vznbl 1/1 Running 0 78spc-deployment-5d89bdfbf9-cl82j 1/1 Terminating 0 97s pc-deployment-5d89bdfbf9-vznbl 1/1 Terminating 0 97s pc-deployment-5d89bdfbf9-kkhr9 1/1 Terminating 0 97spc-deployment-5d89bdfbf9-g9f85 0/1 Pending 0 0s pc-deployment-5d89bdfbf9-qz48q 0/1 Pending 0 0s pc-deployment-5d89bdfbf9-9sw59 0/1 Pending 0 0spc-deployment-5d89bdfbf9-g9f85 0/1 ContainerCreating 0 0s pc-deployment-5d89bdfbf9-qz48q 0/1 ContainerCreating 0 0s pc-deployment-5d89bdfbf9-9sw59 0/1 ContainerCreating 0 0spc-deployment-5d89bdfbf9-g9f85 1/1 Running 0 2s pc-deployment-5d89bdfbf9-qz48q 1/1 Running 0 2s pc-deployment-5d89bdfbf9-9sw59 1/1 Running 0 28s滾動更新
滾動更新的過程
鏡像更新中rs的變化：
# 查看rs，發現原來的rs的依舊存在，只是pod數量變為了0，而后又新產生了一個rs，pod數量為4 # 其實就是deploymennt能夠進行版本回退的奧妙所在，后面會詳細解釋 [root@master ~]# kubectl get rs -n dev NAME DESIRED CURRENT READY AGE pc-deployment-5d89bdfbf9 0 0 0 11m pc-deployment-675d469f8b 0 0 0 10s pc-deployment-7865c58bdf 3 3 3 3m41s版本回退
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.18.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev deployment.apps/pc-deployment iamge 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 19s nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 14s 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-5d89bdfbf9-996rt 1/1 Running 0 3m31s pc-deployment-5d89bdfbf9-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 21s nginx nginx:1.17.1 pc-deployment-675d469f8b 0 0 0 16s 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-5d89bdfbf9-76fwh 1/1 Running 0 37s pc-deployment-5d89bdfbf9-996rt 1/1 Running 0 5m27s pc-deployment-5d89bdfbf9-j2gtj 1/1 Running 0 5m27s pc-deployment-5d89bdfbf9-rf84v 1/1 Running 0 37s刪除Deployment
# 刪除deployment,其下的rs和pod也將被刪除 [root@master ~]# kubectl delete -f pc-deployment.yaml deployment.app "pc-deployment" deleted4. Horizontal Pod AutoScaler(HPA)
在前面的課程中，我們可以通過手工執行kubectl scale命令實現Pod擴容，但是這顯然不符合Kubernetes的定位目標–自動化、智能化。Kubernetes期望可以通過檢測Pod的使用情況，實現pod數量的自動調整，于是就產生了HPA這種控制器。
HPA可以獲取每個pod利用率，然后和HPA中定義的指標進行對比，同時計算出需要伸縮的具體值，最后實現pod的數量的調整。其實HPA與之前的Deployment一樣，也屬于一種Kubernetes資源對象，它通過追蹤分析目標pod的負載變化情況，來確定是否需要針對性地調整目標pod的副本數。
1 安裝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.git # 修改deployment,注意修改的是鏡像和初始化參數 [root@master ~]# cd /root/metrics-server/deploy/1.8+/ [root@master 1.8+]# vim metrics-server-deployment.yaml #按照圖中添加如下選項 hostNetwork: true registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6 - --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 34 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 coredns-master 14m 145Mi ... # 至此，metrics-server安裝完成2 準備deployment和service
為了操作簡單，直接使用命令
# 創建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: Deploymentname: 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 NINPODS MAXPODS REPLICAS AGE pc-hpa Deployment/nginx 0%/3% 1 10 1 62s4 測試
使用壓測工具對service地址192.168.109.100:31136進行壓測，然后通過控制臺查看hps和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 13s pc-hpa Deployment/nginx 0%/3% 1 10 1 14sdeployment變化
[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 21m nginx-7df9756ccc-cpgrv 1/1 Running 0 47m nginx-7df9756ccc-sl9c6 1/1 Running 0 33m nginx-7df9756ccc-g56qb 1/1 Running 0 48m nginx-7df9756ccc-fgst7 1/1 Running 0 66m 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-q56gb 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 6m50s5. DaemonSet
DaemonSet類型的控制器可以保證集群中的每一臺（或指定）節點上都運行一個副本，一般適用于日志收集、節點監控等場景。也就是說，如果一個pod提供的功能是節點級別的（每個節點都需要且只需要一個），那么這類Pod就適合使用DaemonSet類型的控制器創建。
DaemonSet控制器的特點：
- 每當向集群中添加一個節點時，指定的pod副本也將添加到該節點上。
- 當節點從集群中移除時，pod也就被垃圾回收了
下面先來看下DaemonSet的資源清單文件
apiVersion: apps/v1 # 版本號 kind: DaemonSet # 類型 metadata: # 元數據name: pc-daemonSet # rs名稱labels: # 標簽controller: daemontset spec:revisionHistoryLimit: 3 # 保留歷史版本updateStrategy: # 更新策略type: RollingUpdate # 滾動更新策略rollingUpdate: # 滾動更新maxUnavailable: 1 # 最大不可用狀態的pod的最大值，可以為百分比，也可以為正數selector: # 選擇器，通過它指定該控制器管制哪些podmatchLabels: # Labels匹配規則app: nginx-podmatchExpressions: # Expression匹配規則- {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 # 創建daemontset [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-daemont 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-daemontset" deleted6. Job
Job主要用于負責批量處理短暫的一次性任務。Job的特點如下：
- 當Job創建的pod執行成功時，Job將記錄成功結果的pod數量
- 當成功結束的pod達到指定的數量時，Job將完成執行
Job的資源清單文件：
apiVersion: batch/v1 # 版本號 kind: Job # 類型 metadata: # 元數據name: jobName # rs名稱namespace: # 所屬命名空間labels: # 標簽controller: job spec: # 詳情描述completions: 1 # 指定job需要陳宮運行Pods的次數。默認值：1parallelism: 1 # 指定job在任意時刻應該并發運行Pods的數量。默認值：1activeDeadlineSeconds: 10 # 指定job可運行的時間期限，超過時間還未結束，系統將會嘗試進行終止。backoffLimit: 6 # 指定job失敗后進行重拾的次數。默認是6manuaSelector: true # 是否可以使用selector選擇器選擇pod,默認是falseselector: # 選擇器，通過它指定該控制器管理哪些podmatchLabels: # Labels匹配規則app: counter-podmatchExpressions: # Expressions匹配規則- {key: app, operator: In, values: [counter -pod]}template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本metadata:labels:app: counter-podspec:restartPolicy: Never # 重啟策略只能設置為Never或者OnFailurecontainers: - 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"]關于重啟策略設置的說明：
- 如果指定為OnFailure，則job會在pod出現故障時重啟容器，而不是創建pod，failed次數不變
- 如果指定為Never,則job會在pod出現故障時創建新的pod，并且故障pod不會消失，也不會重啟，failed次數+1
- 如果指定為Always的話，就意味著一直重啟，意味著job任務會重復去執行了，當然不對，所以不能設置為Always
創建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 [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" deleted7. Cronjob
CronJob控制器以Job控制器資源為其管控對象，并借助它管理pod資源對象，Job控制器定義的作業任務在其控制器資源創建之后便會立即執行，但CronJob可以以類似于Linux操作系統的周期性任務作業計劃的方式控制其運行世家你點及重復運行的方式。也就是說，CroonJob可以在特定的時間點(反復的)去運行job任務。
CronJob的資源清單文件：
apiVersion: batch/v1beta1 # 版本號 kind: CronJob # 類型 metadata: # 元數據name: cronJob # rs名稱namespace: dev # 所屬命名空間labels: # 標簽controller: cronjob spec: # 詳情描述schedule: # cron格式的作業調度運行時間點，用于控制任務在什么時間執行concurrencyPolicy: # 并發執行策略，用于定義前一次作業運行尚未完成時是否一級如何運行后一次的作業failedJobHistoryLimit: # 為失敗的任務執行保留的歷史記錄數，默認為1successfulJobHistoryLimit: # 為成功的任務執行保留的歷史記錄數，默認為3startingDeadlineSeconds: # 啟動作業錯誤的超時時長jobTemplate: # job控制器模板，用于為cronjob控制器生成job對象；下面其實就是job的定義metadata:spec:completioins: 1parallelism: 1activeDeadlineSeonds: 30backoffLimit: 6manualSelector: trueselector:matchLabels:app: counter-podmatchExpressions: 規則- {key: app, operator: In, values: [counter-pod]}template: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 2;done"] 需要重點解釋的幾個選項： schedule: cron表達式，用于指定任務的執行時間*/1 * * * *<分鐘> <小時> <日> <月份> <星期>分鐘 值從0到59小時 值從0到23日 值從1到31月 值從1到12星期 值從0到6，0代表星期日多個時間可以用逗號隔開，范圍可以用連字符給出；*可以作為通配符；/表示每。。。 concurrencyPolicy:Allow: 允許Jobs并發運行(默認)Forbid: 禁止并發運行，如果上一次運行尚未完成，則跳過下一次運行Replace: 替換，取消當前正在運行的作業并用新作業替換它創建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 2;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控制器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 蓝牙模块--OTA升级
- 下一篇： 如果图框为A2横向 则打印为A3图幅横向