在默认情况下，由于不能确定网格内服务之间的调用依赖关系，Sidecar的配置中保存了数据平面内所有服务的信息；同时，一次针对控制平面或数据平面的修改都会引起控制平面向数据平面所有Sidecar的一次配置推送。
您可以使用Sidecar资源配置Sidecar、来调优与应用实例的出口和入口通信。您可以参考管理Sidecar资源，来自行创建并管理Sidecar资源。除此之外，服务网格ASM可以通过分析数据平面Sidecar产生的访问日志、抽取数据平面服务之间的调用依赖关系，为数据平面中的每个工作负载自动推荐Sidecar资源。在应用了推荐的Sidecar资源后，对应工作负载上的Sidecar将仅关注与自己有调用依赖关系的服务信息。这代表：
-
Sidecar配置内将仅保留该Sidecar对应工作负载所依赖的服务信息
-
与该Sidecar资源对应的工作负载无依赖关系的服务发生改变、或与该服务相关的资源发生改变（如虚拟服务等），都不会引起控制平面向该Sidecar的配置推送
本文以针对实例应用Bookinfo中的微服务productpage推荐的Sidecar资源为例，介绍如何使用基于访问日志分析自动推荐的Sidecar资源。
前提条件
-
已经配置了使用日志服务采集数据平面的访问日志。具体操作，请参见 使用日志服务采集数据平面的AccessLog。
-
已经通过入门指引，在集群中部署了bookinfo示例应用。具体操作，请参见 快速入门。
步骤一：为访问日志分析产生访问日志
-
参照 快速入门，在ACK集群中部署Bookinfo示例应用，在ASM示例中部署所有Istio资源。
-
在浏览器地址栏输入 http://{入口网关服务的IP地址}/productpage。持续刷新，直至观察到Bookinfo应用页面在显示黑色星型图标和红色星型图标之间 等权重地轮流切换。
步骤二：为工作负载推荐Sidecar资源
-
在左侧导航栏，选择 服务网格 > 网格管理 。
-
在 网格管理 页面，找到待配置的实例，单击实例的名称或在 操作 列中单击 管理 。
-
在网格详情页面选择 配置推送优化 > Sidecar资源推荐 。
-
如果已经执行过步骤一，此时在 Sidecar资源推荐 页面中将会出现包括productpage-v1在内的所有Bookinfo示例应用内的工作负载列表，且 推荐任务状态 列均会显示 未推荐过。找到工作负载 productpage-v1，在 操作 列中单击 推荐 。此时productpage-v1的 推荐任务状态 列变为 推荐中，且暂时不可操作其它工作负载，请耐心等待直至推荐完成。
-
推荐完成后，productpage-v1的 推荐任务状态 列变为 推荐完成，且此时已经可以使用 productpage-v1的 查看 与 重新收集日志 操作。在productpage-v1的 操作 列中单击 查看 ，可以查看为该工作负载自动推荐的Sidecar资源yaml。
为productpage-v1推荐的Sidecar资源预期结果如下，可以发现推荐结果中仅包含details和reviews两个服务，这是因为productpage服务仅与这两个服务之间产生调用依赖关系。
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: asm-rec-for-default-productpage-v1
namespace: default
spec:
egress:
- hosts:
- '*/details.default.svc.cluster.local'
- '*/reviews.default.svc.cluster.local'
port:
name: HTTP-9080
number: 9080
protocol: HTTP
workloadSelector:
labels:
app: productpage
version: v1-
在弹出的yaml预览面板中，确认推荐的Sidecar中是否包含了所有该工作负载依赖的所有服务。如确认无误，可以单击 创建 ，ASM将会应用这一自动推荐的Sidecar资源，以减少productpage-v1工作负载的配置推送频率与推送数据量。
可选步骤：重新为工作负载推荐Sidecar资源
随着业务应用的升级，服务网格中服务之间的调用依赖关系可能会发生改变，此时之前ASM推荐的Sidecar资源将不再有效，此时建议重新收集日志，并重新为对应工作负载推荐Sidecar资源。
-
在左侧导航栏，选择 服务网格 > 网格管理 。
-
在 网格管理 页面，找到待配置的实例，单击实例的名称或在 操作 列中单击 管理 。
-
在网格详情页面选择 配置推送优化 > Sidecar资源推荐 。
-
如果已经执行过步骤二，此时在 Sidecar资源推荐 页面中将会出现包括productpage-v1在内的所有Bookinfo示例应用内的工作负载列表，且productpage-v1的 推荐任务状态 列会显示 推荐成功。
-
找到工作负载 productpage-v1，在 操作 列中单击 重新收集日志 ，在随后的弹窗中单击 确定 。此时在步骤二中被成功应用的Sidecar资源将被删除，productpage-v1的 推荐任务状态 列会显示 重新收集日志中。
-
用户需要重新执行步骤一，重新为访问日志分析产生访问日志。
-
用户需要重新执行步骤二，重新为工作负载productpage-v1推荐Sidecar资源。
使用场景
ASM的Sidecar资源推荐通过单独针对每个负载单独的服务依赖关系提供Sidecar资源，能够最大化精简数据面Sidecar配置与减少不必要的配置推送，但其需要针对数据面中的每个工作负载进行单独配置，且由于推荐基于访问日志，如果访问日志中没有工作负载的服务调用记录，可能造成推荐结果的不准确，因此推荐结果需要用户进行二次确认。
如果选择性服务发现无法满足您的配置推送优化需求，您的单个命名空间中存在着大量的服务，需要对Sidecar配置进行最大限度的精简，您可以考虑使用ASM基于访问日志的Sidecar资源推荐功能，此功能可以大幅减少您手动应用Sidecar资源的困难。
应用Sidecar资源后的配置推送优化效果
本节以一个部署440个Pod的较大规模集群为例，测试并分析应用Sidecar资源后的服务网格配置推送优化效果。
前提条件
-
已经配置了使用日志服务采集数据平面的访问日志。具体操作，请参见 使用日志服务采集数据平面的AccessLog。
在集群中部署测试应用
本次测试通过使用多个sleep应用与httpbin应用模拟集群中存在数量庞大的服务，但服务与服务之间只存在少量调用依赖关系的场景。httpbin应用在启动后会在8000端口暴露一个http服务，可模拟集群内部大量被调用的服务；而sleep应用则包含一个curl容器，可以通过修改应用部署的command字段、让sleep应用在睡眠之前调用多个httpbin的容器提供的服务，可模拟集群内依赖其它服务的服务。
-
在集群中部署多个httpbin应用
注意，在部署测试应用前，需要确定default命名空间已经开启Sidecar自动注入，并开启使用日志服务采集数据平面的AccessLog。
使用以下的yaml模板，创建多个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将yaml文件保存为httpbin-{i}.yaml，并在集群中应用。
kubectl apply -f httpbin-{i}.yaml其中标明为{i}的部分可用具体数字代替，以生成多个不同的带编号的httpbin服务。使用此模板可以生成任意多个httpbin应用，具体应用数量限制取决于集群的规模。在本文的测试中，使用该模板生成了200个httpbin应用部署，在集群中共部署400个httpbin应用的Pod。
-
在集群中部署sleep应用
使用以下的yaml模板，创建多个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将yaml文件保存为sleep-{i}.yaml，并在集群中应用。
kubectl apply -f sleep-{i}.yaml其中标明为{i}的部分可用具体数字代替，以生成多个不同的带编号的sleep服务。在此模板中，通过向sleep应用部署的args字段增加curl httpbin-{i*10}:8000这样的命令参数，模拟向不同的httpbin应用的调用依赖，注意这里调用的httpbin服务的编号不能超过之前部署的httpbin服务编号，否则无法产生有效调用。在本例中模拟了每个sleep应用依赖10个httpbin应用，因此本文例中共部署20个sleep应用部署，20个sleep Pod。
测试未使用Sidecar资源之前的控制面配置推送情况
（一）测试使用Sidecar资源优化前每个Sidecar的配置大小
-
执行以下命令，确定httpbin-0 Pod名称。
kubectl get pod -n ns-in-mesh | grep httpbin-0预期输出
httpbin-0-756995d867-jljgp 2/2 Running 0 9m15s
httpbin-0-756995d867-whstr 2/2 Running 0 9m15s-
执行以下命令，下载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-
执行以下命令，查看Sidecar配置文件的大小。
du -sh config_dump.json预期输出
1.2M config_dump.json在集群中部署了420个Pod的测试情况下，此时Sidecar的配置大小约为1.2M。考虑到集群中每个Pod都部署Sidecar，大量的Sidecar配置无疑加重了控制面的推送负担。
（二）测试使用Sidecar资源优化前控制面的配置推送效率
在ASM中为httpbin-0服务应用一个新的虚拟服务规则，可以触发控制面向数据面Sidear的一次配置推送，可以通过查看控制面日志内容来测试控制面在一次推送中的的配置推送效率。
要查看控制面日志内容，请首先启用控制平面日志采集，请参考启用控制平面日志采集和日志告警。
-
在服务网格中用下面的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
-
进入控制平面日志项目的logstore，查看原始日志，可以将时间限定在15分钟（相对）来查看刚刚控制面产生的日志。
预期日志内容
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推送变更，这其中会产生大量推送日志，且每次推送的数据量也比较大。最终在网格中应用一条虚拟服务规则导致了控制面长达约4秒的推送，这对于控制面来说是不可忽视的效率下降。
（三）应用ASM的Sidecar资源
参考《使用基于访问日志分析自动推荐的Sidecar资源》，为测试集群中的每个工作负载应用ASM为其推荐的Sidecar资源，以改善控制面的配置推送效率。
（四）测试使用Sidecar资源优化后每个Sidecar的配置大小
-
同样执行以下命令，下载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-
同样执行以下命令，查看Sidecar配置文件的大小。
du -sh config_dump.json预期输出
105k config_dump.json在集群中部署了420个Pod的测试情况下，不难发现，在应用了Sidecar资源后，httpbin-0 Pod的Sidecar配置大小缩小了10倍以上，这无疑可以大大提高控制面向数据面Sidecar的配置推送效率。
（二）测试使用Sidecar资源优化前控制面的配置推送效率
重新在ASM中为httpbin-0服务应用上述虚拟服务规则，重新触发控制面向数据面Sidear的一次配置推送。
-
在服务网格中删除并重新创建基于以下yaml的虚拟服务。有关如何管理虚拟服务，参见 管理虚拟服务。
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
-
进入控制平面日志项目的logstore，查看原始日志，可以将时间限定在15分钟（相对）来查看刚刚控制面产生的日志。
预期日志包含内容
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推送了配置变更。同时，变更的数据量也缩小了约10倍，这些变化无疑都大幅度地提升了控制面向数据面的配置推送效率。在对文中的测试环境使用Sidecar资源进行优化之后，应用一条虚拟服务规则触发的配置推送仅持续了约0.01秒，相比优化前提升了约400倍的推送效率。
