前言

随着企业信息系统越来越多地采用微服务架构，如何在多集群环境中实现服务的高效、安全地跨集群访问成为了一个重要的挑战。Istio 作为一种流行的服务网格解决方案，提供了丰富的功能来支持跨集群服务的无缝连接。

在部署和使用多集群服务网格时有以下难点：

• 跨集群的服务注册发现与路由
• 集群间服务的身份识别与认证

本文将深入探讨如何在多集群多网格的 Istio 部署中，通过实施 SPIRE 联邦和东西向网关暴露服务的方式，实现跨集群的无缝访问。通过一系列配置和部署示例，本文旨在为读者提供一个清晰的指南，帮助理解和解决多集群服务网格部署中遇到的常见问题和挑战。

Istio 的部署模型

Istio 文档中根据集群、网络、控制平面、网格、信任域及租户等维度划分了多种部署模型，我将其总结并附上适用场景说明如下表所示。

选择合适的部署模型需要考虑到实际的业务需求、安全要求、管理复杂度以及成本等因素。在生产环境中，往往是对多种部署模型的组合使用。

下表展示了在实际应用中如何结合不同的部署模型来满足更复杂的业务和技术需求：

这些混合模型提供了高度的灵活性和可扩展性，能够满足各种复杂的部署要求。在选择混合模型时，组织需要考虑到管理复杂性、成本、安全要求以及业务需求，以确定最合适的部署策略。通过适当的规划和设计，Istio 的灵活部署模型可以帮助组织构建出既安全又高效的服务网格架构。在大多数场景下，单信任域的多集群 + 单网格 + 多控制平面已足够满足需要。

本文将聚焦多集群 + 多网格 + 多控制平面 + 多信任域的混合部署模型，这是一种相当复杂的场景，如果你可以完成这种场景的部署，那么其他场景也就不在话下了。

多集群 Istio 服务网格中的 FQDN

网格间的服务要想互相访问，必须了解各自的 FQDN。FQDN 通常由服务名、命名空间和顶级域（如 svc.cluster.local）组成。在 Istio 的多集群或多网格设置中，可以通过不同的机制（如ServiceEntry、VirtualService、Gateway 配置）来控制和管理服务的路由和访问，而不是通过修改 FQDN 来实现。

多集群服务网格中的 FQDN 与单集群并没有什么不同，通常遵循以下格式：

<service-name>.<namespace>.svc.cluster.local

也许你会想到通过 meshID 来区分网格？meshID 主要用于区分和管理在同一环境中或跨环境的多个 Istio 网格，meshID 并不用于直接构造服务的 FQDN。

跨集群的服务注册发现与路由

在 Istio 多网格环境中，东西向网关（East-West Gateway）起着关键作用，它不仅处理网格间的入口和出口流量，还支持服务的发现和连接。当一个集群需要访问另一个集群中的服务时，它通过这个网关路由到目标服务。

下图展示了跨集群的服务注册发现与路由的过程。

在跨集群的 Istio 网格配置中，服务注册、发现和路由的流程是至关重要的，它们确保了不同集群中的服务可以相互发现并通信。以下是跨集群 Istio 网格中服务注册、发现与路由的基本流程：

1. 服务注册

在每个 Kubernetes 集群中，当一个服务被部署时，它的信息会被注册到 Kubernetes 的 API Server。这包括服务的名称、标签、选择器、端口等信息。

2. 同步到 Istiod

Istiod，作为控制平面，负责监控 Kubernetes API Server 的状态变化。每当有新的服务被注册或现有服务被更新时，Istiod 会自动检测到这些变化。Istiod 接着提取必要的服务信息并构建内部的服务和端点的配置。

3. 跨集群服务发现

为了使一个集群中的服务能够发现并通信到另一个集群的服务，Istiod 需要将服务端点信息同步到所有相关集群。这通常通过以下两种方式之一实现：

• DNS 解析：Istio 可配置为利用 CoreDNS 或类似服务，在 DNS 查询中返回跨集群的服务端点。当一个服务尝试解析另一个集群中的服务时，DNS 查询会返回可以访问的远程服务的 IP 地址。在本文中我们将启用 Istio 的 DNS 代理实现跨集群的服务发现。在一个服务同时存在于本地和远程集群中时，在本地执行 DNS 查询只会返回本地服务的 ClusterIP，若该服务只存在于远程集群中时，DNS 查询将返回远程服务所在集群的东西向网关的负载均衡器地址，该特性也可以用于跨集群的故障恢复。
• 服务入口同步：通过设置特定的 ServiceEntry 配置，使得一个集群的 Envoy 代理知道如何通过东西向网关找到并路由到另一个集群的服务。

4. 路由和负载均衡

