如果您的单个命名空间中存在着大量的服务，需要对Sidecar配置进行最大限度的精简，您可以使用Sidecar资源推荐功能。本文以部署420个Pod的较大规模集群为例，测试并分析应用Sidecar资源后的服务网格配置推送优化效果。

前提条件

在集群中部署测试应用

本文使用多个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为例。 
      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。 
      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

    预期输出：

    httpbin-0-756995d867-j****   2/2     Running   0          9m15s
httpbin-0-756995d867-w****   2/2     Running   0          9m15s
  2. 执行以下命令，下载httpbin-0应用所在Pod的Sidecar，保存至本地。
    kubectl exec -it httpbin-0-756995d867-j**** -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内容，在服务网格中新建一个对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. 查看控制面新产生的日志。
    1. 登录ASM控制台。
    2. 在左侧导航栏，选择服务网格 > 网格管理。
    3. 在网格管理页面单击目标实例的名称。
    4. 在网格详情页面选择网格实例 > 基本信息。
    5. 在基本信息页面单击控制面日志采集右侧的查看日志。

      预期输出：

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

      由预期输出得到，在部署了420个Pod的测试环境下，新增一个虚拟服务会导致控制面向数据面的所有Sidecar推送变更，产生大量推送日志，且每次推送的数据量较大。在服务网格中应用一条虚拟服务规则需要控制面长达约4秒的推送，控制面的推送效率较低。

测试使用Sidecar资源后的控制面配置推送情况

使用基于访问日志分析自动推荐的Sidecar资源功能，为测试集群中的每个工作负载推荐Sidecar资源，改善控制面的配置推送效率。具体操作，请参见使用基于访问日志分析自动推荐的Sidecar资源。

场景一：测试使用Sidecar资源优化后每个Sidecar的配置大小
  1. 执行以下命令，下载httpbin-0应用所在Pod的Sidecar，保存至本地。
    kubectl exec -it httpbin-0-756995d867-j**** -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. 在服务网格中删除之前创建的虚拟服务，使用以下YAML内容，在服务网格中新建一个对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. 查看控制面新产生的日志。
    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-5****.default resources:14 size:7.8kB
2021-12-01T12:12:43.507739Z info  ads LDS: PUSH for node:sleep-0-b68c8c5d9-5****.default resources:3 size:15.5kB
2021-12-01T12:12:43.508029Z info  ads RDS: PUSH for node:sleep-0-b68c8c5d9-5****A.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秒