K8s 暴露服务的新方法 Gateway API 详解，它有什么好处？

K8s 暴露服务的新方法 Gateway API 详解，它有什么好处？

前段时间，​​Kubernetes SIG-Network​​ 发布了备受期待的 Gateway API 0.5.0 版。主要组件的 Api 正在升级到 beta (v1beta1)，这意味着我们很快就会看到更多使用这些原语的项目。

让我们回顾一下 Gateway API 的基础知识，它旨在解决什么，它有什么好处。

什么是 K8s Gateway API？

Gateway API 是新的官方 Kubernetes 资源的集合，它们定义了由供应商实现的规范，类似于 Ingress 由 Google、Amazon 等实现的方式。

它引入的新资源有：

Gateway（ beta ）GatewayClass ( beta )HTTPRoute ( beta )ReferenceGrant（仍处于 alpha 阶段，替换 ReferencePolicy ）TCPRoute（仍处于 alpha 阶段）TLSRoute（仍处于 alpha 阶段）UDPRoute（仍处于 alpha 阶段）

SIG-Network 所述的新​​Gateway API​​的目标是：

面向角色：Gateway 由 API 资源组成，这些 API 资源对使用和配置 Kubernetes 服务网络的组织角色进行建模。便携：这不是一种改进，而是应该保持不变的东西。正如 Ingress 是一个具有多种实现的通用规范一样，Gateway API 被设计为一种可移植的规范，由许多实现支持。富有表现力：Gateway API 资源支持诸如基于​​header​​的匹配、流量加权和其他核心功能，这些功能只能通过自定义注释在 Ingress 中实现。可扩展：Gateway API 允许在 API 的各个层链接自定义资源。这使得在 API 结构中的适当位置进行细粒度定制成为可能。

Gateway 和 GatewayClass 是基础设施级别的组件，它们是 XRoute 组件的底层（这就是这个版本令人兴奋的原因）。

让我们看看这个层次结构实际上是什么样子的：

面向角色的 API：一个集群，多个用户，不同角色

Gateway API 的第一个直接好处是它可以更好地分离关注点。

Ingress 对象很棒，是 Devops 和 App 工程师通常需要一起弄清楚配置的微妙对象，应用程序开发人员知道应用程序的路由，但通常不知道诸如 TLS 证书之类的细节，这些细节通常在 Devops 域，在同一个 Ingress 对象中发生的这个和其他配置正在阻止双方的自治，并为错误配置留出更多空间。

在新的 Gateway API 中，Gateway API 将这些和其他配置解耦为 Gateway 和 Route 对象，允许应用程序工程师和 Devops 工程师/集群操作员自由安全地行动，如下所示：

简化的功能

新 API 的另一个主要好处是，更多功能在 Gateway API 对象定义中表达，而不是让供应商通过自定义注释来定义。 此增强提供了几个好处：

可移植性：考虑到不同的网关供应商，对象不太容易发生变化专业知识：让工程师专注于熟悉 Kubernetes 规范而不是供应商特定的规范。

让我们举个例子，这里是您如何使用 Ingress 对象和 AWS alb 定义流量拆分。

apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: "groundcover-app" namespace: "app" annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/actions.blue-green: | { "type":"forward", "forwardConfig":{ "targetGroups":[ { "serviceName":"groundcover-app-v1", "servicePort":"80", "weight":80 }, { "serviceName":"groundcover-app-v2", "servicePort":"80", "weight":20 } ] } } labels: app: groundcover-appspec: rules: - paths: - path: / pathType: Prefix backend: service: name: blue-green port: name: use-annotation

正如您所看到的，这里有很多供应商特定的定义，大量使用注释，但是，使用新的 Gateway API，等效的将是

apiVersion: gateway.networking.k8s.io/v1beta1kind: Gatewaymetadata: name: prod-webspec: gatewayClassName: acme-lb listeners: - protocol: HTTP port: 80 name: prod-web-gw allowedRoutes: namespaces: from:

apiVersion: gateway.networking.k8s.io/v1beta1kind: HTTPRoutemetadata: name: "hello-kubernetes" labels: gateway: prod-web-gwspec: hostnames: - app.groundcover.com rules: - backendRefs: - name: groundcover-app-v1 port: 80 weight: 90 - name: groundcover-app-v2 port: 80 weight: 10

如您所见，这里的配置要简洁很多，并且定义是完全可移植的！

跨命名空间路由

作为理解的一部分，在 Kubernetes 集群中有不同的角色操作不同的组件，因此需要支持跨命名空间引用，因为这些不同的组织单元通常在不同的命名空间中运行，同时仍然使用通用的基础设施组件，例如 TLS 证书，主机名等等。

为了实现上述功能，Gateway API 支持在一个集群中建立 Gateway 对象，并在引用它的每个应用程序/组织单元命名空间中创建 Route 对象。

以下是此类设置的说明：

基础设施运营商还可以明确限制谁可以将 Route 对象注册到网关，在我们的示例中，网关定义如下：

apiVersion: gateway.networking.k8s.io/v1beta1kind: Gatewaymetadata: name: shared-gateway namespace: infra-nsspec: gatewayClassName: shared-gateway-class listeners: - name: hostname: "foo.example.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Selector selector: matchLabels: shared-gateway-access: "true" tls: certificateRefs: - name: foo-example-com

网关将只允许带有 shared-gateway-access: “true” 标签的命名空间使用共享网关，因此在我们的示例中，命名空间对象必须定义如下：

apiVersion: v1kind: Namespacemetadata: name: infra-ns labels: shared-gateway-access: "true"---apiVersion: v1kind: Namespacemetadata: name: site-ns labels: shared-gateway-access: "true"---apiVersion: v1kind: Namespacemetadata: name: store-ns labels: shared-gateway-access: "true"

一旦部署了这些层，应用程序开发人员就可以注册他们的 Route 对象，引用共享网关。

在我们的示例中，store Route 对象将如下所示：

apiVersion: gateway.networking.k8s.io/v1beta1kind: HTTPRoutemetadata: name: store namespace: store-nsspec: parentRefs: - name: shared-gateway namespace: infra-ns rules: - matches: - path: value: /store backendRefs: - name: store port: 8080

K8s 通用 API 的价值

本文严重依赖 Kubernetes SIG-Network，他们在​​记录​​​新 API 方面做得非常出色，如果您现在有兴趣尝试 Gateway API，他们​​在此处​​列出了可用的实现。

Kubernetes 正在迅速变化，尽管适应这些变化很困难，有时令人沮丧。但这绝对值得。

在我看来，社区在收集案例研究并以负责任的方式统一它们方面做得非常出色。

让 Kubernetes 用户能够在通用 API 方面建立专业知识，而不是成为特定于供应商的专家，这将有助于构建更成熟的产品，专注于创造价值并更轻松地在不同环境中应用我们的技能。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。