当服务 A 需要与服务 B 通信时，它的 Envoy 代理首先解析服务 B 的名称获取 IP 地址，即服务 B 所在集群的东西向网关的负载均衡器地址。接着该东西向网关将请求路由到目标服务。Envoy 代理可以根据配置的负载均衡策略（如轮询、最少连接数等），选择最佳的服务实例来发送请求。

5. 流量管理

Istio 提供了丰富的流量管理功能，例如请求路由、故障注入、流量复制等。这些规则在 Istio 的控制平面中定义，并推送到各个 Envoy 代理执行。这样可以在跨集群环境中灵活地控制和优化服务间的通信。

集群间服务的身份识别与认证

当不同集群中运行的服务需要相互通信时，正确的身份认证和授权是确保服务安全的关键。使用 SPIFFE 可以帮助标识和验证服务的身份，但在多集群环境中需要确保这些身份是唯一且可验证的。

为此，我们将设置 SPIRE 联邦来为多集群的服务分配身份并实现跨集群的身份认证：

• 使用 SPIFFE 来标识服务身份：在 SPIFFE 框架下，每个服务都会被分配一个格式为spiffe://<trust-domain>/<namespace>/<service>的唯一标识符。在多集群环境中，可以通过包括集群名称在内的“trust domain”来确保身份的唯一性。例如，可以设置spiffe://foo.com/ns/default/svc/service1和spiffe://bar.com/ns/default/svc/service1，以区分不同集群中相同名称的服务。
• 使用 SPIRE 联邦来管理集群间的证书：它可以增强多集群服务网格中的安全性。SPIRE（SPIFFE Runtime Environment）提供了一个高度可配置的平台，用于服务身份验证和证书颁发。当使用 SPIRE 联邦时，可以实现跨集群的服务认证，通过为每个 SPIRE 集群创建 Trust Bundle 实现跨集群的身份认证。

以下是实现 SPIRE 联邦的步骤说明。

1. 配置 Trust Domain

每个集群都配置为一个单独的 trust domain。这样，每个集群内的服务都将具有基于其所在 trust domain 的唯一 SPIFFE ID。例如，集群 1 的服务可能拥有 ID spiffe://cluster1/ns/default/svc/service1，而集群 2 的相同服务则为 spiffe://cluster2/ns/default/svc/service1。

2. 建立 Trust Bundle

在 SPIRE 中配置 trust relationships 以允许不同 trust domain 的节点和工作负载相互验证。这涉及到 trust domain 之间交换和接受彼此的 CA 证书或 JWT keys，确保跨集群通信的安全性。

3. 配置 SPIRE Server 和 Agent

在每个集群中部署 SPIRE Server 和 SPIRE Agent。SPIRE Server 负责管理证书颁发和续签，而 SPIRE Agent 负责将证书和密钥安全地分发给集群内的服务。

4. 使用 Workload API

服务可以通过 SPIRE 的 Workload API 请求和更新其身份证书。这样，服务即使在不同集群中运行，也能持续验证其身份，并安全地与其他服务通信。我们将配置 Istio 网格中的代理共享 SPIRE Agent 中的 Unix Domain Socket，从而访问 Workload API 来管理证书。

5. 自动化证书轮换

我们将使用 cert-manager 作为 SPIRE 的 UpstreamAuthority，配置 SPIRE 自动轮换服务证书和密钥，增强系统的安全性。通过自动化轮换，即使证书被泄露，攻击者也只能在很短的时间内利用这些证书。

通过这些步骤，你可以建立一个跨集群的、安全的服务身份验证框架，使得各个集群的服务能够安全地识别和通信，从而有效地降低安全风险并简化证书管理。这样的配置不仅增强了安全性，还通过分散的信任域提高了系统的可扩展性和灵活性。

部署多集群

下图展示了 Istio 多集群及 SPIRE 联邦的部署模型。

下面我将演示如何在多集群 Istio 网格中实现无缝地跨集群无缝访问。

1. 在 GKE 中创建两个 Kubernetes 集群，分别命名为 cluster-1 和 cluster-2
2. 分别在这两个集群中部署 SPIRE 并设置联邦
3. 分别在两个集群中安装 Istio，注意配置信任域、东西向网关、入口网关、 sidecarInjectorWebhook 挂载 SPIFFE UDS 的 workload-socket，并启用 DNS 代理
4. 部署测试应用并验证跨集群的无缝访问

我们部署的各组件版本如下：

• Kubernetes: v1.29.4
• Istio: v1.22.1
• SPIRE: v1.5.1
• cert-manager: v1.15.1

我将所有命令及步骤说明保存在 Github 上：rootsongjc/istio-multi-cluster，你可以按照该项目中的说明操作。下面是对各主要步骤的说明。

1. 准备 Kubernetes 集群

打开 Google Cloud Shell 或本地终端，并确保你已经安装了 gcloud CLI。使用以下命令创建两个集群：

