istio 是服务网格的一种实现，目前经过了 1.5 版本的架构调整与重构之后，优化了很多内容。istio 可以部署在单一集群中，也可以部署在多个集群中，istio 在多集群中的不同部署方式，可以用于规划服务网格的规模大小以及控制面纳管的集群，更细粒度则设计服务的跨集群部署、服务跨集群安全访问等问题。

istio 目前提供了两种多集群部署方案，这两种方案都可以使多个集群构建为一个大的服务网格：

• 多集群独立控制面板：
  每一个集群部署一套 istio 控制面板，不同网格间的服务通过 istio 提供的gateway 相互访问。

• 多集群共享控制面板
  多集群间使用同一套 istio 控制面板，多集群构成一个大规模的服务网格。

本文则着重探究 多集群独立控制面板 的相关内容

多集群独立控制面板

使用多个独立控制面板将多 K8s 集群构建成为一个服务网格，需要多个前置条件：

• root CA 作为统一的签发机构，每个控制面板的证书均需要此机构签发
• 跨集群服务间通信依赖于 istio 的 ingress-gateway 和 egress-gateway
• 每个群集中的istio-ingressgateway服务的IP地址必须可从其他每个群集访问

  注意，此处官方建议使用 L4 负载均衡（NLB），这个需要cloud provider 支持。若部署在没有 NLB 的环境中时， 可能需要修改负载平衡的健康检查。

在不同集群中部署 istio 控制面板

首先需要 root CA 为每个集群签发一套证书，包括 ca-cert.pem ca-key.pem (签发好的证书和key)、root-cert.pem（根证书）cert-chain.pem（证书链）

在部署 istio 控制面之前，执行以下命令:

kubectl create ns istio-system
kubectl create secret generic cacerts -n istio-system \
  --from-file=<your path>/ca-cert.pem \
  --from-file=<your path>/ca-key.pem \
  --from-file=<your path>/root-cert.pem \
  --from-file=<your path>/cert-chain.pem \

部署istio

istioctl manifest apply \
    -f install/kubernetes/operator/examples/multicluster/values-istio-multicluster-gateways.yaml

values-istio-multicluster-gateways.yaml是 istio 官方针对多集群进行的配置，其内容如下：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator             # istio Operator 用于部署 istio 组件
spec:
  addonComponents:
    istiocoredns:               # 开启 istiocoredns
      enabled: true

  components:
    egressGateways:             # 开启 egressGateway，因为ingressGateway默认开启，此处没有配置
      - name: istio-egressgateway
        enabled: true

  values:
    global:
      # Provides dns resolution for global services
      podDNSSearchNamespaces:
        - global
        - "{{ valueOrDefault .DeploymentMeta.Namespace \"default\" }}.global"

      multiCluster:
        enabled: true

      controlPlaneSecurityEnabled: true

    # Multicluster with gateways requires a root CA
    # Cluster local CAs are bootstrapped with the root CA.
    # 关闭自签名证书，使用我们上面创建的证书
    security:
      selfSigned: false

    gateways:
      istio-egressgateway:
        env:
          # Needed to route traffic via egress gateway if desired.
          ISTIO_META_REQUESTED_NETWORK_VIEW: "external"

配置 dns 配置

CoreDNS

在配置 istio dns 之前，我们需要了解一下 coredns 。目前 K8s 中默认使用 CoreDNS 作为service name 解析服务。

CoreDNS 是一个 CNCF 下的孵化级项目，其主要目的是构建一个快速灵活的 DNS 服务器，让用户可以通过不同方式访问和使用 DNS 内的数据。基于 Caddy 服务器框架，CoreDNS 实现了一个插件链的架构，将大量逻辑抽象成插件 Plugin 的形式暴露给使用者，每个插件都执行 DNS 功能，例如 Kubernetes 的 DNS 服务发现、Prometheus 监控等。

CoreDNS 使用 Corefile 进行配置，在Corefile中定义了以下内容：

• 服务器以什么协议监听在哪个端口（可以同时定义多个 server 监听不同端口）
• 服务器负责哪个 zone 的 authoritative DNS 解析
• 服务器将加载哪些插件

Corefile 的典型结构为：

ZONE:[PORT]:
  [PLUGIN]...

下面是一个Corefile在K8s中的示例：

apiVersion: v1
data:
  Corefile: |
    .:53 {                          # 监听域为本地，监听端口53
        errors                      # 错误记录到标准输出
        health                      # 健康状况 可以通过http://localhost:8080/health查看
        # 根据服务的IP响应DNS查询请求，Cluster Domain默认为cluster.local
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          #upstream /etc/resolv.conf
          fallthrough in-addr.arpa ip6.arpa
        }
        # 可以通过http://localhost:9153/metrics获取prometheus格式的监控数据
        prometheus :9153
        # 若解析不到，可以向上转发到 /etc/resolve.conf 中定义的 dns服务中
        #forward . /etc/resolv.conf
        # 缓存时间
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: coredns
  namespace: kube-system

当 CoreDNS 启动后，它将根据配置文件启动不同 server ，每台 server 都拥有自己的插件链。当有 DNS 请求时，它将依次经历如下 3 步逻辑：

