藍綠（Blue-Green）部署簡介

在現(xiàn)代軟件開發(fā)和交付中，確保應用程序的平穩(wěn)更新和發(fā)布對于用戶體驗和業(yè)務連續(xù)性至關重要。藍綠部署是一種備受推崇的部署策略，它允許開發(fā)團隊在不影響用戶的情況下，將新版本的應用程序引入生產(chǎn)環(huán)境。

藍綠部署的核心思想在于維護兩個獨立的環(huán)境：藍環(huán)境和綠環(huán)境。藍環(huán)境是當前正在運行的穩(wěn)定版本，而綠環(huán)境是即將發(fā)布的新版本。在進行部署時，首先將新版本部署到綠環(huán)境中，并在綠環(huán)境中進行嚴格的測試和驗證。一旦新版本通過了各項測試，并被確認為穩(wěn)定和可靠，就可以將流量從藍環(huán)境切換到綠環(huán)境，使用戶開始訪問新版本。

工作流程

考慮一個在線購物應用，用戶可以瀏覽商品、添加到購物車并完成購買。為了演示藍綠部署，我們假設當前應用的版本為1.0（藍環(huán)境），而開發(fā)團隊已經(jīng)開發(fā)了一個新版本2.0（綠環(huán)境），其中包含了一些界面改進和性能優(yōu)化。

以下是藍綠部署的步驟：

• 步驟1：部署新版本到綠環(huán)境
  開發(fā)團隊使用自動化部署工具將新版本2.0部署到綠環(huán)境。
  綠環(huán)境中的新版本經(jīng)過自動化測試，包括功能測試、性能測試和安全測試。
• 步驟2：切換流量到綠環(huán)境
  新版本部署好之后，可以通過負載均衡器將用戶的流量從藍環(huán)境切換到綠環(huán)境。
  現(xiàn)在用戶開始訪問新版本2.0，體驗其中的改進和優(yōu)化。
• 步驟3：監(jiān)控和回滾
  監(jiān)控系統(tǒng)會實時監(jiān)測應用的性能和穩(wěn)定性，看是否發(fā)生錯誤或故障。
• 步驟4：升級或回滾
  如果出現(xiàn)問題，開發(fā)團隊可以快速回滾，將流量切回到藍環(huán)境1.0，以保障用戶體驗。否則，將繼續(xù)使用新版本2.0， 且使新版本2.0成為新的藍環(huán)境。

k8s的Deployment支持藍綠部署嗎

云原生的浪潮下， 越來越多的團隊都將應用遷移到了Kubernetes的環(huán)境中， Kubernetes使應用的部署變得方便快捷，但Kubernetes卻并未原生提供藍綠部署的功能。它提供了Deployment對象，可以實現(xiàn)“滾動更新”（RollingUpdate）。這使得可以在應用程序更新時實現(xiàn)零停機時間，通過逐步用新版本的應用程序替換Pod。

雖然這類似于藍綠部署，但并未提供其所有的好處。比如在滾動部署中，如果新版本出現(xiàn)問題，回滾可能到舊版本需要重新部署應用，這就需要更多的時間，而不能像藍綠部署一樣，可以即時切換新舊版本， 從而最大限度的保障系統(tǒng)的可用性。

Argo Rollouts實現(xiàn)k8s的藍綠部署

雖然Kubernetes沒有提供原生的藍綠部署功能，但豐富的自定義資源往往可以幫我們在Kubernetes的世界中實現(xiàn)各種各樣美好的愿望。Argo的Rollouts就是一個比較流行好用的工具。Argo Rollouts安裝指南

Argo Rollouts是一個運行在Kubernetes中的漸進式發(fā)布控制器，它支持多種部署策略，其中包括藍綠部署和金絲雀部署。Argo Rollouts提供了一個名為Rollout的新的Kubernetes資源類型，類似于Deployment，用戶可以通過指定額外的參數(shù)，從而設置高級的部署策略。

下面是Rollout自動執(zhí)行藍綠部署的方式：

• 用戶指定一個服務名（activeService），其會將流量路由到當前的（藍色）版本，并可選的指定另一個服務（previewService），其會將流量路由到新的（綠色）版本。
• Rollout控制器使用ReplicaSets部署應用程序的當前版本（藍），并通過向服務選擇器注入ReplicaSet的唯一哈希，將流量路由到它。
• 當應用程序有更新時，開發(fā)人員更改Rollout模板（例如，修改鏡像版本）。Rollout對象檢測到更改，然后創(chuàng)建一個新的具有新版本的ReplicaSet。
• activeService繼續(xù)指向舊的ReplicaSet，同時新的ReplicaSet正在部署中。
• 當新的ReplicaSet變?yōu)榭捎脮r，控制器會自動修改activeService，將流量路由到新的ReplicaSet。
• 控制器會等待一段時間（具體時長在Rollout的yaml文件中聲明），然后縮減舊的ReplicaSet副本。

