迁移至 Kubernetes 的三种主要方式对比

企业大规模迁移到云端的时间已经到了，对于正在使用的应用程序，应该如何打包呢？

如今，越来越多的企业选择将应用程序或 Web 服务迁移到云端，各大厂商提供的云基础架构不仅功能强大、稳定且更具扩展性。通过迁移到云，企业可以显著降低运营压力和成本。目前比较流行的选择是迁移到基于容器的云环境，Kubernetes 是最常用的方法。从长远来看，Kubernetes 最具扩展性，本文介绍了主要的三种迁移至 Kubernetes 的方法。

为何选择 Kubernetes？

在了解可迁移到 Kubernetes 的最佳实践和方法之前，值得花时间了解为什么 Kubernetes 是企业的最佳选择。对于初学者来说，Kubernetes 在设置云环境时提供了最大灵活性。

Kubernetes 有两个主要部分：主集群和充当服务容器的节点，这两个元素可以提供更好的可用性和可靠性。当节点处理应用程序的特定任务和部分时，主集群会处理诸如网络管理和其他资源之类的事情。

两部分设置意味着可以对节点进行更改，而不会影响整体集群。例如，当需要更新特定服务时，可以创建新节点并进行更新，然后告诉主集群使用新节点而不是旧节点即可。从迁移到 Kubernetes 的那一刻起，该方法可以最大限度减少停机时间。

此外，Kubernetes 非常灵活，对于如何相对于彼此建立节点没有严格规则。只要主集群配置为正确使用节点，应用程序或 Web 服务将顺利运行。

迁移策略：三个计划

重新托管（Rehosting）

目前，主要通过三种方式将应用迁移到 Kubernetes。第一种方式是重新托管（Rehosting），这也是所有方法中最简单的一种，基本是将整个 Web 服务或应用程序转移到 Kubernetes 集群。这意味着，只需将 Docker 包装在应用程序周围，然后配置 Kube YAML 文件进行部署即可。这个过程不涉及对应用程序进行更改，这也是转移到 Kubernetes 最快的方法。

但是，重新托管可能不是利用 Kubernetes 提供的云环境最有效（或高效）方式，此方式无法立即受益于 Kubernetes 的所有灵活性，但是很好的第一步。一旦初始迁移完成，就可以继续将服务和部分应用分解到其他节点。

重新平台化（Replatforming）

重新平台化是迁移到 Kubernetes 的第二种方法，可以准备应用程序并对其运行方式进行基本更改，而不是将整个应用程序移动到当前状态，这通常涉及将服务分解为单个容器和节点，并将不同功能分解成单独容器。

重新平台化比重新托管需要更多时间，这是因为将应用程序调整到基于容器的云环境并不是一个简单的过程。在本地 Kubernetes 集群和 Minikube 的帮助下，该过程可以变得更简单。

当处理分区版本以进行迁移时，应用程序可以继续运行。完成更新并布置服务集群后，迁移到 GKE 或 Azure 等云集群会变得更加容易，甚至可以在 Minikube 内部进行彻底测试，以确保更顺畅的过渡。

重构

重构是迁移到 Kubernetes 的主要方法之一。与前两种方法不同，整个应用程序和支持服务都经过修改，以更好地适应新分区环境。

在大多数情况下，重构涉及重新架构整个应用程序以充分利用云环境。例如，开发者可以使用与 Kubernetes 一起的云原生框架（例如 Knative）来重构服务，这可以在云中运行无服务器工作负载。

作为权衡，迁移过程需要更长时间并消耗更多资源。但是，在流程结束时，企业将拥有一个完全可扩展的应用程序，可充分利用 Kubernetes 提供的所有优势。如果需要了解代码库以支持主要版本升级，倾向于推荐此过程。

至于哪种方法最合适，答案取决于迁移目标，要迁移到云的应用程序以及当前配置应用程序的方式。

参考链接：

https://dzone.com/articles/cloud-migration-best-practices-how-to-move-your-pr