数据面升级说明 单击“升级”会将所有服务实例对接到新版本控制面，您可以通过修改命名空间的标签（去除istio-injection:enabled ，加上istio.io/rev: {revision} ，其中{revision} 为版本号，如1-13-9-r5），并重启部分pod进行测试，若无问题，则可以全部切换。 1.3和1.6版本升级到1.8版本，因为证书切换，sidecar需要同时全部重启。 数据面升级结束后，请等待所有升级中的工作负载滚动升级完成。 父主题： 金丝雀升级

企业版网格工作原理 企业版网格是如何管理用户集群的，这要从用户集群和网格控制面的连接方式说起。企业版网格支持用户集群通过公网连接和私网连接两种方式连接网格控制面。 公网连接主要用于跨Region添加集群或对接其他云厂商的集群 通过公网连接网格控制面，用户需要为集群绑定弹性公网IP（EIP），因为网格的控制面需要访问用户集群的Kubernetes API Server服务。还需要为集群所在的VPC创建公网NAT网关，因为服务的Envoy组件需要通过NAT网关连接网格的控制面。 图3 公网连接网格控制面 私网连接用于对接华为云Region内部的集群 私网连接网格控制面则是利用VPC间的对等连接功能，打通了不同VPC之间的网络隔离。在创建网格时，要提前规划网格控制面的网段。 图4 私网连接网格控制面 下面要讲一下企业版网格的多集群治理能力。 传统的服务跨集群访问，用户需要创建NodePort或LoadBalancer服务，绑定ELB，配置转发端口，而且对每一个需要跨集群访问的服务都要执行此操作。除此之外，用户还需要维护各个服务的对外访问配置。 图5 传统跨集群访问 ASM企业版网格提供的服务跨集群访问能力，不需要用户进行复杂的配置，只需要将集群添加到网格，网格管理的所有集群的所有服务之间都是能够相互访问的，不管服务属于哪个集群。 图6 ASM跨集群访问

1.18版本特性 支持Istio 1.18.7版本 支持v1.25、v1.27 、v1.28、v1.29 、v1.30、v1.31 、v1.32 CCE Turbo 集群版本 支持v1.25、v1.27、v1.28 、v1.29、v1.30、v1.31 、v1.32 CCE集群版本 支持 Kubernetes Gateway API 详细内容请参阅：https://istio.io/latest/news/releases/1.18.x/ 父主题： 升级

操作步骤 登录应用服务网格控制台，使用以下任意一种方式进入添加集群页面。 （快捷方式）在企业版网格右上方，单击图标。 在企业版网格详情页，单击左侧导航栏的“网格配置”，在“基本信息”页签单击“添加集群”。 设置集群信息。 集群配置 在集群列表中选择集群，或在列表右上角输入集群名称搜索需要的集群。勾选后，系统自动校验集群是否符合添加要求，若校验不通过，会以图标标识，鼠标放上去可以查看校验不通过的原因以及解决方案。 如果当前没有可用集群，需要先创建集群后，再进行添加，详情可参考购买CCE集群。 选择好集群后，按照集群的网络模型或实际的通信需求选择集群的网络类型（要求网格版本为1.8.4-r3及以上）。 命名空间注入配置 选择命名空间：为命名空间设置标签istio-injection=enabled，其中的Pod在重启后会自动注入istio-proxy sidecar。 是否重启已有服务：如果开启（即重启已有服务），会自动注入istio-proxy sidecar，业务将会暂时中断。 可观测性配置 继承自网格配置，不可修改。 设置完成后，单击“确定”。 添加集群大约需要一分钟，请耐心等待。添加完成后，返回网格详情页面可查看到添加的集群信息。

约束与限制 目前支持v1.15、v1.17、v1.19和v1.21版本的集群加入企业版网格。 不支持安全容器类型的CCE Turbo集群添加至网格。 同一网格最多只能添加五个集群。 同一虚拟私有云的集群只能加入同一个网格。 为了满足高可用的要求，集群需要至少包含两个可用节点，每个节点至少保证有2U4G的可用资源。 集群的服务网段、容器网段不能和网格内已有集群的服务网段、容器网段冲突。如果集群和网格内的已有集群处于不同的VPC，集群的子网网段也不能冲突。 如果实例（Pod）需要跨集群通信，集群需要使用ENI网络模型，且集群之间网络互通，可以处于同一VPC内，也可以将多个集群的VPC通过其他方式（对等连接、云连接等）连通。 CCE集群和CCE Turbo集群混合多集群场景，CCE集群服务访问Turbo集群服务时，需要为Turbo集群的ENI安全组入方向放通CCE集群的容器网段，否则会访问不通。

