Kubernetes 上 API 网关的未来

• API 网关已经从基本的转换器发展为先进的云网关，这适应了市场的需求，在管理和保护客户端与后端服务之间的 API 通信方面发挥着至关重要的作用。

• 即便开源的 Kubernetes Gateway API 项目将 API 网关定位为基础设施中不可或缺的商业化组成部分，全生命周期的 API 管理仍将是推动云原生应用和服务发展的关键。

• 要充分利用云原生计算的潜力，就必须重新设计传统的 API 管理架构，使其不仅能够满足 Kubernetes 和云原生环境的要求，还能充分利用它们提供的功能。

互联网和云计算的指数级增长催生了更小型的、更加分布式的、专门为能够根据需要快速扩展或收缩的高动态环境而设计的应用程序。这些应用程序推动了对现代 API 管理产品架构的需求，该架构可以利用云原生功能来实现可扩展性、韧性、敏捷性和成本效益。与此同时，云原生应用也推动 API 网关从简单的转换器发展成为推动数字计划不可或缺的高级中介。

同时，不管是部署在一个还是多个公有云或私有云上，Kubernetes 都已经成为现代分布式应用的首选开源容器编排系统。根据 2022 年云原生计算基金会（CNCF）的年度调查，89% 的 CNCF 终端用户正在使用或试用 / 探索 Kubernetes。Kubernetes Gateway API 项目是一个社区项目，旨在通过定义声明式的 API 来配置 Kubernetes 集群中的网关和入口，从而推进组织的实施。尽管全生命周期 API 管理在推动云原生应用和服务方面依然至关重要，但这一发展有望使 API 网关更易于访问和商业化。

在本文中，我们将会探讨 API 网关是如何演进的、传统 API 网关为何无法支持 Kubernetes 云原生环境、为何 Envoy 是构建下一代 API 网关的最佳标准，以及在 Kubernetes 上管理 API 的未来。

图 1：网关的演进

在研究 API 网关的演进之前，我们先快速定义一下 API 管理和 API 网关的含义。API 管理包括在 API 生命周期的每个阶段对其进行战略规划、设计、实施和监控的端到端流程。API 网关是 API 管理基础设施中的一个专用组件，它是 API 请求的主要入口，可以实现客户端与后端服务之间的通信。

API 网关的发展可分为九个不同的阶段，每个阶段都代表着其功能的进步和变化。这些阶段反映了 API 网关的不断发展和调整，以满足现代应用架构和 API 管理的需求。

• 早期网关起着转换器的作用，实现不同网络架构之间的通信，简化不同系统之间的连接。

• 代理服务器（包括 Apache HTTP 服务器和 Squid）作为网关很受欢迎，它们可以管理多个端点之间的流量，并提供缓存、安全性和访问控制功能。

• 硬件负载均衡器（如 F5 Networks Big-IP）的出现是为了优化性能，并在应用变得越来越复杂时处理不断增长的用户需求。

• 软件负载均衡器（包括 HAProxy）因其健壮的功能、性能和可靠性而备受青睐。它提供了先进的负载均衡算法、回话持久化、健康检查和可扩展性，非常适合处理大量的 API 流量。

• 应用交付控制器（application delivery controller，ADC），如 NGINX 和 Citrix ADC，作为高级网关出现，可优化应用性能并确保客户端和服务器之间的安全通信。它们提供负载均衡、安全套接字层（SSL）和传输层安全（TLS）终止、安全性、缓存和流量管理功能。

• SOAP 网关是与简单对象访问协议（Simple Object Access Protocol，SOAP）和 web 服务 API 一起发展起来的，实现了基于 SOAP 服务的集成、协议转换和安全执行。

• API 网关是随着 web API 和面向服务架构的兴起而发展起来的，从而成为访问 API 和处理一系列任务的中介，这些任务包括路由、认证、限流和转换等。它们在 API 流量的安全、监控和管理方面发挥着重要的作用，有些网关还使用了 Netty 网络框架。API 网关进一步发展，以便于处理微服务架构中复杂的通信和路由问题，并与服务发现机制集成，实现动态路由、负载均衡和协议转换。

• 微网关越来越多地用于网络边缘，以支持微服务、边缘计算和物联网（IoT）的兴起。它们使处理能力和连接性更加接近数据源，减少了延迟和阻塞，同时实现了数据聚合、本地处理和安全执行。它们还能实现物联网设备与后端系统之间的通信。

