关于kubernetes:Kubernetes-Gateway-API-深入解读和落地指南

5次阅读

共计 8333 个字符，预计需要花费 21 分钟才能阅读完成。

Kubernetes Gateway API 是 Kubernetes 1.18 版本引入的一种新的 API 标准，是 Kubernetes 官网正在开发的新的 API，Ingress 是 Kubernetes 已有的 API。Gateway API 会成为 Ingress 的下一代代替计划。Gateway API 提供更丰盛的性能, 反对 TCP、UDP、TLS 等, 不仅仅是 HTTP。Ingress 次要面向 HTTP 流量。Gateway API 具备更强的扩展性, 通过 CRD 能够轻易新增特定的 Gateway 类型, 比方 AWS Gateway 等。Ingress 的扩大绝对较难。Gateway API 反对更细粒度的流量路由规定, 能够准确到服务级别。Ingress 的最小路由单元是门路。

Gateway API 的意义和价值:

作为 Kubernetes 官网我的项目,Gateway API 可能更好地与 Kubernetes 自身集成, 有更强的可靠性和稳定性。
反对更丰盛的流量协定, 实用于服务网格等更简单的场景, 不仅限于 HTTP。能够作为 Kubernetes 的流量入口 API 进行对立。
具备更好的扩展性, 通过 CRD 能够轻松地反对各种 Gateway 的自定义类型, 更灵便。
能够实现细粒度的流量管制, 准确到服务级别的路由, 提供更弱小的流量治理能力。

综上，Gateway API 作为新一代的 Kubernetes 入口 API，有更宽泛的利用场景、更弱小的性能、以及更好的可靠性和扩展性。对于生产级的 Kubernetes 环境,Gateway API 是一个更好的抉择。本篇文章将深刻解读 Kubernetes Gateway API 的概念、个性和用法，帮忙读者深刻了解并理论利用 Kubernetes Gateway API，施展其在 Kubernetes 网络流量治理中的劣势。

Gateway API 目前还处于开发阶段，尚未公布正式版本。其版本倒退现状如下:

v1beta1: 以后的次要迭代版本，Gateway API 进入了 beta 版本，这意味着咱们能够在生产中应用 Gateway API 能力了，目前 beta 版本仅反对 HTTP 协定，TCP 协定、UDP 协定、gRPC 协定、TLS 协定均为 alpha 版本。
v1.0: 首个正式 GA 版本,API 稳固, 能够用于生产环境。但性能还会继续欠缺。

上面简略整顿了一下 HTTPRoute 的一些可用场景：

多版本部署：如果您的应用程序有多个版本，您能够应用 HTTPRoute 来将流量路由到不同的版本，以便测试和逐渐降级。例如，您能够将一部分流量路由到新版本进行测试，同时放弃旧版本的运行。
A/B 测试：HTTPRoute 能够通过权重调配来实现 A/B 测试。您能够将流量路由到不同的后端服务，并为每个服务指定一个权重，以便测试不同版本的性能和性能。
动静路由：HTTPRoute 反对基于门路、申请头、申请参数和申请体等条件的动静路由。这使得您能够依据申请的不同属性将流量路由到不同的后端服务，以满足不同的需要。
重定向：HTTPRoute 反对重定向，您能够将某些申请重定向到另一个 URL 上，例如将旧的 URL 重定向到新的 URL。

目前，只管 Gateway API 还处于开发阶段, 但曾经有局部我的项目示意反对或打算反对 Gateway API。次要包含:

Istio 是最风行的服务网格我的项目之一，Istio 1.9 版本打算引入实验性的 Gateway API 反对。用户能够通过 Gateway 和 HTTPRoute 资源来配置 Istio 的 Envoy 代理。
Linkerd 是另一个风行的服务网格我的项目，Linkerd 2.10 版本增加了 Gateway API 反对。用户能够应用 Gateway API 资源来配置 Linkerd 的代理。
Contour 是一个 Kubernetes Ingress Controller，Contour 1.14.0 版本增加 Gateway API 反对，能够应用 Gateway 和 HTTPRoute 来配置 Contour。
Flagger 是一款 Kubernetes 的蓝绿部署和 A/B 测试工具，Flagger 0.25 版本增加了对 Gateway API 的反对，能够应用 Gateway 和 HTTPRoute 构建 Flagger 的流量路由。
HAProxy Ingress Controller 反对 Gateway API，能够应用 Gateway 和 HTTPRoute 构建 HAProxy 的配置。
Traefik 是驰名的开源边缘路由器，Traefik 2.5 版本开始反对 Gateway API 并逐渐淘汰 Ingress 反对。

