天天看點

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

作者 | 白寂  阿裡雲開發工程師

導讀:前三篇文章我們介紹了應用的開發和部署,那麼在應用成功上雲後,我就要面對應用的管理話題了,這一篇我們來看看如何做線上釋出,并且是可灰階的。

相關文章推薦:

前言

在新版本上線時,無論是從産品穩定性還是使用者對新版本的接受程度上考慮,直接将老應用更新到新版本應用都有很大風險的。我們一般的做法是,保證新老版本同時線上,并且先将少部分流量切換到新版本應用上,同時在此期間對新版本的應用請求進行觀察。在确認新版本沒有問題後,再逐漸将更大比例的流量切換到新版本上。這個過程的核心是可以對流量的流入轉發規則進行配置,EDAS 的金絲雀釋出能力,提供了多個版本同時線上的能力,并且提供了靈活的配置規則來給不同的版本進行流量配置設定。

部署在 EDAS Kubernetes 叢集中的 Spring Cloud 微服務應用,在新版本釋出的時候可以使用金絲雀釋出進行小規模驗證,驗證通過後再全量更新。

金絲雀釋出配置

首先,進入 EDAS 的應用部署頁面,對我們要進行部署更新的應用進行釋出,在這裡我們選擇金絲雀(灰階)釋出。需要注意的是,對灰階釋出的流量控制,目前隻對非入口應用的 Dubbo 和 Spring Cloud 應用生效。所謂入口應用,即承接外部流量的第一個應用節點。并且若您的應用使用了 HPA、Rancher、Istio、或者依賴Deployment.Metadata.Name 或 Deployment.Metadata.Uid 的功能與配置等 K8s 原生功能或配置時,請勿使用灰階釋出或分批釋出。否則,應用部署之後,這些 K8s 原生功能或配置将出現異常。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

在釋出頁面,可以選擇通過上傳 JAR 包或者填入 JAR 包位址的方式選擇要進行釋出的新版本應用部署包。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

在選擇好要進行釋出的新版本應用部署包後,接下來進行釋出政策的配置。這裡分為兩個部分:

  • 第一部分可以對釋出批次進行設定,例如設定釋出灰階批次,首批進行灰階的 pod 執行個體個數,分批間處理方式等;
  • 第二部分可以對流量灰階規則進行配置,我們可以選擇按流量内容進行灰階或者簡單地按照流量比例進行灰階,下面将詳細介紹這兩種釋出政策配置。

設定釋出政策

在批次釋出這裡我們可以進行的配置有:

  • 首批灰階數量:在點選釋出後,會首先将首批灰階數量個數的執行個體進行新版本的釋出,為了保證應用的穩定性,首批灰階的執行個體數不能超過應用執行個體總數的 50%。比如目前執行個體數是 7 台,那麼最多隻能選擇 3 台作為首批灰階的執行個體;
  • 剩餘批次:首批灰階釋出完成後,剩餘的應用執行個體将按照此處指定的批次釋出完成;
  • 分批間處理方式:剩餘批次間的處理方式可選擇手動或者自動,若選擇自動,則剩餘的幾個批次将在前一批釋出完成後進行自動釋出,自動釋出的批次間隔也可進行配置,例如配置每批次在釋出完成後,30 分鐘後自動進行下一批次的釋出;
  • 批次内部署間隔:每一批次内,如果此批次内要釋出的應用執行個體數大于 1,則要進行此配置指定批次内執行個體部署間隔。

在下面的例子中,我們現在有 7 個 pod 應用執行個體,選擇首批對 2 個執行個體進行灰階更新。在首批 2 個執行個體的灰階釋出完成後,将剩下的 5 個執行個體分 3 個批次進行釋出。這3個批次的批次間處理方式選擇自動釋出,在目前批次釋出完成 30 分鐘後自動進行下一批次的釋出。同時,由于第 2 批次和第 2 批次内執行個體個數為兩台,是以選擇批次内兩台執行個體部署間隔為 60 秒。在釋出頁面右側可以對我們的釋出政策配置資訊進行預覽。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

設定灰階規則

目前支援按内容灰階和按比例灰階兩種方式設定灰階規則。按請求内容進行灰階支援将請求内容符合指定灰階規則條件的流量作為灰階流量,進入到灰階執行個體中,例如,選擇使用者 ID 模 100 小于等于 40 的流量作為灰階流量進入灰階執行個體進行處理,而使用者 ID 模 100 大于 40 的仍然進入非灰階執行個體進行處理,如圖 1 所示。而按流量比例進行灰階是指,将指定比例的請求流量作為灰階流量進入灰階執行個體進行處理,例如指定 40% 的流量作為灰階流量,如圖 2 所示。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

(圖1)

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

(圖2)

按請求内容進行灰階

按請求内容進行灰階可以進行下面指定參數的配置,來決定有哪些請求内容特征的流量将作為灰階流量進入灰階執行個體中。

  • 協定類型:可選擇 Spring Cloud 和 Dubbo,這裡我們主要介紹 Spring Cloud 協定。在 Spring Cloud 協定下需要對 HTTP 請求路徑進行配置;
  • 條件模式:針對下面配置的的條件清單,可配置條件模式為:同時滿足下列條件和滿足下列任一條件。符合條件模式的請求将作為灰階流量;
  • 條件清單:Spring Cloud 協定下可分别對 Cookie、Header 和 Parameter 3 種請求内容進行條件配置。
SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

按比例進行灰階

按比例灰階即設定流量比例,然後請求流量會按配置的比例被轉發到目前的灰階分組中進行處理。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

灰階釋出并驗證新版本應用是否符合預期

配置好釋出配置後,即可開始進行灰階釋出,EDAS 将先在指定的灰階分組中部署新版本應用,可在進入變更詳情頁面檢視部署進度和狀态。如果在灰階釋出時,發現新版本有問題,還可以終止變更并對應用進行復原。

在灰階的釋出過程中,可對應用進行監控,以監控灰階流量是否符合預期,同時可以對應用狀态進行新老版本的對比。在目前批次的灰階流量驗證完成後,在變更詳情頁面單擊開始下一批,完成後續分批釋出。如果在驗證過程中,發現新版本應用有問題,可以在變更詳情頁面右上角單擊立即復原。在彈出的立即復原對話框确認復原的影響,然後單擊復原。

關于如何監控灰階流量,可以參考

EDAS文檔《監控灰階流量》

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

灰階釋出後,在基本資訊頁面檢視部署包是否為新部署的應用版本。在執行個體部署資訊頁面檢視應用執行個體的運作狀态是否為運作正常。

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰階)前言金絲雀釋出配置設定釋出政策灰階釋出并驗證新版本應用是否符合預期結語及其後續

結語及其後續

本章我們介紹了如何對 EDAS Kubernetes 叢集上的 Spring Cloud 應用進行灰階釋出,在灰階釋出過程中,我們可以靈活地配置釋出政策、灰階規則以及在釋出過程中對流量及應用狀态進行監控,并且提供了終止復原等操作,最大程度地保證應用能夠平滑地進行版本更新。接下來的文章中,我們将詳細介紹在釋出過程中如何對應用進行監控。

阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,做最懂雲原生開發者的公衆号。”