公眾號「架構成長指南」，專注于生產實踐、云原生、分布式系統、大數據技術分享。

在過去的幾年中，Kubernetes 在生產環境中被廣泛使用，它通過其聲明式 API 提供了大量解決方案，用于編排容器。

Kubernetes 的一個顯著特性是其具有彈性的能力，能夠執行滾動更新和回滾部署，而能夠完成這些滾動更新和回滾，主要是由Deployment來實現的，下面就講解下Deployment的相關知識

Deployment

Deployment是 Kubernetes 中處理工作負載（應用程序）的機制之一。它由 Kubernetes的Deployment Controller管理.。

在 Kubernetes 中，控制器是一個控制環，它負責觀察集群的狀態，然后根據需要做出或請求做出更改。每個控制器都試圖讓當前集群狀態更接近所需的狀態。

在這里的部署中，我們希望實現的狀態其實是 pod 的狀態，在 K8s 中一切都是聲明式的，因此所需的狀態會作為規范寫入部署清單文件中。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

如果pod實例出現故障或更新（狀態改變），Kubernetes會對yaml中聲明狀態和實際狀態之間的差異做出響應，進行修正，即與定義的部署狀態相匹配。

Deployment的內部工作原理

Deployment是對 ReplicaSet 的抽象。在內部，部署創建了一個ReplicaSet，而 ReplicaSet 則在集群上創建了一組 Pod。因此，ReplicaSet 其實實在管理我們的 Pod 的副本。

總之，控制器會讀取Deployment配置聲明，將 pod 配置轉發給 ReplicaSet，然后用適當的副本創建Pod。

Deployment > ReplicaSet > Pods

滾動部署

Kubernetes 承諾零停機時間，其背后的原理之一就是滾動部署。通過滾動部署，Kubernetes可以保證在部署更新 pod 時不會中斷 pod 的流量

示例

下面讓我們親自操作一下Kubernetes，來看看這些部署策略。

Create Deployment

在前面的章節中，寫過一個Kubernetes的部署手冊，如果沒有Kubernetes集群的同學，請進行參考
最佳實踐-使用RKE快速部署K8S集群

$ kubectl create deployment test-nginx --image=nginx:1.18-alpine

如前所述，部署會創建一個ReplicaSet，然后是Pod。您可以使用

$ kubectl get deploy,rs,po -l app=test-nginx

可以檢查Deployment是否創建了ReplicaSet。

$ kubectl describe  <replica-set-name>

同時我們還可以看一下是否是ReplicaSet創建了pod

$ kubectl describe  <pod-name>

擴容 Deployment
讓我們將部署擴展到 3 個 nginx pod 實例。

$ kubectl scale deploy test-nginx --replicas=3

現在，我們的集群上已經有了多個pod實例了，下面讓我們試試部署策略。

滾動更新部署

假設我們在使用nginx的1.18-alpine版本遇到了一些問題，而1.19-alpine版本解決了這些問題，因此我們需要讓pod更新為新版本鏡像。

通過更新當前 pod 的鏡像（狀態變更），Kubernetes 將進行新的部署。

$ kubectl set image deploy test-nginx nginx=nginx:1.19-alpine

設置新鏡像后，我們可以看到舊的 pod 被終止，新的 pod 被創建。

我們可以看到Kubernetes在更新過程中，在為新 pod 創建完整的副本之前，最后一個舊 pod 不會被終止。舊 pod 也會有一個寬限期，確保其服務的流量在一定時間內不會斷開，直到請求可以安全地路由到新創建的 pod。

雖然這么說但是有時候Kubernetes認為的pod啟動就緒，并不是我們期望的啟動并就緒，這個地方需要結合自身系統進行判斷，后面的文章會進行講解

可以看到nginx的版本已經更新完成

回滾部署版本

假設新的nginx更新后比上一個版本問題更多，而我們現在意識到舊版本的還是更靠譜，這時候需要回滾到之前的nginx版本

但該怎么做？你可能已經注意到，現在有兩個ReplicaSets。這與我們前面的說明部署模式是一樣的，我們更新部署，它就會創建一個新的ReplicaSet，從而創建新的Pod。

Kubernetes 默認最多保留 10 個 ReplicaSet 的歷史記錄，我們可以在部署規范中使用revisionHistoryLimit 來更新這一數字。

這些歷史記錄將作為滾動跟蹤，最新版本的才是目前使用的。

到目前為止，我們已經對部署 test-nginx 做了兩次更改，因此部署歷史記錄應該是兩次。

$ kubectl get rs|grep test-nginx
$ kubectl rollout history deploy test-nginx
$ kubectl rollout history deploy test-nginx --revision=1

可以看到revision=1對應的是1.18-alpine，下面讓我們回滾到上一個版本即1.18-alpine

$ kubectl rollout undo deploy test-nginx --to-revision=1

與 滾動更新部署一樣，回滾部署也會終止當前 pod，并用包含來自 Revision 1 的 Pod 替換它們。

如果再次查看部署歷史，就會發現修訂版 1 已被用于創建最新的 pod，并標記為修訂版 3。

在多個修訂版中重復維護同一規范是沒有意義的，所以Kubernetes 刪除了修訂版 1，因為我們已經有了同一規范的最新修訂版 3。

現在我們已經回滾到了1.18-alpine版本，通過describe部署可以進行驗證。

$ kubectl describe deploy test-nginx

總結

通過 Kubernetes，我們可以利用這些策略輕松控制應用程序的部署。以上只是對滾動和回滾更新部署工作原理的簡單介紹。在實際工作中，我們很少手動完成所有這些步驟，我們一般會交給 CI/CD平臺去做這些事情。

總結

以上是生活随笔為你收集整理的滚动更新和回滚部署在 Kubernetes 中的工作原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。