全部產品
Search

搜尋本產品

    Alibaba Cloud Service Mesh：應用Sidecar資源後的配置推送最佳化效果

    文件中心

    Alibaba Cloud Service Mesh：應用Sidecar資源後的配置推送最佳化效果

    更新時間：Jun 30, 2024

    如果您的單個命名空間中存在大量的服務，需要對Sidecar配置進行最大限度的精簡，您可以使用Sidecar資源推薦功能。本文以部署420個Pod的較大規模叢集為例，測試並分析應用Sidecar資源後的Service Mesh配置推送最佳化效果。

    前提條件

    在叢集中部署測試應用

    本文在ns-in-mesh命名空間建立多個sleep應用與httpbin應用類比叢集中存在數量龐大的服務，且服務與服務之間只存在少量調用依賴關係。關於如何建立命名空間，請參見管理全域命名空間。

    • httpbin應用在啟動後會在8000連接埠暴露一個HTTP服務，用於類比叢集內部大量被調用的服務。

    • sleep應用程式套件含一個curl容器，通過修改應用部署的command欄位，使sleep應用在休眠之前調用多個httpbin的容器提供的服務，用於類比叢集內依賴其它服務的服務。

    1. 在叢集中部署多個httpbin應用。

      1. 使用以下YAML內容，建立名為httpbin-{i}的YAML檔案。

        說明

        httpbin-{i}中的{i}可用具體數字代替，以產生多個不同的帶編號的httpbin服務。使用此模板可以產生任意多個httpbin應用，具體應用數量限制取決於叢集的規模。本文以使用該模板產生200個httpbin應用部署，在叢集中部署400個httpbin應用的Pod為例。

        展開查看httpbin YAML

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
    service: httpbin-{i}
  name: httpbin-{i}
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin-0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: httpbin-{i}
  name: httpbin-{i}
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpbin-{i}
      version: v1
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: httpbin-{i}
        version: v1
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
      serviceAccountName: httpbin

      2. 執行以下命令，建立httpbin-{i}應用。

        kubectl apply -f httpbin-{i}.yaml

        預期輸出：

        deployment.apps/httpbin-{i} created

    2. 在叢集中部署sleep應用。

      1. 使用以下YAML內容，建立名為sleep-{i}的YAML檔案。

        說明

        sleep-{i}中的{i}可用具體數字代替，以產生多個不同的帶編號的sleep服務。在此模板中，通過向sleep應用部署的args欄位增加curl httpbin-{i*10}:8000的命令參數，類比向不同的httpbin應用的調用依賴。此處調用httpbin服務的編號不能超過之前部署的httpbin服務編號，否則無法產生有效調用。本文以類比每個sleep應用依賴10個httpbin應用為例，因此共部署20個sleep應用部署，20個sleep Pod。

        展開查看sleep YAML

        apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
    service: sleep-{i}
  name: sleep-{i}
spec:
  ports:
  - name: http
    port: 80
    targetPort: 0
  selector:
    app: sleep-{i}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: sleep-{i}
  name: sleep-{i}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep-{i}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: sleep-{i}
    spec:
      containers:
      - args:
        - curl httpbin-{i*10}:8000; curl httpbin-{i*10+1}:8000; curl httpbin-{i*10+2}:8000; curl httpbin-{i*10+3}:8000;
          curl httpbin-{i*10+4}:8000; curl httpbin-{i*10+5}:8000; curl httpbin-{i*10+6}:8000; curl httpbin-{i*10+7}:8000;
          curl httpbin-{i*10+8}:8000; curl httpbin-{i*10+9}:8000; sleep 3650d
        command:
        - /bin/sh
        - -c
        image: curlimages/curl
        imagePullPolicy: IfNotPresent
        name: sleep
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      serviceAccountName: sleep
      terminationGracePeriodSeconds: 0
      volumes:
      - name: secret-volume
        secret:
          optional: true
          secretName: sleep-secret

      2. 執行以下命令，建立sleep-{i}應用。

        kubectl apply -f sleep-{i}.yaml

        預期輸出：

        deployment.apps/sleep-{i} created

    測試使用Sidecar資源前的控制平面配置推送情況

    情境一：測試使用Sidecar資源最佳化前每個Sidecar的配置大小

    1. 執行以下命令，確定httpbin-0應用的Pod名稱。

      kubectl get pod -n ns-in-mesh | grep httpbin-0

      預期輸出：

      NAME                         READY   STATUS    RESTARTS   AGE
