使用 Kubernetes 探索跨云应用程序可移植性

本文与 Lindsey Tulloch 合著。

在一个快速向云端迁移的世界中，投资者、客户和开发人员都在屏息凝视着“云战争”。随着云巨头的崛起和一种新型基础设施的骨干在我们眼前形成，对于我们这些身处一线的人来说，保持敏捷性以维持我们的技术和经济优势至关重要。

从开发和采用的角度来看，可移植的应用程序（能够在不同操作系统上无缝运行）是有意义的。解释型语言和运行时环境使应用程序能够在任何地方运行。

在谈论操作系统时，这是预期的，但这在实践层面如何转化为跨公共云、私有云和混合云工作呢？

假设您有一个应用程序部署在本地私有云应用程序中，并且您计划有一天将其完全迁移到公共云。您如何确保您的应用程序在公共云基础设施上的可扩展性？或者，您可能已经部署在公共云提供商的基础设施上，并且由于成本原因，您决定不再使用该云提供商。您如何避免供应商锁定并确保平稳过渡到新的提供商？无论您选择哪种解决方案，变化都是永恒的，云中的软件应用程序可移植性是使任何这些潜在的未来决策成为可能的关键。

这还不是一项简单的任务。每个云提供商都有自己做事的方式，从支持 API 到实施计算、存储和网络操作。那么，如何编写云无关的应用程序代码，使其可以在不同的云基础设施之间移植呢？克服这些提供商特定障碍的一种答案涉及 Kubernetes。

Kubernetes 是开源软件，用于“自动化容器化应用程序的部署、扩展和管理”。 Kubernetes 本身是对所有基础设施和云提供商的抽象，从而简化了协调所有资源的方法。 Kubernetes 的一项允许编排多个 Kubernetes 集群的功能恰如其分地称为多集群。多集群（以前称为 federation）仍处于早期的 pre-alpha 阶段，旨在通过跨成员集群同步资源来简化多个 Kubernetes 集群的管理。多集群承诺通过跨集群平衡工作负载来实现高可用性，并在集群发生故障时提高可靠性。此外，它还避免了供应商锁定，让您能够编写一次应用程序，并将其部署在任何单个云提供商或多个云提供商上。

与最初的 federation 项目（提供单个单体控制平面来管理多个联合 Kubernetes 集群）相比，当前的架构采用更具组合性的方法。 kubemci、cluster-registry 和 federation-v2 等较小的原型设计项目正在解决 federation 的基本要素——入口管理、对各个集群的访问和工作负载分配——从头开始构建一个 federation 生态系统，让用户可以更好地控制应用程序在多集群网络中的分布和扩展方式。

作为在 Red Hat CTO 办公室工作的工程师，我们希望测试 Kubernetes 多集群的承诺并进一步探索应用程序的可移植性。我们着手构建一个可信的参考应用程序来验证可移植性。这涉及在 Google Cloud、Amazon Web Services 和 Microsoft Azure 中构建单独的 Kubernetes 集群。每个 Kubernetes 集群都在不同的区域中创建，以测试高可用性的前景。

我们任意选择托管在 Google Cloud 中的 Kubernetes 集群作为主集群，并使用 apiserver-builder 将聚合的 federation API 服务器和控制器部署到其中。为了将这三个集群连接在一起，我们使用了多集群管理工具 kubefnord。这使我们拥有了跨越三个不同区域的三个独立的 Kubernetes 集群——所有集群都通过同一个主 Kubernetes 集群进行管理，如下图所示。

我们基于开源 Pac-Man HTML5 游戏构建了一个有状态的 微服务 参考 Web 应用程序，并对其进行了修改以使用 Node.js（选择 Node.js 是因为它具有 Web 服务器组件、易于调试、容器化功能以及作为我们的后端 API）。我们使用 MongoDB 作为分布式数据库来持久化有状态部分的高分数据。我们通过显示云提供商名称、区域和实例运行的主机名等详细信息，使我们的 Pac-Man 应用程序具有云感知能力。最后，我们使用 Red Hat Enterprise Linux 作为容器操作系统，对 Pac-Man 和 MongoDB 进行了容器化。

为了为 MongoDB 提供持久卷以存储用户数据（例如高分），我们在每个集群中使用了默认的 存储类，该存储类可以使用每个云提供商的块存储功能：Google Persistent Disk、Amazon Elastic Block Storage 和 Azure Disk。我们创建了一个 PersistentVolumeClaim (PVC)，以便 MongoDB 部署可以通过引用 PVC 简单地请求存储卷，而 Kubernetes 将提供一个 动态配置的卷。随后，我们通过构建分布式 MongoDB 集，将容器化的 MongoDB 部署到联合 Kubernetes 集群上，以便将高分数据复制到联合中的每个 Kubernetes 集群。然后，我们将每个集群中 MongoDB 服务的负载均衡器 IP 地址映射到 DNS 条目，以实现负载均衡和高可用性。

在对 Pac-Man 进行容器化之后，我们将其与容器化的 MongoDB 一起部署到三个 Kubernetes 集群。这涉及到将每个集群中 Pac-Man 服务的负载均衡器 IP 地址映射到 DNS 条目。 最终结果 如下所示

现在我们已经成功地将我们的应用程序扩展到三大公共云提供商！这个例子很容易就可以包含一个本地私有云。但是，如果我们想从特定的云提供商缩减我们的应用程序规模呢？

为了验证该用例，我们使用上面概述的相同步骤部署了我们的应用程序，但这次仅在 Google Cloud Platform 和 Amazon Web Services 上。一旦应用程序部署在两个提供商上，我们更新了 Kubernetes YAML 资源的放置首选项，以反映我们希望 Pac-Man 应用程序仅在 Google Cloud Platform 上运行。通过 federation 界面应用更改后，Pac-Man 应用程序部署迅速更新为仅在我们的 Google Cloud Platform Kubernetes 集群上运行。我们的缩减规模取得了成功！

图片来源：

opensource.com

正如我们的简要演练所证明的那样，Kubernetes federation-v2 实现了软件应用程序的可移植性。重要的是 Kubernetes 提供了一个通用的平台，可以跨任何云提供商使用。当您将多集群功能添加到组合中时，您可以编写一次应用程序代码，并将其部署到云提供商的任何组合中。因此，您可以放心地知道，只要有一个共同点：Kubernetes，您今天编写的应用程序代码就可以轻松地跨云提供商部署。

本文基于“使用 Kubernetes 探索跨云应用程序可移植性”，作者将在 Red Hat Summit 2018 上发表的演讲，该峰会将于 5 月 8 日至 10 日在旧金山举行。 在 5 月 7 日之前注册 可节省 500 美元的注册费。在付款页面上使用折扣码 OPEN18 应用折扣。