关于istio:多集群istio-service-mesh复制控制平面

7次阅读

共计 2781 个字符，预计需要花费 7 分钟才能阅读完成。

本文次要介绍多主集群 istio service mesh，每个主集群都有本人的复制管制立体，并应用网关跨集群连贯服务。

在此配置中，每个集群都具备本人的 Istio 管制立体部署，而不是应用共享的 Istio 管制立体来治理网格，每个集群治理本人的端点。为了执行策略和确保安全，所有集群都处于共享的管理控制之下。

通过复制共享服务和名称空间并在所有集群中应用公共根 CA，能够在集群中实现单个 Istio 服务网格。跨集群通信在各个集群的 Istio 网关上进行。

应用 Istio Gateway 跨多个 Kubernetes 集群的 Istio 网格拜访近程 Pod

两个或多个 Kubernetes 集群，其反对版本别离为：1.16、1.17、1.18。
在每个 Kubernetes 集群上部署 Istio 管制立体的权限。
每个集群中的 istio-ingressgateway 服务的 IP 地址必须能够从其余每个集群拜访，最好应用 L4 网络负载平衡器（NLB）。
根 CA。跨集群通信须要服务之间的互相 TLS 连贯。为了在集群之间实现互相 TLS 通信，将为每个集群的 Istio CA 配置为共享根 CA 生成的两头 CA 凭据。

从组织的根 CA 为每个集群的 Istio CA 生成两头 CA 证书。共享的根 CA 容许跨不同集群的互相 TLS 通信。
为便于阐明，以下阐明将 Istio 示例目录中的证书用于两个集群。在理论部署中，您可能会为每个集群应用不同的 CA 证书，所有证书均由公共根 CA 签名。
在每个集群中运行以下命令，以在所有集群中部署雷同的 Istio 管制立体配置。

应用相似于以下命令，为生成的 CA 证书创立 Kubernetes 秘钥。无关更多详细信息，请参见证书颁发机构（CA）证书。

$ kubectl create namespace istio-system
$ kubectl create secret generic cacerts -n istio-system 
    --from-file=samples/certs/ca-cert.pem 
    --from-file=samples/certs/ca-key.pem 
    --from-file=samples/certs/root-cert.pem 
    --from-file=samples/certs/cert-chain.pem

部署 Istio:

$ istioctl install 
    -f manifests/examples/multicluster/values-istio-multicluster-gateways.yaml

为近程集群中的服务提供 DNS 解析将使现有应用程序可能失常运行，因为应用程序通常心愿通过 DNS 名称解析服务并拜访生成的 IP。Istio 自身不应用 DNS 在服务之间路由申请。集群本地的服务共享一个通用的 DNS 后缀（例如 svc.cluster.local）。Kubernetes DNS 为这些服务提供 DNS 解析。

要为近程集群中的服务提供相似的设置，请应用 <name>.<namespace>.global 格局命名近程集群中的服务。Istio 部署蕴含了 CoreDNS 服务器，该服务器将为这些服务提供 DNS 解析。为了利用此 DNS，必须将 Kubernetes 的 DNS 配置为对.global 进行域名存根。

一些云提供商为其 Kubernetes 服务具备不同的特定 DNS 域存根性能和过程。请参考云提供商的文档，以确定如何为每个惟一环境存根 DNS 域。目标是在端口 53 上为.global 增加一个域，以援用或代理 Istio 服务名称空间中的 istiocoredns 服务。

在每个集群中，创立以下 ConfigMap 之一，或更新现有的 ConfigMap，比方 coredns1.4 以上的版本：

kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
    global:53 {
        errors
        cache 30
        forward . $(kubectl get svc -n istio-system istiocoredns -o jsonpath={.spec.clusterIP}):53
    }
EOF

给定集群中须要从其余近程集群拜访的每个服务都须要在近程群集中进行 ServiceEntry 配置。服务条目中应用的主机的格局应为<name>.<namespace>.global，其中名称和名称空间别离对应于服务的名称和名称空间。

为了演示跨集群拜访，请将在一个集群中运行的睡眠服务配置为调用在第二个集群中运行的 httpbin 服务。在开始之前，咱们须要实现以下工作：

抉择两个 Istio 集群，别离称为 cluster1 和cluster2。
您能够应用 kubectl 命令通过 --context 标记拜访 cluster1 和cluster2集群，例如kubectl get pods --context cluster1。应用以下命令列出您的上下文：

$ kubectl config get-contexts
CURRENT   NAME       CLUSTER    AUTHINFO       NAMESPACE
*         cluster1   cluster1   user@foo.com   default
          cluster2   cluster2   user@foo.com   default

将集群的上下文名称存储在环境变量中：

$ export CTX_CLUSTER1=$(kubectl config view -o jsonpath='{.contexts[0].name}')
$ export CTX_CLUSTER2=$(kubectl config view -o jsonpath='{.contexts[1].name}')
$ echo "CTX_CLUSTER1 = ${CTX_CLUSTER1}, CTX_CLUSTER2 = ${CTX_CLUSTER2}"
CTX_CLUSTER1 = cluster1, CTX_CLUSTER2 = cluster2

应用 Istio 网关，公共根 CA 和服务条目，您能够在多个 Kubernetes 集群之间配置单个 Istio 服务网格。一旦以这种形式配置，流量就能够通明地路由到近程集群，而无需任何应用程序的参加。只管此办法须要肯定数量的手动配置能力进行近程服务拜访，然而服务条目创立过程能够自动化。

正文完