5分钟了解Kubernetes Ingress和Gateway API

2024年 1月 4日 58.8k 0

了解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/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是管理传入流量的单个对象,但由于它是整个集群共享的单一资源,因此集群开发人员可以访问或修改,而集群/基础设施团队对此却一无所知。

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

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

Kubernetes Gateway API

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

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

本文由mdnice多平台发布

相关文章

KubeSphere 部署向量数据库 Milvus 实战指南
探索 Kubernetes 持久化存储之 Longhorn 初窥门径
征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
那些年在 Terraform 上吃到的糖和踩过的坑
无需 Kubernetes 测试 Kubernetes 网络实现
Kubernetes v1.31 中的移除和主要变更

发布评论