约束与限制 应用服务网格依赖集群CoreDNS的 域名 解析能力，请确保集群拥有足够资源，且CoreDNS插件运行正常。 集群启用Istio时，需要开通node节点（控制面节点/工作节点）所在安全组的入方向15017端口规则，用于Sidecar自动注入回调。如果您使用CCE创建的默认安全组，此端口会自动开通。如果您自建安全组规则，请手动开通15017端口，以确保Istio自动注入功能正常。 1.13和1.15版本的istio组件不支持在CentOS和EulerOS2.5操作系统的节点上运行，在创建网格时，请不要指定这些类型的节点为master节点。 仅支持华为云CCE集群启用ASM服务网格，暂不支持CCE Autopilot集群。 不支持安全容器类型的CCE Turbo集群启用网格。 不支持已经启用了开源Istio网格的集群，包括自行部署的Istio和通过精选开源方式部署的Istio。 不支持用于出站流量控制的egressgateway。 不支持无 sidecar 的 Ambient 模式。 不支持通过以下自定义资源进行网格自定义 ：ProxyConfig, Envoyfilter, WorkloadEntry, WorkloadGroup, IstioOperator, WasmPlugin 。 不支持使用Kubernetes Gateway API配置Istio入口网关和管理网格流量。 请根据下表ASM网格版本与集群版本适配规则匹配合适的网格版本和集群版本。 表1 ASM网格版本与集群版本适配规则 ASM网格版本 集群版本 1.3 v1.13、v1.15、v1.17、v1.19 1.6 v1.15、v1.17 1.8 v1.15、v1.17、v1.19、v1.21 1.13 v1.21、v1.23 1.15 v1.21、v1.23、v1.25、v1.27、v1.28 1.18 v1.25、v1.27、v1.28、v1.29、v1.30、v1.31、v1.32

Mantis插件介绍 Mantis致力于解决由网格内实例规模增大而引起的Istio控制面组件Istiod和数据面组件Envoy的内存飙升问题。同时，从多个维度输出了Istio相关性能模型，填补了Istio在大规模实例场景下的性能模型空白，为Istio性能提升提供了有力支撑。 提高控制面Istiod稳定性 Istio采用的是全局更新配置信息策略，如下图所示，当服务B的相关信息发生变化时，Istiod会生成全量xds并推送给网格内所有Proxy，这会导致Istiod的瞬时CPU、内存占用过高，可能导致Istiod重启。 Mantis根据服务依赖关系按需更新配置，当服务B的相关信息发生变化时，Istiod会将服务B相关的更新推送给调用服务B的相关服务（服务A和服务D）的所有Endpoint中，包括生成配置和下发配置，可极大缓解Istiod CPU、内存占用过高的问题，提高控制面的稳定性。 减小数据面sidecar资源消耗 Istio使用Envoy作为网格数据面的sidecar。目前Istio采用的是全局更新配置信息策略，即网格内每一个实例中的Envoy都储存了网格内其他所有服务的相关信息，包括listener、route、cluster和endpoint。这在实例规模不断增大的情况下，将会发生内存爆炸，在实际生产环境中是不可接受的。 Mantis根据服务依赖关系按需更新配置，即每一个实例的Envoy只存储和本服务需要调用的服务的相关信息，可以将Envoy的内存占用最小化。

