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

47次阅读

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

在共享管制立体部署模型下，多个 Kubernetes 近程集群连贯到在主集群中运行的共享 Istio 管制立体。近程群集能够与主群集位于同一网络中，也能够位于不同网络中。连贯一个或多个近程集群后，主集群的管制立体将治理所有服务端点上的服务网格。

Istio 网格逾越多个 Kubernetes 集群，可通过 VPN 间接拜访近程 Pod

先决条件

  • 两个或更多运行受反对的 Kubernetes 版本 (1.16、1.17、1.18) 的集群。
  • 所有 Kubernetes 管制立体 API 服务器必须可互相路由。
  • 同一网络上的群集必须是 RFC1918 网络，VPN 或满足以下要求的代替的更高级的网络技术：
  • 各个集群 Pod CIDR 范畴和服务 CIDR 范畴在整个网络中必须是惟一的，并且不能重叠。
  • 同一网络中的所有 Pod CIDR 必须彼此可路由。
  • 不同网络上的集群必须具备 istio-ingressgateway 服务，该服务可从其余每个集群拜访，最好应用 L4 网络负载平衡器（NLB）。并非所有的云提供商都反对 NLB，并且某些云提供商须要应用非凡的正文能力应用它们。

筹备

CA

从组织的根 CA 为每个集群的 CA 生成两头 CA 证书。共享的根 CA 容许跨不同集群的互相 TLS 通信。为便于阐明，以下阐明将 Istio 示例目录中的证书用于两个集群。
在网格中的每个集群上运行以下命令以装置证书。无关配置内部 CA 的更多详细信息，请参阅证书颁发机构（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

samples 中的根证书和两头证书已宽泛散发并广为人知。不要在生产中应用这些证书，因为这样集群将容易受到安全漏洞和危害。

跨集群管制立体拜访

确定如何向近程集群公开主集群的 Istiod 发现服务。抉择以下两个选项之一：

  • Option (1) – 应用与数据流量共享的 istio-ingressgateway 网关。.
  • Option (2) – 在 Istiod 服务上应用云提供商的外部负载平衡器。无关在群集之间应用外部负载均衡器时可能实用的其余要求和限度，请参阅 Kubernetes 外部负载均衡器文档和您的云提供商的文档。

集群和网络命名

确定网格中集群和网络的名称。这些名称将在 mesh 网络配置中以及配置 mesh 网络的服务注册表时应用。为每个集群调配一个惟一的名称。该名称必须是 DNS 标签名称。在上面的示例中，主集群称为main0，而近程群集为remote0。

$ export MAIN_CLUSTER_NAME=main0
$ export REMOTE_CLUSTER_NAME=remote0

如果集群位于不同的网络上，请为每个网络调配一个惟一的网络名称。

$ export MAIN_CLUSTER_NETWORK=network1
$ export REMOTE_CLUSTER_NETWORK=network2

如果集群在同一网络上，则这些集群应用雷同的网络名称。

$ export MAIN_CLUSTER_NETWORK=network1
$ export REMOTE_CLUSTER_NETWORK=network1

部署

主集群

创立主集群的配置。抉择跨集群管制立体拜访的两个选项之一。
如果是抉择istio-ingressgateway , 则：

cat <<EOF> istio-main-cluster.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      multiCluster:
        clusterName: ${MAIN_CLUSTER_NAME}
      network: ${MAIN_CLUSTER_NETWORK}

      # Mesh network configuration. This is optional and may be omitted if
      # all clusters are on the same network.
      meshNetworks:
        ${MAIN_CLUSTER_NETWORK}:
          endpoints:
          - fromRegistry: ${MAIN_CLUSTER_NAME}
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

        ${REMOTE_CLUSTER_NETWORK}:
          endpoints:
          - fromRegistry: ${REMOTE_CLUSTER_NAME}
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

      # Use the existing istio-ingressgateway.
      meshExpansion:
        enabled: true
EOF

如果是抉择外部负载均衡器，则：

cat <<EOF> istio-main-cluster.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      multiCluster:
        clusterName: ${MAIN_CLUSTER_NAME}
      network: ${MAIN_CLUSTER_NETWORK}

      # Mesh network configuration. This is optional and may be omitted if
      # all clusters are on the same network.
      meshNetworks:
        ${MAIN_CLUSTER_NETWORK}:
          endpoints:
          - fromRegistry: ${MAIN_CLUSTER_NAME}
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

        ${REMOTE_CLUSTER_NETWORK}:
          endpoints:
          - fromRegistry: ${REMOTE_CLUSTER_NAME}
          gateways:
          - registry_service_name: istio-ingressgateway.istio-system.svc.cluster.local
            port: 443

  # Change the Istio service `type=LoadBalancer` and add the cloud provider specific annotations. See
  # https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer for more
  # information. The example below shows the configuration for GCP/GKE.
  # If the GCP/GKE version is less than 1.16, add `network.gke.io/internal-load-balancer-allow-global-access: "true"` to the `service_annotations`.
  # See https://stackoverflow.com/questions/59680679/gcp-internal-load-balancer-global-access-beta-annotation-does-not-work?answertab=active#tab-top.
  components:
    pilot:
      k8s:
        service:
          type: LoadBalancer
        service_annotations:
          cloud.google.com/load-balancer-type: Internal
EOF

利用主集群的配置。

istioctl install -f istio-main-cluster.yaml --context=${MAIN_CLUSTER_CTX}

期待管制立体准备就绪，而后再持续。

kubectl get pod -n istio-system --context=${MAIN_CLUSTER_CTX}

