本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
将你的容器工作负载从 Azure 红帽 OpenShift (ARO) 迁移到 AWS 云端 Red Hat OpenShift 服务 (ROSA)
由 Naveen Ramasamy (AWS)、Gireesh Sreekantan () 和 Srikanth Rangavajhala () 创作 AWS AWS
摘要
此模式提供了将容器工作负载从 Azure Red Hat OpenShift (ARO) 迁移到 AWS 云端 Red Hat OpenShift 服务 (ROSA)
将容器工作负载从ARO其他云迁移到其他云中，或者从内部迁移到其他云中，ROSA涉及将应用程序、配置和数据从一个平台转移到另一个平台。这种模式有助于确保平稳过渡，同时优化 AWS Cloud 服务、安全性和成本效益。它涵盖了将工作负载迁移到ROSA集群的两种方法：CI/CD 和容器迁移工具包 () MTC。
此模式涵盖了这两种方法。您选择的方法取决于迁移过程的复杂性和确定性。如果您完全控制应用程序的状态，并且可以通过管道保证设置的一致性，我们建议您使用 CI/CD 方法。但是，如果您的应用程序状态涉及不确定性、不可预见的变化或复杂的生态系统，我们建议您将应用程序及其数据迁移到新集群时将其MTC用作可靠且受控的路径。有关这两种方法的详细比较，请参阅 “其他信息” 部分。
迁移到ROSA以下位置的好处：
ROSA AWS 作为本机服务无缝集成。可通过轻松访问 AWS Management Console 并通过单 AWS 账户笔计费。它与其他产品完全兼容 AWS 服务 ，并提供双方 AWS 和红帽的协作支持。
ROSA支持混合云和多云部署。它使应用程序能够在本地数据中心和多个云环境中一致运行。
ROSA得益于红帽对安全的关注，并提供基于角色的访问控制 (RBAC)、图像扫描和漏洞评估等功能，以确保容器环境的安全。
ROSA旨在轻松扩展应用程序并提供高可用性选项。它允许应用程序根据需要进行扩展，同时保持可靠性。
ROSA与手动设置和管理方法相比，自动化和简化了 Kubernetes 集群的部署。这加快了开发和部署过程。
ROSA受益于 AWS Cloud 服务，并提供与数据库服务、存储解决方案和安全服务等 AWS 产品的无缝集成。
先决条件和限制
先决条件
活跃 AWS 账户的.
AWS 服务 为此配置的权限ROSA依赖于提供功能。有关更多信息，请参阅ROSA文档中的先决条件。
已安装并配置ROSA集群。有关更多信息，请参阅ROSA文档ROSA中的入门。要了解设置ROSA集群的不同方法，请参阅 AWS 规范性指南ROSA实施策略。
建立从本地网络到 AWS 通过 AWS Direct Connect（首选）或 AWS Virtual Private Network （AWS VPN）的网络连接。
亚马逊弹性计算云 (AmazonEC2) 实例或其他虚拟服务器，用于安装诸如
aws client、 OpenShift CLI (oc) 客户端、ROSA客户端和 Git 二进制文件之类的工具。
CI/CD 方法的其他先决条件：
访问本地 Jenkins 服务器，拥有创建新管道、添加阶段、添加 OpenShift 集群和执行构建的权限。
访问维护应用程序源代码的 Git 存储库，有权创建新的 Git 分支并向新分支执行提交。
该MTC方法的其他先决条件：
亚马逊简单存储服务 (Amazon S3) Service 存储桶，将用作复制存储库。
对源ARO集群的管理访问权限。这是设置MTC连接所必需的。
限制
有些 AWS 服务 并非全部可用 AWS 区域。有关区域可用性，请参阅AWS 服务 按地区划分
。有关特定终端节点，请参阅服务终端节点和配额页面，然后选择服务的链接。
架构
ROSA提供三种网络部署模式：公共、私有和AWS PrivateLink。 PrivateLink使红帽站点可靠性工程 (SRE) 团队能够使用连接到现有集群 PrivateLink 终端节点的私有子网来管理集群VPC。
选择该 PrivateLink选项可提供最安全的配置。因此，我们建议将其用于敏感工作负载或严格的合规性要求。有关公网和私有网络部署选项的信息，请参阅红帽 OpenShift 文档
重要
您只能在安装时创建 PrivateLink 集群。安装 PrivateLink 后，您无法更改要使用的群集。
下图说明了用于 AWS Direct Connect 连接到本地和ARO环境的ROSA集群的 PrivateLink 架构。
AWS 权限 ROSA
要获得 AWS 权限ROSA，我们建议您将 AWS Security Token Service (AWS STS) 与短期动态令牌一起使用。此方法使用权限最低的预定义角色和策略来授予在中操作ROSA的最低权限 AWS 账户，并支持ROSA安装、控制平面和计算功能。
CI/CD 管道重新部署
CI/CD pipeline redeployment is the recommended method for users who have a mature CI/CD管道。选择此选项后，您可以使用任何DevOps 部署策略将应用程序负载逐渐转移到部署上ROSA。
注意
下图显示了此方法的工作流程。
MTC方法
您可以使用容器迁移工具包 (MTC)
下图显示了此方法的工作流程。
工具
AWS 服务
AWS DataSync是一项在线数据传输和发现服务，可帮助您在 AWS 存储服务之间移动文件或对象数据。
AWS Direct Connect通过标准的以太网光纤电缆将您的内部网络链接到某个 AWS Direct Connect 位置。通过此连接，您可以直接创建面向公众的虚拟接口， AWS 服务 同时绕过网络路径中的互联网服务提供商。
AWS PrivateLink帮助您创建从虚拟私有云 (VPCs) 到外部服务的单向私有连接。VPC
AWS 云端 Red Hat OpenShift 服务 (ROSA) 是一项托管服务，可帮助红帽 OpenShift 用户在上构建、扩展和管理容器化应用程序。 AWS
AWS Security Token Service (AWS STS) 可帮助您为用户申请临时的有限权限证书。
其他工具
容器迁移工具包 (MTC)
提供了一个控制台，API用于将容器化应用程序从ARO迁移到。ROSA
最佳实践
为了提高弹性，如果您有安全合规性工作负载，请设置一个使用的 PrivateLink多可用区ROSA集群。有关更多信息，请参阅 ROSA 文档。
注意
PrivateLink 安装后无法进行配置。
您用于复制存储库的 S3 存储桶不应公开。使用相应的 S3 存储桶策略来限制访问权限。
如果您选择该MTC方法，请使用阶段迁移选项来缩短直接转换期间的停机时间。
在配置ROSA集群之前和之后，请检查您的服务配额。如有必要，请根据您的要求申请增加配额。有关更多信息，请参阅服务配额文档。
查看ROSA安全准则并实施安全最佳实践。
我们建议您在安装后移除默认的集群管理员。有关更多信息，请参阅红帽 OpenShift 文档
。 使用机器池自动扩展缩减ROSA集群中未使用的工作节点以优化成本。欲了解更多信息，请参阅ROSA研讨会
。 使用红帽 OpenShift 容器平台成本管理服务，更好地了解和跟踪云和容器的成本。欲了解更多信息，请参阅ROSA研讨会
。 使用监控和审计ROSA集群基础设施服务和应用程序 AWS 服务。欲了解更多信息，请参阅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操作员。 | 在两个ROSA集群ARO和集群上安装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 控制台上，创建迁移计划并将数据传输类型指定为 “复制”。这将指示将数据从源 (ARO) 集群复制MTC到 S3 存储桶，以及从存储桶复制到目标 (ROSA) 集群。 | AWS管理员、AWS DevOps、AWS系统管理员 |
运行迁移计划。 | 使用 Stag e 或 Cutover 选项运行迁移计划：
| AWS管理员、AWS DevOps、AWS系统管理员 |
故障排除
| 事务 | 解决方案 |
|---|---|
连接问题 | 当您将容器工作负载从迁移ARO到时ROSA，可能会遇到连接问题，应解决这些问题以确保成功迁移。要解决迁移期间的这些连接问题（在本表中列出），必须进行细致的规划、与网络和安全团队的协调以及全面的测试。实施渐进式迁移策略并在每个步骤中验证连接，将有助于最大限度地减少潜在的中断，并确保从ARO到ROSA的平稳过渡。 |
网络配置差异 | ARO并且其网络配置ROSA可能有所不同，例如虚拟网络 (VNet) 设置、子网和网络策略。为了在服务之间进行适当的通信，请确保两个平台之间的网络设置保持一致。 |
安全组和防火墙规则 | ROSA并且ARO可能有不同的默认安全组和防火墙设置。请务必调整和更新这些规则，以允许必要的流量在迁移期间保持容器和服务之间的连接。 |
IP 地址和DNS更改 | 迁移工作负载时，IP 地址和DNS名称可能会发生变化。重新配置依赖静态IPs或特定DNS名称的应用程序。 |
外部服务访问 | 如果您的应用程序依赖外部服务（例如数据库或）APIs，则可能需要更新它们的连接设置以确保它们可以与来自的新服务进行通信ROSA。 |
Azure 私有链接配置 | 如果您在中使用 Azure 私有链接或私有终端节点服务ARO，则需要在中设置等效功能ROSA，以确保资源之间的私有连接。 |
AWS VPN 或 AWS Direct Connect 设置 | 如果您的本地网络和之间存在现有 AWS Direct Connect 连接 AWS VPN 或连接ARO，则需要与建立类似的连接，以便与本地资源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 服务 现在 GA
（AWS 博客文章）
红帽 OpenShift 文档
其他信息
在 CI/CD 管道重新部署选项之间MTC进行选择
将应用程序从一个 OpenShift 集群迁移到另一个集群需要仔细考虑。理想情况下，您希望使用 CI/CD 管道来重新部署应用程序并处理永久卷数据的迁移，从而实现平稳过渡。但是，实际上，集群上正在运行的应用程序会随着时间的推移而受到不可预见的变化的影响。这些更改可能导致应用程序逐渐偏离其原始部署状态。 MTC为命名空间的确切内容不确定且将所有应用程序组件无缝迁移到新集群很重要的场景提供了解决方案。
做出正确的选择需要评估您的具体场景并权衡每种方法的好处。通过这样做，您可以确保成功实现符合您的需求和优先事项的无缝迁移。以下是在这两个选项之间进行选择的其他指南。
CI/CD 管道重新部署
如果使用管道可以放心地重新部署应用程序，则推荐使用 CI/CD 管道方法。这样可以确保迁移是可控的、可预测的，并且与您现有的部署实践保持一致。选择此方法时，您可以使用蓝/绿部署或金丝雀部署策略将负载逐渐转移到部署上。ROSA在这种情况下，此模式假设 Jenkins 正在从本地环境协调应用程序部署。
优势：
您不需要对源集群的管理访问权限，也不需要在源ARO集群或目标集群上部署任何操作员。
这种方法可以帮助您使用 DevOps 策略逐步切换流量。
劣势：
测试应用程序的功能需要付出更多的努力。
如果您的应用程序包含永久性数据，则需要额外的步骤才能使用 AWS DataSync 或其他工具来复制数据。
MTC迁移
在现实世界中，正在运行的应用程序可能会发生意想不到的变化，从而导致它们偏离初始部署。如果您不确定源集群上应用程序的当前状态，请选择该MTC选项。例如，如果您的应用程序生态系统跨越各种组件、配置和数据存储卷，我们建议您选择确保MTC实现涵盖应用程序及其整个环境的完整迁移。
优势：
MTC提供工作负载的完整备份和恢复。
迁移工作负载时，它会将永久性数据从源复制到目标。
它不需要访问源代码存储库。
劣势：
您需要管理权限才能在源集群和目标集群上安装MTC操作员。
该 DevOps 团队需要接受培训才能使用该MTC工具和执行迁移。
