Hello folks，我是 Luga，今天我们来聊一下云原生网关的历史演进历程：从 Ingress 到 Gateway API。
众所周知，Kubernetes 网络格局正在发生深刻的变化。传统的 Kubernetes Ingress 方法正在被一种更强大、更灵活、更具扩展性的标准所补充，甚至在某些情况下被其取代：Kubernetes Gateway API。
Kubernetes 事实上已成为编排和管理容器化应用程序的首选平台，其核心能力之一是管理网络流量。网络的高效管理对于确保这些应用程序的性能和可用性至关重要。然而，处理 Kubernetes 网络的复杂性通常会导致 Ingress 方法面临诸多挑战。虽然 Ingress 是当前管理集群服务外部流量的标准方法，但在复杂的环境中，它往往需要依赖自定义注释和自定义资源定义 (CRD) 来实现所需的操作，这无疑增加了管理难度和维护成本。
传统的 Ingress 控制器提供了基本的 HTTP 路由功能，但在面对更复杂的流量管理需求时，其灵活性和扩展性显得不足。用户不得不通过添加各种自定义注释或引入额外的 CRD 来实现高级功能，如细粒度的流量控制、安全策略、多租户隔离等。这种方式不仅增加了配置的复杂性，还可能导致不同环境下的行为不一致，进而影响系统的稳定性和可维护性。
Kubernetes Gateway API 带来了令人期待的变革。作为一种更现代化的解决方案，Gateway API 提供了一个基于角色的、适应性强的框架，与使用 Kubernetes 服务网络的组织角色保持一致，简化了网络管理和流量控制。Gateway API 不仅保留了 Ingress 的优点，还在多个方面进行了改进和扩展。它提供了更丰富的路由功能，支持多种协议和高级流量管理策略，能够更好地适应复杂的微服务环境和高并发场景。
此外，Gateway API 注重安全性和可扩展性，通过细粒度的策略控制和灵活的配置选项，确保在多租户环境下的资源隔离和安全性。它引入了控制平面和数据平面的分离，允许不同团队基于各自的角色和职责，独立管理和配置流量策略。这不仅提高了系统的可维护性和可扩展性，还增强了团队协作的效率。
Ingress ：轻松实现 Kubernetes 流量路由
在 Kubernetes 中，Ingress 是一个关键的 API 对象，通常被用于管理集群中服务的外部 IP 访问。其主要功能是将外部的 HTTP 和 HTTPS 流量路由到集群内的相应服务，从而提供了一种将外部请求引导至内部应用的简便方式。通过定义一组规则，Ingress 资源控制了这些流量的路由路径，可以实现多种复杂的流量管理需求。
Ingress 资源不仅支持基本的 HTTP 和 HTTPS 路由，还可以配置为提供服务的 SSL/TLS 终止，这意味着它可以处理加密流量并在入口点解除加密，从而减轻后端服务的负担。此功能在保证数据传输安全的同时，提升了系统的整体性能。此外，Ingress 还支持流量负载平衡，通过将外部请求均匀分配到多个后端服务实例上，确保了服务的高可用性和可靠性。它还能提供外部可访问的 URL，使得用户可以通过域名直接访问集群中的服务，简化了对外服务的配置和管理。
基于名称的虚拟托管也是 Ingress 的一大特点。通过配置不同的域名和路径，Ingress 可以将来自同一入口点的流量路由到不同的服务，从而实现同一 IP 地址上的多服务托管。这对运行多个微服务的应用架构尤其有用，可以显著简化外部流量的管理。
Ingress 的功能实现通常依赖于 Ingress 控制器。Ingress 控制器是一种专门的组件，它负责监控 Ingress 资源的变化并相应地配置底层负载均衡器或其他前端设备。虽然负载均衡器是最常见的 Ingress 控制器实现方式，但它也可以配置其他前端设备(例如边缘路由器)来协助管理流量。这种灵活性使得 Ingress 能够适应各种不同的网络拓扑和需求场景。
通过使用 Ingress，用户可以集中管理集群内的服务访问，避免了在每个服务上公开节点 IP 或者为每个服务创建单独的负载均衡器。这不仅简化了配置管理，还降低了资源消耗和运营成本。因此，Ingress 被广泛应用于 Kubernetes 集群中，成为了管理外部流量访问的标准方法。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: devops-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /api
backend:
serviceName: api-service
servicePort: 8080
- path: /web
backend:
serviceName: web-service
servicePort: 80其实，从本质上来讲，起初，Ingress 控制器被引入 Kubernetes 生态系统，以解决集群内外部流量的管理问题。Ingress 提供了一种简洁的方式来定义路由规则，使得外部请求能够正确地到达内部服务。通过配置 Ingress 资源，用户可以实现基于 HTTP 和 HTTPS 的路径路由、负载均衡以及 SSL 终止等功能。Ingress 控制器作为 Kubernetes 集群中的标准组件，被广泛采用。
然而，随着微服务架构的复杂性增加，Ingress 的局限性逐渐显现。其配置方式相对简单，难以满足复杂路由规则和高级流量管理需求。此外，Ingress 缺乏对多租户隔离、细粒度安全策略等功能的支持，这使得在大规模应用场景中显得力不从心。
IngressRoute ：解锁 Kubernetes 流量管理的精细化密钥
Ingress Route 作为 Kubernetes Ingress 的扩展实现，旨在解决标准 Kubernetes Ingress 功能有限的问题，为云原生应用提供更加丰富、灵活和强大的流量管理能力。它由 Kubernetes Ingress 社区独立维护，与众多流行的 Ingress 控制器相兼容，如 Contour、Nginx Ingress Controller、Envoy 等，为用户提供了更广阔的选择空间。
标准 Kubernetes Ingress 的功能相对较为简单，主要基于域名和 URL 路径进行路由转发，缺乏更高级的路由策略和协议支持。而 Ingress Route 在此基础上做了大幅增强，提供了诸多强大的功能特性。
apiVersion: contour.heptio.com/v1
kind: IngressRoute
metadata:
name: devops-ingress-route
spec:
virtualhost:
fqdn: example.com
routes:
- match: /api
services:
- name: api-service
port: 8080
- match: /web
services:
- name: web-service
port: 80通常而言，Ingress Route 主要解决了传统 Ingress 对象在以下几个方面的问题，具体可参考如下所示：
(1) 配置复杂性和灵活性
传统 Ingress 使用标准的 Kubernetes Ingress 对象，配置较为简单，但灵活性有限，尤其是对于复杂的流量管理需求(如多层次的路径路由、基于头信息的路由、加权路由等)。而 Ingress Route 则提供了更细粒度的控制和配置选项，可以定义更复杂的路由规则、流量管理策略等。
(2) TLS管理
传统 Ingress 的 TLS 配置相对简单，支持单一的 TLS 证书管理，无法轻松地为不同域名或路径配置不同的 TLS 策略。而 Ingress Route 则通常支持更丰富的 TLS 配置，可以为不同的路由定义独立的 TLS 证书和策略，从而提高了安全性和管理的灵活性。
(3) 路由规则的表达能力
传统 Ingress 路由规则的表达能力有限，主要基于路径前缀匹配。而 Ingress Route 则支持更复杂的路由规则，例如基于请求头、查询参数、路径等多种条件的路由规则，满足更精细的流量管理需求。
(4) 流量分配和负载均衡
传统 Ingress 的负载均衡策略比较简单，通常是基于轮询等基本策略。而 Ingress Route 支持更复杂的流量分配策略，例如加权轮询、基于请求属性的负载均衡、流量镜像等。
(5) 健康检查和故障转移
传统 Ingress 健康检查和故障转移功能相对简单。Ingress Route 则通常集成了更高级的健康检查和故障转移功能，能够更有效地检测和应对后端服务的故障。
(6) 扩展性和插件支持
传统 Ingress 在扩展性层面支持有限，难以集成自定义的功能或第三方插件。而 Ingress Route 则通常设计为更易于扩展，可以方便地集成各种自定义功能和第三方插件，以满足不同的业务需求。
总的来说，Ingress Route 虽然为云原生应用带来了更加灵活和强大的流量管理能力，但也同时增加了管理和运维的复杂度。因此，在采用 Ingress Route 时，需要全面评估其带来的好处和挑战，并做好相应的准备工作，包括团队技能培养、流程优化等，以确保能够充分发挥其强大功能，并将复杂性控制在可管理的范围内。同时，也需要根据实际需求和团队情况，选择合适的 Ingress 控制器，以尽可能减少不必要的复杂性。只有这样，才能真正释放 Ingress Route 的全部潜力，为云原生应用提供高效、可靠的流量管理服务。
Gateway API ：云原生时代 API 管理新范式
Kubernetes Gateway API 是由 SIG-NETWORK 社区管理的一种规范或标准，旨在统一对 Kubernetes 集群中服务网络的建模和描述方式。它提供了一种灵活且基于角色的接口，让用户可以更好地定义和管理 Kubernetes 服务网络，从而优化服务暴露、流量管理和安全策略等方面的功能。
作为 Kubernetes 生态系统中的一项关键规范，Gateway API 为不同的网络解决方案提供了统一的抽象层和模型语义。这种统一性使得各种网络解决方案能够遵循相同的模型和语义，从而极大提高了跨平台的可移植性和可重用性。用户无需重新学习新的操作界面和流程，只需在不同环境和平台之间无缝切换，即可享受到相同的使用体验。
对于支持 Gateway API 的项目和公司而言，全面遵守该规范具有重要意义。这不仅可以确保它们实现了与规范完全一致的功能和行为，而且还可以获得 Kubernetes 社区的大力支持。Gateway API 由活跃的 Kubernetes 社区集体维护，社区中的贡献者们不遗余力地持续优化和完善这一规范，使其能够与 Kubernetes 生态系统的发展同步演进。因此，支持 Gateway API 的项目和公司可以借助社区的力量，及时获得规范的更新和改进，确保其产品和服务能够随时与最新版本的 Gateway API 保持一致，为用户提供始终如一的优秀体验。
Gateway API 的推出标志着 Kubernetes 服务网络发展的一个新里程碑，为适应现代化复杂部署环境带来了前所未有的功能支持。这项创新性的技术为组织在 Kubernetes 环境中高效管理流量提供了全新的工具，促进了跨部门之间的无缝运营协作，为构建灵活、可扩展的云原生体系架构注入了新的动力。
然而，Gateway API 技术的真正适用性和价值体现，取决于其是否与特定组织的架构模式和运维理念相契合，是否能够成功地在不同的团队和部门之间合理分配工作负荷。Gateway API 的有效性仍有待在实践中经受更多的检验和观察。
毋庸置疑，传统的 Ingress 规范一直以其简单直观的性质而备受青睐，这使得它在处理基本的流量管理场景时游刃有余。但是，当面临复杂的多租户环境、微服务架构、数据平面与控制平面解耦等现代化需求时，Ingress 规范的局限性就暴露无遗了。
与之相比，Gateway API 凭借其增强的安全性、职责分离以及更丰富的功能集，为组织提供了一种全新的选择方案。通过将控制平面和数据平面进行逻辑上的分离，Gateway API 实现了对流量管理职责的合理划分，使得网络管理员和应用开发人员能够各司其职，提高了运维效率。同时，它支持丰富的流量控制策略、安全加固机制以及与服务网格的无缝集成，为组织构建更加健壮、可靠的云原生应用系统奠定了坚实基础。
当然，我们也需要清醒地认识到，Gateway API 作为一种新兴技术，其成熟度和生态建设仍有待时日。许多组织或许会秉持保守策略，继续选择 Ingress 规范，除非 Gateway API 真正展现出其无可替代的优势。但无疑，对于那些追求卓越、渴望构建下一代云原生应用平台的组织而言，Gateway API 值得被重点关注和评估。
因此，总的来说，Gateway API 的出现为 Kubernetes 生态注入了全新的活力，为云原生架构的发展路径提供了更多可能性。作为一种具有变革性意义的技术创新，将如何与组织内部的运维实践、架构模式相互融合、相互影响，如何在云原生领域掀起新的发展浪潮，这一切都将是非常值得期待和关注的。
Reference ：
- [1] https://traefik.io/blog/getting-started-with-kubernetes-gateway-api-and-traefik/
- [2] https://avinetworks.com/glossary/kubernetes-ingress-services/
