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