功能介绍
自适应配置推送优化通过自动收集envoy的accesslog的方式，自动分析应用间的调用依赖，为数据平面的工作负载应用Sidecar资源来实现配置推送优化。自适应配置推送优化特点如下：
自适应配置推送优化功能将自动、自适应地为您选中的工作负载应用Sidecar资源。您无需对Sidecar资源进行手动的应用或更新操作。当服务的依赖关系发生变化时，也无需进行Sidecar资源的重新推荐。开启自适应配置推送优化功能后，Sidecar资源将会根据集群中被选中的工作负载自动生成。
自适应配置推送优化功能不需要您开启使用日志服务采集数据平面的访问日志。
自适应配置推送优化功能初始仅对sidecar推送istio-system和mesh-operator命名空间下的配置。控制面新增部署一个global-sidecar组件，该组件保存全量配置，当数据面请求产生时，如果没有查到对端的配置信息，会由该组件兜底转发流量。当数据面应用产生初次访问后，会自动更新Sidecar资源给发起方应用。
关于自适应配置推送优化的更多信息，请参见下方文档。
适用场景
自适应配置推送优化功能将自适应地为您的工作负载创建Sidecar资源，无需预先梳理应用间的调用关系。适用于不熟悉Sidecar资源及配置推送优化的相关概念的管理者。
自适应配置推送优化功能在控制面进行日志上报以及服务依赖计算。开启该功能后，可能在短时间内为您网格的数据面流量及控制面资源带来多余的负担，因此建议您在负载较低的时段开启此功能。
如何使用
当遇到控制平面向数据平面大量推送无关配置导致效率低下时，您可以借助自适应配置推送优化功能来提升控制平面的推送效率。通过分析服务间的实际调用关系，该功能自动为服务生成优化后的Sidecar资源，仅为必要的服务推送必需的Sidecar配置，减少不必要的网络通信，增强服务网格的性能和响应速度。
前提条件
已部署Istio资源实现流量路由，可参考快速入门（链接到快速入门）
背景信息
由于无法确定数据平面内所有工作负载与服务之间的关系，服务网格数据平面内的所有Sidecar都默认保存所有服务信息的全量配置。这种情况下网格内的所有Sidecar可能会保留大量无需访问的节点配置，内存消耗过高。同时，一条配置的改动也会广播给所有服务，导致cpu开销过高。
您可以通过开启自适应配置推送优化功能，为服务自动创建用于配置推送优化的Sidecar资源。功能开启后，应用服务网格通过自动收集envoy的accesslog的方式，自动分析应用间的调用依赖，为数据平面的工作负载应用Sidecar资源来实现配置推送优化，无需您手动管理。关于应用Sidecar资源的配置推送优化效果，请参见自适应配置分发优化效果（链接到3.9.3.4）
使用限制
自适应配置推送优化功能仅支持基于HTTP协议访问的服务。
使用步骤
步骤一：开启自适应配置推送优化功能
登录应用服务网格控制台，在首页网格列表中选中目标实例。
在网格管理页面左侧导航栏，选择网格优化中心 > 自适应配置下发。
在自适应配置下发页面，点击开启自适应配置下发。
更新完毕后，您可以看到自适应配置下发开关已打开，再次点击则为关闭该功能。下方会显示所有已经自动纳入自适应配置的服务以及其所属的命名空间。如下图所示
注意：目前只有主集群的服务可以被自动纳入。
如果从集群有命名空间不在主集群中，您需要手动点击右上角命名空间右侧问号，选择手工添加命名空间。
如果从集群中有服务不在主集群中，您需要手动点击右上角搜索框右侧问号，选择手工添加服务。
步骤二：访问应用，触发自适应配置推送优化
1. 部署bookinfo相关应用。部署后可以在网格优化中心 > Sidecar资源中看到这些应用已经默认生成了Sidecar资源，并且仅下发istio-system和mesh-operator的配置。
2. 通过云原生网关发起请求到productpage。具体步骤可以参考通过云原生网关访问bookinfo应用。或者通过ingressgateway访问。或者在集群内执行curl 访问productpage。
3. 首次访问成功后，在网格优化中心 > Sidecar资源中查看productpage已经追加reviews，details等服务的配置。无需您手工配置。
相关操作
关闭自适应配置推送优化功能
1. 登录应用服务网格控制台，在首页网格列表中选中目标实例。
2. 在网格管理页面左侧导航栏，选择网格优化中心 > 自适应配置下发。
3. 在自适应配置下发页面，点击关闭自适应配置下发。
4. 切换到网格优化中心 > Sidecar资源页面查看Sidecar资源列表，
5. 您可以看到创建来源为“系统”的Sidecar资源已被删除。
自适应配置分发优化效果
背景信息
本文对比在相同规模的服务网格场景下开启和关闭自适应配置分发时服务网格控制面和数据面的资源消耗，说明自适应配置分发优化的使用场景和效果。
对比方案概述
应用说明：
在多个命名空间部署bookinfo应用，请求应用，观察控制面和数据面资源消耗。bookinfo调用关系如下
应用规模：
在集群中创建22个命名空间，分别部署一个bookInfo demo，共88个Pod。每个productpage应用只需要访问reviews和details。
场景与指标说明
场景
| 场景描述 | 指标
| |
控制面 | 数据面（sidecar） | ||
基线场景 | 未启用自适应配置下发 | 1、CPU及内存开销 2、Pilot推送频率和时延 3、XDS的请求量 | 1、CPU及内存开销
2、sidecar的服务资源信息 |
启用自适应配置下发场景1 | 启用瞬间 | ||
启用自适应配置下发场景2 | 1、已启用自适应配置下发
2、对每个命名空间下的服务持续发起网络访问请求
| ||
结果说明
基线场景
控制面
可以看到随着服务的启动，控制面内存消耗逐渐增加，由于服务启动后控制面要执行全量配置推送，控制面CPU先上升，然后回落
控制面xds推送ops、大小以及耗时
数据面
选取任意一个pod观察CPU和内存
istio-proxy容器在启动时要获取全量配置，CPU较高，然后回落
内存增长到一个值后保持稳定
查看业务相关outbounds规则情况可以看到sidecar中包含了全量的服务信息
自适应配置下发场景1——开启瞬间
控制面
可以看到控制面CPU相比未开启自适应配置分发的情况明显降低
xds推送ops、大小以及耗时明显降低
数据面
选取任意一个pod观察，可以看到内存有明显降低
业务相关outbounds规则情况，只有业务访问到的目标服务信息
小结
可以明显看到cpu和内存开销峰值下降，xds下发的平均包大小和耗时也大幅下降。
控制面优化概况
场景 | CPU峰值 | 内存峰值 | proxy推送频率峰值ops/s | 推送耗时P99 | 推送耗时P999 | XDS平均请求量峰值 |
基线
| 1.8 | 668M | 170
| 497ms | 2.6s | 1MB/s
|
开启瞬间 | 0.435 (-75.8%) | 362M (-45.8%) | 38 (-77.6%) | 90ms (-81.9%) | 90ms (-96.5%) | 23KB/s (-97.8%) |
数据面优化概况
场景 | sidecarCPU峰值 | sidecar内存峰值 | 是否推送不含依赖关系的服务相关资源 |
基线
| 0.08 | 92.6M | 是
|
开启瞬间 | 0.0015(-98.0%) | 44M(-52.4%) | 否 |
自适应配置下发场景2——开启后持续产生流量
控制面
xds推送大小以及耗时
数据面
选取任意一个pod观察cpu，内存
业务相关outbounds规则情况
小结
可以看到开启后产生的业务访问场景下，控制面cpu和内存进一步降低，xds量几乎为0。
控制面优化概况
场景 | CPU峰值 | 内存峰值 | proxy推送频率峰值ops/s | 推送耗时P99 | 推送耗时P999 | XDS平均请求量峰值 |
基线
| 1.8 | 668M | 170
| 497ms | 2.6s | 1MB/s
|
开启瞬间 | 0.435 (-75.8%) | 362M (-45.8%) | 38 (-77.6%) | 90ms (-81.9%) | 90ms (-96.5%) | 23KB/s (-97.8%) |
开启后 | 0.0157(-99.1%) | 315M(-52.8%) | 3.13 (-98.2%) | 99ms (-80.1%) | 99.9ms (-96.2%) | 0.6KB/s (-99.9%) |
数据面优化概况
场景 | sidecarCPU峰值 | sidecar内存峰值 | 是否推送不含依赖关系的服务相关资源 |
基线
| 0.08 | 92.6M | 是
|
开启瞬间 | 0.0015(-98.0%) | 44M(-52.4%) | 否 |
开启后 | 0.0021(-97.4%) | 53M(-42.3%) | 否 |