理解Kubernetes Ingress和Gateway API之间的差别，以实现无效的流量治理。原文: Kubernetes 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公开服务

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独立于配置创立的，从而为集群运维人员和利用开发人员提供了自主权。

如果须要解耦角色，就能够改为应用Gateway API(仍处于测试阶段)。如果需要比较简单，并且对Nginx ingress或任何其余ingress控制器感到称心，那么最好保持用上来，直到须要更多灵活性或反对特定的配置要求。

你好，我是俞凡，在Motorola做过研发，当初在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。微信公众号：DeepNoMind

本文由mdnice多平台公布