除此之外，Apisix、Envoy gateway、Higress 等开源我的项目也反对或打算反对 Gateway API，各大云服务商都在踊跃跟进 Gateway API 停顿，预计将来会在相应的服务中提供 Gateway API 反对。能够看出，只管 Gateway API 还不算成熟和稳固，但因为其弱小的性能和作为 Kubernetes 官网我的项目的影响力，曾经取得大量我的项目的反对和兼容。服务网格、API 网关以及各大云服务商都将是 Gateway API 的重点生态。

欠缺性能和稳定性：持续欠缺 Gateway API 的性能和稳定性，以确保其可能应答不同场景的需要。
治理规模：针对大规模 Kubernetes 集群的需要，优化 Gateway API 的性能和扩展性，使其可能治理更多的网关和路由规定。
加强安全性：增强 Gateway API 的安全性，包含在传输过程中的加密、身份验证等方面，以确保网络流量的安全性。
欠缺文档和社区反对：欠缺 Gateway API 的文档和社区反对，以帮忙用户更好地应用和理解该我的项目。

Kubernetes Gateway API 定义了三种根本资源类型：GatewayClass、Gateway、Route。

Gatewayclass: 一组共享通用配置和行为的 Gateway 汇合，与 IngressClass、StorageClass 相似，须要晓得 Gateway API 并不会创立真正的网关，真正的网关是由一些反对 Gateway API 的社区（根底设施提供商）所提供的 Controller 所创立，如 Envoy、Istio、Nginx。GatewayClass，Gatewayclass 的作用就是绑定一个 Controller 定义一种网关类型。
Gateway: 能够说成 GatewayClass 的具体实现，申明后由 GatewayClass 的根底设施提供商提供一个具体存在的 Pod，充当了进入 Kubernetes 集群的流量的入口，负责流量接入以及往后转发，同时还能够起到一个初步过滤的成果。
Route: 实在的路由，定义了特定协定的规定，用于将申请从 Gateway 映射到 Kubernetes 服务。目前只有 HTTPRoute 进入了 v1beta 版本，是比较稳定的版本，后续 TCPRoute、UDPRoute、GRPCRoute、TLSRoute 等也会陆续进入 beta 版本达到生产可用，这里将只对 HTTPRoute 进行介绍。

对于他们三者之间的关系，官网文档也给了一幅十分清晰的结构图，如下图所示，在我看来，图片次要强调了面向角色的特点，官网想表白意思是 GatewayClass 由基础设施供应商提供，Gateway 资源由集群工程师创立，根本环境搭建实现后，开发者便能够轻松创立 HTTPRoute 将本人的业务代理进去。

通过部署 GatewayClass 绑定上游实现提供的 Controller，为集群提供一种网关能力，这里能够看作是一种注册申明吧，将你的上游实现注册到集群中供 Gateway 绑定应用。Controller 能够看作监听 Gateway 资源的 Operator。

spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller #绑定的 Controller 名称

Gateway 资源是一个中间层，须要定义所要监听的端口、协定、TLS 配置等信息，能够将网络流量的治理和管制集中到一个中心化的地位，进步集群的可用性和安全性。配置实现后，由 GatewayClass 绑定的 Controller 为咱们提供一个具体存在 Pod 作为流量入口，须要留神的是，各家实现在此处还是略有不同，比如说 Envoy 当你创立 Gateway 资源后，Envoy Controller 会创立一个 Deployment 资源为你提供入口流量 Pod，然而 Nginx 则是本人自身就是流量入口 Pod 不会创立新的。

spec:
  gatewayClassName: envoy #绑定的 GatewayClass 名称。listeners: # 定义了一些监听项，供 Route 进行绑定
  - allowedRoutes: #定义流量转发范畴
      namespaces:
        from: All #容许 Gateway 往所有的 Namespace 的 Pod 转发流量。name: http #监听项名称。port: 8088 #监听项所占用的端口
    hostname：www.gateway.*.com #定义一个域名，个别为泛域名、匹配来自该域名的流量。protocol: HTTP #定义协定，HTTP 或者 HTTPS 
  - allowedRoutes:
      namespaces:
        from: All
    name: https
    port: 8443
    protocol: HTTPS
    tls:  #为 HTTPS 配置加密协议
      mode: Terminate #加密协议类型，Terminate 或 Passthrough
      certificateRefs:
      - kind: Secret
        name: cafe-secret
        namespace: default

