多集群流量管理

在多集群网格内,针对集群拓扑结构的流量规则可能是可行的。本文件描述了在多集群网格中管理流量的几种方法。在阅读本指南之前:

  1. 阅读 Deployment Models
  2. 确保您部署的服务遵循以下概念 命名空间的相同。

保持集群内的流量

在某些情况下,默认的跨集群负载平衡操作是不可取的。为了保持流量的 “cluster-local” (及: 从 cluster-a 发送的流量将只会到达 cluster-a 中的目的地。), 将主机名或通配符标记为 clusterLocal 使用 MeshConfig.serviceSettings

例如,您可以强制管理集群中的本地的流量对于单个服务、特定命名空间下的所有服务和网格中的所有服务,如下所示:

  1. serviceSettings:
  2. - settings:
  3. clusterLocal: true
  4. hosts:
  5. - "mysvc.myns.svc.cluster.local"
  1. serviceSettings:
  2. - settings:
  3. clusterLocal: true
  4. hosts:
  5. - "*.myns.svc.cluster.local"
  1. serviceSettings:
  2. - settings:
  3. clusterLocal: true
  4. hosts:
  5. - "*"

分区服务

DestinationRule.subsets 允许通过选择标签对服务进行分区。这些标签可以是来自Kubernetes metadata 的标签,也可以是来自 built-in labels. 其中一个内置标签, topology.istio.io/cluster, 在子集群的选择的规则中 DestinationRule 允许创造每个集群的子集群。

  1. apiVersion: networking.istio.io/v1beta1
  2. kind: DestinationRule
  3. metadata:
  4. name: mysvc-per-cluster-dr
  5. spec:
  6. host: mysvc.myns.svc.cluster.local
  7. subsets:
  8. - name: cluster-1
  9. labels:
  10. topology.istio.io/cluster: cluster-1
  11. - name: cluster-2
  12. labels:
  13. topology.istio.io/cluster: cluster-2

使用这些子集群,您可以创建各种路由规则基于这些集群,如 mirroring 或者 shifting.

这提供了另一种创建集群本地流量规则的选择,通过控制到达的目标集群的流量VirtualService:

  1. apiVersion: networking.istio.io/v1beta1
  2. kind: VirtualService
  3. metadata:
  4. name: mysvc-cluster-local-vs
  5. spec:
  6. hosts:
  7. - mysvc.myns.svc.cluster.local
  8. http:
  9. - name: "cluster-1-local"
  10. match:
  11. - sourceLabels:
  12. topology.istio.io/cluster: "cluster-1"
  13. route:
  14. - destination:
  15. host: mysvc.myns.svc.cluster.local
  16. subset: cluster-1
  17. - name: "cluster-2-local"
  18. match:
  19. - sourceLabels:
  20. topology.istio.io/cluster: "cluster-2"
  21. route:
  22. - destination:
  23. host: mysvc.myns.svc.cluster.local
  24. subset: cluster-2

使用这种基于子集群的路由方式来控制本地集群流量,但: MeshConfig.serviceSettings, 有一个缺点,把 service-level proxy 和 topology-level proxy 混在了一起。 比如,一个规则发送 10% 的流量给一个服务 v2 需要两倍的子集群的数量。 (例如: cluster-1-v2, cluster-2-v2)。 这个处理方式最好限制在需要对集群的路由进行更多的精细化控制的场景下。