Mantis工作原理 Mantis的架构和工作流程如下图所示： 网格安装Mantis后，会在用户集群安装CentralGateway（CGW）组件。CGW包含网格全局的服务路由信息，用于转发首包流量；网格控制面会根据服务调用关系按需更新服务路由信息。 网格安装初始化完成后，所有服务实例（Pod）的Envoy中只存储了CGW组件的路由信息。 当某个服务Service A的实例（Pod）第一次访问另一个服务Service B时，由于Service A实例的Envoy中没有Service B的路由信息，Envoy会将请求发送到CGW上。 CGW保存了网格全局的服务路由信息，所以CGW可以将请求转发到Service B的实例。 同时，CGW会将Service B的路由信息上报到Mantis控制面。 然后再由Mantis控制面下发给Service A的所有实例。 在后续Service A访问Service B时，由于Service A所有实例的Envoy中已经存在Service B的路由信息，请求将会被直接转发给Service B的实例。 而对于Service A未访问过的服务，Service A所有实例的Envoy中不会存储服务的路由信息，可以有效减小Envoy内存消耗。

Mantis使用约束 启用Mantis插件对网格有如下限制： 企业版网格，1.8.4-r4及以上网格版本。 企业版网格已下线，不再支持创建企业版网格，推荐使用基础版网格。存量的企业版网格仍可继续使用。 Mantis插件仅针对HTTP协议的服务做优化。 安装Mantis插件后，暂时不支持卸载。 安装Mantis插件的网格升级时，会同步升级Mantis插件。 启用Mantis插件后，如有访问外部服务的需求，需要为集群所在VPC子网配置NAT网关。

添加的对外访问方式不能生效，如何排查？ 出现上述问题可能是访问相关的资源配置有缺失或错误，请按照如下方法进行排查： 通过弹性负载均衡服务界面查看使用的ELB是否成功监听使用的外部端口和弹性云服务器。 登录集群，使用kubectl get gateway -n istio-system命令查看使用的gateway是否配置好使用的IP/域名和端口。使用kubectl get svc -n istio-system命令查看使用的ingressgateway是否有对应的IP和端口，且未处于pending状态。 核实加入服务网格的内部访问协议和添加网络配置的外部访问协议一致。 如果通过浏览器访问出现“ERR_UNSAFE_PORT”错误，是因为该端口被浏览器识别为危险端口，此时应更换为其他外部端口。 父主题： 添加服务

问题背景 Istio CNI 插件可能会导致使用了 initContainer 的应用出现网络连通性问题。 使用 Istio CNI 时，kubelet 会通过以下步骤启动一个注入的 Pod： Istio CNI 插件在 Pod 内设置流量重定向到 Istio Sidecar。 等待所有的 Init 容器成功执行完毕。 Istio Sidecar 跟随 Pod 的其它容器一起启动。 由于 initContainer 在 Sidecar 启动之前执行，initContainer 发出的请求会被重定向到尚未启动的 Sidecar 上，这会导致 initContainer 执行期间出现流量丢失。

解决方案 可以通过以下任意方式来防止流量丢失： 使用 runAsUser 将 Init 容器的 uid 设置为 1337。 1337 是 Sidecar 代理使用的 uid。 这个 uid 发送的流量并非通过 Istio 的 iptables 规则进行捕获。 应用容器流量仍将像往常一样被捕获。 对 initContainer 所访问的目标 CIDR，通过设置 traffic.sidecar.istio.io/excludeOutboundIPRanges 注解以使访问该网段的流量不会被重定向到 Sidecar。 对 initContainer 所访问的目标端口，通过设置 traffic.sidecar.istio.io/excludeOutboundPorts 注解以使访问该端口的流量不会被重定向到 Sidecar。 请谨慎使用注解方式排除流量拦截，因为 IP/端口排除注解不仅适用于 Init 容器流量，还适用于应用容器流量。 即发送到配置的 IP/端口的应用流量将绕过 Istio Sidecar。

