相遇 Kubernetes Ingress，是时辰拥抱更强大的继任者 Gateway API 了

 

Gateway API（之前叫 Service API）是由 SIG-NETWORK 社区解决的开源样式，样式地址：https://gateway-api.sigs.k8s.io/。

主要原因是 Ingress 资源对象不行很好的知足采集需求，许多场景下 Ingress 收尾器都需要通过界说 annotations 大略 crd 来进行功能延迟，这关于使用轨范和维持厉害常不利的，新推出的 Gateway API 旨在通过可延迟的面向扮装的接口来增强管事采集。

Gateway API 是 Kubernetes 中的一个 API 资源会聚，包括 GatewayClass、Gateway、HTTPRoute、TCPRoute、Service 等，这些资源共同为多样采集用例构建模子。

Gateway API的价值与定位  提供跨Namespace的一种Ingress机制：让多个跨Namespace的管事，不错分享一个L7 LoadBalancer  可竣事多佃户的一种Ingress机制：提供HttpRoute与Gateway分离的详尽组件，让贪图路由(HttpRoute)的人，不错分享一个L7 LoadBalancer，  蓝绿部署金丝雀部署时为使用团结个定名空间下的部署，不错浅陋的界说在HttpRoute中  基于Hostname、Header、或Subpath的管事，使用AB测试等等。 Gateway API 先容

网关API主要分为以下几个扮装：

 GatewayClass（由Cloud或K8s提供者提供），  Gateway(由网管平台公司自建GatewayClass)，  HTTPRoute（由开辟者团队管事部署者选择对应的网关对接）

现时 GKE 提供了四种网关类，离别是：

 gke-l7-rilb培植在里面 HTTP(S) 负载平衡上的区域里面 HTTP(S) 负载平衡器(单猬集Internal LoadBalancer)  gke-l7-gxlb培植在外部 HTTP(S) 负载平衡之上的群众外部 HTTP(S) 负载平衡器(单猬集External LoadBalancer)  gke-l7-rilb-mc基于Internal HTTP(S) Load Balancing的多集群区域负载平衡器(多猬集Internal LoadBalancer)  gke-l7-gxlb-mc基于External HTTP(S) Load Balancing的多集群全局负载平衡器(多猬集External LoadBalancer) 网关部署

现时GKE的Gateway APIK8S 1.20以上的版块，要是使用GKE发布频道需要捧油，现时需要使用RAPID区域，同期仅在以下提供公开Beta测试：

 us-west1  us-east1  us-central1  europe-west4  europe-west3  europe-west2  europe-west1  asia-southeast1

底下的测试，咱们选择先测试Interal-LoadBalancer并尝试底下的拓扑图：

部署独到 GKE

咱们先开辟一个私人GKE集群，不错参照我提供的Terraform剧本，请径直将shawn.tfvars改为恰当你集群的参数，另外，由于我使用远端GCS也请诞生保存 tfstate，修改config.tf里面的bucket称呼。其他每每诞生和独到GKE访佛，只需要使用里面LB而加多了一个proxy-only的子网给Envoy使用。

部署网关

笔据上述的第三个阶段，咱们先部署Gateway API的CRD档案： 

kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.3.0" \  | kubectl apply -f -  # 部署得胜後，可使用下方号召檢視單叢集internal/external GatewayClass  private-gke-tf % kubectl get gatewayclass  NAME          CONTROLLER                  AGE  gke-l7-gxlb   networking.gke.io/gateway   23h  gke-l7-rilb   networking.gke.io/gateway   23h 

下一步咱们准备部署网关，使用 kubectl apply -f 部署底下YAML： 

kind: Gateway  apiVersion: networking.x-k8s.io/v1alpha1  metadata:    name: internal-http  spec:    gatewayClassName: gke-l7-rilb    listeners:    - protocol: HTTP      port: 80      routes:        kind: HTTPRoute        selector:          matchLabels:            gateway: internal-http        namespaces:          from: "All" 

因为Gateway不错接收三个有关模式，基于 kind，selector，以及namespace。

 kind：以下可选任一种Route: HTTPRoute, TCPRoute, or customRoute  标签：通过选择或选择对应的标签  namespaces：蚁合 namespaces.from 选择Route场地的namespace，预设是跟Gateway在团结个namespace的Route

因为咱们想创建一个跨定名空间的分享网关，是以咱们将 namespaces.from 改成 All。

部署得胜后，不错通过以下号召来检察： 

private-gke-tf % kubectl describe gateway internal-http  Events:    Type    Reason  Age                    From                   Message    ----    ------  ----                   ----                   -------    Normal  SYNC    4m59s (x396 over 23h)  sc-gateway-controller  SYNC on default/internal-http was a success 

部署管事+HTTPRoute

接下来咱们快速部署测试的两个管事，其中 store 管事部署在默许定名空间，site 管事部署在 site 定名空间。部署对应的 HTTPRoute，其中 http-route.yaml 适用于 store 管事的： 

kind: HTTPRoute  apiVersion: networking.x-k8s.io/v1alpha1  metadata:    name: store    labels:      gateway: internal-http  spec:    hostnames:    - "store.example.com"    rules:    - forwardTo:      - serviceName: store-v1        port: 8080        weight: 50      - serviceName: store-v2        port: 8080       weight: 50    - matches:      - headers:          type: Exact          values:            env: canary      forwardTo:      - serviceName: store-v2        port: 8080    - matches:      - path:          type: Prefix          value: /de      forwardTo:      - serviceName: store-german        port: 8080 

