在Kubernetes上如何部署Argo Rollouts和Ambassador進(jìn)行灰度發(fā)布

Ambassador API 網(wǎng)關(guān)與 Argo 集成

灰度發(fā)布（金絲雀發(fā)布/Canary）是一種強(qiáng)大的策略，通過增量地向用戶子集發(fā)布軟件的新版本來降低生產(chǎn)風(fēng)險。假設(shè)你推出了服務(wù)的 v1.1 版本，但它有一個 bug。不是立即將它暴露給所有的流量，而是通過將 v1.1 暴露給流量的一個子集（例如 5%）來開始發(fā)布過程。隨著時間的推移，你的流量逐漸增加到 100%。在此期間，任何暴露的 bug 都僅限于你的用戶子集。

雖然理論上很簡單，但在實踐中使用灰度發(fā)布需要將 CI 流水線與持續(xù)部署工作流（如 Argo）集成在一起，并使用 API 網(wǎng)關(guān)來管理到服務(wù)的流量。

AmbassadorAPI 網(wǎng)關(guān)

Ambassador 是一個基于 Envoy 代理構(gòu)建的開源 kubernetes 原生 API 網(wǎng)關(guān)和入口控制器。Ambassador 的常見用例包括路由 gRPC 流量、認(rèn)證和速率限制。雖然 Ambassador 支持標(biāo)準(zhǔn)的 ingress 類，但大多數(shù)用戶使用 Ambassador mapping 資源。mapping 資源定義了路由并支持大量的屬性集，超出了 ingress 支持的標(biāo)準(zhǔn)集。下面是一個 mapping 示例：

apiVersion: getambassador.io/v2
kind:  Mapping
metadata:
  name:  echo
spec:
  prefix: /echo
  rewrite: /echo
  service: echo-stable:80

在 Kubernetes 上進(jìn)行灰度發(fā)布

我們已經(jīng)在 Argo Rollouts 和 Ambassador 之間建立了一個原生集成（代碼）^[1]。你現(xiàn)在可以創(chuàng)建一個 Rollout 資源來引用 Ambassador mapping：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: echo-rollout
  annotations:
spec:
  replicas: 5
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - image: hashicorp/http-echo
          args:
            - "-text=VERSION 137"
            - -listen=:8080
          imagePullPolicy: Always
          name: echo-v1
          ports:
            - containerPort: 8080
  strategy:
    canary:
      stableService: echo-stable
      canaryService: echo-canary
      trafficRouting:
        ambassador:
          mapping:
            - echo
      steps:
      - setWeight: 20
      - pause: {duration: 10s}
      - setWeight: 50
      - pause: {duration: 10s}
      - setWeight: 100
      - pause: {duration: 10}

請注意上面粗體部分，它引用了上面定義的名為 echo 的 Ambassador mapping 資源。將這些配置應(yīng)用到集群將啟動 echo-canary 服務(wù)，該服務(wù)將把 20%的流量路由到 canary，持續(xù) 10 秒，然后在 10 秒內(nèi)提升到 50%，然后再提升到 100%。