轻松实现应用程序现代化：使用现有 NLB 设置迁移到 Amazon EKS

作者： pmm |

本文由亚马逊云科技容器专家 Henrique Santana 和亚马逊云科技首席解决方案架构师 Luis Felipe 共同撰写。

导言

许多组织都使用 Amazon EC2 和网络负载均衡器（NLB）来构建基础设施，通常采用围绕 NLB 的静态 IP 地址构建安全策略。随着这些组织采用容器化并将其现代应用迁移到 Amazon EKS，他们在保留现有终端节点配置方面面临着重大挑战。这可能会使现代化变得复杂而有风险，因为更改负载均衡器设置可能会中断客户端连接或需要进行重大的 DNS 更改。

好消息是，这种过渡不一定是全有或全无的努力。在这篇文章中，我们探讨了一种混合部署模式，该模式可提供从 Amazon EC2 到 Amazon EKS 的平滑、低风险迁移路径。使用亚马逊云科技负载均衡器控制器中的 TargetGroupBinding 允许组织逐步将流量从 EC2 实例转移到 Amazon EKS 容器，同时保持其现有 NLB 静态 IP 地址。这种方法不仅保留了静态的知识产权要求，而且还为现代化提供了一条务实的途径。此外，这有助于组织验证其容器化工作负载，而无需中断现有客户连接或无需更改 DNS。

在这篇文章中，我们将深入探讨如何在保持业务连续性的同时实现这种模式并对基础架构进行现代化改造。

混合部署

与蓝/绿部署模式类似，我们的混合部署方法支持在迁移过程中在 Amazon EKS 和 Amazon EC2 上同时运行应用程序。该策略的关键是能够使用 TargetGroupBinding 将流量通过现有负载均衡器路由到两个部署，从而实现受控的迁移过程。

TargetGroupBinding 使用 Kubernetes 自定义资源 (CR) 来自动管理容器化工作负载和目标组之间的关系。为容器化工作负载创建新的目标组允许您在使用现有 NLB 基础设施的同时，保持对流量分配的独立控制。

下图显示了这种混合架构。绿色路径表示流向 EC2 实例或 Amazon ECS 的当前流量，而蓝色路径表示如何通过相同的 NLB 将流量定向到新的 Amazon EKS 工作负载：

图 1：显示从 Amazon EC2（绿色）迁移到 Amazon EKS（蓝色）的流量流图

图 1：显示从 Amazon EC2（绿色）迁移到 Amazon EKS（蓝色）的流量流图

本文重点介绍 Amazon EC2 到 Amazon EKS 的迁移。但是，这种模式用途广泛。从其他部署架构（包括非容器化、本地或 Amazon ECS）迁移时，也可以采用相同的方法。此外，这种模式在将现有 Kubernetes 集群升级到新版本时被证明是有价值的，具有相同的受控迁移优势。

使用混合部署方法的优势

混合部署方法具有以下优点：

  • 受控迁移：逐步将流量路由到 Amazon EKS 工作负载，同时通过您的现有 Amazon EC2 基础设施维持服务，从而显著降低迁移风险。
  • 简单回滚：出现问题时快速将流量重定向回 EC2 实例，从而在迁移期间提供可靠的回滚。
  • A/B 测试：比较现实条件下 Amazon EC2 和 Amazon EKS 部署的性能，就最有效的配置和资源分配提供数据驱动的决策。
  • 灵活性：在过渡期间利用两种部署环境的优势，帮助根据特定要求优化工作负载配置。
  • 最大限度地减少服务中断：通过在迁移期间同时运行两个环境来降低停机风险。
  • 风险缓解：使用真实流量验证容器化部署，同时保持备用选项，提供业务连续性。

迁移的先决条件

写这篇文章的前提是你对 Docker 容器化和 Kubernetes 的概念（容器、事件、命名空间和部署等）有基本的了解。

在开始迁移过程之前，请确保准备好以下组件：

  • 现有基础架构：在本示例中，在 Amazon EC2 上运行的零售商店示例应用程序。
  • 容器要求：经过测试的容器化应用程序，将容器映像推送到容器注册表，例如 Amazon ECR。
  • Amazon EKS 环境：Amazon EKS 集群，支持跨多个可用区 (AZ) 的 Kubernetes 版本。
  • 工具：
    • 安装并配置了 kubectl 以与 Amazon EKS 集群进行交互。
    • 亚马逊云科技命令行接口 (亚马逊云科技 CLI) 安装并配置了相应的 Amazon Identity and Access Management (IAM)
  • 亚马逊云科技负载均衡器控制器安装在 Amazon EKS 集群上。

使用 NLB 的混合部署迁移应用程序

我们有一个应用程序在由 Amazon EC2 Auto Scaling 组管理的 EC2 实例上运行。我们的目标环境是 Amazon EKS 集群，我们已经在其中安装和配置了亚马逊云科技负载均衡器控制器。为了迁移，我们采取了与传统模式略有不同的方法。我们没有使用新的负载均衡器进行迁移或对基础设施进行重大更改，而是实施控制迁移，以保持现有 NLB，同时逐步将流量转移到 Amazon EKS 集群。这种方法可以保留当前的客户机连接，最大限度地减少服务中断，并在整个过渡期间保持高可用性。

