将您的容器工作负载从 Azure Red Hat OpenShift(ARO)迁移到 AWS 云端 Red Hat OpenShift 服务(ROSA)
Naveen Ramasamy、Srikanth Rangavajhala 和 Gireesh Sreekantan,Amazon Web Services
摘要
此模式分步说明了如何将容器工作负载从 Azure Red Hat OpenShift(ARO)迁移到 AWS 云端 Red Hat OpenShift 服务(ROSA)
要将容器工作负载从 ARO、其他云或本地迁移到 ROSA,我们需要将应用程序、配置和数据从一个平台转移到另一个平台。此模式可帮助确保平稳过渡,同时优化 AWS 架构服务、安全性和成本效益。其中涵盖将工作负载迁移到 ROSA 集群的两种方法:CI/CD 和容器迁移工具包(MTC)。
此模式涵盖了这两种方法。具体选择哪种方法,取决于迁移过程的复杂性和确定性。若您能完全掌控应用程序的状态,并能确保通过管道实现配置的一致性,建议采用 CI/CD 方法。但如果您的应用程序状态涉及不确定性、不可预见的变更或复杂的生态系统,我们建议您使用 MTC 作为可靠且受控的路径,将应用程序及其数据迁移至新集群。有关这两种方法的详细比较,请参阅其他信息部分。
迁移到 ROSA 的好处:
ROSA 作为原生服务与 AWS 无缝集成。可通过 AWS 管理控制台轻松访问,并通过单个 AWS 账户计费。它与其他 AWS 服务完全兼容,并带来 AWS 和 Red Hat 的协力支持。
ROSA 支持混合及多云部署 它使得应用程序能够在本地数据中心和多个云环境中一致运行。
ROSA 受益于 Red Hat 的安全理念,提供基于角色的访问控制(RBAC)、图像扫描和漏洞评估等功能,从而确保容器环境安全。
ROSA 旨在轻松扩展应用程序,并提供高可用性选项。它允许应用程序根据需要扩展,同时维持可靠性。
与手动设置和管理方法相比,ROSA 可以自动执行和简化 Kubernetes 集群的部署。这加快了开发和部署过程。
ROSA 受益于 AWS 架构服务,并且可与数据库服务、存储解决方案、安全服务等 AWS 产品无缝集成。
先决条件和限制
先决条件
一个活跃的 AWS 账户。
已为 ROSA 赖以实现功能的 AWS 服务 配置权限。有关更多信息,请参阅 ROSA 文档中的先决条件。
已安装并配置 ROSA 集群。有关更多信息,请参阅 ROSA 文档中的开始使用 ROSA。要了解设置 ROSA 集群的不同方法,请参阅 AWS 规范指引指南 ROSA 实施策略。
通过 AWS Direct Connect(首选)或 AWS Virtual Private Network(Site-to-Site VPN)建立从本地网络到 AWS 的网络连接。
Amazon Elastic Compute Cloud(Amazon EC2)实例或其他虚拟服务器,用于安装
aws client、OpenShift CLI(oc)客户端、ROSA 客户端和 Git 二进制文件等工具。
CI/CD 方法的其他先决条件:
访问本地 Jenkins 服务器,拥有创建新管道、添加阶段、添加 OpenShift 集群和执行构建的权限。
访问维护应用程序源代码的 Git 存储库,拥有创建新 Git 分支并向新分支执行提交的权限。
MTC 方法的其他先决条件:
Amazon Simple Storage Service(Amazon S3)存储桶,将用作复制存储库。
对源 ARO 集群的管理访问权限。这是设置 MTC 连接所必需的。
限制
部分 AWS 服务在有些 AWS 区域不可用。有关区域可用性,请参阅按区域划分的 AWS 服务
。有关特定端点,请参阅服务端点和配额页面,然后选择相应服务的链接。
架构
ROSA 提供三种网络部署模式:公共、私有和 AWS PrivateLink。PrivateLink 可助力 Red Hat 站点可靠性工程(SRE)团队使用连接到现有 VPC 中集群的 PrivateLink 端点的私有子网来管理集群。
选择 PrivateLink 选项可提供最安全的配置。因此,我们建议将其用于敏感工作负载或严格的合规要求场景。有关公共和私有网络部署选项的信息,请参阅 Red Hat OpenShift 文档
重要
只能在安装时创建 PrivateLink 集群。安装后即无法将集群更改为使用 PrivateLink。
下图所示为使用 Direct Connect 连接到本地和 ARO 环境的 ROSA 集群的 PrivateLink 架构。

