前言

本篇是Kubernetes第七篇,大家一定要把環境搭建起來,看是解決不了問題的,必須實戰。

Kubernetes系列文章:
  1. Kubernetes介紹
  2. Kubernetes環境搭建
  3. Kubernetes-kubectl介紹
  4. Kubernetes-Pod介紹(-)
  5. Kubernetes-Pod介紹(二)-生命週期
  6. Kubernetes-Pod介紹(三)-Pod排程

Pod升級和回滾

在生產的環境中,當我們需要給某個服務升級時候,需要停止與該服務相關的所有應用Pod,然後下載最新應用的映象並建立新Pod,這樣當我們服務的規模很大的時候,會照成長時間的服務不可用,對於這種情況Kubernetes提出了滾動升級和滾動回滾概念來幫助我們解決該問題。

Deployment升級

這裡我們採用案例驅動的方式來一步一步瞭解Kubernetes滾動升級。

  1. 清空所有的Pod;
kubectl delete pods --all
  1. 這裡我們採用最開始使用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
  1. 建立deployment資源;
kubectl apply -f nginx-deployment.yaml
  1. 檢視Pod執行情況;
kubectl get pods

image.png
  1. 切換映象版本為1.9.1,這裡觸發滾動更新的方式有兩種:一種使用kubectl edit,另外一種使用kubectl set image;
#第一種方式
kubectl edit deployment/nginx-deployment
#第二種方式
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  1. 檢視deployment更新過程;
kubectl rollout status deployment/nginx-deployment

image.png
  1. 再次檢視Pod狀況,會發現Pod,名稱已經發生改變;

image.png
  1. 檢視Pod使用的映象版本,我們會發現nginx的映象版本已經被替換為1.9.1;
kubectl describe pod/nginx-deployment-79fbcd54b4-j9n62

image.png
  1. 檢視Pod更新過程,我們會發現Deployment資源的本質就是ReplicaSet,當我們建立Deployment系統會建立3個ReplicaSet,更新Deployment資源的時候會建立一個新ReplicaSet,減少一箇舊版本的ReplicaSet,後續慢慢替換為新版本ReplicaSet;
kubectl describe deployment/nginx-deployment

image.png

image.png
  1. 檢視ReplicaSet版本;
kubectl get rs

總結:Deployment實際上是一個兩層控制器。首先,它通過 ReplicaSet 來控制應用的版本;然後,它再通過 ReplicaSet 的屬性,來保證 Pod 的副本數量。

在Deployment定義中,可以通過spec.strategy指定Pod的更新策略,目前支援兩種策略:

  1. Recrate(重建): 更新Pod的時候會殺掉所有在執行的Pod,然後重新建立Pod;
  2. RollingUpdate(滾動更新): 預設選項,以滾動更新的方式來逐個更新Pod,可以通過spec.strategy.rollingUpdate下面兩個引數maxUnavailable和maxSurge來控制滾動更新;

maxUnavailable: 用於指定Deployment在更新過程中不可用狀態Pod的上限,可以是百分比也可以是絕對值;

maxSurge: 用於指定在Deployment更新過程中Pod總數量超過期望副本的最大值,可以是百分比也可以是絕對值;從Kubernetes1.6版本開始,以上兩個值的預設為25%;

Deployment回滾

生產環境中可能由於一些原因,導致需要回滾操作,這個時候我們就可以使用Deployment回滾操作,這裡我們還是以更新nginx映象為案例:

  1. 將nginx映象版本更新為Nginx:1.99,在映象倉庫中是不存在該映象版本的;
kubectl set image deployment/nginx-deployment nginx=nginx:1.99
  1. 檢視滾動更新的過程,我們會發現滾動更新被卡死了;
kubectl rollout status deployments nginx-deployment

image.png
  1. 檢視Pod的狀態,這個時候我們會發現映象一直處於被拉取的狀態;
kubectl get pods
  1. 為了解決該問題,這個時候我們需要進行回滾操作,我們可以通過kubectl rollout history檢視Deployment的部署歷史記錄,通過kubectl rollout undo命令回滾到上一個部署版本,當然也可以指定版本回滾;
#檢視Deployment的部署歷史記錄
kubectl rollout history deployment/nginx-deployment
#檢視Deployment的指定版本部署情況
kubectl rollout history deployment/nginx-deployment --revision=3
#回滾到上一個版本
kubectl rollout undo deployment/nginx-deployment
#指定版本回滾
kubectl rollout undo deployment/nginx-deployment  --to-revision=2
  1. 檢視整個回滾過程的事件資訊,回滾的過程就是將新建的ReplicaSet縮容就可以了;
kubectl describe deployment/nginx-deployment

image.png
暫停和恢復Deployment

對於複雜的Deployment配置修改,為了避免頻繁的觸發Deployment的更新操作,可以先暫停Deployment的更新操作,然後進行配置修改,在恢復Deployment,一次性觸發完整的更新操作。

  1. 通過kubectl rollout pause 命令暫停Deployment的更新操作;
kubectl rollout pause deployment/nginx-deployment
  1. 修改Deployment的映象資訊;
kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0 
  1. 檢視Deployment事件資訊,我們會發現Deployment並沒有更新操作;
kubectl describe deployment/nginx-deployment

image.png
  1. 通過kubectl rollout resume命令恢復Deployment的更新操作;
kubectl rollout resume deployment nginx-deployment
  1. 再次檢視Deployment事件資訊或者檢視ReplicaSet資訊,我們會發現Deployment開始更新操作;
#檢視事件資訊
kubectl describe deployment/nginx-deployment
#檢視資訊
kubectl get rs

image.png

結束

歡迎大家點點關注,點點贊!