*作者：趙明山（立衡）*

## 前言

Kruise Rollout 是 OpenKruise 社群開源的漸進式交付框架。Kruise Rollout 支援配合流量和例項灰度的金絲雀釋出、藍綠髮布、A/B Testing 釋出，以及釋出過程能夠基於 Prometheus Metrics 指標自動化分批與暫停，並提供旁路的無感對接、相容已有的多種工作負載（Deployment、CloneSet、DaemonSet）。

近期也在《2022 開放原子全球開源峰會》上面做了主題分享，以下是主要內容。

## 什麼是漸進式交付？

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f3d955e1a35484e90d7922c655f71d1~tplv-k3u1fbpfcp-zoom-1.image "1.png")

漸進式釋出主要區別於全量、一次性發布。它主要包含以下特點：

-   **增量的釋出過程**：通俗講就是我們可以將一次釋出分成多個批次，並且可以控制每個批次的開始與停止。

-   **例項與流量雙重維度的灰度**：比如社群常見的金絲雀釋出、A/B Testing 釋出、藍綠髮布。

-   **階段可驗證性**：就是釋出的每個批次，可以驗證釋出的正確性、是否符合預期。

下面我們來看一個實際的例子。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2d95234c87614094b4c0dae1e1b4efdc~tplv-k3u1fbpfcp-zoom-1.image "2.png")

假如線上是 X 版本，現在需要釋出到 Y 版本。首先，會將釋出分為多個批次（比如，第一批只發布十個例項）；然後，灰度一定規則的流量到 Y 版本，比如：像淘寶每次重大/釋出，會使用 A/B Testing 的方式，只將公司員工灰度到新版本；最後，驗證新版本的健康情況，驗證 OK 後，可以重複上述的過程，完成剩餘的批次。如果在這個過程中發現了任何異常，可以快速回滾到 X 版本。透過上面這個例子，**漸進式釋出與全量釋出相比，增加了很多中間的驗證過程，漸進式釋出可以說是極大的提高了交付的穩定性，尤其是針對一些大規模的場景而言，漸進式釋出是非常有必要的。**

## 漸進式釋出與 K8s 工作負載之間的關係

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/afce982032da4aaaa13015611b32622c~tplv-k3u1fbpfcp-zoom-1.image "3.png")

K8s 當中所有的 Pod 都是由工作負載來管理的，其中最常見的兩個工作負載就是 Deployment 和 statefulset。Deployment 對於升級而言提供了 maxUnavailable 和 maxSurge 兩個引數，但是本質上來講 Deployment 它只支援流式的一次性發布，使用者並不能控制分批。StatefulSet 雖然支援分批，但是跟我們想要的漸進式釋出的能力還有比較大的距離。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/09895d4d2eb746b5bde9a0f71d6b2d50~tplv-k3u1fbpfcp-zoom-1.image "4.png")

所以漸進式釋出與工作負載從能力上講是一種包含關係，它除了基礎的 Pod 釋出之外，還應該包含**流量釋出**和**進度控制**。既然能力上已經梳理清楚了，下面我們就要看看實現，如何去設計和實現 Rollout 能力也是非常重要的。在這我們可以考慮一個問題，從設計的角度看他們也是包含關係嗎？

## Rollout 方案的設計理念

準備開始做這件事情前，肯定要先調研一下社群的優秀方案，看看其他人是如何解決的。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/041520394edf42a8b7acabedb83324a4~tplv-k3u1fbpfcp-zoom-1.image "5.png")

Argo Rollout 是 Argo 公司推出的 Workload，它的實現思路是：重新定義一個類似於 Deployment 的工作負載，在實現 Deployment 原有能力的基礎上，又擴充套件了 Rollout 的相關能力。它的優點是工作負載內建了 Rollout 能力，配置簡單、實現也會比較簡單，並且目前支援的功能也非常的豐富，支援各種釋出策略、流量灰度和 metrics 分析，是一個比較成熟的專案。

但是它也存在一些問題，因為它本身就是一個工作負載，所以它不能適用於社群 Deployment，尤其是針對已經用 Deployment 部署的公司，需要一次線上遷移工作負載的工作。其次呢，現在社群的很多方案是依賴 Deployment 實現的，並且很多公司已經構建了基於 Deployment 的容器管理平臺，都要進行相容適配。所以，Argo-Rollout 更加適用於定製化能力較強的、沒有存量 Deployment 的公司業務。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/98a454f2cd5b433aaa62785300951045~tplv-k3u1fbpfcp-zoom-1.image "6.png")

另一個社群專案是 Flagger，它的實現思路跟 Argo-Rollout 完全不同。它沒有單獨的實現一個 workload，而是在現有 Deployment 的基礎之上，擴充套件了流量灰度、分批發布的能力。

