Kubernetes Gateway API 攻略：解锁集群流量服务新维度

Kubernetes Gateway API 刚刚 GA，旨在改进将集群服务暴露给外部的过程。这其中包括一套更标准、更强大的 API资源，用于管理已暴露的服务。在这篇文章中，我将介绍 Gateway API 资源，并以 Istio 为例来展示这些资源是如何关联的。通过这个示例，你将了解 Gateway API 的各个组成部分如何配合以将流量传递到后端服务。

背景

允许外部与 Kubernetes 集群内的服务通信是 administrator 需要执行的最基本任务之一。Service 在 IP 层面上提供的功能十分有限，且缺乏根据应用层数据（如 DNS 主机名或 HTTP 路径）路由流量的能力。因此 Kubernetes 提供了 Ingress API 来实现应用层路由。

然而，Ingress API 有一些限制。Ingress2gateway 的公告[1]清楚地列出了这些限制：

Ingress 侧重于 HTTP 流量，因此用户需要找到其他解决方案来处理 UDP、TCP 或其他协议。
Ingress 资源混合了基础架构和应用程序配置，让细粒度的基于角色的访问控制（RBAC）的实施变得较为困难。

第二点对于已经熟悉 Ingress 的用户来说是最明显的。在平台工程中提供强大的 RBAC 是集群管理的关键步骤。将基础设施组件（负载均衡器、配置等）的权限与流量路由规则的权限分开，能够让权限的边界更加清晰。

接下来我将介绍 Gateway API 如何划分这些资源，以及它们如何最终结合在一起来路由流量。

设置测试环境

本文使用运行 Istio 和一个示例工作负载的测试环境来检查和理解各种 Gateway API 资源。如果你也想上手尝试，可以复制这个环境。

我用的是 K3s，使用 Kubernetes 集群也是类似的操作。如果选择使用 K3s，则在安装时不要启用 Traefik：

$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --disable=traefik" sh -

首先，部署 Gateway API CRD（Custom Resource Definitions），并按照官方文档安装 Istio（ https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/）：

# Install the CRDs

