
概述
kubernetes如今被广泛应用于容器管理、微服务编排解决方案。对于如何控制微服务的入口流量,kubernetes提供了两种选择: ingress和gateway api。这篇文章将对比ingress api和gateway api,比较两者各自的适用场景。
2022年5月份kubernetes gateway api[1]才发布了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控制器[2]为例。
通常在创建ingress类的同时创建ingress。
apiversion: networking.k8s.io/v1
kind: ingress
metadata:
name: ingress-example
spec:
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/v1
kind: ingress
metadata:
name: ingress-myservicea-two
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /uat/$2
spec:
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/v1
kind: backendconfig
metadata:
name: http-hc-config
spec:
healthcheck:
checkintervalsec: 15
port: 15020
type: https
requestpath: /healthz
gce ingress的managedcertificate也是一个crd对象的好例子。
gateway api
ingress提供了某些字段配置,通过annotations进行配置也很有挑战性。ingress api是管理传入流量的单个对象,但由于它是整个集群共享的单一资源,因此集群开发人员可以访问或修改,而集群/基础设施团队对此却一无所知。
gateway api在ingress api的基础上增加了更多特性,例如http头匹配、加权流量分割、多协议支持(如http、grpc)以及其他各种后端功能(如桶、函数)。
kind: httproute
apiversion: networking.x-k8s.io/v1alpha1
metadata:
name: bar-route
namespace: bar
labels:
gateway: external-https
spec:
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控制器感到满意,那么最好坚持用下去,直到需要更多灵活性或支持特定的配置要求。
参考资料
gateway api graduates to beta: https://kubernetes.io/blog/2022/07/13/gateway-api-graduates-to-beta
[2]nginx ingress controller: https://www.nginx.com/products/nginx-ingress-controller
[3]gateway api: https://gateway-api.sigs.k8s.io
本文由 mdnice 多平台发布
发表评论