都是Kubernetes入口一样吗？

科技 06-30 来源： qaseven

简单的答案是“是”和“不是”，但真正的答案要复杂得多

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。
简单的答案是“是”和“不是”，但真正的答案要复杂得多。已经有很多关于这个话题的文章，我正在尝试使这个领域更容易理解。

在开始之前，我必须指出一个重要的事实。K8s 上游不提供入口。与服务负载均衡器和存储等组件一样，它只是提供了控制器应该使用的 API，以创建 k8s 资源中描述的功能。入侵包括监视 k8s API 的控制器和由该控制器编程以影响转发的代理引擎。

K8s 访问模式

最初的访问模式由服务负载均衡器和入口组成。负载均衡器通过添加 IP 地址将流量吸引到集群，而 Inress 通过 CNI 网络将请求分发给 POD。虽然它们被设计成一起使用，但它们可以单独使用。

仅访问服务负载均衡器.流量被吸引到集群节点，并根据配置直接或通过 kubexy 发送到 POD。最好将服务负载均衡器看作 L3/4函数。它使用 IP 转发流量，当流量在没有目标 POD 的单个节点上接收时，它依赖 kubexy 到达其他节点。但是，只有 LoadBalancer 的解决方案可以为 k8s 集群提供统一的访问解决方案
Ingress-only access . T.入口依赖于另一种机制来获取到入口代理 POD 的流量。入口根据其 HTTP 路由规则分配集群中的流量。这些规则在入口吊舱中编程一个代理引擎，当它在集群中运行时，可以使用 CNI 直接访问 POD。除了 LoadBalancer 之外，ServiceAPI 还有其他机制来获取入口的流量，但它们都是特定于外部基础设施或需要配置外部基础设施的

负载均衡器和入口都依赖于服务 API，负载均衡器是一种服务类型，入口使用服务来定义请求端点。

云供应商入口

更令人困惑的是，云提供商没有遵循设计模式。云供应商使用云控制器将他们的基础设施资源与 Kubernetes 集成，而不是通过独立的负载均衡器、入口或存储控制器。

云提供商已经有了负载平衡器，他们称之为 NLB，在 L3/4运行，所以他们很好地映射到了服务负载平衡器 API。然而，除此之外，他们还有一个产品，他们称之为应用程序负载平衡器，或 ALB。其中一个提供者决定他们应该将 ALB 映射到 Ingreth 资源，其他提供者也跟着这么做。然而，与其他 k8入侵不同，ALB 位于集群之外，因为它重用了用于虚拟化的网络工具。

最重要的是，云提供商 Inress 实现分配 IP 地址，这项任务通常在 Service API 中使用 LoadBalancer 类型执行。因此，在云供应商中，每个供应商都是一个独立的实体。云负载均衡器不能与云入口配对，但是，云负载均衡器可以与集群内入口配对。

是入口 API 网关吗？

没有。一个 API 网关包含了一些入口 API 不支持的功能，因此严格地说入口不是一个 API 网关。有相当多的函数，但是一个很好的例子是头匹配，通常用于开发 A/B 测试。入口资源不支持这个基本功能。

所有的进入都是一样的吗？

是和否... 任何 k8s 入口控制器配置使用入口 API 是相同的，因为他们都有相同的功能。它们可以通过不同的代理引擎实现，但是入口 API 定义了可用的功能。

入侵的真相

除了 CNCF NGNIX Ingrese 只支持 Ingrets API 之外，所有 Ingreses 都是不同的。

因为入口 API 缺少关键功能，所以每个入口都有一个唯一的配置模型。您不能将单独进入的配置应用于大使进入; 它们使用每个实现独有的自定义资源定义(Custom Resource Definition，CRD)中定义的配置。

入口控制器作为一个 API 网关运行所需的扩展功能在“入口”中已经得到了很好的理解和统一，然而，每个入口开发人员对于如何配置入口都有不同的看法，每个人都试图根据他们对简单和目标受众的定义使其简单化。

检查入口配置差异

有很多入口控制器，我已经看了很多，但是，还有很多我无法准确比较。我选择了三个流行的 Ingresses ーー Solo.io 的 GlooEdge、 Traefik 的 Proxy 和 Kong Kubernetes Ingreses ーー并研究了基于自定义资源定义的配置，它们中的每一个都可以作为 API 网关。在我继续之前，他们都是伟大的产品，他们都没有错，他们只是不同。

为了显示这种差异，我将包含一个简单的配置，但是包含 URL 重写的 k8s IngresAPI 是不可能的。入口提供的 URL 是/pre，并被重新映射到/后端 POD 中的目标 URL。在 apiVersion 中很容易识别每个自定义资源。

GlooEdge

YAML

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: default
  namespace: gloo-system
spec:
  virtualHost:
    domains:
    - '*'
    routes:
    - matchers:
      - exact: /pre
      options:
        prefixRewrite: /backend
      routeAction:
        single:
          upstream:
            name: ingress-test-8080
            namespace: gloo-system

