Istio多集群管理方案详解

Posted 2021-04-13 k8s技术圈

随着Kubernetes成为云原生领域应用编排的标准，传统企业及新型互联网企业都在逐步将应用容器化及云化。为了实现高并发和高可用，企业通常会将应用部署在多集群甚至多云、混合云等多种环境中，因此，多集群方案逐步成为企业应用部署的最佳选择。很多云厂商都推出了自己的多云、混合云方案，虽然几乎都提供了多集群管理及跨集群的服务访问能力，但是在服务治理方面都有所欠缺。

因此，越来越多的用户对跨集群的服务治理表现出强烈的兴趣和需求。在此背景下，Istio作为Service Mesh领域的事实标准，推出了三种多集群管理方案，这里讲解其中的多控制面管理方案。

多控制面拓扑模型是在Istio 1.1中新增的一种多集群管理模型，如图7-1所示，每个Kubernetes集群都分别部署自己独立的Istio控制面，并且每个集群的控制面部署形态都是相似的，都各自管理自身的Endpoint。

 

多控制面拓扑模型

多控制面模型还有以下特点。

• 共享根CA。为了支持安全的跨集群通信mTLS，该模型要求每个集群控制面都使用相同的中间CA证书，供Citadel签发证书使用，以支持跨集群的TLS双向认证。

• 不要求不同集群之间共享网络，即容器网络不需要打通，跨集群的访问通过Istio Gateway转发。

• 
  

在多控制面Gateway直连模型中，服务间的访问方式分为以下两种。

• 同一集群内部的服务访问。这种访问方式与单集群模型没有任何区别。

• 跨集群的服务访问。这种方式需要用户创建ServiceEntry规则，将Remote集群的服务暴露在本集群的服务网格内，并且由于集群之间的网络并不互通，所以这种模型依赖Remote集群的Gateway中转流量。

1.1 服务DNS解析的原理

对于Remote集群的服务，本地集群的DNS显得束手无策，因为Kubernetes DNS只能通过Kube-apiserver获取本集群的服务及服务实例信息。Istio为支持Remote集群的服务DNS解析，做出了如下要求。

1）在每个Kubernetes集群中都额外部署一个istiocoredns组件

istiocoredns与在集群中默认安装的kube-dns和CoreDNS是级联的关系，协助默认的DNS服务器解析带“.global”后缀的服务，因此需要配置kube-dns和CoreDNS的私有DNS域服务器。如下所示为kube-dns服务器配置私有DNS域（stub domains）：

apiVersion: v1kind: ConfigMapmetadata: name: kube-dns namespace: kube-system data:stubDomains: | {"global": ["$(kubectl get svc -n istio-system istiocoredns -o jsonpath={.spec.clusterIP})"]}

CoreDNS的私有DNS域设置如下：

apiVersion: v1kind: ConfigMapmetadata: name: coredns namespace: kube-systemdata: Corefile: | .:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } global:53 { errors cache 30 proxy . $(kubectl get svc -n istio-system istiocoredns -o jsonpath={.spec.clusterIP}) }

这两种DNS服务器的私有DNS域服务器都指向了istiocoredns服务，这样“<name>.<namespace>.global”类型的域名解析都会被转发到istiocoredns服务器上。至于istiocoredns服务器为什么可以解析“<name>.<namespace>.global”，请继续阅读下文。

2）为Remote集群服务创建ServiceEntry

我们可以通过创建ServiceEntry将Remote集群的服务暴露到本地集群内，除此之外，在多控制面模型中，ServiceEntry还可以用于带“.global”后缀的服务DNS进行解析。如下所示是remote集群的forecast服务在primary集群中创建的ServiceEntry：

apiVersion: v1apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: forecastspec: hosts: # 必须是 name.namespace.global 的格式 - forecast.weather.global # 将Remote集群的服务认为是网格内部的服务，因为所有的集群共享相同的根证书 location: MESH_INTERNAL ports: - name: http1 number: 8000 protocol: http resolution: DNS addresses: # 虚假的地址，所有发到这个地址的流量都会被Envoy拦截 # 并转发到${CLUSTER2_GW_ADDR} - 127.255.0.2 endpoints: # 集群2的入口网关地址 - address: ${CLUSTER2_GW_ADDR} ports: http1: 15443 # Do not change this port value

注意：在多控制面的多集群模式下，网关地址必须是从对端集群可以访问的地址，在一般情况下，会通过负载均衡器为网关服务分配一个从集群外部可以访问的虚拟IP地址。

“*.global”类型的服务域名解析流程如下：

• 为支持Remote集群的forecast服务访问，需要创建ServiceEntry。

• 在本地集群中访问“forecast.weather.global”服务时首先会进行DNS解析，Kubernetes集群内的DNS解析首先会被发送到kube-dns服务。

• 默认的kube-dns/coredns根据存根DNS的设置，将“*.global”类型的域名解析请求转发到私有DNS服务器istiocoredns。

*.global类型的服务域名解析流程如下图所示。

*.global类型的服务域名解析流程

1.2 Gateway连接的原理

最简单的多控制面跨集群访问模型如图7-3所示，其中，Cluster1中的frontend服务访问Cluster2中的forecast服务，集群1中的工作负载发起到forecast.weather.global的请求，请求首先被Sidecar拦截，Sidecar再根据配置规则将请求转发到Cluster2的Gateway，Gateway再将请求转发到forecast服务实例，基本的流量转发依赖Istio的ServiceEntry、Gateway、VirtualService配置规则。

随着多集群的复杂度提高，例如在级联多集群场景下，相同的应用及服务跨集群部署频见，这对Istio配置规则的设置要求非常高，并且很难自动控制不同集群中服务实例的负载均衡权重。虽然这种多控制面模型基本能够满足跨集群的服务访问，但是需要额外设置很多VirtualService、DestinationRule、Gateway、ServiceEntry等API对象，比较复杂。

 

最简单的多控制面跨集群访问模型

本篇内容节选及改编自《云原生服务网格Istio：原理、实战、架构与源码解析》

本书京东链接：https://item.jd.com/12538407.html

以上是关于Istio多集群管理方案详解的主要内容，如果未能解决你的问题，请参考以下文章

如何使用 Istio 进行多集群部署管理：多控制平面

315 · Istio1.1 功能预告，真的假不了

idou教你学Istio: 如何用Istio实现K8S Egress流量管理

idou教你学Istio10 : 如何用Istio实现K8S Egress流量管理

eBay 基于 Istio 的统一流量管理实践

5G下的微服务架构：拥抱NFV，Istio 1.1将支持多网络平面