Istio 1.8中多集群支持的演变

Istio 1.8 中对多集群的支持有所改变。在之前的文章中，我们介绍过Istio多集群两种部署模型。

• Shared control plane

在此配置中，部署了一个Istio控制平面，并且运行在不同集群上的Pod通常直接进行直接通信（集群位于同一网络上时）。
Istio控制平面正在与其他集群的Kubernetes API服务器通信，以发现它们上运行的工作负载。

• Replicated control plane

在此配置中，在每个集群上部署了一个Istio控制平面，并且在不同集群上运行的Pod通过Istio Ingress网关进行通信。请注意，每个Istio控制平面仅与在同一集群上运行的Kubernetes API服务器通信。
此配置是最受欢迎的配置，因为它提供了更高的可用性。

Istio 1.8 做了那些变更 ?

通过官方文档，我可以总结出有以下4中部署模型：

• 同一网络平面的Multi-Primary

此配置类似于 Replicated control plane 配置，Istio控制平面可以发现其他集群上运行的工作负载（通过访问远程Kubernetes API服务器）。但是由于在同一个网络平面，所以不同集群上运行的Pod可以直接通信。

• 不同网络平面的 Multi-Primary

此配置类似于 Replicated control plane 配置，Istio控制平面可以发现其他集群上运行的工作负载（通过访问远程Kubernetes API服务器）。但是由于在不同的网络平面，所以不同集群上运行的Pod不可以直接通信，必须通过Gateway实现互联互通。

• 同一网络平面的 Primary-Remote

此配置与具有单个网络平面的 Shared control plane 配置相同。

如上图所示，集群cluster1将在两个集群中访问远程Kubernetes API服务器。这样，控制平面将能够为两个集群中的工作负载提供服务发现。不同集群上运行的Pod可以直接通信。

Cluster2中的服务将通过专用于东西向流量的网关到达cluster1中的控制平面。

• 不同网络平面的 Primary-Remote

此配置与具有多个网络平面的 Shared control plane 配置相同。

如上图所示，Primary集群cluster1将访问Remote集群的Kubernetes API服务器。这样，控制平面将能够为两个集群中的工作负载提供服务发现。但是由于在不同的网络平面，所以不同集群上运行的Pod不可以直接通信，必须通过Gateway实现互联互通。

经过我们分析，我们发现其实并没有什么大的变化。只是一种演变。

Endpoint发现如何工作 ?

查看Istio文档，我们就会明白是通过创建远程集群的Kubeconfig，然后访问远程集群的Kubernetes API服务器。

例如 Primary-Remote 部署模型，下面我们就详细讲述一下。

1：配置cluster1 作为 primary集群，也就是控制集群

为cluster1创建istio配置文件：

cat < cluster1.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: cluster1
      network: network1
EOF

并将其应用到集群：

istioctl install --context="${CTX_CLUSTER1}" -f cluster1.yaml

2：在 cluster1 中 部署 east-west gateway

在cluster1中部署一个专门用于东西向流量的网关。默认情况下，此网关将在Internet上公开。生产系统可能需要其他访问限制（例如，通过防火墙规则），以防止外部攻击。

samples/multicluster/gen-eastwest-gateway.sh 
    --mesh mesh1 --cluster cluster1 --network network1 | 
    istioctl --context="${CTX_CLUSTER1}" install -y -f -

等待向东西向网关分配一个外部IP地址：

kubectl --context="${CTX_CLUSTER1}" get svc istio-eastwestgateway -n istio-system

3：公开cluster1中的控制平面

在可以在cluster2上安装之前，我们需要首先在cluster1中公开控制平面，以便cluster2中的服务将能够访问服务发现：

kubectl apply --context="${CTX_CLUSTER1}" -f 
    samples/multicluster/expose-istiod.yaml

4：启用对cluster2 API服务器 的访问

在配置远程集群之前，我们首先必须授予cluster1中的控制平面访问cluster2中的API服务器的权限。这将执行以下操作：

• 使控制平面能够验证来自cluster2中运行的工作负载的连接请求。没有API Server访问权限，控制平面将拒绝请求。
• 启用发现在cluster2中运行的服务端点的功能。

为了提供API Server对cluster2的访问，我们生成一个远程secret并将其应用于cluster1：

istioctl x create-remote-secret 
    --context="${CTX_CLUSTER2}" 
    --name=cluster2 | 
    kubectl apply -f - --context="${CTX_CLUSTER1}"

5：配置cluster2 为远程集群

保存cluster1的东西向网关的地址。

export DISCOVERY_ADDRESS=$(kubectl 
    --context="${CTX_CLUSTER1}" 
    -n istio-system get svc istio-eastwestgateway 
    -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

现在创建远程集群istio配置：

cat < cluster2.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: remote
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: cluster2
      network: network1
      remotePilotAddress: ${DISCOVERY_ADDRESS}
EOF

并将其应用到远程集群cluster2：

istioctl install --context="${CTX_CLUSTER2}" -f cluster2.yaml

部署全部完成。

到目前为止，远程配置文件将在远程集群中安装一台istiod服务器，该服务器将用于该集群中的工作负载的CA和Webhook注入。但是，服务发现将定向到主集群中的控制平面。
将来的版本将完全不需要在远程集群中部署一个Istiod。