借助 Kubernetes 三步开启云原生之旅

原文作者：Dave McAllister of F5

原文链接：借助 Kubernetes 三步开启云原生之旅

转载来源：NGINX 官方网站

---

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

如今，许多公司都已踏上云原生之旅，F5 称之为“感知可控、随需而变的应用”之旅。我们所说的“感知可控、随需而变”主要是指应用通过自动按需扩展、检测和缓解问题并从故障中恢复（以及其他能力），对其运行环境的变化做出响应。

同时，这也意味着，随着流量模式的转变、底层基础架构的发展，以及网络攻击的日益增多和复杂化，我们可以轻松更新应用以满足业务和技术领域不断变化的要求。

这听起来很不错，不是吗？但是，实现感知可控、随需而变的应用（即“自适应应用”）不是一蹴而就的事情。这需要时间。如果您尚处于早期阶段，也没关系。通过简化沿途的关键点，您可以更轻松地完成这段旅程。

我们通常认为自适应应用是由微服务架构驱动的，在错综复杂的弹性云环境中的容器内运行。如果您必须手动处理每项变化，则将无法及时按需增减节点、pod 和容器。您需要进行编排（特别是容器编排），以避免发生混乱。

感知可控、随需而变的应用至少需要在四个方面对环境变化做出响应：

1. 性能

2. 可扩展性（或灵活性）

3. 可观测性

4. 安全性

如何无缝地编排和管理您的感知可控、随需而变的应用（组），以快速对不断变化的条件做出自动化响应？有关编排的讨论很难避开 Kubernetes。这也是为什么我和 Granville Schmidt 会在 GlueCon 上谈论它。

Kubernetes 是云原生计算基金会 (CNCF) 最受欢迎的项目之一——这是有原因的。它拥有大量出色的功能（特别适合需要不断做出调整的企业），在许多情况下，是面向可扩展应用的理想工具，因为它能够提供所需的灵活性。

在2015 年 7 月推出时，它已经是一个成熟的产品了（得益于 Google 在其前身 Borg 项目上所开展的工作）。随着它的不断发展，完善该解决方案所需的支持技术的生态系统不断壮大。然而，虽然 Kubernetes 是一款强大的工具，但它并不是万能的，而且使用起来可能很复杂并具有挑战性。

开启您的云原生之旅

除非您是从全新的代码库开始，否则您可能已经在生产环境中部署了应用。并非每个应用都必须是云原生，特别是当它已经能够满足我们对现代应用的要求时。另外，虽然 Kubernetes 拥有丰富的功能，但并不意味着您需要到处使用它。对 Kubernetes 的使用需要依时依地。但是，向微服务和容器的迁移绝对是有利的。

那么，您如何开启您的云原生之旅呢？您如何从现有的单体迁移到基于微服务的云世界呢？

面对纷繁复杂的资源，我们希望通过 Kubernetes 编排找到从单体迁移到云原生世界的最简单方法。早在 2010 年，Gartner 就概述了云迁移的五种方法：重新托管（rehost）、重构（refactor）、修订（revise）、重建（rebuild）和替换（replace）。

Microsoft 基于 Gartner 的领先理念，构建了一个名为“云合理化（cloud rationalization）”的框架（这个框架将第三个方法“重建”重新命名为“重新架构（rearchitect）”)。

但您也可以把这些方法/框架组件看作是迁移之旅的步骤。这是一段涉及开发人员和运维、代码和流程的旅程——您可能刚刚开启或者已经踏上了这段旅程。在这里，我们重点讨论其中三个步骤：重新托管、重构和重新架构。

重新托管（即直接迁移）

云原生之旅往往从现有的单体应用开始。但是，您肯定不希望一下子从单体跨入云原生世界。我们建议您从重新托管或封装基础架构开始。

虽然我们经常听说云端存在大量微服务，但实际上也充斥着不少单体应用。为什么会这样呢？因为这些单体应用目前运行正常，没有出现故障（至少目前还没有）。然而，尽管单体应用的传统三层架构仍在正常使用中，但使用它的应用很可能会遇到扩展问题，甚至您必须构建混合模式才能适应当今用户的需求。

