Istio学习

学习参考链接

https://www.bilibili.com/video/BV1zU411U7y1?spm_id_from=333.788.videopod.sections&vd_source=0372d3f32c3f19a6a2676a7529d6698a

https://istio.io/latest/docs/setup/getting-started/

https://github.com/istio/istio

 

安装

Helm方式安装

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
# 在istio-system命名空间安装（自动创建）
helm install istio-base istio/base -n istio-system
helm install istiod istio/istiod -n istio-system 

 

istioctl方式安装

这里直接从GitHub里下载release包安装

wget https://github.com/istio/istio/releases/download/1.25.2/istio-1.25.2-linux-amd64.tar.gz

tar -zxvf istio-1.25.2-linux-amd64.tar.gz

cd istio-1.25.2

# copy istioctl to an environment path
cp bin/istioctl /usr/local/bin/istioctl  
 
# demo方式安装
istioctl install --set profile=demo -y

 

istioctl install --help

Examples:
  # Apply a default Istio installation
  istioctl install

  # Enable Tracing
  istioctl install --set meshConfig.enableTracing=true

  # Generate the demo profile and don't wait for confirmation
  istioctl install --set profile=demo --skip-confirmation

  # To override a setting that includes dots, escape them with a backslash (\).  Your shell may require enclosing quotes.
  istioctl install --set "values.sidecarInjectorWebhook.injectedAnnotations.container\.apparmor\.security\.beta\.kubernetes\.io/istio-proxy=runtime/default"

 

安装samples 文件夹下 addons 里面的各种插件

kubectl apply -f samples/addons

 

注入方式

其核心功能之一是通过注入 Sidecar 代理（如 Envoy）来实现服务间通信的管理和监控

通过kubectl label为特定namespace指定注入sidecar

kubectl label namespace <namespace-name> istio-injection=enabled

 

通过istioctl kube-inject 命令注入

istioctl kube-inject -f original.yaml > injected.yaml
kubectl apply -f injected.yaml

 或

kubectl apply -f <(istioctl kube-inject -f original.yaml)

 

 

主要组件

Gateway, VirtualService 和 DestinationRule

Gateway: 功能类似ingress controller, 接收外部流量并转发到内部服务.

VirtualService: 定义路由规则，流量镜像，等

DestinationRule: 定义版本信息，配置熔断，等

 