为了实现这一目标，我们选择了更加可控的方法，而不是使用标准的 Kubernetes 负载均衡器服务类型，使用手动创建的目标组和 TargetGroupBinding（由亚马逊云科技负载均衡器控制器提供的 CR）。这可以独立管理目标组，并可以更精细地控制流量路由到应用程序的方式，这在与现有基础架构集成时非常有价值。这为复杂的迁移场景提供了所需的灵活性，在这些场景中，维护特定的负载均衡器配置至关重要，提供了对目标组配置的精确控制，并维护了现有的负载均衡器资源以实现无缝迁移。

使用 NLB 时的一个关键细节是目标组更改期间的连接处理。修改目标组时，新连接将路由到新目标，而现有连接则保留其原始目标。为了说明这一点，可以将其视为类似于餐厅换班。新客户（连接）被定向到新团队，但现有客户（已建立的连接）会继续使用其原始服务器，直到他们自然完成会话。即使在目标组上启用Connection termination on deregistration了，此行为仍然存在。这是因为在使用 ModifyListener 操作时，不会调用 deRegisterTargets 操作。了解这种行为对于规划应用程序的平稳过渡至关重要，对于长期存在的 TCP 连接或 UDP 工作负载尤其重要。

分步迁移

第一步是创建一个新的目标组：

TARGET_GROUP_ARN=$(aws elbv2 create-target-group \
    --name eks-green \
    --protocol TCP \
    --port 80 \
    --target-type ip \
    --vpc-id <VPCID> \
    --query 'TargetGroups[0].TargetGroupArn' \
    --output text)

目标组亚马逊资源名称 (ARN) 保存到 TARGET_GROUP_ARN 变量中。然后，验证两个目标组（Amazon EC2 和 Amazon EKS）的配置是否Terminate connections on deregistration为真。

aws elbv2 describe-target-group-attributes \
    --target-group-arn $TARGET_GROUP_ARN \
    --query 'Attributes[*]' --output text | \
    grep deregistration_delay.connection_termination.enabled

观察以下输出：

deregistration_delay.connection_termination.enabled true

如果命令的输出返回该属性，false,则表示该属性未启用。要启用，请使用以下命令：

aws elbv2 modify-target-group-attributes \
    --target-group-arn $TARGET_GROUP_ARN \
    --attributes 'Key=deregistration_delay.connection_termination.enabled,Value=true' \
    --query 'Attributes[*]' --output text | \
    grep deregistration_delay.connection_termination.enabled

在此阶段，流量仍被定向到在 Amazon EC2 上运行的应用程序。现在，您可以在 Amazon EKS 集群上部署容器化应用程序：

kubectl create deployment myapp \
    --image public.ecr.aws/aws-containers/retail-store-sample-ui:0.8.1 \
    --replicas 2 --port=8080

我们可以通过创建服务来公开应用程序。以下是该服务的 YAML 文件：

cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: myapp
  name: ui-service
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: myapp
  type: ClusterIP
EOF

我们可以将其应用：

kubectl apply -f service.yaml

在应用程序运行并作为 Kubernetes 服务公开后，为现有 NLB 创建一个新的监听器：

aws elbv2 create-listener \
    --load-balancer-arn <NLB-ARN> \
    --protocol TCP --port 81 \
    --default-actions Type=forward,TargetGroupArn=$TARGET_GROUP_ARN

您当前在端口 80 上有一个监听器。该侦听器继续将流量转发到与 EC2 实例关联的目标组。新创建的监听器将流量转发到与 Amazon EKS 关联的目标群组。在你使用 targetGroupBinding 将服务绑定到新的目标组之前，它没有任何目标。我们可以创建它：

cat << EOF > tg-binding.yaml
apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: ui-tgbinding
spec:
  serviceRef:
    name: ui-service # Service name
    port: 80 # Service port
  targetGroupARN: $TARGET_GROUP_ARN
EOF

应用清单：

kubectl apply -f tg-binding.yaml

您可以验证目标是否已正确注册到 Amazon EKS 目标组。让目标有足够的时间通过运行状况检查，然后验证新目标能否成功提供流量。如果运行状况检查失败，请验证 Amazon EKS 节点安全组是否允许必要的流量。要确认功能正常，请尝试通过新的监听器访问应用程序，确保其正常运行，然后再继续操作。

在开始迁移之前，您需要创建另一个指向现有 Amazon EC2 目标组的监听器：

aws elbv2 create-listener \
    --load-balancer-arn <NLB-ARN> \
    --protocol TCP --port 82 \
    --default-actions Type=forward,TargetGroupArn=<EC2-TARGET-GROUP-ARN>

