ASM配置建议

网格诊断

ASM支持对实例进行网格诊断。诊断项包括数据平面版本检查、服务端口检查、服务关联检查等。建议您经常使用网格诊断功能对配置进行诊断。对于未通过的检查项，请按照相关提示进行配置修改。具体操作，请参见使用ASM网格诊断。

网关

• 一个域名对应一个Gateway资源。不建议多个Gateway CR关联同一个域名。

• 一个Gateway对应一个VirtualService。若需要使用多个VirtualSerice关联同一个Gateway，请勿在多个VirtualService下针对同一个URI或者同一个URI范围进行配置，避免因合并的顺序导致不符合预期的路由优先级问题。

  • 若VirtualService下配置条目过多，需要拆分为多个VirtualService进行配置。建议按照路由的目标服务（Destination）进行拆分，一个目标服务对应一个子VirtualService。

  • 使用VirtualService Delegate功能时，需满足CI/CD单独上线一个服务并关联配置一条路由。

• 一个后端应用服务建议对应一个DestinationRule。多个DestinationRule低版本可能会导致配置同步（xDS）不一致的问题。

网格

• 同一个Host的流控规则（VirtualService）不支持分布到多个VirtualService资源下。如果同一个Host存在多个VirtualService，仅生效最新创建的一个VirtualService。

• 一个后端应用服务对应一个VirtualService和DestinationRule。VirtualService和DestinationRule需创建在服务对应的Namespace下。不建议资源跨Namespace进行配置。

• 针对同一个服务，若该服务也暴露在入口网关下，东西向流量（针对Sidecar的路由配置）和南北向（针对Gateway的路由配置）建议分开配置。

API

通用规则

• istio-system空间下未包含WorkLoadSelector的CR配置，一般针对当前整个集群生效。

• 非istio-system空间下未包含WorkLoadSelector的CR配置，一般针对当前Namespace生效。

ServiceEntry

• 必须密切监控服务项目的添加，以确保不向命名空间提供任意的外部访问权限。

• HostName

  • 一个给定的主机名只能有一个服务条目。同一主机名的多个服务条目将导致未定义的行为。

  • 不建议有多个服务条目在主机名上重叠。例如，两个带有主机xx.example.com和example.com的服务条目将在运行时导致未定义的行为。

  • 必须使用完全符合格式规范的域名作为主机名。不建议使用没有英文半角句号（.）的短名称。

• Address

• 除非地址字段有一个CIDR块，否则避免使用NONE解析模式。一个没有地址字段的NONE解析的服务条目，将会允许在服务条目中指定端口上的任何IP的流量。

VirtualService

• 虚拟服务不能被继承。因此，针对xx.example.com的虚拟服务的设置与example.com的虚拟服务的设置无关。如果具有不同通配符主机的多个虚拟服务与给定的主机名相匹配，在运行时将只应用最具体的虚拟服务的设置。

• 对于HTTP规则，首选精确或前缀的URL匹配，而不是正则表达式。基于正则表达式的匹配速度较慢，还可能导致不符合预期的行为。

• 网格内部，对于一个给定的主机名，应该只有一个虚拟服务。多个虚拟服务将导致不符合预期的行为。请避免使用短名称来指代虚拟服务中的主机，因为主机名称解释受制于运行时的上下文，短名称可能会造成名称模糊，不具有唯一性。

DestinationRule

DestinationRule定义在路由发生之后如何为网络流量提供服务的策略。在DestinationRule中可以配置如下内容：

• 网络流量策略

• 负载均衡策略

• 连接池设置

• mTLS

• 回弹性

• 使用标签（label）指定服务的子集（subsets），这些子集将在VirtualService中用到。

配置Destination Rule时，请注意如下内容：

• 在创建流量转移的子集时，在创建带有子集的目标规则和创建指向这些子集的虚拟服务之间需要留有几秒的延迟。这个延迟可以确保在Pilot发送指向这些子集的路由配置时，对应的Envoy上游配置已经就绪。

• 可以使用通配符目标规则在一系列的主机上指定一个单一的目标规则。例如，istio-config根命名空间中的全局目标规则将所有与.local主机名匹配的服务配置为mTLS。当为一个更具体的主机名创建目标规则时（例如.ns1.svc.cluster.local或svc1.ns1.svc.cluster.local），会选择最具体的目标规则。其他通配符目标规则的设置不会被继承。因此，您编写的任意目标规则都必须携带全局目标规则中的所有必选项，例如mTLS。

VirtualService和DestinationRule的可见性

若访问的权限未严格控制，网格运维人员可能会在客户端命名空间中编写导出值为'.'的规则以覆盖服务器指定的目标规则和虚拟服务。服务的目标规则和虚拟服务（在Kubernetes或Service Entry中）会影响到与该服务对话的所有Sidecar，例如离群值检测、重试策略等设置，将在客户端侧的Sidecar上执行。虽然让每个服务消费者命名空间为另一个命名空间的服务编写自己的虚拟服务和目标规则可能较为便捷，但如果不限制这种自定义配置的可见性，就会导致未定义的行为。

Sidecar

• 若访问的权限未严格控制，命名空间所有者可能会通过在egress.hosts部分声明对*/*的依赖，或者通过从具有潜在冲突配置的多个命名空间导入服务和配置，来覆盖全局指定的Sidecar，导致与没有Sidecar系统的效果一致。

• 建议使用Istio中的Sidecar API来限制每个工作负载对系统中其他工作负载的依赖性。整个命名空间有一个Sidecar资源即可，无需工作负载选择器来配置整个命名空间的默认值。每个Sidecar资源都指定了命名空间中工作负载所需要的主机，这些主机对应Kubernetes服务、Istio服务条目和Istio VirtualServices中的主机名。基于导入的服务主机名，适当的目标规则也会自动从服务的命名空间导入。Sidecars在egress.hosts字段中声明对其他命名空间的服务的依赖性。声明对主机名的依赖（无论是否有通配符）将导致Pilot尝试搜索所有存在上述主机的命名空间，并从所有匹配的命名空间导入。

  #示例一
  egress:
  - hosts:
    - "_/_"
   
  #示例二
  egress:
  - hosts:
    - foo.example.com
    - .fun.com

  如果在多个命名空间中存在同一主机相冲突的服务条目，或者在多个命名空间中存在与同一主机相冲突的虚拟服务（例如有exportTo: *），则特定资源的选择基于这些资源的创建顺序。这种行为可能会在生产中造成未知的后果。

  • Sidecars不支持继承。如果一个命名空间声明了一个Sidecar资源，命名空间的本地Sidecar会优先于全局默认的Sidecar。

  • 当多个Sidecars有重叠的工作负载选择器时，将随机选择一个Pod的Sidecar资源。因此，请确保在编写带有工作负载选择器的Sidecars时，每个Sidecar都针对其命名空间中的一组不同的Pod。

Telemetry

• 同一个Namespace下，不能配置两个未定义workLoadSelector的Telemetry CR。如果定义了多个，则无法确定哪个生效。

• 同一个Namespace下，若Telemetry CR包含workLoadSelector，不能存在两个重叠的workLoadSelector CR。若发生重叠，则无法确定哪个生效。

服务治理

服务治理支持基于全局、命名空间、工作负载三个维度进行配置。例如您可以在全局（istio-system命名空间）创建一个较为宽松的规则，然后在特定命名空间基于业务特点进行更细化的配置用以覆盖全局配置。若存在一些需要重点关注的应用，您还可以使用工作负载级别的配置，对其进行特定配置。