sample project bookinfo (https://github.com/woodhead66/istio/tree/master/samples/bookinfo)

Gateway yaml file from sample project bookinfo

kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"
  - port:      
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "bookinfo.example.com"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/credentials/cert.pem
      privateKey: /etc/istio/credentials/key.pem

 

VirtualService yaml file from sample project bookinfo

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

 

 

DestinationRule yaml file from sample project bookinfo

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

 

 

接入外部服务组件

ServiceEntry：用于在istio中接入访问管理外部第三方服务

sample project external（https://github.com/woodhead66/istio/tree/master/samples/external）

 

# This ServiceEntry exposes the hosts needed for installing packages with apt-get.
# After applying this file, Istio-enabled pods (configured apt-get) be able to execute
# `apt-get upgrade` and `apt-get install`.  If this is not installed you may get
# "404  Not Found"

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: make-aptget-work
spec:
  hosts:
  - deb.debian.org
  - cdn-fastly.deb.debian.org
  - security.debian.org
  - archive.ubuntu.com
  - security.ubuntu.com
  ports:
  - number: 80
    name: http
    protocol: HTTP

 

基于istio的 金丝雀（canary）发布的几种策略

1. 百分比

核心原理：通过配置 VirtualService 中的 weight 字段，按比例将流量分发到不同版本，再逐步放量

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
      weight: 90  # 90% 流量到稳定版本 v1
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v2
      weight: 10  # 10% 流量到新版本 v2

 

2. 特征

核心原理：根据请求的 Header、Cookie、URI 等特征，将特定用户（内部用户，区域用户等）或流量导向新版本，再逐步放量

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - match:  # 匹配特定用户到新版本 v2
    - headers:
        user-agent:
          regex: ".*Chrome.*"  # Chrome 用户
    - headers:
        cookie:
          regex: ".*user=test.*"  # 特定 Cookie
    route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v2
  - route:  # 其他用户到稳定版本 v1
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1

 

 

3. 流量镜像

核心原理：现将流量镜像到新版本，同时监控新版本上的情况，再分发一定比例将流量到新版本，再逐步放量。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
      weight: 90  # 90% 流量到稳定版 v1

   - destination:
       host: my-service.default.svc.cluster.local
       subset: v2
     weight: 10  # 10% 实际流量到 v2

   mirror: # 镜像到新版 v2 
     host: my-service.default.svc.cluster.local 
     subset: v2 
   mirrorPercentage: 
     value: 100 # 100% 镜像到 V2（可调整为 10%、50% 等）

 

istio的可视化

 

 Kiali

kubectl get svc -n istio-system kiali

 

 

jaeger 追踪

kubectl get svc -n istio-system -l app=jaeger

 

 

问题一：在有istio 的k8s集群中，假设有20个微服务，其中5个是对外网的服务，另外15个是内部服务，这种情况下，我需要怎么配置 Gateway，virtualService，destinationRule? 分别配置多少个？

回答一：

在 Istio 服务网格中配置 5 个外部服务和 15 个内部服务时，通常采用 "边缘网关 + 内部路由" 的分层设计。以下是配置策略和数量建议：

一、核心配置组件与数量规划

组件	数量	作用
Gateway	1-2 个	定义集群入口点（通常一个 HTTP 网关 + 一个 HTTPS 网关）
VirtualService	20 个（至少）	为每个服务定义路由规则（外部服务需绑定 Gateway，内部服务仅需网格内路由）
DestinationRule	按需（建议 20 个）	为每个服务定义负载均衡、熔断、TLS 等策略（可按服务或子集分组）

二、具体配置方案

1. Gateway 配置（边缘入口）

yaml

 

 

# 外部 HTTP 网关（端口 80，可重定向到 HTTPS）
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: external-http-gateway
spec:
  selector:
    istio: ingressgateway  # Istio 默认入口网关
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.example.com"  # 替换为实际域名或通配符

# 外部 HTTPS 网关（端口 443，启用 TLS）
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: external-https-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*.example.com"
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key

 

 

关键点：

 

• 通常只需 1 个 Gateway 处理所有外部流量（除非有特殊协议需求）。
• 通过 hosts 字段限制可访问的域名（生产环境避免使用通配符）。

2. VirtualService 配置（路由规则）

外部服务（绑定 Gateway）

每个外部服务需配置一个 绑定 Gateway 的 VirtualService，示例：

 

yaml

 

 

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: external-service-vs  # 替换为实际服务名
spec:
  hosts:
  - "service1.example.com"  # 外部访问域名
  gateways:
  - external-https-gateway  # 绑定到上面定义的 Gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: external-service  # 集群内服务名
        port:
          number: 8080

 

内部服务（仅网格内访问）

每个内部服务需配置一个 仅用于网格内路由的 VirtualService，示例：

 

yaml

 

 

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: internal-service-vs  # 替换为实际服务名
spec:
  hosts:
  - "internal-service"  # 集群内服务名（无需域名）
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: internal-service
        port:
          number: 8080

 

 

关键点：

 

• 外部服务：必须通过 gateways 字段绑定到 Gateway，并使用域名作为 hosts。
• 内部服务：无需绑定 Gateway，直接使用服务名作为 hosts，仅网格内可见。

3. DestinationRule 配置（流量策略）

每个服务建议配置一个 DestinationRule，定义负载均衡、熔断等策略：

 

yaml

 

 

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: service-dr  # 替换为实际服务名
spec:
  host: service-name  # 目标服务名
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 负载均衡策略
    connectionPool:
      http:
        http2MaxRequests: 1000  # HTTP2 最大请求数
        maxRequestsPerConnection: 100  # 每个连接的最大请求数
    outlierDetection:  # 熔断配置
      consecutive5xxErrors: 5  # 连续5次5xx错误
      interval: 10s  # 检测间隔
      baseEjectionTime: 30s  # 熔断时间

 

 

关键点：

 

• 负载均衡：可选择 ROUND_ROBIN、LEAST_CONN、RANDOM 等策略。
• 熔断：通过 outlierDetection 防止故障实例影响整体服务。

三、配置数量总结

组件	外部服务（5 个）	内部服务（15 个）	总计
Gateway	1-2 个（共享）	0	1-2
VirtualService	5 个（绑定 Gateway）	15 个（仅网格内）	20
DestinationRule	5 个	15 个	20

四、最佳实践

1. 分层设计：
   • 外部流量通过 Gateway → VirtualService → DestinationRule 处理。
   • 内部流量直接通过 VirtualService → DestinationRule 处理。
2. 简化管理：
   • 使用标签和选择器批量配置相似服务（如所有 API 服务共用一组策略）。
   • 利用 Kustomize 或 Helm 模板减少重复配置。
3. 安全加固：
   • 为外部服务启用 HTTPS（通过 Gateway 的 TLS 配置）。
   • 为内部服务启用 mTLS（通过 DestinationRule 的 TLS 配置）。
4. 监控与可观测性：
   • 结合 Prometheus 和 Grafana 监控流量指标。
   • 配置 Jaeger 追踪跨服务调用路径。

五、示例：完整配置模板

以下是一个外部服务的完整配置示例（包含 Gateway、VirtualService、DestinationRule）：

 

yaml

 

 

# 1. Gateway（共享，略，见前文）

# 2. VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productpage-vs
spec:
  hosts:
  - "productpage.example.com"
  gateways:
  - external-https-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: productpage
        port:
          number: 9080

# 3. DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: productpage-dr
spec:
  host: productpage
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # 启用 mTLS
    loadBalancer:
      simple: ROUND_ROBIN

 

 

通过这种配置模式，可清晰区分外部和内部服务，同时保持 Istio 网格的统一管理能力。

 

 

 

问题二：根据上面的答案，所以 service 和 virtual Service 必须一一对应起来才能被 istio 管理起来？

回答二：

不是的，Service 和 VirtualService 并非必须一一对应。Istio 的 VirtualService 主要用于定义流量路由规则，它可以关联一个或多个 Service，也可以一个 Service 被多个 VirtualService 关联，具体取决于你的流量管理需求。

更详细的说明：

1. 一个 VirtualService 可以关联多个 Service
   例如，当你需要将流量按规则分发到不同的服务（如 A 服务和 B 服务）时，可以在一个 VirtualService 中通过 hosts 指定多个 Service，再通过 http.route 定义不同的路由规则（如按路径、权重分发）。
   示例：
   yaml

    

    

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: multi-service-vs
   spec:
     hosts:
     - service-a  # 关联 service-a
     - service-b  # 关联 service-b
     http:
     - match:
       - uri:
           prefix: /api/a
       route:
       - destination:
           host: service-a
     - match:
       - uri:
           prefix: /api/b
       route:
       - destination:
           host: service-b
   

    
2. 一个 Service 可以被多个 VirtualService 关联
   例如，同一个 Service（如 user-service）可能需要通过不同的入口（如不同的 Gateway）暴露，或针对不同场景（如内部调用、外部访问）定义不同的路由规则，此时可以创建多个 VirtualService 分别关联它。
   示例：
   • 外部访问的 VirtualService：通过公网 Gateway 路由到 user-service，并添加认证规则；
   • 内部访问的 VirtualService：通过内部 Gateway 路由到 user-service，无需认证。
3. VirtualService 也可以不直接关联 Service，而是通过 “服务别名” 路由
   Istio 支持通过 hosts 指定 “服务别名”（如自定义域名 api.example.com），再通过路由规则指向实际的 Service，此时 VirtualService 与 Service 是 “间接关联” 的。

核心逻辑：

• Service 是 K8s 中服务发现的基础，定义了 Pod 集群的访问入口；
• VirtualService 是 Istio 中流量路由的配置，它的作用是 “告诉 Istio 如何将流量转发到目标服务（Service）”，但两者的关联关系是灵活的，并非一一绑定。

 

是否需要一一对应，完全取决于你的流量管理复杂度：简单场景下可以一一对应（一个 Service 配一个 VirtualService），复杂场景下可以灵活组合。

 

 

 

问题三：如果我的20个service分布在不同的namespace里，我要如何创建 Gateway，virtual service， destination Rule 来实现跨namespace的调用？

回答三：

在 Istio 中，跨 namespace 调用服务的核心是通过服务的完整域名（FQDN） 进行路由，并结合 VirtualService、DestinationRule 的配置实现流量管理。以下是具体的配置方法和注意事项，分场景说明：

一、前提：确保基础环境就绪

在配置前，需先满足两个基础条件：

1. 所有 namespace 已启用 Istio 注入：通过为 namespace 添加标签 istio-injection=enabled，确保 Pod 自动注入 Sidecar，否则流量无法被 Istio 管理。
   bash

    

    

   kubectl label namespace <ns-name> istio-injection=enabled --overwrite
   

    
2. 服务间网络可达：K8s 默认允许跨 namespace 访问 Service（通过 FQDN），Istio 仅在此基础上增加流量管控，无需额外配置网络策略（除非有特殊隔离需求）。

二、Gateway：仅用于 “外部流量入站”，与 namespace 无关

Gateway 的作用是定义 “外部流量如何进入集群”，通常不需要为每个 namespace 创建单独的 Gateway，而是集中管理（推荐在 istio-system 或专用网关 namespace，如 istio-gateways 中创建）。

配置要点：

• Gateway 绑定的是 Istio IngressGateway 的 Service（通常在 istio-system 中），通过 selector 指定（如 istio: ingressgateway）。
• 仅需为 “对外暴露的 5 个服务” 配置 Gateway（内部服务跨 namespace 调用不需要 Gateway）。

示例（全局共享的 Gateway）：

yaml

 

 

# 在 istio-system 命名空间创建
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: global-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway  # 绑定Istio默认的IngressGateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.example.com"  # 外部访问的域名（覆盖所有对外服务的域名）

 

三、VirtualService：跨 namespace 路由的核心，灵活关联多 namespace 服务

VirtualService 用于定义流量路由规则，可以在任意 namespace 创建，但需通过服务的完整域名（FQDN） 指向目标服务（格式：service-name.namespace.svc.cluster.local，简写可省略 .svc.cluster.local，即 service-name.namespace）。

场景 1：外部流量通过 Gateway 访问不同 namespace 的对外服务

需创建 VirtualService 关联 Gateway，并路由到目标 namespace 的服务（用 FQDN）。

示例：
假设对外服务 service-a 在 ns-a namespace，service-b 在 ns-b namespace，外部域名分别为 a.example.com 和 b.example.com：

yaml

 

 

# 在 istio-system 或与服务同namespace创建均可
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: external-vs
  namespace: istio-system  # 建议与Gateway同namespace，方便管理
spec:
  hosts:
  - "a.example.com"  # 外部域名
  - "b.example.com"
  gateways:
  - global-gateway  # 关联上面创建的Gateway
  http:
  - match:
    - host: "a.example.com"  # 匹配a的域名
    route:
    - destination:
        host: service-a.ns-a  # 目标服务的FQDN（简写）
  - match:
    - host: "b.example.com"  # 匹配b的域名
    route:
    - destination:
        host: service-b.ns-b  # 目标服务的FQDN（简写）

 

场景 2：内部服务跨 namespace 调用（如 ns-1 的 service-x 调用 ns-2 的 service-y）

如果需要对内部跨 namespace 调用添加路由规则（如版本分流、超时重试），需创建 VirtualService；若无需规则，直接通过 FQDN 调用即可（Istio 自动处理）。

示例（带路由规则的内部跨 namespace 调用）：

yaml

 

 

# 在调用方namespace（ns-1）或目标方namespace（ns-2）创建均可
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: internal-vs
  namespace: ns-1  # 在调用方namespace创建，更贴近业务
spec:
  hosts:
  - service-y.ns-2  # 目标服务的FQDN（作为路由的“入口”）
  http:
  - route:
    - destination:
        host: service-y.ns-2  # 路由到目标服务
        subset: v1  # 若有版本，需结合DestinationRule
      weight: 90
    - destination:
        host: service-y.ns-2
        subset: v2
      weight: 10

 

四、DestinationRule：定义服务的 “出口规则”，建议与服务同 namespace

DestinationRule 用于定义服务的负载均衡策略、版本子集（subset）、连接池等，推荐在 “目标服务所在的 namespace” 创建，原因是：

• 规则与服务生命周期绑定，便于管理（服务删除时可同步删除规则）；
• Istio 默认优先查找 “与目标服务同 namespace” 的 DestinationRule，避免跨 namespace 引用冲突。

示例（为 ns-2 的 service-y 定义规则）：

yaml

 

 

# 在目标服务所在的namespace（ns-2）创建
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: service-y-dr
  namespace: ns-2
spec:
  host: service-y  # 直接用服务名（同namespace内可省略FQDN）
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 负载均衡策略
  subsets:
  - name: v1  # 版本子集v1
    labels:
      version: v1
  - name: v2  # 版本子集v2
    labels:
      version: v2

 

此时，其他 namespace 的 VirtualService（如上面的 internal-vs）可以通过 host: service-y.ns-2 + subset: v1 引用该规则。

五、总结：配置数量与原则

资源类型	配置数量原则
Gateway	1-2 个全局共享（如 HTTP、HTTPS 各一个），与对外服务的 namespace 无关。
VirtualService	按需创建： - 外部流量：1 个或多个（按域名 / 功能分组），关联 Gateway，覆盖所有对外服务的 FQDN； - 内部跨 namespace 调用：仅在需要路由规则时创建，每个规则可覆盖多个服务。
DestinationRule	为需要自定义策略（负载均衡、版本）的服务创建，每个服务 1 个，且与服务同 namespace。

关键注意事项

1. 服务 FQDN 必须正确：跨 namespace 调用时，VirtualService 的 destination.host 必须写全 service-name.namespace（或完整 FQDN），否则 Istio 会默认在当前 namespace 查找服务。
2. 权限与可见性：Istio 资源（VirtualService、DestinationRule）默认在所有 namespace 可见，无需额外授权，但建议按服务所属 namespace 隔离管理。
3. 简化内部调用：若内部服务跨 namespace 调用无需复杂路由（如仅需默认转发），可直接通过 service-name.namespace 调用，无需创建 VirtualService（Istio Sidecar 会自动处理流量）。

通过以上配置，即可实现不同 namespace 服务的跨域调用和流量管理。

 

 

问题四：我看到virtual service 里面有按百分比分发流量的配置，又看到destination rule里有round_robin 这样的规则，这两者是否冲突？

回答四：

VirtualService 的按百分比分发流量与 DestinationRule 的round_robin等负载均衡规则不冲突，因为它们作用于流量路由的不同阶段，职责完全不同。

1. 核心区别：作用阶段与职责

资源	作用阶段	核心职责	举例
VirtualService	流量路由决策阶段	决定 “流量往哪里去”（比如路由到哪个服务版本、哪个子集、哪个命名空间的服务）。	按权重分发：80% 流量到服务 v1 版本，20% 到 v2 版本；或按路径路由到不同服务。
DestinationRule	流量到达目标后的负载均衡阶段	决定 “流量在目标服务内部如何分配到具体实例”（比如 Pod 级别的负载均衡策略）。	对 v1 版本的 Pod 使用round_robin（轮询），对 v2 版本使用random（随机）。

2. 协同工作示例

假设一个服务user-service有两个版本（v1、v2），部署在同一命名空间：

 

• VirtualService 负责 “宏观路由”：将 70% 流量路由到 v1，30% 路由到 v2。
• DestinationRule 负责 “微观负载均衡”：在 v1 的所有 Pod 间用round_robin，在 v2 的所有 Pod 间用least_request（最少请求优先）。

 

配置示例：

 

yaml

 

 

# VirtualService：按权重分发到不同版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service-vs
spec:
  hosts:
  - user-service  # 目标服务名
  http:
  - route:
    - destination:
        host: user-service
        subset: v1  # 对应DestinationRule的v1子集
      weight: 70
    - destination:
        host: user-service
        subset: v2  # 对应DestinationRule的v2子集
      weight: 30
---
# DestinationRule：定义每个子集的负载均衡策略
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user-service-dr
spec:
  host: user-service
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN  # v1内部Pod轮询
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: LEAST_REQUEST  # v2内部Pod优先分配给请求少的实例

 

 

流程说明：

 

1. 流量先经过 VirtualService，70% 被路由到v1子集，30% 到v2子集。
2. 到达v1子集的流量，由 DestinationRule 的ROUND_ROBIN策略分配到 v1 的各个 Pod；
3. 到达v2子集的流量，由LEAST_REQUEST策略分配到 v2 的各个 Pod。

3. 总结

• 不冲突：VirtualService 管 “路由到哪个目标”，DestinationRule 管 “目标内部如何分发给实例”，两者是 “先后顺序” 的协同关系，而非竞争关系。
• 灵活组合：可以根据需求自由搭配（比如 VirtualService 按权重路由，DestinationRule 按 Pod 负载分配），实现更精细的流量控制。