第一步“重新托管”也被称为“直接迁移”。简而言之，您把现有的应用复制并“粘贴”到适当的云平台上。也就是说，您正在迁移到“别人的电脑”上，同时尽可能减少对自己的应用的影响。

这经常发生在虚拟机 (VM) 环境中，这可让您开始在云中管理应用并确定需要处理的问题。仅仅通过直接迁移，您无法真正利用感知可控，随需而变的应用的许多优势，因为您只能通过复制整个应用进行扩展，即使构成瓶颈的只是其中的某一项功能。而进入云原生世界后，您会遇到陌生的问题，需要面对动态运行代码的 Web 应用和静态资产。

尽管现在您还未到容器和编排层面，但已经为下一步做好了准备。

重构

在下一步中，您将应用重构为几个部分（通常以模块形式实现），其中每个部分都执行单一功能（或者可能是一组密切相关的功能）。同时，您可以添加新的应用功能，或将一些功能绑定到特定的云服务（例如数据库或消息传递服务）。您也可以迁移到容器，同时保留一些虚拟机来搭建基础架构。编排也将变得更加重要。

关于此处内容，您可以点击文章《借助 Kubernetes 三步开启云原生之旅》进行查看。

重新架构

通过重构在初始应用中添加和替换服务之后，接下来您需要重新架构，为微服务架构实施稳定而合理的重新设计。缝缝补补可能暂时有效，但在生产系统中，系统稳定性是第一位的。

按照我们的设想，在重新架构这一步，您需要继续解构初始应用，这样所有函数都由 Kubernetes 管理的容器中的微服务（或 serverless 函数）执行。在这里，通信是关键所在。每个微服务都足够小（这并不意味着“尽可能地小”），并且通常由独立的团队开发。

当应用由一组以松散耦合的方式进行通信的离散、独立的微服务组成时，会不可避免地出现新的问题，甚至发生混乱。还记得那个外部 Ingress 问题吗？又出现了，而且更严重了。现在，您要处理的是一组更复杂的需要 Ingress 的服务，并且需要与更多的团队协作。

使用 NGINX Ingress Controller 和 NGINX Kubernetes Gateway 进行重新架构

NGINX Ingress Controller 不只依赖标准的 Kubernetes Ingress 资源，还支持自己的一套自定义资源定义 (CRD)，后者将 NGINX 的功能扩展到了更广泛的用例，例如使用 Kubernetes API 的基于角色的访问控制 (RBAC) 功能委托对象。

实施 Kubernetes Gateway API 规范的 Ingress controller也值得研究。Kubernetes Gateway 允许您将基础架构管理委托给多个团队，并简化部署和管理。该网关不会取代 Ingress controller，但是随着规范的成熟，它可能会成为首选解决方案。

NGINX 对 Kubernetes Gateway API 的实现，即NGINX Kubernetes Gateway，在数据平面使用 NGINX 技术，（截至本文撰写时）处于测试阶段。

根据Kubernetes Gateway API 规范，NGINX Kubernetes Gateway 支持多个团队在开发和交付应用时对 Ingress 配置进行多方面的控制。

在云原生世界中，开发人员和网站可靠性工程师 (SRE) 经常持续开展合作，网关支持他们更轻松地将不同的控制权委托给适当的团队。网关还整合了以前属于自定义 Kubernetes 注释和 CRD 的核心功能，支持更轻松地构建和运行云原生世界。

云原生和开源

在容器和 Kubernetes 的驱动下，只需简单的几步即可从单体迁移到云原生世界。您可能会发现许多其他适合您的用例的方法，比如保留初始应用，同时围绕它构建一个新的框架，将 NGINX Unit 和 Kubernetes 的功能结合起来。或者您也可以构建一个混合模式。如欲了解 Kubernetes 世界中的 NGINX 参考模型，请查看我们的开源现代应用参考架构 (MARA) 项目。

无论您选择哪种云原生方法，您始终需要在 Kubernetes 集群中具备控制和通信能力，以实现所期望的生产系统性能和稳定性。NGINX 企业和开源技术可帮助您实现从数据平面到管理平面的所有这些，同时考虑到安全性和性能。

---

NGINX 唯一中文官方社区 ，尽在nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：

• 开源社区官网：https://www.nginx.org.cn/
• 微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg