Kubernetes之Pod Deployment
阿新 • • 發佈:2021-12-14
Pod升級和回滾
在生產的環境中,當我們需要給某個服務升級時候,需要停止與該服務相關的所有應用Pod,然後下載最新應用的映象並建立新Pod,這樣當我們服務的規模很大的時候,會造成長時間的服務不可用,對於這種情況Kubernetes提出了滾動升級和滾動回滾概念來解決該問題。
Deployment升級
這裡我們採用案例驅動的方式來一步一步瞭解Kubernetes滾動升級。
- 清空所有的Pod;
kubectldeletepods--all
- 這裡我們採用最開始使用nginx-deployment.yaml檔案;
apiVersion:apps/v1
kind:Deployment
metadata:
name:nginx-deployment
spec:
selector:
matchLabels:
app:nginx
replicas:3
template:
metadata:
labels:
app:nginx
spec:
containers:
-name:nginx
image:nginx:latest
resources:
limits:
memory:"128Mi"
cpu:"128m"
ports:
-containerPort:80
- 建立deployment資源;
kubectlapply-fnginx-deployment.yaml
- 檢視Pod執行情況;
kubectlgetpods
- 切換映象版本為1.9.1,這裡觸發滾動更新的方式有兩種:一種使用kubectl edit,另外一種使用kubectl set image;
#第一種方式
kubectleditdeployment/nginx-deployment
#第二種方式
kubectlsetimagedeployment/nginx-deploymentnginx=nginx:1.9.1
- 檢視deployment更新過程;
kubectlrolloutstatusdeployment/nginx-deployment
- 再次檢視Pod狀況,會發現Pod,名稱已經發生改變;
- 檢視Pod使用的映象版本,我們會發現nginx的映象版本已經被替換為1.9.1;
kubectldescribepod/nginx-deployment-79fbcd54b4-j9n62
- 檢視Pod更新過程,我們會發現Deployment資源的本質就是ReplicaSet,當我們建立Deployment系統會建立3個ReplicaSet,更新Deployment資源的時候會建立一個新ReplicaSet,減少一箇舊版本的ReplicaSet,後續慢慢替換為新版本ReplicaSet;
kubectldescribedeployment/nginx-deployment
- 檢視ReplicaSet版本;
kubectlgetrs
總結:Deployment實際上是一個兩層控制器。首先,它通過 ReplicaSet 來控制應用的版本;然後,它再通過 ReplicaSet 的屬性,來保證 Pod 的副本數量。
在Deployment定義中,可以通過spec.strategy指定Pod的更新策略,目前支援兩種策略:
- Recrate(重建): 更新Pod的時候會殺掉所有在執行的Pod,然後重新建立Pod;
- RollingUpdate(滾動更新): 預設選項,以滾動更新的方式來逐個更新Pod,可以通過spec.strategy.rollingUpdate下面兩個引數maxUnavailable和maxSurge來控制滾動更新;
maxUnavailable: 用於指定Deployment在更新過程中不可用狀態Pod的上限,可以是百分比也可以是絕對值;
maxSurge: 用於指定在Deployment更新過程中Pod總數量超過期望副本的最大值,可以是百分比也可以是絕對值;從Kubernetes1.6版本開始,以上兩個值的預設為25%;
Deployment回滾
生產環境中可能由於一些原因,導致需要回滾操作,這個時候我們就可以使用Deployment回滾操作,這裡我們還是以更新nginx映象為案例:
- 將nginx映象版本更新為Nginx:1.99,在映象倉庫中是不存在該映象版本的;
kubectl set image deployment/nginx-deployment nginx=nginx:1.99
- 檢視滾動更新的過程,我們會發現滾動更新被卡死了;
kubectlrolloutstatusdeploymentsnginx-deployment
- 檢視Pod的狀態,這個時候我們會發現映象一直處於被拉取的狀態;
kubectlgetpods
- 為了解決該問題,這個時候我們需要進行回滾操作,我們可以通過kubectl rollout history檢視Deployment的部署歷史記錄,通過kubectl rollout undo命令回滾到上一個部署版本,當然也可以指定版本回滾;
#檢視Deployment的部署歷史記錄
kubectlrollouthistorydeployment/nginx-deployment
#檢視Deployment的指定版本部署情況
kubectlrollouthistorydeployment/nginx-deployment--revision=3
#回滾到上一個版本
kubectlrolloutundodeployment/nginx-deployment
#指定版本回滾
kubectlrolloutundodeployment/nginx-deployment--to-revision=2
- 檢視整個回滾過程的事件資訊,回滾的過程就是將新建的ReplicaSet縮容就可以了;
kubectldescribedeployment/nginx-deployment
暫停和恢復Deployment
對於複雜的Deployment配置修改,為了避免頻繁的觸發Deployment的更新操作,可以先暫停Deployment的更新操作,然後進行配置修改,在恢復Deployment,一次性觸發完整的更新操作。
- 通過kubectl rollout pause 命令暫停Deployment的更新操作;
kubectlrolloutpausedeployment/nginx-deployment
- 修改Deployment的映象資訊;
kubectlsetimagedeployment/nginx-deploymentnginx=nginx:1.18.0
- 檢視Deployment事件資訊,我們會發現Deployment並沒有更新操作;
kubectldescribedeployment/nginx-deployment
- 通過kubectl rollout resume命令恢復Deployment的更新操作;
kubectlrolloutresumedeploymentnginx-deployment
- 再次檢視Deployment事件資訊或者檢視ReplicaSet資訊,我們會發現Deployment開始更新操作;
#檢視事件資訊
kubectldescribedeployment/nginx-deployment
#檢視資訊
kubectlgetrs