协定类型：

Terminate：将加密的流量解密并将明文流量转发到后端服务。这种模式须要在网关处配置证书和密钥，以便对客户端和服务器之间的流量进行加密和解密，确保数据安全性。
Passthrough：将加密的流量原样转发到后端服务。这种模式不须要在网关处配置证书和密钥，因为 TLS 连贯只在后端服务处终止。这种模式实用于须要将 TLS 流量间接传递到后端服务的场景，如须要对后端服务进行更细粒度的访问控制或流量监控的状况。

HTTPRoute 便跟你的业务密切相关了，在这里定义具体的规定，将流量代理到对应的业务服务上。

#HTTPRoute A
spec:
  parentRefs: #绑定 Gateway 监听项
  - name: gateway #Gateway 资源名称
    namespace: envoy #Gateway 所在命名空间
    sectionName: http #监听项名称
  hostnames:  #为路由配置域名
  - "www.gateway.example.com" #可配置泛域名, 可配置多个
  rules: #配置具体的路由规定，可配置多个，上面有对各种规定类型的具体解析
  - matches: #匹配条件
    - path:  #门路匹配
        type: PathPrefix #门路类型：Exact 齐全匹配 /PathPrefix 前缀匹配 /RegularExpression 正则匹配
        value: /gateway 
    filters: #高级设置
    - type: requestHeaderModifier #加工申请头
      requestHeaderModifier: #反对 set 笼罩 /add 增加 /remove 删除
        set:
        - name: service
          value: goodrain
    - type: RequestRedirect #申请重定向
      requestRedirect: 
        scheme: https # 重定向所应用的协定，http/https
        hostname: www.baidu.com #重定向的域名
        port: 8443 #重定向所应用的端口
        statusCode: 301 #重定向状态码：301 永恒的重定向 /302 长期重定向
-----------------
#HTTPRoute B
spec:
  parentRefs: 
  - name: gateway 
    namespace: envoy 
    sectionName: https
  hostnames:  
  - "www.gateway.example.com" 
  rules: 
  - matches: 
    - headers: #申请头匹配
      - name: service 
        value: goodrain
    backendRefs: #后端路由
    - name: goodrain-v1 # service 名称
      port: 80 #service 端口
      weight: 80 #权重
    - name: goodrain-v2
      port: 80
      weight: 20

规定类型：

matches: 由一个或多个匹配条件组成，这些匹配条件能够基于 HTTP 申请的各种属性（如申请办法、门路、头部、查问参数等）进行匹配，从而确定哪些申请应该被路由到该规定对应的后端服务。
filters: 对传入申请进行更细粒度的管制，例如批改申请的头部、转发申请到其余服务、将申请重定向到不同的 URL 等。它们由一组规定组成，每个规定都蕴含一个或多个过滤器。这些过滤器能够在申请被路由到后端服务之前或之后进行解决，以实现各种不同的性能。
backendRefs: 用来指定后端服务的援用，它蕴含一个后端服务的列表，每个服务由名称和端口号组成，能够应用不同的负载平衡算法，将申请路由到后端服务的其中一个实例中，实现负载平衡。

深刻理解当前，咱们能够看进去 HTTPRoute 的用法十分的灵便，能够通过将不同的规定组合搭配，来创立一条适宜咱们业务的路由，就拿下面的 yaml 为例，整体流量走向如下图所示，当 http 协定的申请流量进入后，依照规定匹配，流量会向下转发到 HTTPRoute A 的路由上，HTTPRoute A 依照规定程序，先对申请进行加工解决增加申请头，之后将申请重定向到 HTTPRoute B 上，再由 HTTPRoute 将流量依照权重比例路由到对应的后端服务。

须要留神的是，规定集有优先级，当同时存在多个规定（rule）的时候，流量会从上往下进行匹配，只有有匹配上流量会间接代理到其对应的后端或重定向到对应的路由。

整顿一下部署思路，如果在业务中应用 Gateway API 咱们都须要做什么。

Kubernetes Gateway API 根底 CRD。装置网关 API CRD 地址。
Gateway API 上游实现，即根底设施供应商。（蕴含 GatewayClass 资源）上游实现地址。
创立 Gateway，定义根底的路由形式供 HTTPRoute 抉择。依据下面的字段解释自行编写。
创立 HTTPRoute 设置规定绑定本人的业务。依据下面的字段解释自行编写。

上面以 Envoy 提供的 demo 为例，串一下整体流程

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.3.0/install.yaml

查看装置成果