通過這種方式，Rollout對象實現(xiàn)了自動的藍綠部署，使得應用程序的更新能夠在不影響用戶使用的情況下進行。這為團隊提供了更靈活、可控的部署流程，同時最大程度地減少了潛在的風險。

如下是一份配置藍綠部署策略的Rollout資源配置示例：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
[...] # 省略的配置的格式與Deployment的配置格式完全相同
  strategy:
    blueGreen: 
      activeService: service-active
      previewService: service-preview
      autoPromotionEnabled: false

• activeService: 該項指定的服務會將流量導向藍服務（活躍版本）
• previewService（可選配置項）: 該項指定的服務會將流量導向綠服務（預覽版本）。這使得可以在不將新版本暴露給生產(chǎn)流量的情況下預覽新版本。
• autoPromotionEnabled: 如果設置為false，新版本不會立即自動升級為活躍版本?？梢允褂妹?code>kubectl argo rollouts promote <ROLLOUT>手動進行版本切換。如果設置為true，默認情況下，當新版本Pod Ready時，Rollout會立即切換活躍版本到新版本pod。

值得注意的是，上述配置中的activeService和previewService這兩項指定的服務不會被自動創(chuàng)建，而需要根據(jù)Rollout的配置手動創(chuàng)建，以上面的Rollout的示例配置為基礎，應當創(chuàng)建兩個Service，例如：

---
apiVersion: v1
kind: Service
metadata:
  name: service-active
spec:
  selector:
    app: your-app-label
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: service-preview
spec:
  selector:
    app: your-app-label
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080 
  type: ClusterIP

僅與配置相關的藍綠部署

一個服務的行為不僅取決于源代碼，也與其運行時的配置相關， 在kubernetes中，配置通常通過Configmap來生成，例如下面的配置：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: demo-configmap
  template:
    metadata:
      labels:
        app: demo-configmap
    spec:
      containers:
      - name: demo-container
        image: demo-app:latest
        env:
        - name: DB_USER
          valueFrom:
            configMapKeyRef:
              name: demo-settings
              key: DB_USER
        - name: DB_URL
          valueFrom:
            configMapKeyRef:
              name: demo-settings
              key: DB_URL
[...snip...]
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-settings
data:
  DB_URL: "10.1.1.1:3306"
  DB_USER: "myuser"

上面的配置中， 在容器運行時會從demo-settings這個Configmap中獲取對應的值作為環(huán)境變量，分別是：

  DB_URL: "10.1.1.1:3306"
  DB_USER: "myuser"

此時，我們希望將應用連接到另一個數(shù)據(jù)庫（使用不同的url和用戶）進行測試，例如：

  DB_URL: "10.1.1.2:3306"
  DB_USER: "testuser"

ConfigMap Generator

為了使環(huán)境中同時存在使用兩個不同數(shù)據(jù)庫的服務，我們需要一種方式來同時保持兩個 ConfigMap的存在，并且每個都具有其相應的配置。這可以通過使用 ConfigMap Generator來實現(xiàn)， 這是一個與 Argo Rollouts 無關的功能，它是 Kustomize 的內(nèi)置功能，可以用于標準的滾動部署，我們也可以利用它進行漸進式交付。

Configmap Generator的工作原理如下：kustomize會根據(jù)Configmap Generator中配置的name, 動態(tài)的創(chuàng)建一個ConfigMap, 創(chuàng)建的這個ConfigMap的名稱是name的值加上一個唯一的后綴， 例如：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yml
- service.yml

# declare ConfigMap from a ConfigMapGenerator
configMapGenerator:
- name: demo-settings
  literals:
  - DB_URL="10.1.1.2:3306"
  - DB_USER="testuser"

這時我們查看deployment的yaml內(nèi)容, 其中使用了這個動態(tài)生成的ConfigMap：

[...snip...]
		spec:
		  containers:
		  - env:
		    - name: DB_URL
		    - valueFrom:
		        configMapKeyRef:
		          key: DB_URL 
		          name: demo-settings-2k9m722878
		    - name: DB_USER
		      valueFrom:
		        configMapKeyRef:
		          key: DB_USER 
		          name: demo-settings-2k9m722878
[...snip...]

查看這個動態(tài)的ConfigMap的內(nèi)容：

apiVersion: v1 
name: demo-settings-2km722878
data:
  DB_URL: "10.1.1.2:3306"
  DB_USER: "testuser"

在Argo Rollout中使用Configmap Generator

在上一小節(jié)中，我們已經(jīng)知道了Configmap Generator的工作原理，在Argo Rollout中合理的利用它的特性，就可以實現(xiàn)配置的藍綠部署和漸進式發(fā)布。首先，我們將上文中的Deployment清單轉換成Rollout清單：