gcloud container clusters create cluster-1 --zone us-central1-a --num-nodes 3
gcloud container clusters create cluster-2 --zone us-central1-b --num-nodes 3

2. 部署 cert-manager

使用 cert-manager 作为根 CA 为 istiod 和 SPIRE 颁发证书。

./cert-manager/install-cert-manager.sh

3. 部署 SPIRE 联邦

SPIRE 联邦的基本信息如下：

注意：信任域不需要与 DNS 名称一致，但需要与 Istio Operator 配置中的信任域相同。

执行下面的命令部署 SPIRE 联邦：

./spire/install-spire.sh

想了解 Istio 中使用 SPIRE 进行身份管理的详情，请参考使用 cert-manager 和 SPIRE 管理 Istio 中的证书。

4. 安装 Istio

我们将使用 IstioOperator 来安装 Istio，其中为每个集群配置了：

• 自动 Sidecar 注入
• 入口网关
• 东西向网关
• DNS 代理
• SPIRE 集成
• 访问远程 Kubernetes 集群的 Secret

执行下面的命令安装 Istio：

istio/install-istio.sh

验证流量联邦

为了验证多集群安装的正确性，我们将在两个集群中分别部署不同版本的 helloworld 应用，然后在 cluster-1 中访问 helloworld 服务，以测试以下跨集群访问场景：

1. 东西向流量联邦：跨集群的服务冗余
2. 东西向流量联邦：处理非本地目标服务
3. 南北向流量联邦：通过远程入口网关访问服务

执行下面的命令在两个集群中部署 helloworld 应用：

./example/deploy-helloword.sh

东西向流量联邦：跨集群的服务冗余

部署完成 helloworld 应用后，从 cluster-1 的 sleep pod 访问 hellowrold 服务：

kubectl exec --context=cluster-1 -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -sS helloworld.helloworld:5000/hello; sleep 1; done"

下图展示的是该场景下的部署架构及流量路由路径。

从请求结果既有 helloworld-v1 又有 helloworld-v2 的响应来看，说明跨集群的服务冗余生效了。

验证 DNS

此时，因为 helloworld 服务既存在于本地又在远程集群中，若你在 cluster-1 中查询 helloworld 服务的 DNS 名称：

kubectl exec -it deploy/sleep --context=cluster-1 -n sleep -- nslookup helloworld.helloworld.svc.cluster.local

你将得到 cluster-1 集群中的 helloworld 服务的 ClusterIP。

验证流量路由

接下来我们将通过查看 Envoy 代理配置来验证跨集群的流量路由路径。

在 cluster-1 中查看 helloworld 服务的端点：

istioctl proxy-config endpoints deployment/sleep.sleep --context=cluster-1 --cluster "outbound|5000||helloworld.helloworld.svc.cluster.local"

你将得到类似下面的输出：

ENDPOINT               STATUS      OUTLIER CHECK     CLUSTER
10.76.3.22:5000        HEALTHY     OK                outbound|5000||helloworld.helloworld.svc.cluster.local
34.136.67.85:15443     HEALTHY     OK                outbound|5000||helloworld.helloworld.svc.cluster.local

这两个端点，一个是 cluster-1 中的 helloworld 服务的端点，另一个是 cluster-2 的 istio-eastwestgateway 服务的负载均衡器地址。Istio 将为跨集群的 TLS 连接设置 SNI，在 cluster-2 中将通过 SNI 区分目标服务。

执行下面的命令，在 cluster-2 中查询前面 SNI 的端点：

istioctl proxy-config endpoints deploy/istio-eastwestgateway.istio-system --context=cluster-2 --cluster "outbound_.5000_._.helloworld.helloworld.svc.cluster.local"

你将得到类似下面的结果：

ENDPOINT           STATUS      OUTLIER CHECK     CLUSTER
10.88.2.4:5000     HEALTHY     OK                outbound_.5000_._.helloworld.helloworld.svc.cluster.local

这个端点就是 helloworld 服务在 cluster-2 集群中的端点。

通过以上步骤，你应该了解了跨集群冗余服务的流量路径。接下来我们将删除 cluster-1 中的 helloworld 服务，不需要对 Istio 做任何配置，就可以自动实现故障转移。

东西向流量联邦：故障转移

执行下面的命令将 cluster-1 中的 helloworld 副本数量缩容为 0：

kubectl -n helloworld scale deploy helloworld-v1 --context=cluster-1 --replicas 0

再次从 cluster-1 中访问 helloworld 服务：

kubectl exec --context=cluster-1 -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -sS helloworld.helloworld:5000/hello; sleep 1; done"

依然可以获得来自 helloworld-v2 的响应。

现在，直接删除 cluster-1 中的 helloworld 服务：

kubectl delete service helloworld -n helloworld --context=cluster-1

依然可以获得来自 helloworld-v2 的响应，这说明跨集群的故障转移生效了。

