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
}

到这里可以看到测试成功了!

原文链接:https://medium.com/%E8%BC%95%E9%AC%86%E5%B0%8F%E5%93%81-pks%E8%88%87k8s%E7%9A%84%E9%BB%9E%E6%BB%B4/k8s-gateway-api-contour%E7%9A%84%E9%80%B2%E5%8C%96%E7%89%88-44476e59135e

给TA打赏
共{{data.count}}人
人已打赏

相关文章

eBPF、sidecars 和服务网格的未来

eBPF、sidecars 和服务网格的未来

eBPF 最近很火热,因为可以为云原生世界提供很多东西。由于 Cilium 之类的项目,它一直是 Kubernetes 集群的 CNI 层的流行选择。Linkerd 等服务网格通常与 Cilium 等 CNI 层一起部署,将 Linkerd 强大的 L7 处理与 Cilium 超快的 L3/4 处理相结合。 但是,eBPF 的网络技术到底有多强大?例如,它能否让我们完全替换 Linkerd 的 sidecars 代理,而只在内核中做所有事情? 在本文中,我将尽我所能评估这种可能性——尤其是当它与对用户的影响有关时。

Kalix:构建无服务器的云原生业务关键型应用程序,无需数据库

Kalix:构建无服务器的云原生业务关键型应用程序,无需数据库

Akka 背后的公司Lightbend最近推出了 Kalix,这是一种新的平台即服务产品,用于使用任何没有数据库的编程语言构建云原生、业务关键型应用程序。Kalix 是一个统一的应用层,它将编写软件所需的部分汇集在一起,并抽象出它们的实现细节。Lighbend 旨在为开发人员提供“创新的 NoOps 开发人员体验”。 Lightbend 的创始人兼首席执行官Jonas Bonér解释了 Kalix 的动机: 云生态系统的复杂性正在减缓工程和开发团队的速度。Kubernetes在管理、编排和确保容器的可用性和可扩展性

英特尔进军比特币挖矿设备市场

英特尔进军比特币挖矿设备市场

本文由半导体产业纵横综合   英特尔总部位于加利福尼亚州圣克拉拉   英特尔公司的新比特币挖矿芯片可能会成为多年来主导市场的中国挖矿设备制造商的第一个主要挑战者。   这家总部位于加利福尼亚州圣克拉拉的芯片制造巨头本月早些时候公布了其加密挖矿计划,并于1月份推出了第一代Bonanza Mine芯片。Jack Dorsey 的数字支付公司Block Inc.以及两家矿业公司Griid Infrastructure 和Argo Blockchain将在今年晚些时候收到第一批芯片。 &nbs

浅谈铁电存储器:如何实现下一代内存计算?

浅谈铁电存储器:如何实现下一代内存计算?

本文由半导体产业纵横编译自technews 因应人工智能、物联网、5G、车载等新兴科技所迎来的巨量资讯分析需求,近年来各国政府及国际知名大厂皆积极地投注大量资源,加速开发兼具提升运算速度以及降低耗能的下世代存储器。而新兴存储器技术选项中,当属铁电存储器最被看好,其原理、技术挑战与未来机会为何?(本文出自中国台湾清华大学工程与系统科学系巫勇贤教授,于闳康科技“科技新航道合作专栏”介绍《铁电存储器的原理、挑战与展望》文稿,经科技新报修编为上下两篇,此篇为上篇。)    Memory-Centric
云原生后端开发

Kubernetes即将移除Dockershim:承诺和下一步

2022-1-15 15:37:52

云原生后端开发

2022 年要考虑的 7 种 Docker 替代方案

2022-2-6 7:54:09

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索