5 分钟了解 Kubernetes Ingress 和 Gateway API

了解 Kubernetes Ingress 和 Gateway API 之间的差异，以实现有效的流量管理。原文: Kubernetes Ingress Vs Gateway API

Ingress vs Gateway API

概述

Kubernetes 如今被广泛应用于容器管理、微服务编排解决方案。对于如何控制微服务的入口流量，Kubernetes 提供了两种选择: Ingress 和 Gateway API。这篇文章将对比 Ingress API 和 Gateway API，比较两者各自的适用场景。

2022 年 5 月份Kubernetes Gateway API才发布了 Beta 版本，当前大多数组织应该还在使用稳定的 Ingress API。

• 为什么需要新的 API 来管理入口流量?

• 新的 Gateway API 解决了 Ingress API 的哪些缺点?

本文将介绍 Ingres API 和 Gateway API 之间的区别和应用。

通过 Ingress 公开服务

Ingress 路由

Kubernetes Ingress 定义了如何将外部流量定向到集群内部的服务。作为负载均衡器，处理来自集群外部的请求，发送给集群内运行的适当服务。定义入口规则的 YAML 文件描述了一组基于主机名或 URL 路径的流量路由指南，基本设置和示例可参考Kubernetes Ingress with NGINX Ingress Controller Example一文。

只有在 K8s 集群中运行 Ingress 控制器，才能使 ingress 资源生效。

Kubernetes 有很多不同的 Ingress 控制器，参考Kubernetes Additional controllers。

本文将以 Nginx ingress 及其ingress控制器为例。

通常在创建 ingress 类的同时创建 ingress。

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: ingress-examplespec:  rules:  - host: sub.example.com    http:      paths:      - path: /auth        pathType: Prefix        backend:          service:            name: http-echo-server            port:              number: 8080      - path: /api        pathType: Prefix        backend:          service:            name: api-svc            port:              number: 9090  ingressClassName: nginx

以上代码是基于路径路由的一个简单的 ingress 示例，/auth请求重定向到http-echo-server服务，而/api请求重定向到api-svc。

根据ingressClassName的值，特定的 ingress 控制器将管理 ingress 对象。

对于 ingress 对象，唯一可配置的字段是 SSL/TLS 密钥，其他配置就只能通过 annotations 实现，比如路径重写、代理消息体和头域。

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: ingress-myservicea-two  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /uat/$2spec:  rules:  - host: sub.example.com    http:      paths:      - path: /auth/api(/|$)(.*)        pathType: Prefix        backend:          service:            name: http-echo-server            port:              number: 8080  ingressClassName: nginx

上面的配置将/auth/api/example/1这样的 URL 路径重写为/uat/example/1。

Nginx ingress 控制器不支持任何 CRD，然而，GCE 的 ingress 提供了各种各样的 CRD，与注释相比，CRD 可以支持灵活的路由配置。

以下是一个 CRD 示例，来自 GCE ingress 的BackendConfig，参考文档Parameters from a BackendConfig CRD。

apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:  name: http-hc-configspec:  healthCheck:    checkIntervalSec: 15    port: 15020    type: HTTPS    requestPath: /healthz

GCE ingress 的ManagedCertificate也是一个 CRD 对象的好例子。

Gateway API

Ingress 提供了某些字段配置，通过 annotations 进行配置也很有挑战性。Ingress API 是管理传入流量的单个对象，但由于它是整个集群共享的单一资源，因此集群开发人员可以访问或修改，而集群/基础设施团队对此却一无所知。

资源 —— GatewayClass、Gateway、HTTPRoute、TCPRoute、Service等，旨在通过表达性的、可扩展的、面向角色的接口来定义Kubernetes服务网络，接口由众多供应商提供实现，并拥有广泛的行业支持。

Gateway API 在 Ingress API 的基础上增加了更多特性，例如 HTTP 头匹配、加权流量分割、多协议支持(如 HTTP、gRpc)以及其他各种后端功能(如桶、函数)。

kind: HTTPRouteapiVersion: networking.x-k8s.io/v1alpha1metadata:  name: bar-route  namespace: bar  labels:    gateway: external-httpsspec:  hostnames:  - "bar.example.com"  rules:  - forwardTo:    - serviceName: bar-v1      port: 8080      weight: 90    - serviceName: bar-v2      port: 8080      weight: 10  - matches:    - headers:        values:          env: canary    forwardTo:    - serviceName: bar-v2      port: 8080

另外，Gateway API 比 Ingress API 更好的分离了关注点。使用 Ingress，集群运维人员和应用开发人员在同一个 Ingress 对象上操作，却不知道彼此的角色，可能会导致设置错误。

Route 和 Gateway 对象是由 Gateway API 独立于配置创建的，从而为集群运维人员和应用开发人员提供了自主权。

Kubernetes Gateway API

如果需要解耦角色，就可以改为使用 Gateway API(仍处于测试阶段)。如果需求比较简单，并且对 Nginx ingress 或任何其他 ingress 控制器感到满意，那么最好坚持用下去，直到需要更多灵活性或支持特定的配置要求。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind