![0.png](https://ucc.alicdn.com/pic/developer-ecology/da449d5dd4e243c4a97b463e767af0d8.png)

作者 | 郝樹偉（流生）阿里雲高階研發工程師

# 前言

軟體技術更新換代很快，但我們追求的目標是一直不變的，那就是在安全穩定的前提下，增加應用的部署頻率，縮短產品功能的迭代週期，這樣的好處就是企業可以在更短的時間內獲得產品的價值、更快地獲得客戶反饋和響應客戶需求，從而進一步提升產品的競爭力；除此之外，企業還可以釋放更多的資源投入到創新業務的研發上，創造更多的價值，這是一個良性迴圈的過程。

應用產品的快速迭代誠然能給我們帶來各種各樣的好處，但挑戰也與其並存。更高頻率的應用釋出，意味著線上業務有不可預期故障的風險更大，除了產品上線之前在預發測試環境中充分測試驗證迭代功能之外，制定最合適的應用釋出策略就是另外一個非常重要的話題，因為它可以最大限度的降低業務故障的風險以及帶來的損失。

# 雲原生應用交付的關鍵點

我們說頻繁地進行產品迭代意味著更大的故障風險，傳統應用如此，雲原生應用更是如此。因為雲原生應用通常都是基於雲的分散式部署模式，且每個應用可能是由多個功能元件互相呼叫來一起提供完整的服務的，每個元件都有自己獨立的迭代流程和計劃。在這種情況下，功能元件越多，意味著出錯的機率越大。那麼如何在應用交付層面對上述這些痛點做出改進，我們總結出以下幾個雲原生應用交付的關鍵點。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/c01efe813149468f9235b718998a2ad9.png)

- 如何充分利用雲原生架構基礎設施的優勢。這個優勢我們可以簡單總結為兩點：彈性和高可用；
- 如何具有跨平臺移植和交付的能力。基礎設施底層的計算、儲存、網路資源有很大的差異化，在以前，基礎架構的不同是由上層應用決定的，而云原生應用的交付需要具有跨平臺移植和交付的能力；
- 如何實現應用運維自治化。自治化不等於自動化，自動化是指觸發一個流程，流程結束後能自動達到想要的一個預期結果，而自治化是指應用再高可用的執行態時，如果其中某個功能元件的某個副本出現故障，應用能自動移除故障副本並補充新的應用副本；
- 如何讓應用變得更具有可預測性。應用的交付終態，在我們編寫應用編排模板的時候就是可預測到的，如果應用的交付變得更有可預測性，那麼風險也會最大程度地降低；
- 如何提高應用更快的平均恢復時間。如果應用有超出了應用自治的能力範疇之外的故障發生需要人工介入，那更快的平均恢復時間就意味著更低的業務損失。

Kubernetes 是一個可移植的，可擴充套件的開源平臺，用於管理容器化的工作負載和服務，可促進宣告式配置和自動化。它自身的平臺能力已經滿足了我們前面提到的大部分需求。Kubernetes 使用容器技術部署應用，這樣的好處包括但不限於：

- 應用程式建立和部署更敏捷
- 可移植性
- 環境一致性
- 松耦合和分散式
- 資源隔離
- 高效率和高密度的資源利用

![2.png](https://ucc.alicdn.com/pic/developer-ecology/57b4294a64c74e9aa3b3cbbdd28e256c.png)

Kubernetes 還提供了應用管理、排程、監控和運維的強大能力：

- 服務發現和負載均衡能力
- 應用的自動部署和回滾能力
- 應用的自治修復能力
- 儲存編排能力
- 金鑰和配置管理能力

但 Kubernetes 它也有很多功能是不提供但允許擴充套件的部分，比如日誌採集、監控報警等能力。下面這張圖就是阿里雲容器服務是在支援標準 Kubernetes 的基礎上，對與使用者息息相關的能力做了增強和提升後的架構大圖，包括提供最大的彈性化與低廉成本的全球化接入能力，強大的安全架構支撐能力，深度整合阿里雲基礎資源服務的能力，並經過 雙11 驗證和沉澱了海量使用者經驗，同時支援專有、託管、無服務化、邊緣和神龍裸金屬等多種產品形態，我們今天后面的所有演示就是在此平臺上做的。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/9e43aa871e7a4631a29c1c399b0aa136.png)

# 應用交付的邊界

在 Kubernetes 中應用交付的邊界是什麼？