Flagger 的優勢是支援原生 Deployment 、並且與社群的 Helm、Argo-CD 等方案都是相容的。但是也存在一些問題，首先就是釋出過程中的 Double Deployment 資源的問題，因為它是先升級使用者部署的 Deployment，再升級 Primary，所以在這過程中需要準備雙倍的 Pod 資源。第二呢，針對一些自建的容器平臺需要額外對接，因為它的實現思路是將使用者部署資源都 copy 一份，且更改資源的名字以及 Label。所以，Flagger 更加適合那種規模不大、基於社群方案部署、定製化較小的公司。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a420bab13ea64ef585474768dd20a0f0~tplv-k3u1fbpfcp-zoom-1.image "7.png")

另外，百花齊放是雲原生的一大特點。阿里雲容器團隊負責整個容器平臺雲原生架構的演進，在應用漸進式交付領域也有強烈的需求，因此在參考社群方案以及考慮阿里內部場景的基礎上，我們在設計 Rollout 過程中有以下幾個目標：

1. **無侵入性**：對原生的 Workload 控制器以及使用者定義的 Application Yaml 定義不進行任何修改，保證原生資源的乾淨、一致

2. **可擴充套件性**：透過可擴充套件的方式，支援 K8s Native Workload、自定義 Workload 以及 Nginx、Isito 等多種 Traffic 排程方式

3. **易用性**：對使用者而言開箱即用，能夠非常方便的與社群 Gitops 或自建 PaaS 結合使用

## Kruise Rollout 工作機制與演進

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/15d8f515f6a9441da9445c380d54e1f4~tplv-k3u1fbpfcp-zoom-1.image "8.png")

Kruise Rollout API 設計是非常簡單的，主要包含以下四個部分：

-   **ObjectRef**：用於表明 Kruise Rollout 所作用的工作負載，例如：Deployment Name

-   **Strategy**：定義了 Rollout 釋出的過程，如上是一個金絲雀釋出的示例，第一批發布 5% 的例項，並且灰度 5% 流量到新版本，待人工確認後，再進行後續釋出****

-   **TrafficRouting**：流量灰度所需要的資源 Name，例如：Service、Ingress 或 Gateway API****

-   **Status**：用來展示 Rollout 的過程以及狀態

接下來介紹一下 Kruise Rollout 的工作機制。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/31097149a151401da4d161b6c9ed49c7~tplv-k3u1fbpfcp-zoom-1.image "9.png")

首先，使用者基於容器平臺做一次版本釋出（一次釋出從本質上講就是將 K8s 資源 apply 到叢集中）。

-   Kruise Rollout 包含一個 webhook 元件，它會攔截使用者的釋出請求，然後透過修改 workload strategy 的方式 Pause 住 workload 控制器的工作。

-   然後，就是根據使用者的 Rollout 定義，動態的調整 workload 的引數，比如：partition，實現 workload 的分批發布。

-   等到批次釋出完成後，又會調整 ingress、service 配置，將特定的流量匯入到新版本。

-   最後，Kruise Rollout 還能夠透過 prometheus 中的業務指標判斷髮布是否正常。比如說，對於一個 web 類 http 的服務，可以校驗 http 狀態碼是否正常。

上面的過程，就完成了第一批次的灰度，後面的批次也是類似的。完整的 Rollout 過程結束後，kruise 會將 workload 等資源的配置恢復回來。 所以說，整個 Rollout 過程，是與現有工作負載能力的一種協同，它儘量複用工作負載的能力，又做到了非 Rollout 過程的零入侵。

Kruise Rollout 工作機制就先介紹到這裡，下面我簡單介紹一下 OpenKruise 社群。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cf247498ae9f4422ba87583aaf76a9e5~tplv-k3u1fbpfcp-zoom-1.image "10.png")

## 最後

隨著 K8s 上面部署的應用日益增多，如何做到業務快速迭代與應用穩定性之間的平衡，是平臺建設方必須要解決的問題。Kruise Rollout 是 OpenKruise 在漸進式交付領域的新探索，旨在解決應用交付領域的流量排程以及分批部署問題。Kruise Rollout 目前已經正式釋出 v0.2.0 版本，並且與社群 OAM KubeVela 專案進行了整合，vela 使用者可以透過 Addons 快速部署與使用 Rollout 能力。此外，也希望社群使用者能夠加入進來，我們一起在應用交付領域做更多的擴充套件。

-   *Github：*
    *<https:>*

-   *Official：*
    *<https:></https:>*

-   *Slack:*
    *<https:></https:>*

掃碼加入社群交流釘釘群

![12.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/506596f5f7b24ff3a924117ab59cdc27~tplv-k3u1fbpfcp-zoom-1.image "12.jpeg")

戳[此處](https://github.com/openkruise/kruise)，檢視 OpenKruise 專案 github 主頁！</https:>

Kruise Rollout：靈活可插拔的漸進式釋出框架

相關文章