NAME                                    READY   STATUS    RESTARTS   AGE
istio-ingressgateway-7c8dd65766-lv9ck   1/1     Running   0          136m
istiod-f756bbfc4-thkmk                  1/1     Running   0          136m

依据之前抉择的近程管制立体配置选项设置 ISTIOD_REMOTE_EP 环境变量。

如果抉择的是istio-ingressgateway，则：

$ export ISTIOD_REMOTE_EP=$(kubectl get svc -n istio-system --context=${MAIN_CLUSTER_CTX} istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ echo "ISTIOD_REMOTE_EP is ${ISTIOD_REMOTE_EP}"

如果抉择的是外部负载均衡器，则：

$ export ISTIOD_REMOTE_EP=$(kubectl get svc -n istio-system --context=${MAIN_CLUSTER_CTX} istiod -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ echo "ISTIOD_REMOTE_EP is ${ISTIOD_REMOTE_EP}"

近程集群

创立近程集群的配置。

cat <<EOF> istio-remote0-cluster.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      # The remote cluster's name and network name must match the values specified in the
      # mesh network configuration of the primary cluster.
      multiCluster:
        clusterName: ${REMOTE_CLUSTER_NAME}
      network: ${REMOTE_CLUSTER_NETWORK}

      # Replace ISTIOD_REMOTE_EP with the the value of ISTIOD_REMOTE_EP set earlier.
      remotePilotAddress: ${ISTIOD_REMOTE_EP}

  ## The istio-ingressgateway is not required in the remote cluster if both clusters are on
  ## the same network. To disable the istio-ingressgateway component, uncomment the lines below.
  #
  # components:
  #  ingressGateways:
  #  - name: istio-ingressgateway
  #    enabled: false
EOF

利用近程集群配置。

$ istioctl install -f istio-remote0-cluster.yaml --context ${REMOTE_CLUSTER_CTX}

期待近程集群准备就绪。

$ kubectl get pod -n istio-system --context=${REMOTE_CLUSTER_CTX}
NAME                                    READY   STATUS    RESTARTS   AGE
istio-ingressgateway-55f784779d-s5hwl   1/1     Running   0          91m
istiod-7b4bfd7b4f-fwmks                 1/1     Running   0          91m

在近程集群中运行的 istiod 部署为近程集群的 pod 提供主动 sidecar 注入和 CA 服务。这些服务以前由 Sidecar 注入器和 Citadel 部署提供，而 Istiod 中不蕴含这服务。近程集群的 Pod 正在从主集群的 Istiod 获取配置以进行服务发现。

跨集群负载平衡

配置 ingress gateway

如果两个集群都在同一网络上，请跳过此步骤并持续配置服务注册表。

跨网络流量通过每个指标集群的 ingress gateway 平安地路由。当网格中的集群位于不同的网络上时，您须要在入口网关上配置端口 443，以将传入流量传递到申请的 SNI 标头中指定的指标服务，以获取本地顶级域（即 Kubernetes）的 SNI 值。DNS 域）。互相 TLS 连贯将从源到目的地始终应用。

将以下配置利用于每个集群。

cat <<EOF> cluster-aware-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cluster-aware-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: tls
      protocol: TLS
    tls:
      mode: AUTO_PASSTHROUGH
    hosts:
    - "*.local"
EOF

$ kubectl apply -f cluster-aware-gateway.yaml --context=${MAIN_CLUSTER_CTX}
$ kubectl apply -f cluster-aware-gateway.yaml --context=${REMOTE_CLUSTER_CTX}

配置跨集群服务注册

为了实现跨集群的负载平衡，Istio 管制立体要求拜访网格中的所有集群以发现服务，端点和 Pod 属性。要配置拜访权限，请为每个具备凭据的近程集群创立一个秘钥，以拜访近程集群的 kube-apiserver 并将其装置在主集群中。此秘钥应用近程集群中 istio-reader-service-account 的凭据。--name指定近程集群的名称。它必须与主集群的 IstioOperator 配置中的集群名称匹配。

$ istioctl x create-remote-secret --name ${REMOTE_CLUSTER_NAME} --context=${REMOTE_CLUSTER_CTX} | 
    kubectl apply -f - --context=${MAIN_CLUSTER_CTX}

不要为运行 Istio 管制立体的本地群集创立近程秘钥。Istio 始终晓得本地集群的 Kubernetes 凭据。

其余

Automatic injection

每个集群中的 Istiod 服务都会为其本身集群中的代理提供主动 Sidecar 注入。必须依照主动 Sidecar 注入指南在每个集群中标记名称空间。

拜访来自不同集群的服务

Kubernetes 会基于集群解析 DNS。因为 DNS 解析与集群相干，因而无论服务端点的地位如何，您都必须在运行客户端的每个集群中定义服务对象。为确保这种状况，请应用 kubectl 将服务对象复制到每个集群。复制可确保 Kubernetes 能够解析任何集群中的服务名称。因为服务对象是在名称空间中定义的，因而您必须定义该名称空间（如果该名称不存在），并将其蕴含在所有集群的服务定义中。

平安

每个集群中的 Istiod 服务向其本人集群中的代理提供 CA 性能。晚期的 CA 设置可确保网格中集群之间的代理具备雷同的信赖根。

正文完
istio
发表至： istio
2020-10-25
 0
关于istio:云原生现场分析-Part4-eBPF-跟踪-IstioEnvoy-之上下游事件驱动协作下的-HTTP-反向代理流程
关于istio:上帝和-Istio-打架时程序员如何自我救赎-记一次-Envoy-Filter-修正任性HTTP-Header
关于istio:Rainbond-55-发布支持Istio和扩展第三方Service-Mesh框架
关于istio:Istio在Rainbond-Service-Mesh体系下的落地实践