• 云原生 API 网关的出现是为了管理云原生环境中的流量，利用 Kubernetes 这样的容器编排平台和云原生原则来实现可扩展性和韧性。随着云原生环境对自动化和增强智能的关注，网关越来越多地采用人工智能（AI）和机器学习（ML）技术。

图 2：API 网关概览

API 网关的角色在当今技术领域中的作用随着它的演进发生了重大的变化。目前，API 网关是 API 管理的核心，它是 API 请求的入口点，将服务质量（quality of service，QoS）问题从单个服务中抽象了出来。它整合了各种 QoS 功能，包括安全性、限流、消息转换、请求路由、缓存和 API 洞察，以确保对 API 进行全面管理。

API 安全性至关重要，其中认证和授权发挥着重要作用，比如双向 TLS（mTLS）、开放授权（OAuth） 2.0 令牌和 API 秘钥等身份认证方式，以及通过授权范围进行的细粒度访问控制，都能用来增强安全性。

API 限流通过遵守定义好的策略确保用户之间的公平使用。它能够防止滥用，保持服务质量的一致性，并提高 API 管理的透明度和责任清晰度（accountability）。

缓存能够为 API 驱动的应用带来显著的性能收益。它通过降低后端负载、减少延迟、优化带宽使用以及提供对后端故障的恢复能力，提高了性能、可扩展性和韧性。

消息转换功能允许用户修改 API 请求，但是直接在 API 网关上实现大量转换会影响性能。最佳实践是利用专门为复杂消息转换设计的集成层。

请求路由涉及根据定义好的规则和配置将传入的 API 请求引导到适当的后端服务，同时还包含服务负载均衡、故障转移机制和 A/B 测试。

API 洞察通过收集和发布数据进行分析和可视化，从而提供商业智能。

监控和可观测性涉及数据收集和分析，以深入了解 API 性能、可用性和使用情况。通过这些功能，组织可以跟踪度量指标、检测异常并排除故障，从而确保 API 网关和底层 API 基础设施的高效运行和持续改进。

现代 API 网关不仅支持表述性状态转移（REST）服务，还支持 GraphQL 服务、gRPC 服务和各种流服务。每种类型的 API 都能从 API 网关获得不同的 QoS 处理。部署模式包括中心化模式和非中心化模式，前者将所有 API 集中在一起，而后者则根据重要程度和运维需要等因素将 API 分布到多个网关上。API 管理器的控制平面会管理部署在不同环境中的网关，提供集中控制和配置。

随着企业利用容器化和微服务架构所带来的收益，Kubernetes 的采用推动了 API 网关使用的增加。API 网关可以在基于 Kubernetes 的环境中实现高效的 API 管理、可扩展性和安全性，使其成为现代应用程序开发和部署的重要组成部分。

尽管传统的 API 管理架构得到了广泛的采用，但是它们并不适合 Kubernetes 和其他云原生环境。它们采用单体设计，将多个功能捆绑在一个应用程序中。这样很难独立扩展各个组件，整个应用必须一起进行扩展，这就会导致资源的浪费，并在处理高流量或工作负载增加时引发性能问题。

传统的 API 管理架构还依赖于与云原生环境不兼容的特定基础设施组件和技术。它们不仅内存占用较大、服务器启动时间较长，还可能需要专用硬件、特定的软件配置或专有的解决方案。这限制了它们使用云平台优势的能力，包括自动扩展、基础设施即代码实践和多云部署。

由于 API 管理架构中的一些外部依赖性，API 网关在支持云原生应用方面也面临着类似的挑战。为了克服这些挑战并满足当前和未来云原生环境的需求，API 网关需要重新架构。

Envoy 已经成为重新架构 API 网关的首选解决方案，因为这款开源的边缘和服务代理是专门为云原生应用而设计的。此外，它的适应性、可扩展性和强大的安全特性使其成为在不同云环境中管理 API 流量的绝佳选择。此外，作为一个开源解决方案，Envoy 得到了全球开发人员的不断改进，他们贡献了新特性、功能增强和缺陷修复，进一步增强了代理的健壮性和可靠性。

