关于istio:Istio-18中多集群支持的演变

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 <<EOF > 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 <<EOF > 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。