# 查看装置的 CRD 资源
kubectl get crd |grep networking.k8s.io

# 查看装置的 envoy controller
kubectl get pod -n envoy-gateway-system

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.3.0/quickstart.yaml

资源的 controllerName 属性字段配置绑定了 envoy 的 controller

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

资源的 gatewayClassName 属性字段配置绑定了 gatewayclass 资源名称 eg，同时提供了一个对内监听端口为 80，协定类型为 http 的监听项。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: eg
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80

资源的 parentRefs 属性字段配置绑定了 gateway 资源名称 eg。域名为 www.example.com，代理的后端服务类型抉择了 service，名称为 backend，服务端口为 3000。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: backend
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - group: ""
          kind: Service
          name: backend
          port: 3000
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /

查看装置成果

# 查看装置的 gatewayclass 资源
kubectl get gatewayclass

# 查看装置的 gateway 资源
kubectl get gateway

# 查看装置的 httproute 资源
kubectl get httproute

#查看由 Controller 提供的流量入口 Pod。kubectl get pod -n envoy-gateway-system

#查看路由解析地址, 其中 nodeport 类型的 svc 便是你的解析地址。kubectl get svc -n envoy-gateway-system|grep LoadBalancer

#拜访
curl --resolve www.example.com:31830:xx.xxx.xx.xxx --header "Host: www.example.com"  http://www.example.com:31830/get

Gateway API 应用到生产须要思考易用性、可管理性和稳定性因素：

易用性：Gateway API 扩大了很多配置内容，如果间接写 yaml 上手难度较大，而且容易出错，所以须要有一个基于 UI 的管理工具。
可管理性：Gateway API 反对分角色治理和应用，跟平台工程的思路统一，但要用到生产须要有一个分权限和角色的平台。
稳定性：Gateway API 以后的实现中，Envoy 和 Nginx 能够用到生产环境。

基于以上因素，在生产环境须要 Gateway API 的管理工具，以后绝对成熟的工具能够抉择 Rainbond，它运行 Kubernetes 根底上，它也是平台工程的设计思路，提供 web 界面治理 Kubernetes 的资源，包含 Gateway API，对使用者不须要写 Yaml 文件，能辨别管理员角色和一般开发者角色，管理员能够通过治理界面装置兼容的 Gateway API 的实现，比方 Envoy 和 Nginx，装置好的网关，一般开发者只须要配置业务的路由就能够应用，不必关怀是哪一种实现。

具体落地过程：

参考装置文档：基于 Kubernetes 装置 Rainbond

通过 Rainbond 提供的利用市场，搜寻 GatewayAPI 会进去三个利用，先装置 GatewayAPI-Base，再装置 GatewayAPI-Envoy 或 Gateway-Nginx，当然也能够两个都装。

在 平台治理 / 扩大 / 能力 点击对应资源的编辑，配置 Gateway 和 GatewayClass 资源。

开发者在本人开发的利用中配置网关，如果同时装置多个网关实现，能够先抉择网关类型，而后通过界面配置 HTTPRoute 字段。

补充阐明：

Rainbond 以后版本只反对 HTTPRoute，其余类型的 Route 临时不反对；
从 Rainbond 利用市场只能装置 Envoy 和 Nginx 两种网关实现，要反对更多网关实现须要 Rainbond 先反对或本人制作插件；
材料参考：Rainbond 的 Gateway API 插件制作实际。

正文完

kubernetes

发表至： kubernetes

2023-05-06

0

关于kubernetes:使用-Nocalhost-开发-Rainbond-上的微服务应用

关于kubernetes:k8s常用命令

关于kubernetes:Longhorn-的正确使用姿势如何处理增量-replica-与其中的-snapshotbackup

关于kubernetes:SKS-SMTX-Kubernetes-Service

关于程序员:基于-RetinaFace-的口罩人脸检测算法

关于kubernetes:Kubernetes-Gateway-API-深入解读和落地指南

背景

倒退现状

版本现状

可用场景

周边生态

将来布局

Gateway API 标准解读

根底概念

工作原理

结构图

GatewayClass

Gateway

HTTPRoute

Gateway API 疾速上手

装置 Gateway API CRD 和 Envoy Controller

装置 Gateway、HTTPRoute 及示例利用

外部 GatewayClass 资源

外部 Gateway 资源

外部的 HTTPRoute 资源

Gateway API 生产指南

在 Kubernetes 上装置 Rainbond

管理员装置 Gateway API 的网关实现

管理员配置 Gateway API 的资源

开发者配置业务路由

站内搜索