关于程序员:5分钟了解Kubernetes-Ingress和Gateway-API

理解 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/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 是治理传入流量的单个对象，但因为它是整个集群共享的繁多资源，因而集群开发人员能够拜访或批改，而集群 / 基础设施团队对此却无所不知。

资源 —— GatewayClass、Gateway、HTTPRoute、TCPRoute、Service等，旨在通过表白性的、可扩大的、面向角色的接口来定义 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 独立于配置创立的，从而为集群运维人员和利用开发人员提供了自主权。

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

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

本文由 mdnice 多平台公布