Kubernetes Gateway API攻略教程

Kubernetes Gateway API 剛剛 GA，旨在改進將集群服務暴露給外部的過程。這其中包括一套更標準、更強大的 API資源，用于管理已暴露的服務。在這篇文章中，我將介紹 Gateway API 資源，并以 Istio 為例來展示這些資源是如何關(guān)聯(lián)的。通過這個示例，你將了解 Gateway API 的各個組成部分如何配合以將流量傳遞到后端服務。

背 景

允許外部與 Kubernetes 集群內(nèi)的服務通信是 administrator 需要執(zhí)行的最基本任務之一。Service 在 IP 層面上提供的功能十分有限，且缺乏根據(jù)應用層數(shù)據(jù)（如 DNS 主機名或 HTTP 路徑）路由流量的能力。因此 Kubernetes 提供了 Ingress API 來實現(xiàn)應用層路由。

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

Ingress 側(cè)重于 HTTP 流量，因此用戶需要找到其他解決方案來處理 UDP、TCP 或其他協(xié)議。

Ingress 資源混合了基礎架構(gòu)和應用程序配置，讓細粒度的基于角色的訪問控制（RBAC）的實施變得較為困難。

第二點對于已經(jīng)熟悉 Ingress 的用戶來說是最明顯的。在平臺工程中提供強大的 RBAC 是集群管理的關(guān)鍵步驟。將基礎設施組件（負載均衡器、配置等）的權(quán)限與流量路由規(guī)則的權(quán)限分開，能夠讓權(quán)限的邊界更加清晰。

接下來我將介紹 Gateway API 如何劃分這些資源，以及它們?nèi)绾巫罱K結(jié)合在一起來路由流量。

設置測試環(huán)境

本文使用運行 Istio 和一個示例工作負載的測試環(huán)境來檢查和理解各種 Gateway API 資源。如果你也想上手嘗試，可以復制這個環(huán)境。

我用的是 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.

接下來創(chuàng)建一個簡單的工作負載，比如一個 Nginxdeployment，并通過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 實現(xiàn)了關(guān)注點分離和強大的、細粒度的訪問控制。

讓我們逐個了解這些資源，以了解它們之間的關(guān)系。

了解 GatewayClass 資源

GatewayClass資源的作用與現(xiàn)有 Ingress API 中的IngressClass相同，類似于 Storage API 中的StorageClass。它定義了可以創(chuàng)建的Gateway類別。通常，此資源由你的基礎架構(gòu)平臺（如 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字段提供了有關(guān)實現(xiàn)GatewayClass功能的 controller 的信息，它定義了整個集群使用的控制器，而GatewayClasses是集群范圍的資源，適用于所有命名空間。

$ kubectl get gatewayclass istio -o yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  creationTimestamp: "2023-10-30T0211Z"
  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-30T0211Z"
    message: Handled by Istio controller
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted

GatewayClass還可以指定傳遞給控制器的參數(shù)。這樣上游項目能夠進一步定制向集群管理員公開的配置。也就是說，GatewayClass允許集群管理員專注于將其流量暴露給外部，而不必擔心例如在底層基礎設施上如何創(chuàng)建負載均衡器等實現(xiàn)細節(jié)。

創(chuàng)建 Gateway

Gateway代表在基礎設施提供商中實例化的負載均衡器服務。它可以是一個實際的云負載均衡器，用于處理流量。也可以代表現(xiàn)有負載均衡器中的虛擬配置。然后通過GatewayClass進行抽象。Cluster operator 專注于定義必要的Gateway資源，無需擔心由GatewayClass處理的實現(xiàn)細節(jié)。

Gateway在其規(guī)范中引用了一個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 在創(chuàng)建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中沒有定義路由規(guī)則。Gateways代表基礎設施的配置,這種分離對于實現(xiàn) RBAC 至關(guān)重要。訪問控制模型允許 cluster operator 配置可用的Gateways，讓用戶在其路由資源中引用，而無需暴露對基礎設施配置本身的訪問。

創(chuàng)建路由

現(xiàn)有的 Ingress API 僅支持 HTTP 和 HTTPS 服務，這是一個比較大的限制。

而新的 Gateway API 為各種入站流量類型提供通用支持。HTTPRoute、TCPRoute、TLSRoute、GRPCRoute等資源在特定Gateway上指定了實際的流量路由。Gateway API 的 GA 版本只在標準的 v1 通道中包含了HTTPRoute資源，在未來的版本中將會有更多的協(xié)議支持。

HTTPRoute資源指定與用于暴露服務的 Gateway 的連接，以及一系列規(guī)則來將流量路由到適當?shù)暮蠖?。下面的示例將HTTPRoute附加到tutorial-gwGateway，并指定規(guī)則將所有流量路由到nginxService：

---
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               6s

綜合以上

Gateway API 將許多傳統(tǒng)上包含在單個資源定義中的資源拆分開來。要跟蹤所有這些資源之間的連接可能有點困難，這里我將資源之間的關(guān)系圖展示如下：

Gateway API 資源之間的關(guān)系

快速回顧

GatewayClass定義了可以部署的 Gateway 類型。通常由基礎設施提供商提供。在本示例中，Istio 定義了GatewayClass。

Gateway是負載均衡基礎設施的實例化。這可以是在云環(huán)境中部署的實際負載均衡器，也可以是針對現(xiàn)有負載均衡器執(zhí)行的一些配置。無論哪種方式，通過簡單地引用所需的GatewayClass，就能從 cluster administrator 中抽象出來。

HTTPRoute（或任何其他支持的 Route 資源）定義了處理流量的實際規(guī)則。這些路由附加到特定的 Gateway，最終決定了流量的轉(zhuǎn)發(fā)。

有了所有這些配置，就可以對服務進行測試請求。本示例Gateway配置為偵聽端口 8080 上*.example.com的 HTTP 請求，因此你的請求需要設置適當?shù)?Host header 和端口：

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

這樣，你就使用新的網(wǎng)關(guān) API 成功配置了第一組資源咯！