• 如果有当前请求的 server 有多个 zone，将采用贪心原则选择最匹配的 zone。
• 一旦找到匹配的 server，按照 plugin.cfg 定义的顺序执行插件链上的插件。
• 每个插件将判断当前请求是否应该处理，将有以下几种可能：
  • 请求被当前插件处理
    插件将生成对应的响应并回给客户端，此时请求结束，下一个插件将不会被调用，如 whoami 插件。
  • 请求不被当前插件处理
    直接调用下一个插件。如果最后一个插件执行错误，服务器返回 SERVFAIL 响应。
  • 请求被当前插件以 Fallthrough 形式处理
    如果请求在该插件处理过程中有可能将跳转至下一个插件，该过程称为 fallthrough，并以关键字 fallthrough 来决定是否允许此项操作，例如 host 插件，当查询域名未位于 /etc/hosts，则调用下一个插件。
    • 请求在处理过程被携带 Hint。
    • 请求被插件处理，并在其响应中添加了某些信息（hint）后继续交由下一个插件处理。这些额外的信息将组成对客户端的最终响应，如 metric 插件。

接入 istiocoredns

在一开始的部署过程中，我们开启了 istiocoredns，因此在 istio-system namespace中会出现

NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
istiocoredns   ClusterIP   172.19.XX.XX   <none>         53/UDP,53/TCP   44m

此外，在集群的 CoreDNS 的 Corefile 中，也已经出现了global域的配置：

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
        reload
    }
    global:53 {
         errors
         cache 30
         proxy . {cluster IP of this istiocoredns service}
    }

下文中 serviceEntry 会将集群外的服务配置为 global 域，因此在dns 解析过程中，coredns会将带有global的解析请求上传给 istiocoredns，由其完成解析工作。

不同集群间的服务通信

使用 serviceEntry

跨集群的服务通信依赖于 istio 的 ServiceEntry。假设 A集群中有服务serviceA，需要访问B集群中的serviceB，此时我们需要在 A集群中创建 ServiceEntry 资源，其定义如下：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: serviceB
spec:
  hosts:
  # 此处需要将host 定义为 <serviceName>.<namespace>.global，这样才能通过 coredns 的global 域从 istiocoredns 中获取到 serviceB 中的ip
  - serviceB.namespace.global
  # 此处定义 serviceB 是服务网格中的内部服务，因为A集群和B集群是公用同一套根证书
  location: MESH_INTERNAL
  ports:
  - name: http1
    number: 8000
    protocol: http
  resolution: DNS
  addresses:
  # 此IP 是一个虚拟IP，且是A集群无法访问到的，当有访问该IP的数据包时，该流量会被 sidecar 劫持，并正确路由。
  - 240.0.0.2
  endpoints:
  # 此 ip 是 B集群中的 istioGateway 的ip
  - address: ${CLUSTER2_GW_ADDR}
    ports:
      http1: 15443 # 此端口为 B集群 istioGateway 的加密端口，服务间通信均使用 TLS 加密。

注意上述 yaml 文件中的 address， 如果serviceB有明确的 vip，则应该直接定义，否则istio官方建议使用 E类地址 240.0.0.0/4，因为这类地址的流量会被 sidecar 劫持。当sidecar 劫持流量之后，会直接将流量导向 B集群的 ingressGateway中。

如果 serviceB 有多个版本，我们可以在 serviceEntry 中添加 label 指定访问的版本:

endpoints:
  - address: ${CLUSTER2_GW_ADDR}
    labels:
      cluster: cluster2
    ports:
      http1: 15443 # Do not change this port value

之后，在A集群中，我们可以同样配置 VirtualService 和 DestinationRule

使用egress Gateway

我们也可以使用 egressGateway，不让流量从 sidecar 直接流量 B集群的 ingressGateway，而是统一走 egressGateway 所在的节点。这样做可以统一管理集群边界。

使用egressGateway，相应的 serviceEntry 需要做如下变动:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: serviceB
spec:
  hosts:
  # must be of form name.namespace.global
  - serviceB.namespace.global
  location: MESH_INTERNAL
  ports:
  - name: http1
    number: 8000
    protocol: http
  # 解析规则设置为静态
  resolution: STATIC
  addresses:
  - 240.0.0.2
  # endpoints 需要指定两个ip，集群B的 ingressGateway ip；集群A的 egressGateway ip
  endpoints:
  - address: ${CLUSTER2_GW_ADDR}
    network: external
    ports:
      http1: 15443
  - address: ${CLUSTER1_EGW_ADDR}
    ports:
      http1: 15443

总结

下图为 pod A 跨集群访问名为 serviceB 的 pod 时整个流程图：

image

1. podA 的 sidecar 会劫持出pod 的流量，向集群中的 coredns 解析 serviceB.default.global域名
2. coredns 根据global 域向上请求 istioCoreDNS 解析域名，istiocoredns 依据 serviceEntry 将域名解析为 serviceEntry yaml 文件中的address ip
3. sidecar 发现返回的ip并不存在，则直接转发到 serviceEntry 中 clusterB 的 ingressGateway
4. clusterB ingressGateway 将流量转发至 podB中

使用Istio网关，公共根CA和serviceEntry，可以跨多个Kubernetes集群配置单个Istio服务网格。
以这种方式配置后，流量可以透明地路由到远程集群，而无需任何应用程序的参与。
serviceEntry的创建需要手动或程序进行创建，istio并不会为我们创建。

这种方式部署简单，使用较为麻烦，但它对于多集群是否处于同一网络没有要求，podIP、service、namespace也没有任何限制。

下一篇将继续介绍 istio 多集群的另一种方式：多集群共享控制面板