咱们针对 store 管事，挑升开辟了三个不同的后端管事，一次来测试HTTPRoute的不同智商

 (1)主机名匹配：通过不同的主机名（如store.example.com or site.example.com）将用户迷惑路由到指定的后台管事  (2.1) header match: 要是央求 header 中包含 env: canary 这么的信息，就会被路由到 store-v2 管事  (2.2)前缀匹配：若央求旅途前缀是 /de，则会被路由到 store-german 管事  (3)默许路由：笔据权重，自动平衡到指定的 store-v1 与 store-v2 的两个后台管事

而 http-service.yaml 是用于设置管事的，由于 HTTPRoute 与 Gateway 场地的定名空间不同，因此必须引入一个 gatewayRefs 参数： 

kind: HTTPRoute  apiVersion: networking.x-k8s.io/v1alpha1  metadata:    name: site    namespace: site    labels:      gateway: internal-http  spec:    gateways:      allow: FromList      gatewayRefs:      - name: internal-http        namespace: default    hostnames:    - "site.example.com"    rules:    - forwardTo:      - serviceName: site-v1        port: 8080 

由于咱们使用的是 Internal LoadBalancer，是以咱们需要开一台 GCE VM 来进行测试，由于咱们使用的是 private cluster，是以要难忘 GCE VM 和 private GKE cluster 在团结个 VPC 中。

在 K8S client上，赢得 Internal LoadBalancer 的IP地址： 

kubectl get gateway internal-http -o jsonpath='{.status.addresses[0].value}'  10.81.68.140 

在 GCE VM 上，咱们来测试上头咱们界说的 HttpRoute：

(1) 按照 Hostname 来路由管事：通过界说 hostname 为 site.example.com 来路由到另一个 namespace 的K8S管事中: 

shawnho@jumper2:~$ curl -H "host: site.example.com" 10.81.68.140  {    "cluster_name": "pgke-1",    "host_header": "site.example.com",    "metadata": "site-v1",    "node_name": "gke-pgke-1-cluster-runtime-425beb23-vx9j.c.shawn-demo-2021.internal",    "pod_name": "site-v1-86dc4b4fbc-4g6jr",    "pod_name_emoji": "🌾",    "project_id": "shawn-demo-2021",    "timestamp": "2021-07-18T15:26:15",    "zone": "asia-southeast1-a"  } 

(2) 基于Hostname: “store.example.com”，再分別测试 (2.1) Header 与 (2.2) Prefix 前缀机制： 

# 测试header match  shawnho@jumper2:~$ curl -H "host: store.example.com" -H "env: canary" 10.81.68.140  {    "cluster_name": "pgke-1",    "host_header": "store.example.com",    "metadata": "store-v2",    "node_name": "gke-pgke-1-cluster-runtime-425beb23-vx9j.c.shawn-demo-2021.internal",    "pod_name": "store-v2-6856f59f7f-49fv8",    "pod_name_emoji": "🎹",    "project_id": "shawn-demo-2021",    "timestamp": "2021-07-18T15:33:04",    "zone": "asia-southeast1-a"  } # 测试prefix match  shawnho@jumper2:~$ curl -H "host: store.example.com" 10.81.68.140/de  {    "cluster_name": "pgke-1",    "host_header": "store.example.com",    "metadata": "Gutentag!",    "node_name": "gke-pgke-1-cluster-runtime-425beb23-vx9j.c.shawn-demo-2021.internal",    "pod_name": "store-german-66dcb75977-ttngz",    "pod_name_emoji": "💇🏼‍♀",    "project_id": "shawn-demo-2021",    "timestamp": "2021-07-18T15:32:15",    "zone": "asia-southeast1-a"  } 

(3) 通过基于 Host: store.example.com 下的 Default Route 按权重（1:1）路由管事： 

# 测试default route   shawnho@jumper2:~$ curl -H "host: store.example.com" 10.81.68.140   {     "cluster_name": "pgke-1",   "host_header": "store.example.com",     "metadata ": "store-v1",     "node_name": "gke-pgke-1-cluster-runtime-425beb23-vx9j.c.shawn-demo-2021.internal",     "pod_name": "store-v1-65b47557df-rv65j ",     "pod_name_emoji": "🧘🏿‍♂️",     "project_id": "shawn-demo-2021",     "timestamp": "2021-07-18T15:32:09",     "zone": "asia-southeast1-a”   }  shawnho@jumper2:~$ curl -H "host: store.example.com" 10.81.68.140   {     "cluster_name": "pgke-2",     "host_header": "store.example.com",     "metadata": "store -v2",     "node_name": "gke-pgke-2-cluster-runtime-e7f1b4b7-wg5a.c.shawn-demo-2021.internal",    "pod_name": "store-v2-6856f59f7f-gkkct",     "pod_name_emoji ": "👈🏼",     "project_id": "shawn-demo-2021",     "timestamp": "2021-07-18T15:32:29",    "zone": "asia-southeast1-a"   } 

到这里不错看到测试得胜了！