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.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec:  values:    global:      meshID: mesh1      multiCluster:        clusterName: cluster1      network: network1EOF

并将其利用到集群：

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.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec:  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。