简介¶
网关 API 是一个官方的 Kubernetes 项目，专注于 Kubernetes 中的 L4 和 L7 路由。该项目代表了下一代 Kubernetes Ingress、负载均衡和服务网格 API。从一开始，它就被设计成通用的、富有表现力的和面向角色的。
整个资源模型侧重于 3 个不同的角色以及他们预计将管理的相应资源
此 API 中的大部分配置都包含在路由层。这些特定于协议的资源（HTTPRoute、GRPCRoute 等）为 Ingress 和网格提供了高级路由功能。
网关 API 徽标有助于说明此 API 的双重目的，即为南北向（Ingress）和东西向（网格）流量启用路由以共享相同的配置。
用于 Ingress 的网关 API ¶
自 v0.5.0 以来一直是标准通道
网关、网关类和 HTTPRoute 自 v0.5.0 以来一直是网关 API 标准通道的一部分，被视为稳定的 API。有关更多信息，请参阅我们的版本控制指南.
当使用网关 API 管理 Ingress 流量时，网关 资源定义了一个访问点，可以在该点跨多个上下文路由流量——例如，从集群外部到集群内部（南北向流量）。
每个网关都与一个网关类 相关联，该类描述了将处理网关流量的实际网关控制器 类型；然后，单独的路由资源（例如 HTTPRoute）与网关资源相关联。将这些不同的关注点分离到不同的资源中，是网关 API 面向角色的性质的关键部分，并且允许在同一个集群中使用多种类型的网关控制器（由网关类资源表示），每个控制器都有多个实例（由网关资源表示）。
用于服务网格的网关 API（GAMMA 计划) ¶
当使用网关 API 管理服务网格 时，情况有所不同。由于通常集群中只有一个网格处于活动状态，因此不会使用网关 和 网关类 资源；相反，单独的路由资源（例如 HTTPRoute）直接与服务资源相关联，允许网格管理指向该服务的任何流量，同时保留网关 API 的面向角色的性质。
迄今为止，GAMMA 能够通过对网关 API 进行非常小的更改来支持网格功能。然而，GAMMA 中迅速变得至关重要的一个特定领域是定义服务资源的不同方面。
入门¶
无论您是希望使用网关 API 的用户，还是希望符合 API 的实现者，以下资源将帮助您提供必要的背景信息
网关 API 概念¶
以下设计目标推动了网关 API 的概念。这些表明网关如何旨在改进 Ingress 等现有标准。
- 面向角色 - 网关由 API 资源组成，这些资源模拟使用和配置 Kubernetes 服务网络的组织角色。
- 可移植 - 这不是改进，而是应该保持不变的东西。正如 Ingress 是一种具有众多实现 的通用规范一样，网关 API 被设计为由许多实现支持的可移植规范。
- 富有表现力 - 网关 API 资源支持基于标头的匹配、流量加权以及仅通过 Ingress 中的自定义注释才有可能的其他功能。
- 可扩展 - 网关 API 允许将自定义资源链接到 API 的各个层。这使得可以在 API 结构内的适当位置进行细粒度的自定义。
其他一些值得注意的功能包括
- 网关类 - 网关类将负载均衡实现类型形式化。这些类使用户能够轻松且明确地了解通过 Kubernetes 资源模型提供的功能类型。
- 共享网关和跨命名空间支持 - 它们允许通过允许独立的路由资源附加到同一个网关来共享负载均衡器和 VIP。这允许团队（即使跨命名空间）在没有直接协调的情况下安全地共享基础设施。
- 类型化路由和类型化后端 - 网关 API 支持类型化路由资源以及不同类型的后端。这使得 API 能够灵活地支持各种协议（如 HTTP 和 gRPC）以及各种后端目标（如 Kubernetes 服务、存储桶或函数）。
- 使用GAMMA 计划 的实验性服务网格支持 - 网关 API 支持将路由资源与服务资源相关联，以配置服务网格以及 Ingress 控制器。
为什么面向角色的 API 很重要？¶
无论是道路、电力、数据中心还是 Kubernetes 集群，基础设施都是为了共享而构建的。但是，共享的基础设施提出了一个共同的挑战——如何在维护基础设施所有者的控制权的同时，为基础设施用户提供灵活性？
网关 API 通过面向角色的 Kubernetes 服务网络设计来实现这一目标，该设计在分布式灵活性与集中控制之间取得平衡。它允许许多不同的非协调团队使用共享的网络基础设施（硬件负载均衡器、云网络、集群托管代理等），所有这些团队都受集群运营商设置的策略和约束的约束。
网关 API 设计中使用的角色由三个角色定义
角色¶
-
伊恩（他/他）是一名基础设施提供者。他的职责是维护和管理一组基础设施，这些基础设施允许多个隔离的集群为多个租户提供服务。他不受任何单个租户的约束；相反，他关心所有租户的集体利益。
-
千寻（他们/他们）是一名集群运营者。他们的职责是管理单个集群，确保它满足其多个用户的需求。同样，千寻不受其集群的任何单个用户的约束；他们需要确保集群按需为所有用户提供服务。
-
安娜（她/她）是一名应用程序开发者。安娜在 Gateway API 角色中处于独特的地位：她专注于她的应用程序旨在满足的业务需求，而不是 Kubernetes 或 Gateway API。事实上，安娜可能会将 Gateway API 和 Kubernetes 看作是阻碍她完成工作的纯粹摩擦。
（这三者在 角色和人物 中有更详细的讨论。）
应该清楚的是，虽然安娜、千寻和伊恩不一定在所有事情上都意见一致，但他们需要协同工作才能使事情顺利运行。这是 Gateway API 在本质上的核心挑战。
用例¶
示例用例 展示了这种以角色为导向的模型在实际中的应用。其灵活性使 API 能够适应截然不同的组织模型和实现方式，同时保持一个可移植且标准的 API。
所呈现的用例故意使用上面介绍的角色来描述。最终，Gateway API 是为人类使用而设计的，这意味着它必须适合安娜、千寻和伊恩每个人都会使用的用途。
Gateway API 和 API 网关有什么区别？¶
API 网关是一个通用概念，它描述任何暴露后端服务功能的东西，同时提供用于流量路由和操作的额外功能，例如负载均衡、请求和响应转换，有时还包括更高级的功能，如身份验证和授权、速率限制和断路器。
Gateway API 是一个接口，或一组资源，用于在 Kubernetes 中建模服务网络。其中一个主要资源是Gateway，它声明要实例化的 Gateway 类型（或类）及其配置。作为 Gateway 提供者，您可以实现 Gateway API 以一种表达性、可扩展且以角色为导向的方式建模 Kubernetes 服务网络。
大多数 Gateway API 实现从某种程度上来说都是 API 网关，但并非所有 API 网关都是 Gateway API 实现。
谁在开发 Gateway API？¶
Gateway API 是一个由 SIG-Network 项目开发的项目，旨在改进和标准化 Kubernetes 中的服务网络。查看 实现参考 以了解支持 Gateway 的最新项目和产品。如果您有兴趣为 Gateway API 贡献代码或构建使用 Gateway API 的实现，请不要犹豫 加入我们！