Kubernetes Gateway API - 服务网络的演进

在本文中，我们将讨论 Kubernetes Gateway API 以及它如何演进 Kubernetes 服务网络。我们将简要介绍 Gateway API 的设计目标以及它如何改进当前的服务网络标准，如 Ingress。

Background

服务网络 是 Kubernetes 的一部分，涉及在网络上公开或发布你的 pod，以便其他客户端可以访问它们。服务网络提供了多种抽象来帮助暴露 pod，提供在集群内执行此操作的简单方法，或者提供更复杂的方法，将 Kubernetes 应用程序暴露给在集群外部甚至公共互联网上运行的客户端。服务网络资源，例如 Service 负载均衡器和 Ingress 通常用于在网络上公开在 Kubernetes 内部运行的应用程序。

Ingress API 主要用于以简单的声明性语法公开 HTTP 应用程序，并且 Ingress 控制器 配置底层负载均衡器并实现入口。Ingress API 专为简单的用例而设计，并支持一些基本的 HTTP 路由语义：

• HTTP 主机匹配

• HTTP 路径匹配

• TLS 终止

• 路由到服务后端

而且在灵活性方面，Ingress 资源并没有提供很多方法来发展这个 API 以支持更高级的功能。因此，对于高级用例和对新负载平衡功能不断增长的需求，各个供应商通过使用供应商特定的 注解。尽管注解确实完成了工作，但它导致了不同实现之间的不一致、糟糕的用户体验和安全问题，因为注解可以自由形成字符串，因此没有验证，总体而言，从一个供应商迁移到另一个供应商变得困难。

Service 资源遇到了与入口资源几乎相似的问题，并且它也获得了大量自定义注解，并且由于涉及 Kubernetes 不同领域的功能（如负载平衡等）而变得臃肿。

这些问题已经存在了一段时间，导致现有的 Service 网络资源变得相当复杂，并使其管理和发展有点困难。 在 KubeCon San Diego 2019 上，一群人聚在一起讨论这些问题，并提出了一个可以用来解决这些问题的新 API 的想法。 Kubernetes Gateway API 旨在为这些问题提供解决方案，并发展 Kubernetes 的服务网络领域。

Kubernetes Gateway API 是什么？

Kubernetes Gateway API是由SIG-NETWORK社区管理的开源项目，是一种规范或标准，这意味着支持它的项目和公司必须遵守它。这促进了可移植性和可重用性，因为许多不同的实现具有相同的用户接口。截至今天，Gateway API 有许多贡献者，如 Google、RedHat、VMWare、Kong、Traefiklabs 等，而且这个名单还在继续增长。这些贡献者和许多其他贡献者还提供了称为网关控制器的 Gateway API 的实现。在撰写本文时，官方网站上列出了 13 个网关控制器的实现，我们相信还有更多尚未进入官方网站的实现。

Gateway API 吸取了 Ingress 和服务网格社区的经验教训，提升了我们用来建模服务网络的 Kubernetes 原生资源。Gateway API 增加了对以下方面的支持：

• 基于 HTTP 头的匹配

• HTTP 标头操作

• 加权流量拆分

• 流量镜像

• 面向角色的资源模型

• 更多

它还提供了内置于 API 中的可扩展性和扩展点，用于未来的提升，并支持：

• 任意后端 CRD 引用（存储桶、函数等）

• 分层 API 用于不同的路由资源到已有的资源，例如 支持 gRPC 协议和路由语义

• 实现特定行为的粒度扩展点，如负载平衡算法、自定义匹配类型等

就像 Ingress 控制器，代表Ingress 资源管理网络基础设施，网关 API 有 网关控制器 管理底层网络基础设施，如负载均衡器，可以是从云管理的负载均衡器到集群内的软件代理的任何东西。每个网关控制器支持一个或多个 GatewayClass，其中 GatewayClass 就像一个模板，明确定义了一组 GatewayClass 共享一个共同的配置和行为。每个 GatewayClass 将由单个控制器处理，尽管控制器可以处理多个 GatewayClass。

网关 是从 GatewayClass 创建的，它们对处理流量的实际网络基础设施进行建模，例如实际的负载均衡器。网关描述了如何将流量转换为集群内的 Service。也就是说，它定义了一种将流量从不了解 Kubernetes 的地方转换到了解 Kubernetes 的地方的方法的请求。例如，流量由云负载均衡器、集群内代理或外部硬件负载均衡器发送到 Kubernetes Service。网关被设计为抽象的，因此它们可以对许多不同类型的执行路由的数据平面进行建模。

然后你有 Route Resources，它定义了将请求从网关映射到 Kubernetes 服务的特定协议规则。从 v1alpha2 开始，有四种 Route 资源类型，如 HTTPRoute、TLSRoute .k8s.io/concepts/api-overview/#tlsroute), TCPRoute, and UDPRoute 是包含在 API 中的。对于其他协议，鼓励使用特定于实现的自定义路由类型。未来可能会向 API 添加新的路由类型。

如模型图所示，我们可以看到 Gateway 和 HTTP 路由资源一起完成了一个 Ingress 资源所做的事情。 这种分离允许不同的角色部署和拥有该资源。

Gateway API 通过其面向角色的 Kubernetes 网络设计在分布式灵活性和集中控制之间取得平衡，为基础设施的用户提供灵活性，同时保持基础设施所有者的控制。

• 基础设施提供商 (infra) 负责集群运行的整体环境示例包括云提供商（AWS、Azure、GCP...）或公司中的 PaaS 提供商。

• 集群操作员 (ops) 负责管理整个集群。他们管理策略、网络访问和应用程序权限。

• 应用程序开发人员 (dev) 负责定义他们的应用程序配置（例如超时、请求匹配/过滤器）和服务组合（例如到后端的路径路由）。

这种角色分离允许许多不同的团队甚至跨命名空间边界共享相同的网关资源。这允许集群运维人员从本质上控制谁可以访问网关和该网关上的策略，同时以分布式方式将路由控制委派给不同的团队。

总结

我们简要介绍了当前 Kubernetes 服务网络资源的背景、挑战和复杂性，以及 Kubernetes Gateway API 如何提供新的抽象来克服这些挑战。我们还了解到 Kubernetes Gateway API 被设计为面向角色、表达性、可扩展性和通用性，因此它可以灵活地被不同的组织使用并在不同的网关控制器集上实现，并为将来的场景保留其核心可移植性。

在下一篇文章中，我们将探讨 Gateway API 和一些其他关键概念，并使用其中一个网关控制器进行演示。 所以请继续关注。