6 第六章 Pod控制器詳解

6.1 Pod控制器介紹

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：管理有狀態應用

6.2 ReplicaSet(RS)

ReplicaSet的主要作用是保證一定數量的pod正常運行，它會持續監聽這些Pod的運行狀態，一旦Pod發生故障，就會重啟或重建。同時它還支持對pod數量的擴縮容和鏡像版本的升降級。

ReplicaSet的資源清單文件：

apiVersion: apps/v1 # 版本號
kind: ReplicaSet # 類型       
metadata: # 元數據
 name: # rs名稱 
 namespace: # 所屬命名空間 
 labels: #標簽
   controller: rs
spec: # 詳情描述
 replicas: 3 # 副本數量
 selector: # 選擇器，通過它指定該控制器管理哪些pod
   matchLabels:      # Labels匹配規則
     app: nginx-pod
   matchExpressions: # Expressions匹配規則
     - {key: app, operator: In, values: [nginx-pod]}
 template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1
       ports:
       - 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-replicaset
 namespace: dev
spec:
 replicas: 3
 selector: 
   matchLabels:
     app: nginx-pod
 template:
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1

# 創建rs
[root@k8s-master01 ~]# kubectl create -f pc-replicaset.yaml
replicaset.apps/pc-replicaset created
​
# 查看rs
# DESIRED:期望副本數量  
# CURRENT:當前副本數量  
# READY:已經准備好提供服務的副本數量
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl edit rs pc-replicaset -n dev
replicaset.apps/pc-replicaset edited
​
# 查看pod
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl scale rs pc-replicaset --replicas=2 -n dev
replicaset.apps/pc-replicaset scaled
​
# 命令運行完畢，立即查看，發現已經有4個開始准備退出了
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl edit rs pc-replicaset -n dev
replicaset.apps/pc-replicaset edited
​
# 再次查看，發現鏡像版本已經變更了
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev
replicaset.apps/pc-replicaset image updated
​
# 再次查看，發現鏡像版本已經變更了
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete rs pc-replicaset -n dev
replicaset.apps "pc-replicaset" deleted
[root@k8s-master01 ~]# kubectl get pod -n dev -o wide
No resources found in dev namespace.
​
# 如果希望僅僅刪除RS對象（保留Pod），可以使用kubectl delete命令時添加--cascade=false選項（不推薦）。
[root@k8s-master01 ~]# kubectl delete rs pc-replicaset -n dev --cascade=false
replicaset.apps "pc-replicaset" deleted
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete -f pc-replicaset.yaml
replicaset.apps "pc-replicaset" deleted

6.3 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 # 暫停部署，默認是false
 progressDeadlineSeconds: 600 # 部署超時時間（s），默認是600
 strategy: # 策略
   type: RollingUpdate # 滾動更新策略
   rollingUpdate: # 滾動更新
     maxSurge: 30% # 最大額外可以存在的副本數，可以為百分比，也可以為整數
     maxUnavailable: 30% # 最大不可用狀態的 Pod 的最大值，可以為百分比，也可以為整數
 selector: # 選擇器，通過它指定該控制器管理哪些pod
   matchLabels:      # Labels匹配規則
     app: nginx-pod
   matchExpressions: # Expressions匹配規則
     - {key: app, operator: In, values: [nginx-pod]}
 template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1
       ports:
       - containerPort: 80

創建deployment

創建pc-deployment.yaml，內容如下：

apiVersion: apps/v1
kind: Deployment      
metadata:
 name: pc-deployment
 namespace: dev
spec: 
 replicas: 3
 selector:
   matchLabels:
     app: nginx-pod
 template:
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1

# 創建deployment
[root@k8s-master01 ~]# kubectl create -f pc-deployment.yaml --record=true
deployment.apps/pc-deployment created
​
# 查看deployment
# UP-TO-DATE 最新版本的pod的數量
# AVAILABLE 當前可用的pod的數量
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78   3         3         3       23s
​
# 查看pod
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl scale deploy pc-deployment --replicas=5 -n dev
deployment.apps/pc-deployment scaled
​
# 查看deployment
[root@k8s-master01 ~]# kubectl get deploy pc-deployment -n dev
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
pc-deployment   5/5     5            5           2m
​
# 查看pod
[root@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl edit deploy pc-deployment -n dev
deployment.apps/pc-deployment edited
​
# 查看pod
[root@k8s-master01 ~]# 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之前會先殺掉所有已存在的Pod
    RollingUpdate：滾動更新，就是殺死一部分，就啟動一部分，在更新過程中，存在兩個版本Pod
 rollingUpdate：當type為RollingUpdate時生效，用於為RollingUpdate設置參數，支持兩個屬性：
    maxUnavailable：用來指定在升級過程中不可用Pod的最大數量，默認為25%。
    maxSurge： 用來指定在升級過程中可以超過期望的Pod的最大數量，默認為25%。

重建更新

1) 編輯pc-deployment.yaml,在spec節點下添加更新策略

