$ 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,有三種資源類型你需要明確了解:

這些資源在標準 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 為各種入站流量類型提供通用支持。 HTTPRouteTCPRoute 、 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 資源之間的關系

快速回顧

有了所有這些配置,就可以對服務進行測試請求。本示例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運維

上一篇:

Graphene-Django 深度集成:構建高性能、類型安全的 GraphQL API

下一篇:

根據Swagger OpenAPI規范生成TypeScript類型
#你可能也喜歡這些API文章!

我們有何不同?

API服務商零注冊

多API并行試用

數據驅動選型,提升決策效率

查看全部API→
??

熱門場景實測,選對API

#AI文本生成大模型API

對比大模型API的內容創意新穎性、情感共鳴力、商業轉化潛力

25個渠道
一鍵對比試用API 限時免費

#AI深度推理大模型API

對比大模型API的邏輯推理準確性、分析深度、可視化建議合理性

10個渠道
一鍵對比試用API 限時免費