让建站和SEO变得简单

让不懂建站的用户快速建站,让会建站的提高建站效率!

栏目分类
热点资讯

易发购彩官网

你的位置:易发购彩 > 易发购彩官网 > 相遇 Kubernetes Ingress,是时辰拥抱更强大的继任者 Gateway API 了

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

2022-03-13 18:53    点击次数:124

 

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"   } 

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

 



Powered by 易发购彩 @2013-2022 RSS地图 HTML地图

Copyright 365建站 © 2013-2021 365建站器 版权所有