从 API 管理的角度来看，Envoy 提供了一些基本功能，如限流、响应缓存、跨源资源共享（CORS）处理、请求认证和授权。它支持对外暴露 REST 和 gRPC，并能够与 Amazon Web Services（AWS）直接集成，以对外暴露 AWS Lambda 函数。该代理还提供了内置的可观测性特性，可以与开放性遥测技术无缝集成，为监控和调试提供全面的度量指标和跟踪数据。Envoy 代理使用 xDS API 进行配置，可实现代理的动态配置、服务发现、流量路由和运行时控制。通过 xDS API，可以轻松设置和修改 Envoy，以满足不断变化的需求。

Envoy 代理主要有两种部署模式：sidecar 代理模式和前置代理模式。在 sidecar 代理模式中，Envoy 在面向服务架构（SOA）中充当内部流量的总线。它通常用作服务网格中的 sidecar，在代理服务的同时管理网络流量。Envoy 的轻量级内核和强大的功能（如负载均衡和服务发现）使其成为 Istio 等服务网格的热门选择。

在前置代理模式中，Kubernetes Ingress 控制器利用 Envoy 将服务暴露给外部消费者。有些 Ingress 控制器是在 Envoy 的基础上构建的，充分利用了其基本功能。Envoy 灵活的配置模型和特性集也使其成为 API 网关的理想选择。大多数现代 API 网关都建立在 Envoy 代理之上，在这个过程中，Envoy 代理会作为基础框架。

基于 Envoy 代理的 API 网关在增强整体 API 管理架构方面发挥着至关重要的作用，因为它们利用云原生技术和实践来有效管理 API，同时确保了可扩展性和韧性。在这里，API 管理架构基于微服务原则、容器化，并使用 Kubernetes 进行容器编排，为云原生环境中的高效 API 管理提供了必要的基础设施。

云原生 API 管理架构包括两个不同的平面：控制平面和数据平面。控制平面是执行 API 管理任务和 API 秘钥生成的指挥中心。数据平面作为 API 调用的网关，将创建的 API 暴露给公开或私有的消费者。该架构的设计具有高度的可扩展性，允许一个控制平面管理多个数据平面。这就实现了无缝的 API 网关联盟，并且能够实现跨多种云供应商或企业内部数据中心的 API 管理。为了增强可扩展性和韧性，该架构利用了 Kubernetes 的基本功能，如自动扩展和自动修复，以确保最佳性能和可靠性。

图 3：用于 API 管理的控制平面和数据平面

2022 年，Envoy 的创建者 Matt Klein 推出了一个名为 Envoy Gateway 的新项目，专门用于 API 网关。Envoy 已经具备了构建 API 网关的必要组件，包括代理层；用于网络流量过滤、路由选择和处理的可配置过滤器架构；以及用于将数据传输到 Envoy 代理的 xDS API。开源 Envoy Gateway 项目增加了一个管理层，可以将 Envoy 代理作为独立网关或 Kubernetes 管理的 API 网关来处理。

该项目的目标是提供简化 API 层和部署模型，重点关注更简单的用例。它还致力于将各种 CNCF API 网关项目整合为一个通用的核心，使供应商能够在 Envoy 和 Envoy Gateway 的基础上构建增值解决方案。通过促进社区合作，该项目还致力于消除在开发基本 API 网关功能方面的重复劳动，使厂商能够更加专注于 API 管理功能。在统一方面的努力有望提高 API 网关领域的效率并鼓励创新。

Envoy Gateway 项目主要基于 Kubernetes Gateway API，该 API 定义了如何将 Kubernetes 服务暴露给外部世界。它利用 Kubernetes 自定义资源（CRD），比如 GatewayClass、Gateway、HTTPRoute、TCPRoute 等来配置 API 网关。CRD 勾勒出了流量分割、请求路由、重定向、重写和 TLS 处理等重要特性。此外，各种策略可与 API 网关或特定 API 路径关联。

通过以 Kubernetes Gateway API 作为基础，供应商可以灵活地在其偏好的技术栈上开发自己的实现方案，还可以利用 API 规范提供的扩展点来整合特定供应商的功能。这种方法有助于采用共享的、标准的 API 规范，从而实现互操作性，提高 API 网关之间的一致性，并为未来的创新开辟新的可能。