spec:
 strategy: # 策略
   type: Recreate # 重建更新

2) 創建deploy進行驗證

# 變更鏡像
[root@k8s-master01 ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev
deployment.apps/pc-deployment image updated
​
# 觀察升級過程
[root@k8s-master01 ~]# 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          31s
​
pc-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          41s
​
pc-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          0s
​
pc-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          0s
​
pc-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

滾動更新

1) 編輯pc-deployment.yaml,在spec節點下添加更新策略

spec:
 strategy: # 策略
   type: RollingUpdate # 滾動更新策略
   rollingUpdate:
     maxSurge: 25% 
     maxUnavailable: 25%

2) 創建deploy進行驗證

# 變更鏡像
[root@k8s-master01 ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev 
deployment.apps/pc-deployment image updated
​
# 觀察升級過程
[root@k8s-master01 ~]# kubectl get pods -n dev -w
NAME                           READY   STATUS    RESTARTS   AGE
pc-deployment-c848d767-8rbzt   1/1     Running   0          31m
pc-deployment-c848d767-h4p68   1/1     Running   0          31m
pc-deployment-c848d767-hlmz4   1/1     Running   0          31m
pc-deployment-c848d767-rrqcn   1/1     Running   0          31m
​
pc-deployment-966bf7f44-226rx   0/1     Pending             0          0s
pc-deployment-966bf7f44-226rx   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-226rx   1/1     Running             0          1s
pc-deployment-c848d767-h4p68    0/1     Terminating         0          34m
​
pc-deployment-966bf7f44-cnd44   0/1     Pending             0          0s
pc-deployment-966bf7f44-cnd44   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-cnd44   1/1     Running             0          2s
pc-deployment-c848d767-hlmz4    0/1     Terminating         0          34m
​
pc-deployment-966bf7f44-px48p   0/1     Pending             0          0s
pc-deployment-966bf7f44-px48p   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-px48p   1/1     Running             0          0s
pc-deployment-c848d767-8rbzt    0/1     Terminating         0          34m
​
pc-deployment-966bf7f44-dkmqp   0/1     Pending             0          0s
pc-deployment-966bf7f44-dkmqp   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-dkmqp   1/1     Running             0          2s
pc-deployment-c848d767-rrqcn    0/1     Terminating         0          34m
​
# 至此，新版本的pod創建完畢，就版本的pod銷毀完畢
# 中間過程是滾動進行的，也就是邊銷毀邊創建

滾動更新的過程：

鏡像更新中rs的變化:

# 查看rs,發現原來的rs的依舊存在，只是pod數量變為了0，而后又新產生了一個rs，pod數量為4
# 其實這就是deployment能夠進行版本回退的奧妙所在，后面會詳細解釋
[root@k8s-master01 ~]# kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78   0         0         0       7m37s
pc-deployment-6696798b11   0         0         0       5m37s
pc-deployment-c848d76789   4         4         4       72s

版本回退

deployment支持版本升級過程中的暫停、繼續功能以及版本回退等諸多功能，下面具體來看.

kubectl rollout： 版本升級相關功能，支持下面的選項：

• status 顯示當前升級狀態

• history 顯示 升級歷史記錄

• pause 暫停版本升級過程

• resume 繼續已經暫停的版本升級過程

• restart 重啟版本升級過程

• undo 回滾到上一級版本（可以使用--to-revision回滾到指定版本）

# 查看當前升級版本的狀態
[root@k8s-master01 ~]# kubectl rollout status deploy pc-deployment -n dev
deployment "pc-deployment" successfully rolled out
​
# 查看升級歷史記錄
[root@k8s-master01 ~]# kubectl rollout history deploy pc-deployment -n dev
deployment.apps/pc-deployment
REVISION  CHANGE-CAUSE
1         kubectl create --filename=pc-deployment.yaml --record=true
2         kubectl create --filename=pc-deployment.yaml --record=true
3         kubectl create --filename=pc-deployment.yaml --record=true
# 可以發現有三次版本記錄，說明完成過兩次升級
​
# 版本回滾
# 這里直接使用--to-revision=1回滾到了1版本， 如果省略這個選項，就是回退到上個版本，就是2版本
[root@k8s-master01 ~]# kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev
deployment.apps/pc-deployment rolled back
​
# 查看發現，通過nginx鏡像版本可以發現到了第一版
[root@k8s-master01 ~]# kubectl get deploy -n dev -o wide
NAME            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES         
pc-deployment   4/4     4            4           74m   nginx        nginx:1.17.1   
​
# 查看rs，發現第一個rs中有4個pod運行，后面兩個版本的rs中pod為運行
# 其實deployment之所以可是實現版本的回滾，就是通過記錄下歷史rs來實現的，
# 一旦想回滾到哪個版本，只需要將當前版本pod數量降為0，然后將回滾版本的pod提升為目標數量就可以了
[root@k8s-master01 ~]# kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78   4         4         4       78m
pc-deployment-966bf7f44    0         0         0       37m
pc-deployment-c848d767     0         0         0       71m

金絲雀發布

Deployment控制器支持控制更新過程中的控制，如“暫停(pause)”或“繼續(resume)”更新操作。

比如有一批新的Pod資源創建完成后立即暫停更新過程，此時，僅存在一部分新版本的應用，主體部分還是舊的版本。然后，再篩選一小部分的用戶請求路由到新版本的Pod應用，繼續觀察能否穩定地按期望的方式運行。確定沒問題之后再繼續完成余下的Pod資源滾動更新，否則立即回滾更新操作。這就是所謂的金絲雀發布。

# 更新deployment的版本，並配置暫停deployment
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl rollout resume deploy pc-deployment -n dev
deployment.apps/pc-deployment resumed
​
# 查看最后的更新情況
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete -f pc-deployment.yaml
deployment.apps "pc-deployment" deleted

6.4 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@k8s-master01 ~]# yum install git -y
# 獲取metrics-server, 注意使用的版本
[root@k8s-master01 ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改deployment, 注意修改的是鏡像和初始化參數
[root@k8s-master01 ~]# cd /root/metrics-server/deploy/1.8+/
[root@k8s-master01 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@k8s-master01 1.8+]# kubectl apply -f ./
​
# 查看pod運行情況
[root@k8s-master01 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj   1/1     Running   0          90s
​
# 使用kubectl top node 查看資源使用情況
[root@k8s-master01 1.8+]# kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-master01   289m         14%    1582Mi          54%       
k8s-node01     81m          4%     1195Mi          40%       
k8s-node02     72m          3%     1211Mi          41%  
[root@k8s-master01 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

創建pc-hpa-pod.yaml文件，內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
 namespace: dev
spec:
 strategy: # 策略
   type: RollingUpdate # 滾動更新策略
 replicas: 1
 selector:
   matchLabels:
     app: nginx-pod
 template:
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1
       resources: # 資源配額
         limits:  # 限制資源（上限）
           cpu: "1" # CPU限制，單位是core數
         requests: # 請求資源（下限）
           cpu: "100m"  # CPU限制，單位是core數

# 創建service
[root@k8s-master01 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev

# 查看
[root@k8s-master01 1.8+]# kubectl get deployment,pod,svc -n dev
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx   1/1     1            1           47s
​
NAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-7df9756ccc-bh8dr   1/1     Running   0          47s
​
NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/nginx   NodePort   10.101.18.29   <none>        80:31830/TCP   35s

3 部署HPA

創建pc-hpa.yaml文件，內容如下：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
 name: pc-hpa
 namespace: dev
spec:
 minReplicas: 1  #最小pod數量
 maxReplicas: 10 #最大pod數量
 targetCPUUtilizationPercentage: 3 # CPU使用率指標
 scaleTargetRef:   # 指定要控制的nginx信息
   apiVersion: apps/v1
   kind: Deployment
   name: nginx

# 創建hpa
[root@k8s-master01 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created
​
# 查看hpa
    [root@k8s-master01 1.8+]# kubectl get hpa -n dev
NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx   0%/3%     1         10        1          62s

4 測試

使用壓測工具對service地址192.168.5.4:31830進行壓測，然后通過控制台查看hpa和pod的變化

hpa變化

[root@k8s-master01 ~]# 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          14m

deployment變化

[root@k8s-master01 ~]# 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           20m

pod變化

[root@k8s-master01 ~]# 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          6m50s

6.5 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: # 選擇器，通過它指定該控制器管理哪些pod
   matchLabels:      # Labels匹配規則
     app: nginx-pod
   matchExpressions: # Expressions匹配規則
     - {key: app, operator: In, values: [nginx-pod]}
 template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1
       ports:
       - containerPort: 80

創建pc-daemonset.yaml，內容如下：

apiVersion: apps/v1
kind: DaemonSet      
metadata:
 name: pc-daemonset
 namespace: dev
spec: 
 selector:
   matchLabels:
     app: nginx-pod
 template:
   metadata:
     labels:
       app: nginx-pod
   spec:
     containers:
     - name: nginx
       image: nginx:1.17.1

# 創建daemonset
[root@k8s-master01 ~]# kubectl create -f pc-daemonset.yaml
daemonset.apps/pc-daemonset created
​
# 查看daemonset
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete -f pc-daemonset.yaml
daemonset.apps "pc-daemonset" deleted

6.6 Job

Job，主要用於負責批量處理(一次要處理指定數量任務)短暫的一次性(每個任務僅運行一次就結束)任務。Job特點如下：

• 當Job創建的pod執行成功結束時，Job將記錄成功結束的pod數量

• 當成功結束的pod達到指定的數量時，Job將完成執行

Job的資源清單文件：

apiVersion: batch/v1 # 版本號
kind: Job # 類型       
metadata: # 元數據
 name: # rs名稱 
 namespace: # 所屬命名空間 
 labels: #標簽
   controller: job
spec: # 詳情描述
 completions: 1 # 指定job需要成功運行Pods的次數。默認值: 1
 parallelism: 1 # 指定job在任一時刻應該並發運行Pods的數量。默認值: 1
 activeDeadlineSeconds: 30 # 指定job可運行的時間期限，超過時間還未結束，系統將會嘗試進行終止。
 backoffLimit: 6 # 指定job失敗后進行重試的次數。默認是6
 manualSelector: true # 是否可以使用selector選擇器選擇pod，默認是false
 selector: # 選擇器，通過它指定該控制器管理哪些pod
   matchLabels:      # Labels匹配規則
     app: counter-pod
   matchExpressions: # Expressions匹配規則
     - {key: app, operator: In, values: [counter-pod]}
 template: # 模板，當副本數量不足時，會根據下面的模板創建pod副本
   metadata:
     labels:
       app: counter-pod
   spec:
     restartPolicy: Never # 重啟策略只能設置為Never或者OnFailure
     containers:
     - name: counter
       image: busybox:1.30
       command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;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-job
 namespace: dev
spec:
 manualSelector: true
 selector:
   matchLabels:
     app: counter-pod
 template:
   metadata:
     labels:
       app: counter-pod
   spec:
     restartPolicy: Never
     containers:
     - name: counter
       image: busybox:1.30
       command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

# 創建job
[root@k8s-master01 ~]# kubectl create -f pc-job.yaml
job.batch/pc-job created
​
# 查看job
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete -f pc-job.yaml
job.batch "pc-job" deleted

6.7 CronJob(CJ)

CronJob控制器以Job控制器資源為其管控對象，並借助它管理pod資源對象，Job控制器定義的作業任務在其控制器資源創建之后便會立即執行，但CronJob可以以類似於Linux操作系統的周期性任務作業計划的方式控制其運行時間點及重復運行的方式。也就是說，CronJob可以在特定的時間點(反復的)去運行job任務。

CronJob的資源清單文件：

apiVersion: batch/v1beta1 # 版本號
kind: CronJob # 類型       
metadata: # 元數據
 name: # rs名稱 
 namespace: # 所屬命名空間 
 labels: #標簽
   controller: cronjob
spec: # 詳情描述
 schedule: # cron格式的作業調度運行時間點,用於控制任務在什么時間執行
 concurrencyPolicy: # 並發執行策略，用於定義前一次作業運行尚未完成時是否以及如何運行后一次的作業
 failedJobHistoryLimit: # 為失敗的任務執行保留的歷史記錄數，默認為1
 successfulJobHistoryLimit: # 為成功的任務執行保留的歷史記錄數，默認為3
 startingDeadlineSeconds: # 啟動作業錯誤的超時時長
 jobTemplate: # job控制器模板，用於為cronjob控制器生成job對象;下面其實就是job的定義
   metadata:
   spec:
     completions: 1
     parallelism: 1
     activeDeadlineSeconds: 30
     backoffLimit: 6
     manualSelector: true
     selector:
       matchLabels:
         app: counter-pod
       matchExpressions: 規則
         - {key: app, operator: In, values: [counter-pod]}
     template:
       metadata:
         labels:
           app: counter-pod
       spec:
         restartPolicy: Never 
         containers:
         - name: counter
           image: busybox:1.30
           command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;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-cronjob
 namespace: dev
 labels:
   controller: cronjob
spec:
 schedule: "*/1 * * * *"
 jobTemplate:
   metadata:
   spec:
     template:
       spec:
         restartPolicy: Never
         containers:
         - name: counter
           image: busybox:1.30
           command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

# 創建cronjob
[root@k8s-master01 ~]# kubectl create -f pc-cronjob.yaml
cronjob.batch/pc-cronjob created
​
# 查看cronjob
[root@k8s-master01 ~]# kubectl get cronjobs -n dev
NAME         SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
pc-cronjob   */1 * * * *   False     0        <none>          6s
​
# 查看job
[root@k8s-master01 ~]# 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@k8s-master01 ~]# 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@k8s-master01 ~]# kubectl delete -f pc-cronjob.yaml
cronjob.batch "pc-cronjob" deleted