從簡單處入手，我們可以認為應用的交付就是它的網路服務模式，服務的的後端資源以及業務資料的持久化儲存，這些資源被分別抽象成 service、deployment/pod，volume 資源等。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/9ec1091394864361aeec1846400d5ee6.png)

以一個 wordpress 應用為例，它包括兩個功能元件：前端元件處理使用者請求，後端元件儲存資料。前端元件包括一個 frontend service 和 3 個 pod，後端元件包括一個 backend service 和一個 pod 元件，所以這個 wordpress 應用交付的資源就是 2 個 service 和總共 4 個後端 pod。這個後端的 pod 資源我們在 Kubernetes 中透過 deployment 來統一管理，service 資源相當於一個負載均衡器，把請求路由到後端 pod 上，它涉及叢集內各個元件之間呼叫以及外部使用者訪問叢集內服務，所以有不同的種類劃分。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/791605503b234f8296c7981b1c93bf6d.png)

根據服務暴露的方式不同，可以分為以下幾種：

## ClusterIP

透過為 Kubernetes 的 Service 分配一個叢集內部可訪問的固定虛擬 IP（Cluster IP），實現叢集內的訪問。為最常見的方式。

```
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: ClusterIP      # 預設的service型別，服務僅暴露為叢集內部可訪問
  ports:
    - port: 80         # 暴露給叢集內部的服務埠
      targetPort: 80   # 容器監聽的服務埠
      protocol: TCP
  selector:
    app: wordpress     # 轉發請求到有相同標籤的後端pod
```

## NodePort

NodePort 是把 service 的 port 對映到叢集節點的一個埠上，如果你不指定這個埠，系統將選擇一個隨機埠。大多數時候我們應該讓 Kubernetes 來選擇埠，使用者自己來選擇可用埠代價太大。

```
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort       # NodePort service型別，服務暴露一個固定的靜態埠用於叢集外部訪問
  ports:
    - port: 80         # 暴露給叢集內部的服務埠
      targetPort: 80   # 容器監聽的服務埠
      protocol: TCP
      nodePort: 31570  # 叢集外部可以透過此埠訪問服務
  selector:
    app: wordpress     # 轉發請求到有相同標籤的後端pod
```

NodePort 的方式雖然可以把服務暴露給叢集外訪問，但是也有很多缺點：

- 每個埠只能是一種服務
- 埠範圍有限制，一般是 30000-32767
- 如果節點的 IP 地址變化了的話，你需要做一些變更操作去適配

所以在生產中一般不推薦這種方式，但如果你的應用對成本比較敏感又能容忍服務有不可用視窗期的話，是可以使用這種方式的。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/cd7d1e96594443f1b1ceff117cedd76a.png)

## LoadBalancer

LoadBalancer 是服務暴露到叢集外或者公網上的標準方式，但它依賴 cloud provider 提供的一個負載均衡器的能力，負載均衡器會單獨分配一個 ip 地址並監聽後端服務的指定埠，請求的流量會透過指定的埠轉發到後端對應的服務。

```
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: LoadBalancer       # LoadBalancer service型別，一般依賴於公共雲廠商供的負載均衡能力
  ports:
    - port: 80         # 暴露給叢集內部的服務埠
      targetPort: 80   # 容器監聽的服務埠
      protocol: TCP
  selector:
    app: wordpress     # 轉發請求到有相同標籤的後端pod
```

![7.png](https://ucc.alicdn.com/pic/developer-ecology/04edc844104344b9ae8edcc22059b0ab.png)

## Ingress

`ClusterIP` 服務型別僅限叢集內通訊，`NodePort` 可以實現暴露服務訪問入口，但每個節點都會佔用一個埠，會增加埠管理的複雜性，LoadBalancer 通常需要第三方雲提供商支援，有一定的約束性。而 Ingress 這個服務型別跟我們前面的三種服務型別不一樣，它實際上不是一種服務型別，而是類似一種叢集服務入口的存在，它可以基於你配置的不同路徑或者子域名把流量路由到對應的後端服務，更像是一個“智慧路由”服務。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/236d6789a74547bba0aa1066f333ff26.png)

前面介紹了一些應用釋出涉及到的資源型別，以及 service 資源型別的幾種模式，那 service 如何找到對應的後端 pod 呢，這個就是標籤的作用，我們可以把每個應用的 pod 和 service 都打上同樣的標籤，這個標籤的機制就是我們後面要講的幾種應用釋出策略的關鍵點了。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/38ae0744c8d441ac98d0362b080cea55.png)

