Kubernetes 中的金絲雀部署#3：Istio

使用 Istio+Kiali 啟動和視覺化 Canary 部署

本系列文章

1. Kubernetes 中的金絲雀部署 #1：Gitlab CI
2. Kubernetes 中的 Canary 部署 #2：Argo 推出
3. （本文）
4. 使用 Jenkins-X Istio Flagger 進行金絲雀部署

金絲雀部署

我們希望您閱讀 第一部分，我們簡要地解釋了 Canary 部署是什麼，並展示瞭如何使用標準 Kubernetes 資源來實現它們。

Istio

我們假設透過閱讀本文，您已經了解 Istio 是什麼。 如果沒有，那麼您可以閱讀相關內容 這裡.

申請測試

每個 Pod 包含兩個容器：我們的應用程式和 istio-proxy。

我們將使用一個帶有前端 nginx 和後端 python pod 的簡單測試應用程式。 nginx pod 將簡單地將每個請求重新導向到後端 pod 並充當代理。 詳細資訊可以在以下 yaml 中找到：

• 前端.yaml
• 後端.yaml
• istio.yaml

自己運行測試應用程式

如果您想按照我的範例並自行使用此測試應用程序，請參閱 項目自述文件.

初始部署

當我們啟動第一個 Deployment 時，我們看到應用程式的 pod 只有 2 個容器，即 Istio sidecar 剛剛實作：

我們還在命名空間中看到 Istio Gateway Loadbalancer istio-system:

流量產生

我們將使用下列 IP 產生前端 Pod 接收並轉送至後端 Pod 的流量：

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

我們還將添加 frontend.istio-test 到我們的主機檔案。

透過 Kiali 查看網格

我們安裝了測試應用程式和 Istio，以及 Tracing、Grafana、Prometheus 和 Kiali（詳細資訊請見下文）。 項目自述文件）。 因此我們可以透過以下方式使用 Kiali：

istioctl dashboard kiali # admin:admin

Kiali 透過 Mesh 可視化當前流量

正如我們所看到的，100% 的流量流向前端服務，然後流向帶有標籤v1 的前端Pod，因為我們使用簡單的nginx 代理將請求重定向到後端服務，後端服務又將它們重定向到後端Pod附有標籤 v1。

Kiali 與 Istio 配合得很好，並為網格渲染提供了盒裝解決方案。 太棒了。

金絲雀部署

我們的後端已經有兩個 k8 部署，一個用於 v1，一個用於 v2。 現在我們只需要告訴 Istio 將一定比例的請求轉送到 v2 即可。

第 1 步：10%

我們需要做的就是調整 VirtualService 的權重 istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

我們看到 10% 的請求被重新導向到 v2。

第 2 步：50%

現在只需將其增加到 50% 就足夠了：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

第 3 步：100%

現在可以認為 Canary 部署完成，所有流量都會重新導向到 v2：

手動測試 Canary

假設我們現在將所有請求的 2% 發送到 v10 後端。 如果我們想手動測試 v2 以確保一切按我們的預期工作怎麼辦？

我們可以根據HTTP headers添加特殊的匹配規則：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

現在使用curl我們可以透過發送標頭來強制v2請求：

沒有標頭的請求仍將以 1/10 比例驅動：

兩個依賴版本的金絲雀

現在我們將考慮前端和後端都有 v2 版本的選項。 對於兩者，我們指定 10% 的流量應流向 v2：

我們看到前端v1和v2都以1/10的比例轉送後端v1和v2的流量。

如果我們需要將流量從 frontend-v2 轉送到 backend-v2，因為它與 v1 不相容怎麼辦？ 為此，我們將為前端設定 1/10 比率，該比率透過協商控製到達後端 v2 的流量 sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

結果，我們得到了我們需要的：

與手動 Canary 方法的差異

В 第一部分 我們手動執行 Canary 部署，同樣使用兩個 k8s 部署。 在那裡，我們透過更改副本數量來控制請求的比率。 這種方法有效，但有嚴重的缺點。

Istio 使得無論副本數量多少都可以決定請求的比率。 例如，這意味著我們可以使用 HPA（Horizo​​ntal Pod Autoscalers），並且不需要根據 Canary 部署的當前狀態進行設定。

總

Istio 工作得很好，與 Kiali 一起使用可以形成非常強大的組合。 我的下一個興趣是將 Spinnaker 與 Istio 結合起來以實現自動化和金絲雀分析。

來源： www.habr.com