$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \

  { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.8.0" | kubectl apply -f -; }

customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created

customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created

customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created

customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io created



# Install Istio

$ istioctl install --set profile=minimal -y

✔ Istio core installed

✔ Istiod installed

✔ Installation complete

Made this installation the default for injection and validation.

接下来创建一个简单的工作负载，比如一个 Nginx deployment ，并通过 deservice 将其暴露：

# Deployment.yaml

---

apiVersion: apps/v1

kind: Deployment

metadata:

  labels:

    app: nginx

  name: nginx

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: nginx

    spec:

      containers:

      - image: nginx:latest

        name: nginx

# Service.yaml

---

apiVersion: v1

kind: Service

metadata:

  labels:

    app: nginx

  name: nginx

  namespace: default

spec:

  ports:

  - port: 80

    protocol: TCP

    targetPort: 80

  selector:

    app: nginx

  type: ClusterIP

$ kubectl apply -f Deployment.yaml

deployment.apps/nginx created

$ kubectl apply -f Service.yaml

service/nginx created

以上就是你用来理解 Gateway API 所需的全部基础设施。

了解 Gateway API 资源

想要使用 Gateway API，有三种资源类型你需要明确了解：

GatewayClass
Gateway
路由资源，比如 HTTPRoute或GRPCRoute。GA 版本仅包含在 v1 通道中到 HTTPRoute。

这些资源在标准 Ingress API 或自定义提供商负载均衡器和路由工具提供的 CRD 中以各种方式组合在一起。通过将这些资源拆分为单独的组件，Gateway API 实现了关注点分离和强大的、细粒度的访问控制。

让我们逐个了解这些资源，以了解它们之间的关系。

了解 GatewayClass 资源

GatewayClass资源的作用与现有 Ingress API 中的 IngressClass相同，类似于 Storage API 中的 StorageClass。它定义了可以创建的 Gateway类别。通常，此资源由你的基础架构平台（如 EKS 或 GKE）提供。也可以由第三方的 Ingress Controller 提供，例如 Istio 或 Nginx。Istio 包含两个 GatewayClasses：

$ kubectl get gatewayclass

NAME           CONTROLLER                    ACCEPTED   AGE

istio-remote   istio.io/unmanaged-gateway    True       19h

istio          istio.io/gateway-controller   True       19h

spec字段提供了有关实现 GatewayClass功能的 controller 的信息，它定义了整个集群使用的控制器，而 GatewayClasses 是集群范围的资源，适用于所有命名空间。

$ kubectl get gatewayclass istio -o yaml

apiVersion: gateway.networking.k8s.io/v1beta1

kind: GatewayClass

metadata:

  creationTimestamp: "2023-10-30T02:15:11Z"

  generation: 1

  name: istio

  resourceVersion: "636"

  uid: dea0bb44-5f1b-4d23-8f7f-c34f70b4603c

spec:

  controllerName: istio.io/gateway-controller

  description: The default Istio GatewayClass

status:

  conditions:

  - lastTransitionTime: "2023-10-30T02:15:11Z"

    message: Handled by Istio controller

    observedGeneration: 1

    reason: Accepted

    status: "True"

    type: Accepted

GatewayClass还可以指定传递给控制器的参数。这样上游项目能够进一步定制向集群管理员公开的配置。也就是说， GatewayClass允许集群管理员专注于将其流量暴露给外部，而不必担心例如在底层基础设施上如何创建负载均衡器等实现细节。

创建 Gateway

Gateway 代表在基础设施提供商中实例化的负载均衡器服务。它可以是一个实际的云负载均衡器，用于处理流量。也可以代表现有负载均衡器中的虚拟配置。然后通过 GatewayClass 进行抽象。Cluster operator 专注于定义必要的 Gateway 资源，无需担心由 GatewayClass 处理的实现细节。

Gateway 在其规范中引用了一个 GatewayClass。下面的示例使用 istio 类，并定义了一个响应端口 8080 上 *.example.com 的 HTTP 请求的单个侦听器：

# Gateway.yaml

---

apiVersion: gateway.networking.k8s.io/v1beta1

kind: Gateway

metadata:

  name: tutorial-gw

  namespace: default

spec:

  gatewayClassName: istio

  listeners:

  - name: default

    hostname: "*.example.com"

    port: 8080

    protocol: HTTP

    allowedRoutes:

      namespaces:

        from: All

使用 Istio 在创建 Gateway 时还会相应配置Deployment和 Service 来处理流量。GatewayClass 的控制器负责为 Gateway 处理所需的基础设施或配置的设置：

$ kubectl get pods

NAME                                READY   STATUS    RESTARTS        AGE

tutorial-gw-istio-65bfccf7c-45c4w   1/1     Running   2 (6m31s ago)   18h



$ kubectl get service

NAME                TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                          AGE

tutorial-gw-istio   LoadBalancer   10.43.126.90   192.168.122.10   15021:31348/TCP,8080:31728/TCP   18h

这里需要注意的是 Gateway 中没有定义路由规则。Gateways 代表基础设施的配置,这种分离对于实现 RBAC 至关重要。访问控制模型允许 cluster operator 配置可用的Gateways ，让用户在其路由资源中引用，而无需暴露对基础设施配置本身的访问。

创建路由

现有的 Ingress API 仅支持 HTTP 和 HTTPS 服务，这是一个比较大的限制。

而新的 Gateway API 为各种入站流量类型提供通用支持。 HTTPRoute、TCPRoute 、 TLSRoute 、 GRPCRoute 等资源在特定 Gateway 上指定了实际的流量路由。Gateway API 的 GA 版本只在标准的 v1 通道中包含了 HTTPRoute资源，在未来的版本中将会有更多的协议支持。

HTTPRoute资源指定与用于暴露服务的 Gateway 的连接，以及一系列规则来将流量路由到适当的后端。下面的示例将 HTTPRoute附加到 tutorial-gw Gateway，并指定规则将所有流量路由到 nginx Service：

---

apiVersion: gateway.networking.k8s.io/v1beta1

kind: HTTPRoute

metadata:

  name: tutorial-route

  namespace: default

spec:

  parentRefs:

  - group: gateway.networking.k8s.io

    kind: Gateway

    name: tutorial-gw

  rules:

  - backendRefs:

    - group: ""

      kind: Service

      name: nginx

      port: 80

      weight: 1

    matches:

    - path:

        type: PathPrefix

        value: /

$ kubectl apply -f HTTPRoute.yaml

httproute.gateway.networking.k8s.io/tutorial-route created

$ kubectl get httproute

NAME             HOSTNAMES   AGE

tutorial-route

综合以上

Gateway API 将许多传统上包含在单个资源定义中的资源拆分开来。要跟踪所有这些资源之间的连接可能有点困难，这里我将资源之间的关系图展示如下：

Gateway API 资源之间的关系

快速回顾

GatewayClass 定义了可以部署的 Gateway 类型。通常由基础设施提供商提供。在本示例中，Istio 定义了GatewayClass 。
Gateway 是负载均衡基础设施的实例化。这可以是在云环境中部署的实际负载均衡器，也可以是针对现有负载均衡器执行的一些配置。无论哪种方式，通过简单地引用所需的GatewayClass ，就能从 cluster administrator 中抽象出来。
HTTPRoute（或任何其他支持的 Route 资源）定义了处理流量的实际规则。这些路由附加到特定的 Gateway，最终决定了流量的转发。

有了所有这些配置，就可以对服务进行测试请求。本示例Gateway 配置为侦听端口 8080 上 *.example.com 的 HTTP 请求，因此你的请求需要设置适当的 Host header 和端口：

$ curl -H "Host: www.example.com" 192.168.122.10:8080

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

这样，你就使用新的网关 API 成功配置了第一组资源咯！

文章转自微信公众号@马哥Linux运维

Kubernetes Gateway API 攻略：解锁集群流量服务新维度

背景

设置测试环境

了解 Gateway API 资源

了解 GatewayClass 资源

创建 Gateway

创建路由

综合以上

快速回顾

Graphene-Django 深度集成：构建高性能、类型安全的 GraphQL API

根据Swagger OpenAPI规范生成TypeScript类型

Kubernetes Gateway API 攻略：解锁集群流量服务新维度

背 景

设置测试环境

了解 Gateway API 资源

了解 GatewayClass 资源

创建 Gateway

创建路由

综合以上

快速回顾

Graphene-Django 深度集成：构建高性能、类型安全的 GraphQL API

根据Swagger OpenAPI规范生成TypeScript类型

背景