httpbin-0-756995d867-jljgp   2/2     Running   0          9m15s
httpbin-0-756995d867-whstr   2/2     Running   0          9m15s

    2. 執行以下命令，下載httpbin-0應用所在Pod的Sidecar，儲存至本地。

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json

    3. 執行以下命令，查看Sidecar設定檔的大小。

      du -sh config_dump.json

      預期輸出：

      1.2M    config_dump.json

      由預期輸出得到，在叢集中部署了420個Pod的測試情境下，Sidecar的配置大小約為1.2 MB。如果叢集中每個Pod都部署Sidecar，大量的Sidecar配置會加重控制平面的推送負擔。

    情境二：測試使用Sidecar資源最佳化前控制平面的配置推送效率

    在ASM中為httpbin-0服務應用一個新的虛擬服務規則，觸發控制平面向資料平面Sidear的一次配置推送。本文通過查看控制平面日誌內容來測試控制平面在一次推送中的配置推送效率。啟用控制平面日誌採集的具體步驟，請參見啟用控制平面日誌採集和日誌警示。

    1. 使用以下YAML內容，在Service Mesh中建立一個對httpbin-0服務進行逾時處理的虛擬服務。建立虛擬服務的具體操作，請參見管理虛擬服務。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-0-timeout
  namespace: default
spec:
  hosts:
    - httpbin-0.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: httpbin-0.default.svc.cluster.local
      timeout: 5s

    2. 查看控制平面新產生的日誌。

      ASM執行個體版本為1.17.2.35及以上

      1. 登入ASM控制台，在左側導覽列，選擇服務網格 > 網格管理。

      2. 在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇可觀測管理中心 > 日誌中心。

      3. 在日誌中心頁面，單擊控制平面日誌頁簽，查看日誌。

      ASM執行個體版本為1.17.2.35以下

      1. 登入ASM控制台。

      2. 在左側導覽列，選擇服務網格 > 網格管理。

      3. 在網格管理頁面單擊目標執行個體的名稱。

      4. 在網格詳情頁面，選擇網格執行個體 > 基本資料。

      5. 在基本資料頁面，單擊控制面日誌採集右側的查看日誌。

      日誌樣本如下：

      021-12-01T10:20:09.708673Z info  ads CDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:227 size:169.3kB
2021-12-01T10:20:09.710469Z info  ads CDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:227 size:169.3kB
2021-12-01T10:20:09.713567Z info  ads CDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:227 size:169.3kB
2021-12-01T10:20:09.714514Z info  ads LDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:16 size:70.7kB
2021-12-01T10:20:09.792732Z info  ads LDS: PUSH for node:httpbin-27-7dd8578b46-nkmvg.default resources:16 size:70.7kB
2021-12-01T10:20:09.792982Z info  ads LDS: PUSH for node:httpbin-184-65d97797db-njst5.default resources:16 size:70.7kB
2021-12-01T10:20:09.796430Z info  ads RDS: PUSH for node:httpbin-86-5b64586bbf-jv92w.default resources:8 size:137.4kB
……
2021-12-01T10:20:13.405850Z info  ads RDS: PUSH for node:httpbin-156-68b85b4f79-2znmp.default resources:8 size:137.4kB
2021-12-01T10:20:13.406154Z info  ads RDS: PUSH for node:httpbin-121-7c4cff97b9-sn5g4.default resources:8 size:137.4kB
2021-12-01T10:20:13.406420Z info  ads CDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:227 size:169.3kB
2021-12-01T10:20:13.407230Z info  ads LDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:16 size:70.7kB
2021-12-01T10:20:13.410147Z info  ads RDS: PUSH for node:httpbin-161-7bc74c5fb5-ldgn4.default resources:8 size:137.4kB
2021-12-01T10:20:13.494840Z info  ads RDS: PUSH for node:httpbin-57-69b756f779-db7vv.default resources:8 size:137.4kB

      可以看到在部署了420個Pod的測試環境下，新增一個虛擬服務會導致控制平面向資料平面的所有Sidecar推送變更，產生大量推送日誌，且每次推送的資料量較大。在Service Mesh中應用一條虛擬服務規則需要控制平面長達約4秒的推送，控制平面的推送效率較低。

    測試使用Sidecar資源後的控制平面配置推送情況

    使用基於訪問日誌分析自動推薦的Sidecar資源功能，為測試叢集中的每個工作負載推薦Sidecar資源，改善控制平面的配置推送效率。具體操作，請參見使用基於訪問日誌分析自動推薦的Sidecar資源。

    情境一：測試使用Sidecar資源最佳化後每個Sidecar的配置大小

    1. 執行以下命令，下載httpbin-0應用所在Pod的Sidecar，儲存至本地。

      kubectl exec -it httpbin-0-756995d867-jljgp -c istio-proxy -n ns-in-mesh -- curl -s localhost:15000/config_dump > config_dump.json

    2. 執行以下命令，查看Sidecar設定檔的大小。

      du -sh config_dump.json

      預期輸出：

      105k    config_dump.json

      由預期輸出得到，在叢集中部署了420個Pod的情境下，使用基於訪問日誌分析自動推薦的Sidecar資源功能，Sidecar的配置大小縮小了10倍以上，大大提高控制平面向資料平面Sidecar的配置推送效率。

    情境二：測試使用Sidecar資源最佳化後控制平面的配置推送效率

    重新在ASM中為httpbin-0服務應用一個新的虛擬服務規則，觸發控制平面向資料平面Sidear的一次配置推送。

    1. 在Service Mesh中刪除之前建立的虛擬服務，使用以下YAML內容，在Service Mesh中建立一個對httpbin-0服務進行逾時處理的虛擬服務。建立虛擬服務的具體操作，請參見管理虛擬服務。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-0-timeout
  namespace: default
