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，巨大黑人极品videos精品是以咱们需要开一台 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"   } 

到这里不错看到测试奏效了！