# 應用的釋出策略
在 Kubernetes 叢集中，除了根據業務需求選定服務暴露方式外，為了讓應用在升級期間依然平穩提供服務，選擇一個正確的釋出策略就非常重要了。

## 滾動釋出

第一種應用釋出策略就是滾動釋出，這也是比較常見的策略。它是透過逐個替換例項來逐步部署新版本的應用，直到所有例項都被替換完成為止。

如下圖所示，當前我的應用提供的服務版本是 v1， 這個服務的後端有 3 個副本， 但我更新版本 v2 的時候，它是一個副本一個副本地開始替換，直到最終服務的後端全部替換成 v2 版本。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/2366845351dd4d5f9f8edacef77ce516.png)

一個應用示例的編排檔案如下所示：

- `go-demo-v1.yaml`

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-demo
  template:
    metadata:
      labels:
        app: go-demo
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
  type: ClusterIP
```

- 部署版本 v1

```
$ kubectl apply -f go-demo-v1.yaml
```

- 檢視 pod 執行狀態

```
$ kubectl get po
NAME                       READY   STATUS    RESTARTS   AGE
go-demo-78bc65c564-2rhxp   1/1     Running   0          19s
go-demo-78bc65c564-574z6   1/1     Running   0          19s
go-demo-78bc65c564-sgl2s   1/1     Running   0          19s
```

- 訪問應用服務

```
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
```

- 更新 `go-demo-v1.yaml` 為 `go-demo-v2.yaml` 並更新映象 tag

```
...
registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
...
```

- 部署版本 v2

```
$ kubectl apply -f go-demo-v2.yaml
```

- 可以檢視 pod 會被新版本 pod 逐個替換

```
$kubectl get po -w
NAME                                READY   STATUS              RESTARTS   AGE
application-demo-8594ff4967-85jsg   1/1     Running             0          3m24s
application-demo-8594ff4967-d4sv8   1/1     Terminating         0          3m22s
application-demo-8594ff4967-w6lpz   0/1     Terminating         0          3m20s
application-demo-b98d94554-4mwqd    1/1     Running             0          3s
application-demo-b98d94554-ng9wx    0/1     ContainerCreating   0          1s
application-demo-b98d94554-pmc5g    1/1     Running             0          4s
```

- 訪問服務會發現在應用滾動升級過程中，版本 v1 和 v2 都會被訪問到，這個時間的長短取決於應用的啟動速度

```
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
```

滾動釋出優點就是它比較簡單，而且不會佔用太多的計算資源。缺點是：

- 版本在例項之間緩慢替換
- 這個滾動釋出可能需要一定時間
- 無法控制流量

從應用在叢集中的終態上來說，叢集中要麼只有版本 1 的應用後端，要麼只有版本 2 的後端；如果版本 2 有缺陷，那麼線上服務應用到的就是整體使用者， 雖然我們有機制可以快速回滾，但涉及到整體使用者使用故障的代價還是太大。

## 藍綠髮布

第二種就是藍綠髮布，藍/綠髮布是應用版本 1 與版本 2 的後端 pod 都部署在環境中，透過控制流量切換來決定釋出哪個版本。與滾動釋出相比，藍綠髮布策略下的應用終態，是可以同時存在版本 1 和版本 2 兩種 pod 的，我們可以透過 service 流量的切換來決定當前服務使用哪個版本的後端。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/ba966234f1784e0d8bb6184b1ca0c4e9.png)

一個應用示例的編排檔案如下所示。

- `go-demo-v1.yaml`

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 4
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `go-demo-v2.yaml`

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 4
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `service.yaml`

```
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v1
  type: ClusterIP
```

- 部署以上 3 個資源

```
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
```

- 訪問服務可以看到目前只訪問到版本 1 的服務

```
$ while sleep 0.1; do curl http://172.19.8.137; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
```

- 修改 `service.yaml` 的 spec.selector 下 version=v2

```
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v2
  type: ClusterIP