spec:
  hosts:
    - httpbin-0.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: httpbin-0.default.svc.cluster.local
      timeout: 5s

    2. 查看控制平面新產生的日誌。

      ASM執行個體版本為1.17.2.35及以上

      1. 登入ASM控制台，在左側導覽列，選擇服務網格 > 網格管理。

      2. 在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇可觀測管理中心 > 日誌中心。

      3. 在日誌中心頁面，單擊控制平面日誌頁簽，查看日誌。

      ASM執行個體版本為1.17.2.35以下

      1. 登入ASM控制台。

      2. 在左側導覽列，選擇服務網格 > 網格管理。

      3. 在網格管理頁面單擊目標執行個體的名稱。

      4. 在網格詳情頁面選擇網格執行個體 > 基本資料。

      5. 在基本資料頁面單擊控制面日誌採集右側的查看日誌。

      日誌樣本如下：

      2021-12-01T12:12:43.498048Z info  ads Push debounce stable[750] 1: 100.03379ms since last change, 100.033692ms since last push, full=true
2021-12-01T12:12:43.504270Z info  ads XDS: Pushing:2021-12-01T12:12:43Z/493 Services:230 ConnectedEndpoints:421  Version:2021-12-01T12:12:43Z/493
2021-12-01T12:12:43.507451Z info  ads CDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:14 size:7.8kB
2021-12-01T12:12:43.507739Z info  ads LDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:3 size:15.5kB
2021-12-01T12:12:43.508029Z info  ads RDS: PUSH for node:sleep-0-b68c8c5d9-5kww5.default resources:1 size:6.3kB

      可以看到在應用ASM推薦的Sidecar資源後，資料平面的每個工作負載將不再接收與其沒有依賴關係的服務相關變更。對httpbin-0服務應用一條虛擬服務規則後，由於只有sleep-0應用與httpbin-0服務之間存在依賴關係，所以控制平面僅向sleep-0應用所在Pod的Sidecar推送配置變更。應用一條虛擬服務規則引發的配置推送僅持續了約0.01秒，相比最佳化前提升了約400倍的推送效率。同時，變更的資料量縮小了約10倍，大幅度提升了控制平面向資料平面的配置推送效率。

    效果對比總結

    本次測試通過使用多個sleep應用與httpbin應用類比叢集中存在數量龐大的服務，但服務與服務之間只存在少量調用依賴關係，共部署200個httpbin應用，400個httpbin應用的Pod，20個sleep應用，20個sleep應用的Pod。以下為使用Sidecar資源最佳化前後的效果對比。

    類別

    未使用Sidecar資源最佳化

    使用Sidecar資源最佳化

    Sidecar配置大小

    1.2 MB

    105 KB

    是否推送不含依賴關係的服務

    是

    否

    控制平面配置推送時間

    約4秒

    約0.01秒