Kubernetes-Pod介紹(四)-Deployment

2021 年 9 月 26 日
筆記
DevOps

前言

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

Kubernetes系列文章:

Pod升級和回滾

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

Deployment升級

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

清空所有的Pod；

kubectl delete pods --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資源；

kubectl apply -f nginx-deployment.yaml

查看Pod執行情況;

kubectl get pods

切換鏡像版本為1.9.1，這裡觸發滾動更新的方式有兩種:一種使用kubectl edit，另外一種使用kubectl set image;

#第一種方式
kubectl edit deployment/nginx-deployment
#第二種方式
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

查看deployment更新過程;

kubectl rollout status deployment/nginx-deployment

再次查看Pod狀況，會發現Pod，名稱已經發生改變;

查看Pod使用的鏡像版本，我們會發現nginx的鏡像版本已經被替換為1.9.1；

kubectl describe pod/nginx-deployment-79fbcd54b4-j9n62

查看Pod更新過程，我們會發現Deployment資源的本質就是ReplicaSet，當我們創建Deployment系統會創建3個ReplicaSet，更新Deployment資源的時候會創建一個新ReplicaSet，減少一個舊版本的ReplicaSet，後續慢慢替換為新版本ReplicaSet；

kubectl describe deployment/nginx-deployment

查看ReplicaSet版本；

kubectl get rs

總結：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

查看滾動更新的過程，我們會發現滾動更新被卡死了；

kubectl rollout status deployments nginx-deployment

查看Pod的狀態，這個時候我們會發現鏡像一直處於被拉取的狀態；

kubectl get pods

為了解決該問題，這個時候我們需要進行回滾操作，我們可以通過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

查看整個回滾過程的事件資訊，回滾的過程就是將新建的ReplicaSet縮容就可以了；

kubectl describe deployment/nginx-deployment

暫停和恢復Deployment

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

通過kubectl rollout pause 命令暫停Deployment的更新操作;

kubectl rollout pause deployment/nginx-deployment

修改Deployment的鏡像資訊；

kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0

查看Deployment事件資訊，我們會發現Deployment並沒有更新操作；

kubectl describe deployment/nginx-deployment

通過kubectl rollout resume命令恢復Deployment的更新操作;

kubectl rollout resume deployment nginx-deployment

再次查看Deployment事件資訊或者查看ReplicaSet資訊，我們會發現Deployment開始更新操作；

#查看事件資訊
kubectl describe deployment/nginx-deployment
#查看資訊
kubectl get rs

結束

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

Tags: DevOps