本文转载自 The New Stack。
许多人认为 Ingress controller(Ingress 控制器)的价值不大,但实际上它可成为您软件栈中的强大工具。
Ingress controller 可能看似只是 Kubernetes 环境中的又一技术小部件。许多人认为 Ingress controller 的价值不大,但实际上它可成为您软件栈中的强大工具。如果部署和配置得当,Ingress controller 能够从根本上简化 Kubernetes 集群的操作,同时增强安全防护并提高性能和弹性。
Ingress controller 可完全接替其他工具或解决方案提供的许多功能。因为专为 Kubernetes 而设计,所以 Ingress controller 能够更轻松地接替这些功能,不像负载均衡器、API 网关及应用交付控制器 (ADC) 等现有技术结构,需要重新适应奇妙的 Kubernetes 环境。Ingress controller 的多功能性使其仿若 Kubernetes 的瑞士军刀。
Ingress controller 对于定义和管理 Kubernetes(比非 Kubernetes 应用更复杂的 Ingress 环境)中的入向(南北向)流量至关重要。
默认情况下,外部网络和流量无法访问在 Kubernetes Pod(和容器)中运行的应用。Kubernetes 中的 Pod 仅可彼此之间相互通信。Kubernetes 拥有一个用于 HTTP(七层)负载均衡的内置配置对象,即 Ingress。该对象定义了 Kubernetes 集群外部的实体如何连接到分配一个或多个 Kubernetes service 的 Pod。当需要提供对 Kubernetes service 的外部访问时,您可以创建一个 Ingress 资源来定义连接规则,其中包括 URI 路径、支持 service 名称及其他信息。不过,Ingress 资源本身不执行任何操作。您必须通过部署和配置 Ingress controller 应用(使用 Kubernetes API)来实施 Ingress 资源中定义的规则。
换句话说,您需要部署 Ingress controller,以利用 Kubernetes 的现有资源和对象结构。不然,您就得更费事地结合使用 Service 对象和外部设备来创建更详细的规则。无 Ingress Controller 方案无法扩展,不仅成本高昂,而且还需投入大量的工程设计时间。
Ingress controller 既可独立工作以均衡和调度流量,也可与负载均衡器协同工作,从而释放 Kubernetes 的强大潜力,提高应用性能。
请注意:所谓的“LoadBalancer”这种 service 与“专用负载均衡器”并不能等同。
Ingress controller 有时被描述为 Kubernetes 的“专用负载均衡器”。这就引出了一个问题:您是否需要同时部署负载均衡器和 Ingress controller?答案是:视情况而定。正如上一篇博文《复制,而非整合:应用发展道路》中所述,有时您需要根据工具的使用群体和部署位置进行一些功能复制。
对于许多用例,尤其是要扩展 Kubernetes 或在高合规性要求环境中运行时,企业会同时部署 Ingress controller 和负载均衡器。不过,二者部署在不同的位置,用于不同的用途,并由不同的团队进行管理。
下图显示了负载均衡器处理跨多个集群的流量分发,同时集群部署了 Ingress controller 来确保对 service 的平均分发。
Ingress controller 可为应用安全防护提供一个细粒度的集成层,该层适用于确保“左移”安全防护,并能够更紧密地集成应用团队(而非 NetOps 或全局安全防护团队)所用的较低级别的安全防护工具。
Ingress controller 可成为安全工具库中的关键工具,帮助您将安全防护向左迁移,从而更好地满足微服务和现代应用的需求并从容地应对它们带来的风险。Ingress controller 的一些主要安全防护优势包括:
Ingress controller 以 Kubernetes 原生方式整合了大多数 API 网关功能,可降低复杂性和成本,同时提高性能。
采用 Ingress controller 的最重要理由之一是节约成本和简单易用。因为 Ingress controller 是一种专用代理,所以它能够满足传统代理(负载均衡器/反向代理或 ADC)可实现的许多相同用例需求。其中包括多项负载均衡和 API 网关功能,例如:
注:“API 网关”经常被视为一种单一产品。事实上,它是一组可通过代理实现的用例。大多数情况下,负载均衡器、ADC 或反向代理被部署为 API 网关。但在 NGINX,我们看到越来越多的 Ingress controller 和 service mesh(服务网格)被用于 API 网关功能。
您不一定能看出 Ingress controller 和标记为 API 网关的工具之间的相似性,这也无妨。在 Kubernetes 中,您实际上并不需要所有这些额外的特性,而且试图实现它们可能会给您带来麻烦。Kubernetes 中最适用的两个 API 网关用例是流量管理(协议、整形、精分)和安全防护(身份验证、端到端加密)。有鉴于此,您需要使用 Ingress controller 来处理以下操作:
您的开发人员定会对您不胜感激,因为 Ingress controller 允许他们以可轻松融入工作流的 Kubernetes 原生方式(声明式/命令式 YAML)定义 API 网关或负载均衡器功能。您的法律和财务团队也将获益匪浅,因为成本更低,需要跟踪的许可更少。最后,客户和用户能够享受更佳的体验,因为从流量路径中移除额外的控制元素必定有助于提高性能。
请阅读《API 网关 vs. Ingress Controller vs. Service Mesh,该怎么选?》一文,了解有关该主题的更多信息,包括南北向和东西向 API 流量的示例场景。
Ingress controller 可监控所有进出流量,这意味着 Ingress controller 能够提供一个轻量级、集成式且易于管理的监控和可观测性层。
因为位于集群的前面并控制着四层—七层流量和传统或非 HTTP 协议流量,所以 Ingress controller 可提供应用和基础架构健康状态的特别视图。这一特性强大且实用。您可以轻松地将流量监控从现有数据和控制平面扩展到 Prometheus 等可观测性工具。事实上,大多数 Ingress controller 均原生集成了卓越的 CNCF 监控和可观测性工具,例如前面提到的 Prometheus 及与之密切相关的平台 Grafana。您可以使用 Ingress controller 处理以下两种用例:
《如何提高 Kubernetes 环境的可见性》深入介绍了上述用例,包括演示如何使用 NGINX 工具和 Prometheus 及 Grafana 解决 Kubernetes 问题。
对于一些 service meshes、负载均衡器及其他 Kubernetes 风格的网络工具,创建监控和可观测性可能会增加负载和延迟。此外,它们也无法以与 Ingress controller 相同的细粒度级别解析流量。由于 Ingress controller 无需将额外的 CRD 或对象添加到您的配置文件和 Kubernetes 堆栈中,因此可避免不必要的复杂性和延迟。毕竟,部署的 CRD 越多,Kubernetes 环境就越复杂。
希望现在您已进一步了解为何 Ingress controller 是 Kubernetes 网络中的幕后英雄,意识到若不对其加以利用,可谓一大失误。一些注意事项如下:
Ingress controller 将不断改进并添加功能 — 事实上,Gateway API 的发布就是社区投资 Ingress controller 的最佳示例。
选择 Ingress controller 就是选择 Kubernetes 的未来。由于构建现代应用本质上就是构建松散耦合的 service 并赋予开发人员更大的自主权,因此部署 Ingress controller 能够加快应用开发和迭代速度。Kubernetes 网络工具的“瑞士军刀”正是普通开发人员或 DevOps 团队之所需,有助于智能、高效、安全地在应用之间转移流量。
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."