**发布时间:** 2025-09-22
**厂商:** AWS
**类型:** BLOG
**原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/building-resilient-multi-cluster-applications-with-amazon-eks/
---
<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 使用 Amazon EKS 构建弹性多集群应用（一）：通过 NLB 实现跨集群负载均衡
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
该解决方案旨在解决在 **Amazon EKS** 环境中，单集群部署在进行集群升级、组件更新或意外删除等操作时面临的可用性与韧性挑战。核心目标是通过在多个 EKS 集群中部署应用，并利用 **AWS Load Balancer Controller (LBC) v2.10+** 的新特性，实现单个 **Network Load Balancer (NLB)** 对跨集群工作负载的统一流量分发，从而构建高可用的云原生应用架构。
该方案的技术原理是利用 `TargetGroupBinding` 资源中的新参数 `multiClusterTargetGroup`。启用后，每个 EKS 集群内的 LBC 会独立管理其本地的服务后端（Pods），并通过一个本地的 `ConfigMap` 对象来跟踪这些 Target。随后，各个集群的 LBC 会将各自管理的 Target 注册到由 NLB 使用的同一个共享 Target Group 中。这种设计将 Target 的管理责任分散到各个集群，避免了跨集群协调的复杂性，同时实现了流量在所有集群间的无缝分发。此方案特别适用于 **蓝绿部署**、**滚动升级** 和 **灾难恢复** 等场景。
## 实施步骤
该方案提供了两种核心实施场景：为现有工作负载启用跨集群负载均衡，以及为新部署的工作负载直接配置跨集群能力。
1. **场景一：扩展现有 NLB 以支持多集群**
1. **启用多集群支持**：在主集群中，通过为现有的 `LoadBalancer` 类型的 `Service` 添加注解 `service.beta.kubernetes.io/aws-load-balancer-multi-cluster-target-group: "true"`，来更新其关联的 `TargetGroupBinding` 资源。
2. **验证主集群配置**：LBC 会在主集群中创建一个 `ConfigMap`，用于跟踪该集群内 `nginx` 服务的 Pod IP 地址作为 Target。
3. **部署备集群应用**：在备用 EKS 集群中部署相同的 `nginx` 应用，但其 `Service` 类型设置为 `ClusterIP`，因为它不需要创建新的负载均衡器。
4. **创建备集群 TargetGroupBinding**：在备集群中手动创建一个 `TargetGroupBinding` 资源。此资源需要明确指向主集群 NLB 所使用的 Target Group ARN，并同样启用 `multiClusterTargetGroup` 标志。
5. **验证 Target 注册**：备集群的 LBC 会创建自己的 `ConfigMap`，并将备集群的 Pod IP 注册到共享的 Target Group 中。通过 AWS CLI 或控制台确认来自两个集群的 Pod IP 都已成功注册且状态健康。
6. **测试流量分发**：通过 NLB 的 DNS 地址发起请求，验证流量是否被均匀分发到两个集群的 Pod 上。
2. **场景二：为新部署实现多集群负载均衡**
1. **部署主集群应用**：在主集群中创建一个新的 `LoadBalancer` 类型的 `Service`，并在其定义中直接包含启用多集群支持的注解。LBC 会自动创建 NLB、Target Group 以及 `TargetGroupBinding`。
2. **部署并关联备集群**：后续步骤与场景一的 3-5 步完全相同，即在备集群部署应用并创建指向同一个 Target Group 的 `TargetGroupBinding`。
3. **验证与测试**：完成配置后，进行跨集群 Target 注册和流量分发的验证。
## 方案客户价值
- **提升应用可用性与韧性**：通过将工作负载分布在多个独立的 EKS 集群，有效规避了因单个集群故障（如升级失败、配置错误或意外删除）导致的业务中断，实现了架构层面的高可用。
- **实现零停机平滑升级**：支持 **蓝绿部署** 模式。在升级集群或应用时，可先升级一个集群，验证通过后再将流量逐步切换过去，整个过程对用户透明，无服务中断。
- **简化灾难恢复 (DR) 架构**：构建了跨集群的 **主动-主动 (active-active)** 服务模式，简化了传统的冷备或热备 DR 方案。当一个集群不可用时，NLB 会自动将流量路由到健康的集群，提升了业务连续性。
- **统一流量入口与简化管理**：使用单个 NLB 作为多个后端集群的统一访问入口，简化了 DNS 配置和客户端连接管理。后端集群的增减对前端透明，降低了运维复杂度。
## 涉及的相关产品
- **Amazon EKS (Elastic Kubernetes Service)**：提供高可用的 Kubernetes 控制平面，是运行容器化应用的基础平台。
- **Network Load Balancer (NLB)**：提供高性能、低延迟的第四层（TCP/UDP）负载均衡服务，作为跨集群流量的统一入口。
- **AWS Load Balancer Controller (LBC)**：在 EKS 集群中运行的 Kubernetes 控制器，它将 Kubernetes 的 `Service` 资源与 AWS 的 NLB 进行关联和生命周期管理。
- **Amazon VPC & EC2**：为 EKS 集群提供隔离的网络环境和计算资源（工作节点）。
- **AWS CloudFormation**：作为基础设施即代码 (IaC) 工具，用于自动化部署本方案所需的 VPC、EKS 集群等所有资源。
## 技术评估
该解决方案通过原生 Kubernetes 控制器（LBC）扩展了 NLB 的能力，为 EKS 用户提供了一种优雅且高效的跨集群服务高可用方案。
- **技术优势**
- **原生集成与声明式配置**：方案与 Kubernetes `Service` 资源模型紧密集成，用户通过标准的注解和 CRD (`TargetGroupBinding`) 进行声明式配置，完全符合 Kubernetes 的运维习惯，学习成本低。
- **去中心化管理模型**：每个集群的 LBC 仅负责管理本集群内的 Target，避免了需要一个中心化组件来协调所有集群的复杂性，架构更具弹性和可扩展性。
- **高性能流量处理**：方案基于 NLB，继承了其高吞吐、低延迟和保持源 IP 的能力，足以应对大规模、高性能要求的应用场景。
- **潜在限制与注意事项**
- **流量分发策略单一**：目前仅支持在所有后端 Target 之间进行 **均等** 的流量分发，尚不支持基于权重或策略的复杂路由，无法实现金丝雀发布等高级流量管理模式。
- **`ConfigMap` 规模限制**：LBC 将一个服务的所有 Target 信息写入单个 `ConfigMap` 对象中，该对象有 1MB 的大小限制。对于单个服务背后有数千个 Pod 的超大规模场景，可能触及此限制。
- **版本依赖性**：此功能强依赖于 **LBC v2.10+** 版本，用户在采纳前需确保集群中的 LBC 已升级到符合要求的版本。
- **资源生命周期管理**：建议为 NLB 启用删除保护，以防止因主集群的 `Service` 被误删而导致 NLB 及共享的 Target Group 被级联删除，从而影响所有集群的服务。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 使用 Amazon EKS 构建弹性多集群应用，第一部分：借助 NLB 实现跨集群负载均衡
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/building-resilient-multi-cluster-applications-with-amazon-eks/](https://aws.amazon.com/blogs/networking-and-content-delivery/building-resilient-multi-cluster-applications-with-amazon-eks/)
**发布时间:** 2025-09-22
**厂商:** AWS
**类型:** BLOG
---
这个由三部分组成的系列文章探讨了多种设计模式和策略，旨在通过在 [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 上进行多集群部署来增强应用程序的弹性。在第一部分中，我们将解决在多集群环境中使用 [网络负载均衡器 (Network Load Balancer, NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) 时遇到的一个常见挑战。
无论是通过 [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 还是在 [Amazon Web Services (AWS)](https://aws.amazon.com/) 上自建集群，企业越来越依赖 Kubernetes 来支持和扩展其关键任务应用。虽然在单个 EKS 集群上运行工作负载很方便，但在关键操作期间维持高可用性 (high availability) 却面临挑战。集群升级、附加组件更新和工作流变更等活动都可能影响工作负载的弹性和应用可用性，因此主动应对这些问题至关重要。
为了缓解这些挑战，用户通常会将应用程序部署到多个 EKS 集群。这种多集群方法具有以下几个关键优势：
- **蓝绿升级 (Blue-green upgrades)**：通过蓝绿部署实现零停机升级，允许流量在集群间逐步迁移。
- **集群升级和附加组件更新**：跨集群交错进行集群和附加组件的更新，最大限度地减少全系统范围的中断。
- **工作负载弹性**：增强工作负载抵御意外集群删除的能力。
- **故障转移 (Failover) 和灾难恢复 (disaster recovery)**：通过跨集群故障转移能力改善灾难恢复。
尽管这些优势引人注目，但在多个集群间实现有效的负载均衡 (load balancing) 在过去一直颇具挑战。然而，[AWS Load Balancer Controller (LBC)](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) v2.10+ 版本现在通过引入多集群 `TargetGroupBinding` 来支持跨集群流量分发，从而填补了这一空白。这是我们将在本文中详细探讨的一项强大功能。该解决方案对于客户端-服务器通信模式以及组织自行管理第七层 (Layer 7) 代理配置的场景尤其有价值，因为网络负载均衡器 (NLB) 为这些用例提供了必要的灵活性和性能。
## 增强的 NLB 目标组绑定：支持多集群 EKS 部署
这项新 [功能](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/targetgroupbinding/targetgroupbinding/#multicluster-target-group) 使 NLB 能够将来自不同 EKS 集群的目标 (`TargetGroupBinding`) 注册到同一个目标组 (target group) 中，确保流量能够无缝分发。
### 该功能的工作原理
在 LBC 2.10+ 版本中，新功能实现了跨多个 EKS 集群的高效目标管理。通过为每个 `TargetGroupBinding` 使用一个 `ConfigMap`，控制器可以无缝支持多集群部署。
新增的 `multiClusterTargetGroup` 参数允许 NLB 处理跨多个集群的目标。启用此标志后，每个集群将独立管理其目标，从而增强了可靠性并简化了跨集群的负载均衡。
下图展示了参考架构：
图 1 – 架构
其工作流程如下：
1. **管理目标**：对于每个 EKS 集群，LBC 都会维护一个独立的 `ConfigMap`，用于跟踪该集群的服务端点 (service endpoints) 对应的目标。这确保了只有特定集群的目标会被注册到 NLB 或从 NLB 注销，避免对其他集群造成意外更改。
2. **Pod 注册**：当新 Pod 启动时，LBC 会在其协调循环 (reconciliation loop) 中更新 `ConfigMap`。新目标会被注册到 NLB 中，确保流量可以正确路由到新 Pod。
3. **Pod 删除**：同样，当 Pod 被删除时，LBC 会更新 `ConfigMap` 以反映这一变化，并从 NLB 中注销已删除的目标，从而保持系统一致性并避免错误。
4. **协调过程**：LBC 定期将服务端点与 NLB 目标进行协调，添加新端点并移除过时的端点，同时利用 `ConfigMap` 维持集群间的隔离。当发生变化时，LBC 会将整个 `ConfigMap` 对象作为单个操作进行更新。控制器不支持部分更新或修补功能。
现在，让我们来实施这个多集群配置。
## 前提条件
在进行本演练之前，您应拥有一个 AWS 账户，并具备创建 EKS 集群和 IAM 角色的相应 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 权限，同时能够启动所提供的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板。有关详细的定价信息，请参阅官方 [AWS 定价](https://aws.amazon.com/pricing) 页面。
## 使用 CloudFormation 部署解决方案
我们使用一个 CloudFormation 堆栈来部署此解决方案。该堆栈会创建所有必要的资源，例如：
- 网络组件，如 [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/)、子网 (subnets) 和 [NAT 网关 (NAT Gateway)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)。
- 两个 EKS 集群：每个 EKS 集群都带有两个工作节点 ([Amazon EC2)](https://aws.amazon.com/ec2/)，部署在同一个 VPC 内。
要开始操作，请完成以下步骤：
1. 登录 [AWS 管理控制台 (AWS Management Console)](https://aws.amazon.com/console/)。
2. 在任何 [AWS 区域 (AWS Region)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 中选择 **Launch Stack**，并在新标签页中打开它：
3. 在 **Create stack** 页面上，保留所有默认值并继续。
4. 勾选复选框以确认将创建 IAM 资源。
5. 选择 **Create stack**。
6. 等待堆栈创建完成。此步骤最多可能需要 15 分钟。
此时，您的主 EKS 集群 (Primary) 和辅助 EKS 集群 (Secondary) 已准备就绪。接下来，在两个集群上配置 LBC 附加组件并部署一个示例应用程序，以演示多集群负载均衡。
从控制台启动 [AWS CloudShell](https://aws.amazon.com/cloudshell/)：
图 2 – 从 AWS 控制台启动 CloudShell
使用 CloudShell，运行以下命令：
```bash
git clone https://github.com/aws-samples/eks-design-patterns
cd eks-design-patterns
bash ./install_prereqs.sh
```
该脚本成功地在主 EKS 集群 (pri-eks-clu1) 上部署了三个 `nginx` Pod 和一个 NLB `LoadBalancer` 服务，而辅助 EKS 集群 (sec-eks-clu1) 已初始化并准备好进行后续配置。
我们将在接下来的部分中介绍两种场景：
1. **场景 1 (现有工作负载)**：使用现有的 NLB 将流量路由到同时运行在主、辅 EKS 集群上的 `nginx` 服务。
2. **场景 2 (新工作负载)**：创建一个新的 NLB，将流量路由到同时运行在主、辅 EKS 集群上的 `nginx` 服务。
每个场景都将演示如何使用单个 NLB 设置在多个集群间无缝分发流量。
我们从针对现有工作负载的场景 1 开始。
### 场景 1：扩展现有 NLB 配置以支持多集群
在此场景中，您将使用一个已有的 NLB 及其关联的目标组和在主 EKS 集群上配置的 `TargetGroupBinding`。您需要更新主 EKS 集群上的 `TargetGroupBinding` 以启用多集群支持。然后，您将在辅助 EKS 集群上为 `nginx` 服务创建一个新的 `TargetGroupBinding`。此配置允许现有的 NLB 使用同一个目标组在主、辅 EKS 集群上运行的 `nginx` 服务之间分发流量。这种方法确保了在维持现有负载均衡器基础设施的同时，实现跨两个集群的无缝流量分发。
***步骤 1***：验证 LBC 中的多集群支持
使用 CloudShell，通过运行以下命令来验证主、辅 EKS 集群是否都安装了 `aws-load-balancer-controller` 并启用了多集群功能：
```bash
kubectl --context pri-eks-clu1 explain targetGroupBinding.spec.multiClusterTargetGroup
kubectl --context sec-eks-clu1 explain targetGroupBinding.spec.multiClusterTargetGroup
```
成功的输出应在两个集群的 `TargetGroupBinding` 规范中显示 `multiClusterTargetGroup` 字段的定义，确认 LBC 的多集群能力已正确启用。如果该字段缺失，请确保您已安装最新版本的 LBC。
***步骤 2***：在 NLB 上启用多集群支持和删除保护
使用 CloudShell，运行以下命令，通过在主 EKS 集群上添加注解来启用删除保护和多集群目标组：
```bash
kubectl --context pri-eks-clu1 patch service nginx \
--patch '{"metadata": {"annotations": {"service.beta.kubernetes.io/aws-load-balancer-multi-cluster-target-group": "true", "service.beta.kubernetes.io/aws-load-balancer-attributes": "deletion_protection.enabled=true"}}}' \
--type=merge
```
成功的输出会显示 `service/nginx patched`。
***步骤 3***：验证 TargetGroupBinding 中的多集群配置
使用 CloudShell，运行以下命令以验证 `targetGroupBinding` 是否已更新并带有 `multiClusterTargetGroup` 标志：
```bash
kubectl --context pri-eks-clu1 get targetgroupbinding -l service.k8s.aws/stack-name=nginx \
-o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.multiClusterTargetGroup}{"\n"}{end}'
```
成功的输出会显示 `true`。
***步骤 4***：验证 ConfigMap 中的目标注册
当 `TargetGroupBinding` 的 `multiClusterTargetGroup` 标志更新后，LBC 会创建一个包含目标列表的 `ConfigMap` 对象，并将目标 Pod 与 NLB 目标进行协调。
使用 CloudShell，运行以下命令以验证 `ConfigMap` 的创建和目标注册情况：
```bash
kubectl --context pri-eks-clu1 get cm aws-lbc-targets-$(kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
kubectl --context pri-eks-clu1 describe cm aws-lbc-targets-$(kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
```
成功的输出会显示一个包含已注册目标的 `ConfigMap`，确认 LBC 在 `nginx` Pod 和 NLB 之间的目标协调已完成。
***步骤 5***：在辅助 EKS 集群上部署 `nginx` 应用程序
使用 CloudShell，运行以下命令在辅助 EKS 集群上创建一个 Deployment 和一个类型为 `ClusterIP` 的 Service 对象：
```bash
kubectl --context sec-eks-clu1 create -f nginxapp.yaml
kubectl --context sec-eks-clu1 create -f nginx_sec-eks-clu1.yaml
kubectl get all
```
成功的输出会显示在辅助集群上创建了一个包含 2 个运行中 Pod 的 `nginx` Deployment 和一个 `ClusterIP` 服务。
***步骤 6***：在辅助 EKS 集群上创建多集群 `TargetGroupBinding`
使用 CloudShell，运行以下命令在辅助 EKS 集群上创建一个带有 `multiClusterTargetGroup` 标志的 `TargetGroupBinding`：
```bash
# 从主 EKS 集群获取 TargetGroup ARN
targetgrouparn=$(kubectl --context pri-eks-clu1 get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.spec.targetGroupARN}{end}')
lb=$(kubectl --context pri-eks-clu1 get svc nginx -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' | sed -n 's/.*\(k8s-default-nginx-[a-z0-9]*\).*/\1/p')
# 获取安全组 ID
secgrpid=$(aws ec2 describe-security-groups --group-ids $(aws elbv2 describe-load-balancers --names ${lb} --query 'LoadBalancers[*].SecurityGroups[]' --output text) --query "SecurityGroups[?Description=='[k8s] Shared Backend SecurityGroup for LoadBalancer'].GroupId" --output text)
# 更新 tgb.yaml 文件
sed "s|<securitygroupid>|${secgrpid}|g; s|<targetgrouparn>|${targetgrouparn}|g" tgb.yaml > tgb_sec.yaml
kubectl --context sec-eks-clu1 create -f tgb_sec.yaml
```
***步骤 7***：验证辅助 EKS 集群上的 `ConfigMap` 创建情况
使用 CloudShell，运行以下命令来验证控制器随 `targetGroupBinding` 一起创建的 `ConfigMap` 对象及其内容：
```bash
kubectl --context sec-eks-clu1 get cm aws-lbc-targets-nginx
kubectl --context sec-eks-clu1 describe cm aws-lbc-targets-nginx
```
成功的输出会显示一个名为 `aws-lbc-targets-nginx` 的 `ConfigMap`，其中包含 `nginx` 目标的 IP 地址和端口。
***步骤 8***：验证跨两个 EKS 集群的目标注册情况
使用 CloudShell，运行以下命令来验证 NLB 是否已从主、辅 EKS 集群注册了目标：
```bash
aws elbv2 describe-target-health --target-group-arn $( kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.spec.targetGroupARN}{end}') --query 'TargetHealthDescriptions[*].[Target.Id,Target.AvailabilityZone,TargetHealth.State]' --output table
```
成功的输出会显示分布在主、辅 EKS 集群上的健康目标，确认多集群配置成功。
***步骤 9***：验证跨 EKS 集群的流量分发
使用 CloudShell，运行以下命令执行综合工作负载测试 (synthetic workload test)，并验证流量是否分发到主、辅 EKS 集群上的 Pod：
```bash
# 获取 NLB 主机名
lb=$(kubectl --context pri-eks-clu1 get svc nginx -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
# 运行 ApacheBench 测试
ab -n 1000 -c 40 http://$lb/
# 检查主集群的日志
echo "Primary EKS Cluster:"
kubectl --context pri-eks-clu1 logs deployment/nginx --tail=2
# 检查辅助集群的日志
echo "Secondary EKS Cluster:"
kubectl --context sec-eks-clu1 logs deployment/nginx --tail=2
```
成功的输出会显示两个集群中都记录了 HTTP 请求，确认 NLB 正在正确地将流量分发到主、辅 EKS 集群上的所有 `nginx` Pod。
***清理*****：** 使用 CloudShell，运行以下命令：****
```bash
kubectl --context sec-eks-clu1 delete targetgroupbinding nginx
kubectl --context sec-eks-clu1 delete svc nginx
kubectl --context pri-eks-clu1 patch service nginx --patch '{"metadata": {"annotations": {"service.beta.kubernetes.io/aws-load-balancer-attributes": "deletion_protection.enabled=false"}}}' --type=merge
kubectl --context pri-eks-clu1 delete svc nginx
kubectl --context pri-eks-clu1 delete deployment nginx
```
您已成功测试了场景 1 中现有工作负载的迁移。在场景 2 中，您将探索如何为新部署实现多集群负载均衡。
### 场景 2：为新部署实现多集群负载均衡
在此场景中，您将创建一个新的 NLB，该 NLB 从一开始就设计为支持多集群流量分发。此实现需要在两个 EKS 集群上都安装 LBC 2.10 或更高版本。
***步骤 1***：在主 EKS 集群上部署带有 `LoadBalancer` 服务的 `nginx`
使用 CloudShell，运行以下命令：
```bash
kubectl --context pri-eks-clu1 create -f nginxapp.yaml
kubectl --context pri-eks-clu1 create -f nginxsvc.yaml
```
***步骤 2***：验证 LBC 创建的 ConfigMap
使用 CloudShell，运行以下命令来验证随 `targetGroupBinding` 一起创建的 `ConfigMap` 对象及其内容：
```bash
kubectl --context pri-eks-clu1 get cm aws-lbc-targets-$(kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
kubectl --context pri-eks-clu1 describe cm aws-lbc-targets-$(kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
```
成功的输出会显示一个包含 `nginx` 目标 IP 地址和端口的 `ConfigMap`，确认 LBC 配置正确。
***步骤 3***：在辅助 EKS 集群上部署 `nginx` 服务
使用 CloudShell，运行以下命令在辅助 EKS 集群上创建一个 `nginx` Deployment 和一个 `ClusterIP` 服务：
```bash
kubectl --context sec-eks-clu1 create -f nginxapp.yaml
kubectl --context sec-eks-clu1 create -f nginx_sec-eks-clu1.yaml
```
***步骤 4***：在辅助 EKS 集群上配置 `TargetGroupBinding`
使用 CloudShell，运行以下命令创建一个支持多集群的 `TargetGroupBinding`：
```bash
# 从主 EKS 集群获取 TargetGroup ARN
targetgrouparn=$(kubectl --context pri-eks-clu1 get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.spec.targetGroupARN}{end}')
lb=$(kubectl --context pri-eks-clu1 get svc nginx -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' | sed -n 's/.*\(k8s-default-nginx-[a-z0-9]*\).*/\1/p')
# 获取安全组 ID
secgrpid=$(aws ec2 describe-security-groups --group-ids $(aws elbv2 describe-load-balancers --names ${lb} --query 'LoadBalancers[*].SecurityGroups[]' --output text) --query "SecurityGroups[?Description=='[k8s] Shared Backend SecurityGroup for LoadBalancer'].GroupId" --output text)
# 更新 tgb.yaml 文件
sed "s|<securitygroupid>|${secgrpid}|g; s|<targetgrouparn>|${targetgrouparn}|g" tgb.yaml > tgb_p2.yaml
kubectl --context sec-eks-clu1 create -f tgb_p2.yaml
```
***步骤 5***：验证辅助 EKS 集群上的 ConfigMap
使用 CloudShell，运行以下命令来验证控制器创建的 `ConfigMap` 对象及其内容：
```bash
kubectl --context sec-eks-clu1 get cm aws-lbc-targets-$(kubectl --context sec-eks-clu1 get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
kubectl --context sec-eks-clu1 describe cm aws-lbc-targets-$(kubectl --context sec-eks-clu1 get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.metadata.name}{end}')
```
成功的输出会显示一个 `ConfigMap`，其中包含辅助 EKS 集群的 `nginx` 目标的 IP 和端口。
***步骤 6***：验证跨两个 EKS 集群的目标注册情况
使用 CloudShell，运行以下命令来验证 NLB 是否已成功从主、辅 EKS 集群注册了目标：
```bash
aws elbv2 describe-target-health --target-group-arn $( kubectl get targetgroupbinding -l service.k8s.aws/stack-name=nginx -o jsonpath='{range .items[*]}{.spec.targetGroupARN}{end}') --query 'TargetHealthDescriptions[*].[Target.Id,Target.AvailabilityZone,TargetHealth.State]' --output table
```
预期输出：
```
-------------------------------------------
| DescribeTargetHealth |
+--------------+--------------+-----------+
| xx.xx.xx.xxx| us-east-1b | healthy |
| xx.xx.xx.xxx| us-east-1c | healthy |
| xx.xx.xx.xxx| us-east-1c | healthy |
| xx.xx.xx.xxx| us-east-1b | healthy |
+--------------+--------------+-----------+
```
输出显示了分布在主、辅 EKS 集群上的健康目标，确认多集群配置成功。
**清理：** 使用 AWS CloudShell，运行以下命令清理所有资源：
```bash
kubectl --context sec-eks-clu1 delete targetgroupbinding nginx
kubectl --context sec-eks-clu1 delete svc nginx
kubectl --context pri-eks-clu1 patch service nginx --patch '{"metadata": {"annotations": {"service.beta.kubernetes.io/aws-load-balancer-attributes": "deletion_protection.enabled=false"}}}' --type=merge
kubectl --context pri-eks-clu1 delete svc nginx
kubectl --context pri-eks-clu1 delete deployment nginx
aws cloudformation delete-stack --stack-name eks-nlb
```
本演示展示了 NLB 多集群功能如何通过在多个 EKS 集群间实现流量分发，从而为现有和新的负载均衡器部署增强服务弹性。
## 注意事项
- 该功能目前仅支持在两个 EKS 集群的目标之间进行双活 (active-active)、均等分发。尚不支持加权目标负载均衡。
- 现有的 VPC 账户限制、API 限制和 NLB 限制在此功能中仍然有效。
- 作为最佳实践，建议在 NLB 上启用删除保护 (delete protection)，以防止意外删除。
- 每个服务与一个 `ConfigMap` 对象一一对应，确保对每个服务的 `TargetGroupBinding` 进行精确管理。
- LBC 将所有目标以单次更新的方式写入 `ConfigMap` (上限 1MB)，而不是增量写入。请相应地监控 EKS 控制平面 (control plane) 的健康状况。
## 结论
在本系列的第一部分中，我们演示了如何使用 NLB 的新功能，通过声明式方法实现跨多个 Amazon EKS 集群的弹性。随着组织越来越多地将其应用程序迁移和现代化到 Kubernetes 环境，实施健壮且可扩展的解决方案对于维持高可用性至关重要。将工作负载分布到多个集群不仅能增强容错能力 (fault tolerance)，还能简化升级流程并加强灾难恢复能力。请访问我们的 [EKS 最佳实践中心](https://github.com/aws/aws-eks-best-practices) ，了解针对生产工作负载的架构模式、安全指南和成本优化策略。
请继续关注本系列的后续文章，我们将探讨更多的设计模式，以进一步提高在 Amazon EKS 上运行的工作负载的弹性。
## 关于作者
| | |
| :--- | :--- |
|  | **Krishna Sarabu** 是 AWS 的一名高级数据库工程师。他专注于容器、应用现代化、基础设施以及开源数据库引擎 Amazon RDS for PostgreSQL 和 Amazon Aurora PostgreSQL。他乐于与用户合作，帮助他们在 AWS 上设计、部署和优化关系型数据库工作负载。 |
|  | **Anuj Butail** 是 AWS 的一名首席解决方案架构师。他常驻旧金山，帮助旧金山和硅谷的用户在 AWS 上设计和构建大规模应用程序。他在 AWS、边缘服务和容器领域拥有专业知识。他喜欢打网球、阅读以及与家人共度时光。 |
|  | **Pushkar Patil** 是 AWS 网络团队的产品负责人，常驻加利福尼亚。他在推动云计算和基础设施领域的产品创新和战略规划方面拥有十多年的经验。Pushkar 通过理解用户需求并提供创新解决方案，成功推出了许多新产品。工作之余，这位板球爱好者喜欢与家人一起旅行。 |
<!-- AI_TASK_END: AI全文翻译 -->