```

- 重新部署

```
$ kubectl apply -f service.yaml
```

- 重新訪問服務可以看到很快切換到了版本 2 上

```
$ [root@iZbp13u3z7d2tqx0cs6ovqZ blue-green]# while sleep 0.1; do curl http://172.19.8.137; done
Version: v2
Version: v2
Version: v2
```

我們剛才說到滾動升級有一個過程需要時間，即使回滾，它也需要一定的時間才能回滾完畢，在新版本應用有缺陷的情況下，藍綠髮布的策略可以快速在 v1 和 v2 兩個版本之前切流量，所以這個切換流量的時間跟滾動升級相比就縮短了很多了，但藍綠髮布的缺點跟滾動釋出相同的就是這個缺陷會影響到整體使用者，服務要麼百分百切換到版本 2 上，要麼百分百切換到版本 1 上，這是個非 0 即 100 的操作，即使藍綠髮布策略可以大大縮短故障恢復時間，但在某些場景下也是不可接受的。 而且叢集環境中同時存在兩個版本的 pod 副本，資源佔用的話相比滾動釋出是 2 倍的。

## 金絲雀釋出（灰度釋出）

第三種要介紹的釋出策略是金絲雀釋出，金絲雀部署是應用版本 1 和版本 2 同時部署在環境中，並且使用者請求有可能會路由到版本 1 的後端，也可能會路由到版本 2 的後端，從而達到讓一部分新使用者訪問到版本 2 的應用。 這種釋出策略下，我們可以透過調整流量百分比來逐步控制應用向新的版本切換，它與藍綠部署相比，不僅繼承了藍綠部署的優點，而且佔用資源優於藍綠部署所需要的 2 倍資源，在新版本有缺陷的情況下隻影響少部分使用者，把損失降到最低。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/4a38550086164ef9bb1847b7fef0ae85.png)

對於灰度釋出的概念來說，有人認為它跟金絲雀釋出講的是一個東西，有人認為它們不同。它跟金絲雀釋出的過程是相同的，但目的有所不同：

- 金絲雀釋出更傾向於能快速獲取使用者的一些反饋，比如我可能不確定我的這個新版本功能的使用者體驗是否能被大眾很好的接受，我期望能得到線上使用者的一些及時反饋，在產品側做功能體驗調整之後再迭代 v3 版本；
- 而灰度釋出則是我的產品功能已經設計並開發的很完善了，現在就是要逐步替換線上的舊版本，但是要控制釋出可能帶來的風險，所以要灰度釋出。

示例應用 1 如下， 這個示例中我們透過 pod 的數量來控制流量比例。

- `go-demo-v1.yaml` 設定副本數為 9

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 9
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `go-demo-v2.yaml` 設定副本數為 1

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `service.yaml`

```
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
  type: ClusterIP
```

- 部署以上 3 個資源

```
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
```

- 訪問服務可以看到基本上是 10% 的流量切換到版本 2 上

```
$ while sleep 0.1; do curl http://172.19.8.248; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
```

另外我們可以使用 nginx ingress controller 來控制流量切換，這個方式要更精準。

- `go-demo-v1.yaml`

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `go-demo-v2.yaml`

```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
```

- `service-v1.yaml`

```
apiVersion: v1
kind: Service
metadata:
  name: go-demo-v1
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v1
  type: ClusterIP
```

- `service-v2.yaml`

```
apiVersion: v1
kind: Service
metadata:
  name: go-demo-v2
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v2
  type: ClusterIP
```

- `ingress.yaml`， 設定 `nginx.ingress.kubernetes.io/service-weight: | go-demo-v1: 100, go-demo-v2: 0`， 版本1 - 100% 流量， 版本2 - 0% 流量

```
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 100, go-demo-v2: 0
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80
```

- 部署以上 4 個資源

```
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml
```

- 訪問服務可以看到流量 100% 到版本 1 上

```
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
```

- 更新 `ingress.yaml`， 設定流量比為 50:50

```
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 50, go-demo-v2: 50
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80
```

- 訪問服務可以看到流量 50% 到版本 1 上， 50% 到版本 2 上

```
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v1
Version: v1
Version: v1
Version: v2
Version: v2
Version: v1
Version: v1
Version: v2
Version: v2
```

- 更新 `ingress.yaml`， 設定流量比為 0:100

```
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 0, go-demo-v2: 100
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80
```

- 訪問服務可以看到流量 100% 到版本 2 上

```
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
```

不管是金絲雀釋出還是灰度釋出，缺點就是釋出週期相對來說要慢很多。

在這些釋出策略當中，

- 當你在開發測試環境中對應用做更新發布的話，用滾動釋出；
- 在生產環境，滾動更新或者藍綠髮布在新版本已經提前測試充分的情況下可以用；
- 如果對新版本的應用的更新需要最大限度地控制風險，降低故障對使用者的影響的話，那就使用金絲雀釋出或灰度釋出。

以上就是我們在 Kubernetes 當中常用的幾種釋出策略的介紹。

![2群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/e6741f9ea448426f91c2604156763931.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

3 種釋出策略，解決 K8s 中快速交付應用的難題

相關文章