API 管理在动态 API 环境中起着至关重要的作用，随着 API 标准化的推进，API 网关不可避免地将成为基础设施的基本要素。这种行为将把开发人员从直接管理网关及其相关复杂性的负担中解放了出来，使他们能够将注意力集中在构建和维护 API 以及其他核心开发任务上。因此，重点转向了 API 管理，其中包含了一系列基本特性。

• API 生命周期管理能够为 API 提供生命周期，允许自定义事件和利益相关者对生命周期变更进行授权。

• API 治理建立流程和策略，以确保有效的 API 开发、管理并符合组织的目标和标准。

• API 市场是开发人员发现、访问和管理 API 的在线平台。它提供了文档、目录、软件开发工具包（SDK）、测试工具、社区支持和货币化选项。

• API 版本管理涉及管理不同的 API 版本，以适应变化，同时保持向后兼容性。

• API 产品化会将 API 视为可市场化的产品，使用产品管理的原则来满足开发人员和业务人员的需求。这包括创建用户友好的体验并实现货币化策略。

• API 洞察通过分析使用情况、性能和行为以提供有价值的信息，从而为增强 API 体验做出数据驱动型的决策。

要充分利用云原生生态系统的优势，需要重新设计其中的许多特性。这涉及与 Kubernetes 上的各种第三方服务进行无缝集成，以实现更全面、更强大的 API 解决方案。

除此之外，采用开源发布模式对企业来说也是一个至关重要的因素。开源产品鼓励社区参与和调整，促进生态系统内的协作和创新。拥抱开源还能确保 API 管理解决方案从不同社区的集体知识和贡献中获益，从而实现不断地改进和发展。

图四：适用于不同 API 网关实现的单一控制平面

API 标准化将 API 网关视为商品，为包含 API 管理和发现的统一控制平面铺平了道路。同时，数据平面可以由来自不同供应商的一个或多个 API 实现组合在一起。这种模式转变带来了很多影响和机遇。

• 供应商中立和灵活性：通过使用能够管理来自不同供应商的多个网关的单一控制平面，企业可以实现供应商中立性并提高灵活性。这使得他们能够为每个特定的用例或环境选择最合适的网关解决方案。通过采用多个供应商，组织能够利用不同供应商提供的特定优势和长处，避免供应商锁定，并实现更具适应性的生态系统。

• 互操作性和标准化：采用单一控制平面可促进不同网关之间的互操作性和标准化。通过采用共享的 API、协议和数据格式，控制平面可实现不同供应商网关之间的无缝通信和管理。这将促成配置、策略和安全措施的一致性，从而提高整个 API 基础设施的稳定性和可靠性。

• 生态系统扩展和创新：单一控制平面能够管理来自多个供应商的网关，这促成了多样化生态系统的发展，并激发了创新。它使组织能够接受和集成新兴供应商的新网关解决方案，而不会对现有的基础设施造成破坏。供应商之间的良性竞争推动了创新，扩大了可用方案的范围，并使组织能够通过更广泛的尖端解决方案来满足其 API 管理的需求。

• 成本优化：通过单一控制平面管理不同供应商的网关，组织可以灵活选择符合其特定要求和预算因素的高性价比的网关解决方案。这种自由度能够使企业优化支出，从 API 管理基础设施中获得最大的价值，并做出符合其特定需求的明智决策。

• 简化管理和运维：组织可以集中配置、监控和控制其 API 网关，消除了单独管理不同网关的复杂性。这种中心化的方式提高了管理效率，简化了运维，并最大限度地减少了潜在的不一致性。由于网关遵循相同的 API 标准化，所以 API 网关解决方案之间的迁移变得更加容易。这简化了从一个解决方案迁移至另一个解决方案的过程，确保了顺利集成，并减少了对现有基础设施的潜在干扰。

总而言之，当 API 网关成为一种商品，并且由单个控制平面管理来自不同供应商的多个网关时，企业就能获得供应商中立性、简化的管理、更高的互操作性、成本优化、更强的安全性以及更容易的生态扩展等优势。这种融合还能让企业能够利用不同网关解决方案的优势，简化运维，推动创新，并优化 API 管理实践。

原文链接：

https://wso2.com/library/blogs/the-future-of-api-gateways-on-kubernetes/

声明：本文为 InfoQ 翻译，未经许可禁止转载。