关于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 服务器通信。
此配置是最受欢迎的配置，因为它提供了更高的可用性。

通过官网文档，我能够总结出有以下 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 实现互联互通。

通过咱们剖析，咱们发现其实并没有什么大的变动。只是一种演变。

查看 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。

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

Istio 1.8 做了那些变更 ?

Endpoint 发现如何工作 ?