将 3,000 个应用程序从另一个云平台迁移到 Kubernetes：成功的关键

计划大规模云迁移？考虑这些经验教训，以最大程度地降低风险并改善结果。

最近，我们帮助一家大型医疗保健公司将 3,000 个应用程序从其现有的云平台迁移到 Kubernetes。他们已经在使用 Kubernetes 和另一个云平台，因此说服他们迁移到 Kubernetes 并不是一件大事。他们的目标是通过仅在 Kubernetes 上运行来集中一切。从财务角度来看，这种迁移将为客户节省大约 1000 万美元的许可费用——这是一笔可观的节省。 

探索运营和应用团队的迁移挑战 

除了技术之外，云迁移的关键挑战在于与您一起工作的人员以及他们对离开现有云平台并迁移到 Kubernetes 的开放程度。 

当涉及到这种类型的迁移时，云运营团队往往是焦点。该团队了解当前平台的进出，但当您提供培训和支持时，他们会了解并拥有一个新平台。但还有一个更大的问题：云运营团队可能拥有平台，但他们不控制开发团队，开发团队也受到这种变化的影响。

在我们的案例中，我们有一个拥有该平台的团队，并且有兴趣迁移到 Kubernetes。但是我们有一个应用程序团队问：“我们为什么要更改代码并迁移到 Kubernetes？”

为了解决这种情况，我们建议云团队提供领导和赞助商。我们还建议他们分享时间表、缓解措施和迁移计划，并坚持执行。例如，他们可以通知应用程序开发团队，“如果您在 2022 年年中之前不将您的云应用程序迁移到 Kubernetes，您的应用程序将不再受支持。您必须迁移。” 他们还提供了支持和文档来帮助开发团队迁移到 Kubernetes。

云运营团队希望迁移到 Kubernetes 的一些原因是现有平台许可证的成本、对硬件更新的渴望以及现有平台的不成熟和不明确的产品计划。他们想转向行业标准的做事方式。

他们的执行发起人对省钱很感兴趣。如果他们愿意为 Kubernetes 平台和他们现有的平台（需要相当大的成本）付费，他们可能愿意合并——通过一个运营团队和一个平台来节省成本。

另一个需要考虑的因素是，大多数组织都在考虑云优先战略。他们想知道如何将工作负载部署到可以快速迁移到云的解决方案中。

我们建议执行团队成立一个迁移团队，执行迁移计划，并遵守时间表。迁移团队的工作是查看当前云平台的代码并处理应用程序团队的首要问题：将第一个版本迁移到 Kubernetes。他们将帮助应用程序开发团队在 Kubernetes 上部署他们的第一个应用程序版本，让他们拥有它，并为他们提供所需的文档和支持。应用程序团队喜欢这个计划，因为这意味着他们不需要广泛学习 Kubernetes 来移动应用程序和重新构建他们的解决方案。 

创建迁移计划

（阿什拉夫·苏莱曼，CC BY-SA 4.0）

成功的云迁移从评估阶段开始，以确定差距和依赖关系。在评估阶段之后，您可以开始创建试点。试点的目标是让一两个候选人完全迁移到 Kubernetes，并且已经设置了持续集成/持续开发 (CI/CD) 管道工具。

通过这次迁移，我们建议通过将最复杂的应用程序迁移到 Kubernetes 来开始试点。这与我们之前在 Konveyor 社区中推荐的相反，即您的快速获胜应该是最简单的。在这种情况下，你的快速获胜应该是最复杂的，因为成功将击败团队的任何争论。

迁移最复杂的应用程序并查看其外观后，请说明您做了什么以及迁移了什么。然后着眼于为未来设置迁移工具和最佳实践，以创建迁移工厂以扩展后续应用程序（在本例中为 3,000 个应用程序）。

选择应用程序迁移策略

我们考虑了三种迁移策略： 

• 按原样重新托管或提升和转移
• 重新平台、提升和调整
• 重构、重写和解耦应用程序 

当您有 3,000 个应用程序时，很难考虑重构。这将需要多年的重构、解耦和重写。因此，我们专注于两种迁移策略：重新托管和重新平台化。

评估阶段

评估阶段至关重要，因为它可以帮助您了解您拥有的依赖关系以及将应用程序迁移到 Kubernetes 需要做什么。我们选择自下而上的方法，您可以在其中查看云应用程序、它们的清单配置文件和 REST API，并尝试为依赖项和配置收集所有需要的应用程序。然后，编译所有依赖项并尝试映射它们。

自动分析和识别应用程序的依赖关系和复杂性至关重要，因为 3,000 对人类来说太多了，无法管理。对于一个 10 人的团队，手动检查这么多人并发现对所有人的依赖关系将花费太多时间。仅仅提出评估将是具有挑战性的。

我们研究了如何使整个过程自动化。因此，我们开发了 Cedrus 迁移工具。该工具通过所有配置清单文件从依赖关系的角度自动查看不同的模式并生成报告。该报告提供了开始分析应用程序的第一级信息，以及应用程序分组，以开始了解现有云平台和 Kubernetes 之间的服务差距。

图片

（阿什拉夫·苏莱曼，CC BY-SA 4.0）

这是一个示例报告。它从服务器的角度显示了应用程序名称、服务、它们如何进行自动缩放、复杂性、使用的库、堆栈、解包、插件和依赖项。

要使用该工具，您必须配置一些规则来确定它应该从模式的角度来看什么。

评估揭示的依赖关系

我们从平台的角度来看待这个问题。所有 3,000 个应用程序都在使用一些通用服务——一些托管在现有的云平台上，一些则在外部。好消息是外部不需要改变。坏消息是，当前的云平台服务必须替换为 Kubernetes 服务或等效服务。这需要重构代码以使用新服务。

当前云平台的市场正在使用一些应用程序和服务。它们作为实例启动，并通过云平台的清单和环境变量共享凭据。

他们还构建了一个非常复杂的自定义身份验证层来为其外部应用程序生成身份验证令牌。这是云平台之上的内置应用程序。这是一个复杂的应用程序，这是我们迁移时遇到的最大挑战，因为 3,000 个应用程序中的大多数都在以某种方式使用它；它被作为一个图书馆包含在其中的大多数中。 

这似乎是我们试​​点的一个很好的候选，因为它是最复杂的应用程序。首先迁移这让我们走上了在平台上进行任何其他具有挑战性的部署的道路。

处理依赖关系

接下来，我们收集了所有的发现并尝试将它们映射到 Kubernetes。我们决定将自定义身份验证移至 Kubernetes。我们再次使用外部服务，但将一些内置在云平台中的服务添加到外部服务中。我们使用 Kubernetes 中的操作员将它们创建为外部服务器，并更改了代码以使用该服务。

从那里，我们可以构建 CI/CD 管道，并让整个自动化发生在 Kubernetes 之上。那是我们从平台角度和识别服务所做的差距分析，从评估角度来看，这是迁移到 Kubernetes 的最关键部分。

CI/CD 管道

我们没有在现有的云平台中找到传统的、直接的 CI/CD 管道。他们与 Jira 和其他票证系统、质量保证工具和发布管理解决方案进行了如此多的集成。从企业的角度来看，目标是拥有能够控制部署的所有控制点。 

（阿什拉夫·苏莱曼，CC BY-SA 4.0）

为了实现这一目标，我们需要在 Kubernetes 中使用相同的控制点。我们转向了 Kubernetes 原生 CI/CD 解决方案，以新的方式思考各个阶段。 

图片

我们从 Kubernetes 的角度将 CI/CD 管道映射到他们以前拥有的东西，同时还从批准的角度创建了他们拥有的网关。