授予 ROSA 的 AWS 权限
关于授予 ROSA 的 AWS 权限,我们建议您搭配使用 AWS Security Token Service(AWS STS)和短期动态令牌。该方法使用最低权限预定义角色和策略,授予 ROSA 在 AWS 账户中运行所需的最低权限,并支持 ROSA 安装、控制面板和计算功能。
CI/CD 管道重新部署
对于拥有成熟的 CI/CD 管道的用户,推荐使用 CI/CD 管道重新部署方法。选择此选项后,可以使用任何 DevOps 部署策略将应用程序负载逐步转移到 ROSA 上的部署。
注意
下图显示了此方法的工作流:

MTC 方法
可以使用容器迁移工具包(MTC)
下图显示了此方法的工作流:

工具
AWS 服务
AWS DataSync 是一项在线数据传输和发现服务,帮助您将文件或对象数据移动到 AWS 存储服务、从这些存储服务移出,以及在这些存储服务之间移动。
AWS Direct Connect 通过标准的以太网光纤电缆将您的内部网络链接到 Direct Connect 位置。通过此连接,您可以直接创建连接到公有 AWS 服务 的虚拟接口,同时绕过网络路径中的互联网服务提供商。
AWS PrivateLink 可帮助您创建从虚拟私有云(VPC)到该 VPC 之外的服务的单向私有连接。
AWS 云端 Red Hat OpenShift 服务(ROSA)是一项托管服务,可帮助 Red Hat OpenShift 用户在 AWS 上构建、扩展和管理容器化应用程序。
AWS Security Token Service(AWS STS)可帮助您为用户申请权限受限的临时凭证。
其他工具
容器迁移工具包(MTC)
提供用于将容器化应用程序从 ARO 迁移到 ROSA 的控制台和 API。
最佳实践
为了韧性,且若您有安全合规工作负载,请设置一个使用 PrivateLink 的多可用区 ROSA 集群。有关更多信息,请参阅 ROSA 文档。
注意
安装后不能配置 PrivateLink。
用于复制存储库的 S3 存储桶不应设置为公开状态。使用相应的 S3 存储桶策略来限制访问权限。
如果选择 MTC 方法,请使用阶段迁移选项来缩短割接期间的停机时间。
在预调配 ROSA 集群之前和之后,请检查您的服务配额。如有必要,可以根据要求申请增加配额。有关更多信息,请参阅服务配额文档。
查看 ROSA 安全指南并实施安全最佳实践。
我们建议您在安装后移除默认集群管理员。有关更多信息,请参阅 Red Hat OpenShift 文档
。 使用机器池自动缩放功能,缩减 ROSA 集群中未使用的 Worker 节点,从而优化成本。有关更多信息,请参阅 ROSA 讲习会
。 使用适用于 OpenShift 容器平台的 Red Hat 成本管理服务,更深入地了解并追踪云和容器的成本。有关更多信息,请参阅 ROSA 讲习会
。 使用 AWS 服务监控和审计 ROSA 集群基础设施服务及应用程序。有关更多信息,请参阅 ROSA 讲习会
。
操作说明
| 任务 | 描述 | 所需技能 |
|---|---|---|
将新的 ROSA 集群添加到 Jenkins。 |
| AWS 管理员、AWS 系统管理员、AWS DevOps |
将 |
| AWS 管理员、AWS 系统管理员、AWS DevOps |
创建新的 Git 分支。 | 在您的 Git 存储库中为 | AWS DevOps |
为 ROSA 标记图像。 | 在构建阶段,使用不同的标签来标识通过 ROSA 管道构建的图像。 | AWS 管理员、AWS 系统管理员、AWS DevOps |
创建管道。 | 创建一个与现有管道相似的新 Jenkins 管道。对于此管道,请使用您之前创建的 | AWS 管理员、AWS 系统管理员、AWS DevOps |
添加 ROSA 部署阶段。 | 在新管道中,添加一个部署到 ROSA 集群的阶段,并引用您添加到 Jenkins 全局配置中的 ROSA 集群。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
开始新的构建操作。 | 在 Jenkins 中,选择管道并选择立即构建,或者通过在 Git 中提交对 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
验证部署。 | 使用 oc 命令或 ROSA 控制台 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
将数据复制到目标集群。 | 对于有状态的工作负载,请使用 AWS DataSync 或者诸如 rsync 之类的开源实用程序,将数据从源集群复制到目标集群,也可以使用 MTC 方法。有关更多信息,请参阅 AWS DataSync 文档。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
测试您的应用程序。 |
| AWS 管理员、AWS DevOps、AWS 系统管理员 |
割接。 | 如果测试成功,请使用相应的 Amazon Route 53 策略将流量从 ARO 托管的应用程序转移到 ROSA 托管的应用程序。完成此步骤后,您的应用程序的工作负载将完全迁移到 ROSA 集群。 | AWS 管理员、AWS 系统管理员 |
| 任务 | 描述 | 所需技能 |
|---|---|---|
安装 MTC 操作程序。 | 在 ARO 和 ROSA 集群上安装 MTC 操作程序:
| AWS 管理员、AWS DevOps、AWS 系统管理员 |
配置到复制存储库的网络流量。 | 如果您使用的是代理服务器,请将其配置为允许复制存储库与集群之间的网络流量。复制存储库是 MTC 用来迁移数据的中间存储对象。迁移期间,源集群和目标集群必须具有对复制存储库的网络访问权限。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
将源集群添加到 MTC。 | 在 MTC Web 控制台上,添加 ARO 源集群。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
将 Amazon S3 添加为复制存储库。 | 在 MTC Web 控制台上,将 Amazon S3 存储桶(参见先决条件)添加为复制存储库。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
制定迁移计划。 | 在 MTC Web 控制台上,创建迁移计划并将数据传输类型指定为复制。这将指示 MTC 将数据从源(ARO)集群复制到 S3 存储桶,然后从存储桶复制到目标(ROSA)集群。 | AWS 管理员、AWS DevOps、AWS 系统管理员 |
运行迁移计划。 | 使用分阶段或割接选项运行迁移计划:
| AWS 管理员、AWS DevOps、AWS 系统管理员 |
故障排除
| 问题 | 解决方案 |
|---|---|
连接问题 | 当您将容器工作负载从 ARO 迁移到 ROSA 时,可能会遇到连接问题,应解决这些问题以确保迁移成功。为解决迁移过程中出现的连接问题(详见本表),必须进行周密规划、与网络和安全团队协调配合,并开展全面测试。实施分阶段迁移策略并在每个阶段验证连接性,将有助于最大限度地减少潜在的中断,并确保平稳从 ARO 迁移到 ROSA。 |
网络配置差异 | ARO 和 ROSA 的网络配置可能有所不同,例如虚拟网络(VNet)设置、子网和网络策略。为确保服务间通信顺畅,请确认两个平台的网络设置保持一致。 |
安全组和防火墙规则 | ROSA 和 ARO 的默认安全组和防火墙设置可能有所不同。请务必调整和更新这些规则,以允许必要的流量,在迁移过程中保持容器和服务的连通性。 |
IP 地址和 DNS 变更 | 迁移工作负载时,IP 地址和 DNS 名称可能发生变化。重新配置依赖静态 IP 或特定 DNS 名称的应用程序。 |
外部服务访问权限 | 如果您的应用程序依赖于数据库或 API 等外部服务,可能需要更新它们的连接设置,以确保它们可以与 ROSA 的新服务通信。 |
Azure Private Link 配置 | 如果在 ARO 中使用 Azure Private Link 或私有端点服务,则需在 ROSA 中配置等效功能,以确保资源间的私有连接。 |
Site-to-Site VPN 或 Direct Connect 设置 | 如果您的本地网络与 ARO 之间存在Site-to-Site VPN 或 Direct Connect 连接,则需要与 ROSA 建立类似连接,以确保与本地资源的通信不中断。 |
入口和负载均衡器设置 | ARO 与 ROSA 中的入口控制器和负载均衡器配置可能有所不同。重新配置这些设置可保持对服务的外部访问权限。 |
证书和 TLS 处理 | 如果您的应用程序使用 SSL 证书或 TLS,请确保这些证书在 ROSA 中有效且配置正确。 |
容器注册表访问权限 | 如果您的容器托管在外部容器注册表中,请为 ROSA 设置正确的身份验证和访问权限。 |
监控和日志记录 | 更新监控和日志记录配置,以反映 ROSA 上的新基础设施,以便您可以继续有效地监控容器的运行状况和性能。 |
相关资源
AWS 参考
什么是 AWS 云端 Red Hat OpenShift 服务? (ROSA 文档)
开始使用 ROSA(ROSA 文档)
AWS 云端 Red Hat OpenShift 服务 实施策略(AWS 规范指引)
AWS 云端 Red Hat OpenShift 服务 Now GA
(AWS 博客文章)
Red Hat OpenShif 文档
其他信息
在 MTC 与 CI/CD 管道重新部署选项之间进行选择
要将应用程序从一个 OpenShift 集群迁移到另一个集群,必须做审慎考量。理想情况下,您可以使用 CI/CD 管道来重新部署应用程序并处理持久卷数据的迁移,从而实现平稳过渡。然而,实际上,集群上运行的应用程序容易受到随时间推移而出现的不可预见的变更影响。这些变更可能导致应用程序逐步偏离其原始部署状态。MTC 针对以下场景提供了解决方案:当命名空间的确切内容不确定时,需要将所有应用程序组件无缝迁移到新集群。
做出正确选择需要评估具体情况,并权衡每种方法的利弊。通过这样做,您可以确保迁移过程顺利无缝,并符合您的需求和优先级。以下是关于如何在两个选项之间进行取舍的补充指导原则。
CI/CD 管道重新部署
如果您的应用程序能够通过管道进行可靠的重新部署,则推荐采用持续集成/持续交付(CI/CD)管道方法。这样可以确保迁移过程可控且可预测,并与您现有的部署实践保持一致。选择此方法时,您可以使用蓝绿部署或金丝雀部署策略,将负载逐步转移到 ROSA 上的部署。在这种情况下,此模式假设 Jenkins 正在从本地环境协调应用程序部署。
优势:
您无需对源 ARO 集群拥有管理员访问权限,也不需要将任何操作程序部署到源集群或目标集群上。
这种方法通过 DevOps 策略帮助您逐步切换流量。
劣势:
测试应用程序的功能需要投入更多精力。
如果您的应用程序包含持久化数据,则需要采取额外的步骤来使用 AWS DataSync 或其他工具复制数据。
MTC 迁移
在现实世界中,运行中的应用程序可能会经历意外变化,导致其偏离初始部署状态。如果您不确定应用程序在源集群上的当前状态,请选择 MTC 选项。例如,如果您的应用程序生态系统涉及多种组件、配置和数据存储卷,我们建议您选择 MTC 来确保完成涵盖应用程序及其整个环境的完整迁移。
优势:
MTC 提供完整的工作负载备份和恢复功能。
迁移工作负载时,它会把持久化数据从源端复制到目标端。
不需要访问源代码存储库。
劣势:
您需要管理权限才能在源集群和目标集群上安装 MTC 操作程序。
DevOps 团队必须接受培训,才能使用 MTC 工具并执行迁移。