Solo 的工程师显然在他们的配置上花了很多心思。资源的创建可以使用它们的 CLI、 glootl 进行。控制器动态识别 k8s 服务并创建称为上游的资源，用于路由目标。VirtualService 自定义资源(CR)包含入口 API prefixRewrite 中不可用的路由和我们需要的函数。

Solo 显然非常关注应用程序前端和后端开发人员。虽然它没有显示在上面的简单配置，这些家伙已经做了一些聪明的东西。他们的产品能够添加 OpenAPI 引用作为配置对象，可用于配置 API 网关和文档/发布 API。

Gloo Edge 代理引擎。使者是 Gloo Edge 使用的代理引擎。它是一个现代的、维护良好的、开源的代理引擎。

Traefik Proxy

YAML

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: simpleingressroute
spec:
  entryPoints:
    - web
  routes:
  - match: PathPrefix(`/pre`)
    kind: Rule
    services:

这里的团队似乎更关注 Traefik 代理的功能。他们的产品在 Kubernetes 之前就已经存在了，他们已经采用了他们的配置模型并将其转换为 CRD。重写函数包含在 IngresRouteCR 引用的中间件 CR 中。我确信这对于那些在其他地方使用 Traefik 的人来说是很好的，但是阅读他们的文档是一件苦差事。

如果你的重点是网址路由，你有很多其他的非库伯内特环境，正在寻找的东西，将运行在所有这些，Traefik 可能是一个不错的选择。

Traefik 代理引擎。使用的代理引擎是用 Go 编写的，特定于 Traefik。

Kong Kubernetes Ingress

apiVersion: v1
kind: Service
metadata:
  annotations:
    konghq.com/override: demo-customization
  name: ingress-test
  
spec:
  ports:
  - port: 8080
    protocol: TCP
  selector:
    app: ingress-test-server
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    konghq.com/override: demo-customization
  name: demo
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /pre
        pathType: ImplementationSpecific
        backend:
          service:
            name: ingress-test
            port:
              number: 8080
---
apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: demo-customization
route:
  methods:
  - GET
  strip_path: true
proxy:
  path: /backend/

Kong 是 API 门户的大人物(无法抗拒) ，他们的门户平台比 Kubernetes 存在的时间更长，这是该平台与库伯内特(Kubernetes)的整合。这里的团队采取了一个非常不同的配置路径。它们确实有 CRD，但是它们没有使用 CR 替换 Inress 对象，而是使用引用它们的 CR 的注释修改 Inress 和服务对象。

对 Service 对象和 Ingreth 对象都进行了注释，以引用 KongIngrestCR。引用 Inress，以便可以使用 Strip _ path 参数对其进行修改，并对 Service 进行注释，以便它可以引用代理参数。这些每个都可以放在自己的康恩进入 CR。

我赞赏kong的工程师尝试这种配置模型。它使Kong Kubernetes Ingress可以说更兼容的 k8s 配置。然而，这种方法的执行比概念更加困难，可能会被认为是混乱的。

Kong 代理引擎。开源的 NGINX 代理引擎被 Kong 使用。

有人试图简化这个问题吗？

是的，Kubernetes 的 GatewayAPI 特别兴趣小组正在研究一种新的 API。GatewayAPI 将提供所有的通信和请求管理功能，以便在集群内外实现 API Gateways。

YAML

apiVersion: gateway.networking.k8s.io/v1alpha2brkind: HTTPRoutebrmetadata:br  name: http-filter-redirectbrspec:br  parentRefs:br  - group: gateway.neworking.k8s.iobr    kind: Gatewaybr    name: uswest-gtwapibr  rules:br    - matches:br      - path:br          type: PathPrefixbr          value: /prebr      filters:br      - type: RequestRedirectbr        requestRedirect:br          path:br            type: ReplacePrefixMatchbr            replacePrefixMatch: /backendbr      backendRefs:br      - name: ingress-testbr        weight: 1br        port: 8080

上面提到的三个集群内提供商目前都对 GatewayAPI 提供了实验性的支持，在不久的将来，GatewayAPI 将升级为 beta 版，默认情况下可以从上游 k8获得。

云供应商

Gateway API 还解决了云供应商使用集群外部的代理实现 Inress 所造成的混乱。GatewayAPI 支持根据需要为每个名称空间网关创建外部网关。目前有两项实施措施:

谷歌云: GKE 支持网关 API 编程他们的外部代理引擎https://gateway-api.sigs.k8s.io/implementations/#google-kubernetes-engine
Acnodal EPIC: 这是一个使用网关 API 的 API 网关的多云实现https://www.epick8sgw.io/

你可在此了解更多关于 GatewayAPI 的 https://gateway-api.sigs.k8s.io/ ，以及当前实现状态的 https://gateway-api.sigs.k8s.io/implementations。