Istio 在阿里雲容器服務的部署及流量治理實踐

目標

• 在阿里雲容器服務 Kubernetes 集羣上部署 Istio 服務網格
• 實踐灰度發佈、故障注入、熔斷等 Istio 流量管理特性

準備工做

1. 安裝和設置 kubectl 客戶端，請參考不一樣的操做系統，若是已經安裝請忽略：

• macOS

curl -LO https://kubectl.oss-cn-hangzhou.aliyuncs.com/macos/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl --help

• Linux

curl -LO https://kubectl.oss-cn-hangzhou.aliyuncs.com/linux/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl --help

• Windows

把 https://kubectl.oss-cn-hangzhou.aliyuncs.com/windows/kubectl.exe 放到系統PATH路徑下

kubectl --help

配置 kubectl 鏈接 Kubernetes 集羣的配置，可參考文檔 經過kubectl鏈接Kubernetes集羣

實驗步驟

部署Istio

1. 登陸容器服務控制檯，在集羣列表中選擇一個集羣，打開更多 - 部署 Istio
2. 保持默認配置，點擊"部署 Istio"

1. 等待完成後，Istio 已經成功部署在 Kubernetes 集羣中
2. 使用 kiali 查看服務網格可視化

kubectl port-forward -n istio-system "$(kubectl get -n istio-system pod --selector=app=kiali -o jsonpath='{.items..metadata.name}')" 20001

在本地瀏覽器中訪問 http://localhost:20001 ，使用默認帳戶 admin/admin 登陸

灰度發佈

1. 建立命名空間並開啓 Sidecar 自動注入：單擊左側導航欄中的集羣 > 命名空間，進入命令空間頁面，建立一個名稱爲 demo 的命名空間，併爲其添加一個 istio-injection:enabled 的標籤
2. 單擊左側導航欄中服務網格 > 虛擬服務，進入虛擬服務（Virtual Service）頁面，點擊建立，建立一個簡單的示例應用，指定應用名稱爲istio-app，指定應用版本爲v1，選擇剛剛建立的命名空間 demo
3. 配置應用容器，使用以下鏡像：registry.cn-beijing.aliyuncs.com/test-node/node-server:v1
4. 配置服務，服務名稱爲istio-app-svc，類型爲虛擬集羣 IP ，服務端口和容器端口均爲8080
5. 提交應用配置，將會自動建立 Deployment、Service、DestinationRule、VirtualService
6. 單擊導航欄中的應用 > 容器組，確認全部的 Pod 都已經正確的定義和啓動
7. 建立服務客戶端測試應用

kubectl apply -n demo -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - name: sleep
        image: pstauffer/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
EOF

1. 在測試應用的 Pod 中訪問 Istio 應用：登陸到 sleep 應用的 Pod 中

kubectl exec -it -n demo "$(kubectl get -n demo pod --selector=app=sleep -o jsonpath='{.items..metadata.name}')" sh

執行以下命令調用以前部署的 Istio 應用：

for i in `seq 1000`
do
curl http://istio-app-svc.demo:8080;
echo '';
sleep 1;
done;

能夠看到返回的信息：

Hello from v1
Hello from v1
Hello from v1

1. 單擊左側導航欄中服務網格 > 虛擬服務，進入虛擬服務（Virtual Service）頁面，找到istio-app-svc服務，點擊管理，在版本管理中，點擊增長灰度版本，新的版本指定爲v2

在容器配置中使用如下鏡像：

registry.cn-beijing.aliyuncs.com/test-node/node-server:v2

在灰度策略中選擇基於流量比例發佈，流量比例 50%

1. 提交灰度發佈後，查看 sleep 應用的調用結果，能夠看到，v1和v2版本的返回結果

Hello from v1
Hello from v2
Hello from v1
Hello from v1
Hello from v2
Hello from v1

1. 在 kiali 中查看，能夠確認，調用被分發到兩個版本中

故障注入

1. 目前應用工做正常，咱們爲 istio-app-svc 注入故障，以測試整個應用的彈性。在 istio-app-svc 的管理界面中，打開故障注入策略，選擇注入中斷故障，百分比 50%，狀態碼 503

1. 提交後，繼續查看 sleep 應用的調用結果，便可看到 istio-app-svc 服務約有 50% 的機率沒法訪問，輸出fault filter abort。

Hello from v1
Hello from v1
Hello from v1
fault filter abort
fault filter abort
fault filter abort
Hello from v1
Hello from v2
fault filter abort
Hello from v2
Hello from v2

同時，在 kiali 可視化界面中，也能夠看到 sleep 服務對 istio-app-svc 服務的調用有 50% 左右的失敗比例

1. 除此以外，咱們也能夠爲服務注入時延故障，例如在上述界面中，選擇時延故障，爲 50% 的請求添加 5s 的時延

1. 確認提交以後，咱們能夠看到，部分調用的耗時顯著增長。在 kiali 中也能夠查看調用的平均請求耗時

1. 刪除故障注入策略和灰度版本 v2

熔斷

1. 在 DestinationRule 中設置熔斷規則

kubectl delete destinationrule -n demo istio-app-svc
kubectl apply -n demo -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: istio-app-svc
spec:
  host: istio-app-svc
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v2
    name: v2
EOF

1. 部署一個 HTTP 客戶端，用於負載測試

kubectl apply -n demo -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/sample-client/fortio-deploy.yaml

1. 在上面的熔斷設置中指定了 maxConnections: 1 以及 http1MaxPendingRequests: 1。這意味着若是超過了一個鏈接同時發起請求，Istio 就會熔斷，阻止後續的請求或鏈接。所以咱們以併發數爲 3，發出 100 個請求：

FORTIO_POD=$(kubectl -n demo get pod | grep fortio | awk '{ print $1 }')
kubectl -n demo exec -it $FORTIO_POD  -c fortio /usr/bin/fortio -- load -c 3 -qps 0 -n 100 -loglevel Warning http://istio-app-svc:8080

從結果中，能夠看到，有超過 40% 的請求被 Istio 阻斷了。

Code 200 : 57 (57.0 %)
Code 503 : 43 (43.0 %)
Response Header Sizes : count 100 avg 130.53 +/- 113.4 min 0 max 229 sum 13053
Response Body/Total Sizes : count 100 avg 242.14 +/- 0.9902 min 241 max 243 sum 24214
All done 100 calls (plus 0 warmup) 0.860 ms avg, 2757.6 qps

在 kiali 中觀察能夠發現，這部分請求並無真正到達 istio-app-svc 的 Pod

1. 經過查詢 istio-proxy 的狀態，能夠得到更多信息，upstream_rq_pending_overflow 的值即爲被熔斷策略阻止的請求數

kubectl -n demo exec -it $FORTIO_POD -c istio-proxy -- sh -c 'curl localhost:15000/stats' | grep istio-app-svc | grep pending

cluster.outbound|8080|v1|istio-app-svc.demo-ab.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|8080|v1|istio-app-svc.demo-ab.svc.cluster.local.upstream_rq_pending_failure_eject: 0
cluster.outbound|8080|v1|istio-app-svc.demo-ab.svc.cluster.local.upstream_rq_pending_overflow: 99
cluster.outbound|8080|v1|istio-app-svc.demo-ab.svc.cluster.local.upstream_rq_pending_total: 199

清理實驗環境

執行如下命令：

kubectl delete ns demo

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。