完成此步骤后，NLB 有三个监听器（端口 80、81 和 82），您在其中创建了另外两个监听器，以实现顺畅的流量迁移操作。本文中使用的端口号仅为示例，您可以选择端口号以反映您的应用程序需求。我们建议测试现有目标群组的流量是否由新监听器提供。这可确保 NLB 配置已准备就绪，可以继续执行后续步骤。

将流量从 Amazon EC2 迁移到 Amazon EKS 目标组

两个目标组都运行良好，所有监听器都已准备好处理流量，因此是时候迁移流量了。首先，在端口 80 上配置现有侦听器以向eks-green目标组发送流量。

aws elbv2 modify-listener \
    --listener-arn <NLB-Listen-80> \
    --default-actions Type=forward,TargetGroupArn=$TARGET_GROUP_ARN

此配置更改可确保所有新流量都定向到新的目标组。由于目标在端口 81 上与监听器关联时已经通过了运行状况检查，因此这有助于加快此过程。

这种监听器更改可能需要几分钟才能传播。因此，我们建议您在继续执行后续步骤之前监控流向新目标组中目标的流量。在此期间，监控应用程序的行为和性能指标非常重要。您可以使用以下方法监控目标运行状况：

aws elbv2 describe-target-health \
    --target-group-arn $TARGET_GROUP_ARN

尽管现有连接不会受到影响，但在流量迁移完成后，新连接将停止路由到旧目标组。确认新目标成功处理流量，并且先前存在的目标不再提供流量后，从先前存在的 Amazon EC2 目标组中检索目标列表，为取消注册做准备：

aws elbv2 describe-target-health \
    --target-group-arn <EC2-TARGET-GROUP-ARN> \
    --query 'TargetHealthDescriptions[*].Target.Id' \
    --output text

此命令输出实例 ID 列表。对于每个实例 ID，运行以下deregister-targets命令：

aws elbv2 deregister-targets \
    --target-group-arn <EC2-TARGET-GROUP-ARN> \
    --targets Id=<InstanceID>

注销步骤很重要，因为 Amazon EC2 目标组通过端口 82 监听器与 NLB 保持关联。执行后，将强制执行 deregister-targets 调用Connection termination on deregistration，这将终止与旧目标的现有连接。当客户重新连接时，他们将被路由到新的 Amazon EKS 目标群组目标。

将过程回滚到原始目标组（如果需要）

如果您需要回滚到最初的 Amazon EC2 目标组，请按照以下步骤操作：

  1. 将所有原始目标再次注册到 Amazon EC2 目标组：
aws elbv2 register-targets \
    --target-group-arn <EC2-TARGET-GROUP-ARN> \
    --targets Id=<InstanceID1> Id=<InstanceID2>
  1. 等待目标通过运行状况检查。监控他们的健康状况：
aws elbv2 describe-target-health \
    --target-group-arn <EC2-TARGET-GROUP-ARN>
  1. 在 NLB 的端口 80 上重新配置侦听器，将流量发送到 Amazon EC2 目标组：

aws elbv2 modify-listener \
    --listener-arn <NLB-Listen-80> \
    --default-actions Type=forward,TargetGroupArn=<EC2-TARGET-GROUP-ARN>

迁移后清理

如果迁移成功（无需回滚），则可以继续进行清理操作。这包括删除您在端口 81 和 82 上创建的另外两个监听器，因为它们仅在迁移过程中需要。最后，您可以安全地删除 Amazon EC2 目标组，因为它不再接收任何流量。

aws elbv2 delete-listener \ 
     --listener-arn <Listen-Port81-ARN>

aws elbv2 delete-listener \ 
     --listener-arn <Listen-Port82-ARN>

aws elbv2 delete-target-group \ 
    --target-group-arn <EC2-TG-ARN>

结论

使用 NLB 和 TargetGroupBinding 的混合部署模式为将应用程序从各种来源（包括 Amazon EC2、本地基础设施或其他容器编排解决方案）迁移到 Amazon EKS 提供了一种实用、低风险的方法。保持现有的 NLB 配置，同时逐步将流量转移到容器化工作负载，可以让这种方法支持无缝过渡并提供内置的回滚功能。尽管我们专注于从 Amazon EC2 到 Amazon EKS 的迁移，但这种模式的多功能性可以扩展到各种场景，包括从本地基础设施或其他容器编排解决方案的过渡。

最近对亚马逊云科技负载均衡器控制器的增强，尤其是引入了多集群目标组，进一步扩展了这些功能。组织现在可以管理多个 Kubernetes 集群的工作负载并与非集群资源集成，从而促进更复杂的迁移策略和分布式应用程序架构。这种混合方法是现代化的可靠蓝图，提供了维持业务连续性和最大限度地降低风险所需的工具，同时提供了适应不断变化的基础设施要求的灵活性。

为了进一步推动您的迁移之旅，我们建议您阅读配套文章：从自我管理的 Kubernetes 迁移到 Amazon EKS：以下是一些关键注意事项。这篇文章提供了进一步的见解和优秀实践，以补充此处讨论的混合部署策略，特别是当你要从自我管理的 Kubernetes 环境迁移到 Amazon EKS 时。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。