# example-rollout.yml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo-app
spec:
  replicas: 3
  strategy:
    blueGreen:    
      activeService: configmaps-example-active      
      previewService: configmaps-example-preview    
      autoPromotionEnabled: false  
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: demo-configmap
  template:
    metadata:
      labels:
        app: demo-configmap
    spec:
      containers:
      - name: my-container
        image: demo-app:latest
        env:
        - name: DB_URL
          valueFrom:
            configMapKeyRef:
              name: demo-settings
              key: DB_URL
        - name: DB_USER
          valueFrom:
            configMapKeyRef:
              name: demo-settings
              key: DB_USER
[...snip...]

然后修改我們的kustomization清單：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# declare ConfigMap as a resource
resources:
- example-rollout.yml
- service-active.yml
- service-preview.yml

configurations:
  - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml

注意：

1. 上面的配置中， service-active.yml 和 service-preview.yml分別對應的藍綠版本的service清單文件，參考上節(jié)，此處省略具體配置。
2. configuration 這一行不可省略，其作用是啟用kustomization的rollout功能，由于Argo Rollout不是原生的Kubernetes資源，因此必須通過yaml來告知kustomization， Rollout資源的詳細信息。

檢驗結果

首先對應用進行首次部署

kustomize build . | kubectl apply  -f -
kubectl-argo-rollouts get rollout demo-app

結果如下：

Name:       demo-app
Namespace:  default
Status:     ~ Healthy
Strategy:   BlueGreen
Images:     demo-app:latest (stable, active)
Replicas:   
    Desired:    3
    Current:    3
    Updated:    3
    Ready:      3
    Available:  3

NAME                                 KIND                   STATUS  AGE INFO
~ demo-app                           Rollout                Healthy 15s
└──# revision: 1
   └── demo-app-55df5b623d           ReplicaSet             Healthy 15s stable,active
      ├── demo-app-55df5b623d-2nlgf  Pod                    Healthy 15s ready:1/1
      ├── demo-app-55df5b623d-78udn  Pod                    Healthy 15s ready:1/1      
      └── demo-app-55df5b623d-6sceo  Pod                    Healthy 15s ready:1/1      

現(xiàn)在我們來改變配置，在Configmap Generator中更改配置：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# declare ConfigMap as a resource
resources:
- example-rollout.yml
- service-active.yml
- service-preview.yml

configurations:
  - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml

configMapGenerator:
  - name: demo-settings
	literals:
	  - DB_URL="10.1.1.2:3306"
  	  - DB_USER="testuser"

運行命令進行藍綠部署并查看結果：

kustomize build . | kubectl apply  -f -
kubectl-argo-rollouts get rollout demo-app

結果如下：

Name:       demo-app
Namespace:  default
Status:     Paused
Message:    BlueGreenPause
Strategy:   BlueGreen
Images:     demo-app:latest (active, preview, stable)
Replicas:   
    Desired:    3
    Current:    6
    Updated:    3
    Ready:      3
    Available:  3

NAME                                 KIND                   STATUS  AGE INFO
~ demo-app                           Rollout                Paused  100s
├──# revision: 2
│  └── demo-app-76tk9i812c           ReplicaSet             Healthy 10s preview
│     ├── demo-app-76tk9i812c-1nvlf  Pod                    Healthy 10s ready:1/1
│     ├── demo-app-76tk9i812c-70qce  Pod                    Healthy 10s ready:1/1      
│     └── demo-app-76tk9i812c-21kap  Pod                    Healthy 10s ready:1/1      
└──# revision: 1
   └── demo-app-55df5b623d           ReplicaSet             Healthy 100s stable,active
      ├── demo-app-55df5b623d-2nlgf  Pod                    Healthy 100s ready:1/1
      ├── demo-app-55df5b623d-78udn  Pod                    Healthy 100s ready:1/1      
      └── demo-app-55df5b623d-6sceo  Pod                    Healthy 100s ready:1/1      

進入對應的Pod中查看環(huán)境變量，可以看到已經(jīng)生效，檢驗成功。

通過上面的方法，我們可以僅使用 Argo Rollouts 進行配置更改，在不修改容器鏡像的情況下，只需更改配置即可執(zhí)行藍/綠部署和金絲雀部署。如果你想要在生產(chǎn) Kubernetes 集群中微調(diào)應用程序配置參數(shù)，而不想使用新的容器鏡像，那么希望這篇文章將會給你一些啟發(fā)和幫助。文章來源地址http://www.zghlxwxcb.cn/news/detail-690560.html

到了這里，關于【kubernetes】Argo Rollouts -- k8s下的自動化藍綠部署的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！