下图展示了该场景下的流量路径。

验证 DNS

此时，因为 helloworld 服务既存在于本地又在远程集群中，若你在 cluster-1 中查询 helloworld 服务的 DNS 名称：

kubectl exec -it deploy/sleep --context=cluster-1 -n sleep -- nslookup helloworld.helloworld.svc.cluster.local

你将得到 cluster-2 集群中东西向网关的地址和 15443 端口。

南北向流量联邦：通过远程入口网关访问服务

通过入口网关访问远程集群中的服务，是最传统的跨集群访问方式，下图展示了该场景下的流量路径。

执行下面的命令在 cluster-2 中创建 Gateway 和 VirtualService：

kubectl apply --context=cluster-2 \
	-f ./examples/helloworld-gateway.yaml -n helloworld

获取 cluster-2 中的入口网关地址：

GATEWAY_URL=$(kubectl -n istio-ingress --context=cluster-2 get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

执行下面的验证可以通过远程入口网关访问服务：

kubectl exec --context="${CTX_CLUSTER1}" -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -s http://$GATEWAY_URL/hello; sleep 1; done"

你将得到来自 helloworld-v2 的响应。

验证身份

执行下面的命令获取 cluster-1 集群中 sleep pod 中的证书：

istioctl proxy-config secret deployment/sleep -o json --context=cluster-1| jq -r '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | base64 --decode > chain.pem
split -p "-----BEGIN CERTIFICATE-----" chain.pem cert-
openssl x509 -noout -text -in cert-ab
openssl x509 -noout -text -in cert-aa

如果在输出的消息中看到下面的字段，说明身份分配正确：

Subject: C=US, O=SPIFFE

URI:spiffe://foo.com/ns/sample/sa/sleep

查看 SPIRE 中的身份信息：

kubectl --context=cluster-1 exec -i -t -n spire spire-server-0 -c spire-server \
	-- ./bin/spire-server entry show -socketPath /run/spire/sockets/server.sock --spiffeID spiffe://foo.com/ns/sleep/sa/sleep

你将看到类似下面的输出：

Found 1 entry
Entry ID         : 9b09080d-3b67-44c2-a5b8-63c42ee03a3a
SPIFFE ID        : spiffe://foo.com/ns/sleep/sa/sleep
Parent ID        : spiffe://foo.com/k8s-workload-registrar/cluster-1/node/gke-cluster-1-default-pool-18d66649-z1lm
Revision         : 1
X509-SVID TTL    : default
JWT-SVID TTL     : default
Selector         : k8s:node-name:gke-cluster-1-default-pool-18d66649-z1lm
Selector         : k8s:ns:sleep
Selector         : k8s:pod-uid:6800aca8-7627-4a30-ba30-5f9bdb5acdb2
FederatesWith    : bar.com
DNS name         : sleep-86bfc4d596-rgdkf
DNS name         : sleep.sleep.svc

生产环境建议

对于生产环境，建议使用统一网关，通过 Tier-2 架构，在 Tier-1 边缘网关配置全局的流量路由，该边缘网关将把转写的 Istio 配置下发给 Tier-2 集群中的各个入口网关。

下图展示了使用 TSB 部署的 Tier2 架构的 Istio 服务网格，其中使用 SPIRE 联邦。

我们将这四个 Kubernetes 集群分为 Tier1 集群（tier1）和 Tier2 集群（cp-cluster-1、cp-cluster-2 和 cp-cluster-3）。在 T1 中安装 Edge Gateway，而在 T2 中安装 bookinfo 和 httpbin 应用程序。每个集群将拥有独立的信任域，所有这些集群将构成 SPIRE 联邦。

下图展示了用户通过入口网关访问 bookinfo 和 httpbin 服务的流量路由。

你需要在 Istio 之上创建一个适用于多集群的逻辑抽象层，关于 TSB 中的统一网关的详细信息，请参考 TSB 文档.

总结

本文详细介绍了在 Istio 多集群网格环境中实现服务身份验证、DNS 解析和跨集群流量管理的关键技术和方法。通过精确配置 Istio 和 SPIRE 联邦，我们不仅增强了系统的安全性，还提高了服务间通信的效率和可靠性。遵循这些步骤，你将能够构建一个强大的、可扩展的多集群服务网格，满足现代应用的复杂需求。

参考

• Deploying a Federated SPIRE Architecture - spiffe.io
• Install Multi-Primary on different networks -istio.io
• Istio SPIRE Integration - istio.io
• DNS Proxying - istio.io
• Attesting Istio workload identities with SPIFFE and SPIRE - developer.ibm.com
• Expanding into New Frontiers - Smart DNS Proxying in Istio - istio.io
• 使用 cert-manager 和 SPIRE 管理 Istio 中的证书 - jimmysong.io