sidecar注入失败可能的原因 sidecar注入失败常见场景和解决方案： 可能原因：网格管理实例数到达上限，无法继续注入。 检查方法：统计网格注入Pod总数是否已达上限。 登录应用服务网格ASM控制台，在网格列表页面查看您的网格卡片展示的实例个数是否达到网格规格。如果达到即网格注入Pod总数已达上限。 解决方案：联系运维工程师或提交工单处理。 可能原因：控制面组件istiod异常。 检查方法：请检查istio-system命名空间下的istiod组件是否异常。 登录云容器引擎CCE控制台，依次单击您的集群名称-工作负载，选择istio-system命名空间，查看istiod-1-18-7-r4组件工作负载状态列是否是运行中，如果不是运行中则可能是组件异常了。 组件中的1-18-7-r4即网格的版本。网格版本号可从网格详情页面的“网格配置-基本信息”中获取，即“当前版本”的值。此处展示的版本号是中划线连接。 解决方案：若异常可以联系运维工程师或提交工单处理。 可能原因：命名空间未打上自动注入标签。 检查方法：执行以下命令，查看需要的webhook的 namespaceSelector条件。 kubectl get mutatingwebhookconfiguration istio-sidecar-injector-1-18-7-r4 -o yaml | grep "rev.namespace.sidecar-injector.istio.io" -A20 | grep "namespaceSelector:" -A7 请将上述命令中的1-18-7-r4按当前格式（中划线连接）替换成您的网格的版本。网格版本号可从网格详情页面的“网格配置-基本信息”中获取，即“当前版本”的值。 例如上图查询结果表示需要有一个istio.io/rev=1-18-7-r4的标签同时不能有istio-injection的标签。 执行以下命令，确认目标命名空间是否包含在 webhook范围内。 kubectl get {namespace} --show-labels 解决办法：命名空间添加上面查出来的注入标签。 可能原因：为集群开放命名空间注入的默认策略未设置为enabled。 检查方法：执行以下命令检查默认策略，确认policy的值为enabled。 kubectl -n istio-system get configmap istio-sidecar-injector-1-18-7-r4 -o jsonpath='{.data.config}' | grep policy: 请将上述命令中的1-18-7-r4按当前格式（中划线连接）替换成您的网格的版本。网格版本号可从网格详情页面获取，即“当前版本”的值。 解决办法：参考如何为集群开放命名空间注入？进行处理。 可能原因：存在sidecar.istio.io/inject: 'false'标签。 检查方法：检查工作负载标签。 登录云容器引擎CCE控制台，依次单击您的集群名称-工作负载，选择对应命名空间，单击您的工作负载操作列的“更多-查看YAML”。找到spec.template.metadata.labels字段，确认不能存在sidecar.istio.io/inject: 'false'标签。 请将上述命令中的1-18-7-r4按当前格式（中划线连接）替换成您的网格的版本。网格版本号可从网格详情页面获取，即“当前版本”的值。 解决办法：如果存在请删除sidecar.istio.io/inject: 'false'标签。参考某些工作负载不注入Sidecar，该如何配置？ 可能原因：Pod不能创建。 解决方案：执行以下命令，查看events事件报错，根据events事件报错信息进一步处理。 kubectl describe -n {namespace} {deployment name} 可能原因：确保Pod 不在 kube-system 或 kube-public 命名空间中。 kube-system 以及 kube-public 命名空间中的 Pod 将忽略 Sidecar 自动注入。 可能原因：确保Pod 定义中没有 hostNetwork：true。 hostNetwork：true 的 Pod 将忽略 Sidecar 自动注入。 父主题： 网格管理

负载级别指定端口配置出入流量拦截 通过修改业务deployment文件，可以在负载级别配置端口上的出入流量拦截规则： 执行kubectl edit deploy –n user_namespace user_deployment 1. 在deployment.spec.template.metadata.annotations中配置入流量指定端口不拦截traffic.sidecar.istio.io/excludeInboundPorts： 2. 在deployment.spec.template.metadata.annotations中配置入流量指定端口拦截traffic.sidecar.istio.io/includeInboundPorts： 3. 在deployment.spec.template.metadata.annotations中配置出流量指定端口不拦截traffic.sidecar.istio.io/excludeOutboundPorts： 4. 在deployment.spec.template.metadata.annotations中配置出流量指定端口拦截traffic.sidecar.istio.io/includeOutboundPorts： 上述操作会导致业务容器滚动升级。

操作场景 Istio 为实现服务网格的透明化流量治理，Sidecar默认拦截所有出入流量， 这种设计确保了流量治理无死角、业务零侵入和安全可信。但这种默认拦截机制在实际应用场景下也会带来一些问题： 所有流量都经过Sidecar代理，会导致Sidecar的资源占用（内存、CPU）较高，严重时可能导致业务pod重启甚至服务雪崩。 某些场景下需要直接访问外部服务（如数据库连接池），不能使用默认拦截机制。 因此本章将介绍如何精细化配置流量拦截规则，以解决Istio的默认拦截机制在实际应用场景下的问题。