![](data:image/svg+xml;charset=utf-8,<svg height="384" width="640" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
本文转载自 The New Stack。
许多人认为 Ingress controller（Ingress 控制器）的价值不大，但实际上它可成为您软件栈中的强大工具。
![](data:image/svg+xml;charset=utf-8,<svg height="900" width="1240" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Ingress controller 可能看似只是 Kubernetes 环境中的又一技术小部件。许多人认为 Ingress controller 的价值不大，但实际上它可成为您软件栈中的强大工具。如果部署和配置得当，Ingress controller 能够从根本上简化 Kubernetes 集群的操作，同时增强安全防护并提高性能和弹性。
Ingress controller 可完全接替其他工具或解决方案提供的许多功能。因为专为 Kubernetes 而设计，所以 Ingress controller 能够更轻松地接替这些功能，不像负载均衡器、API 网关及应用交付控制器 (ADC) 等现有技术结构，需要重新适应奇妙的 Kubernetes 环境。Ingress controller 的多功能性使其仿若 Kubernetes 的瑞士军刀。
为何需要使用 Ingress controller？
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 如何与负载均衡器协同工作（或替代负载均衡器）
Ingress controller 既可独立工作以均衡和调度流量，也可与负载均衡器协同工作，从而释放 Kubernetes 的强大潜力，提高应用性能。
请注意：所谓的“LoadBalancer”这种 service 与“专用负载均衡器”并不能等同。
Ingress controller 有时被描述为 Kubernetes 的“专用负载均衡器”。这就引出了一个问题：您是否需要同时部署负载均衡器和 Ingress controller？答案是：视情况而定。正如上一篇博文《复制，而非整合：应用发展道路》中所述，有时您需要根据工具的使用群体和部署位置进行一些功能复制。
对于许多用例，尤其是要扩展 Kubernetes 或在高合规性要求环境中运行时，企业会同时部署 Ingress controller 和负载均衡器。不过，二者部署在不同的位置，用于不同的用途，并由不同的团队进行管理。
- 负载均衡器（或称 ADC）：
- 管理者：NetOps（也可能是 SecOps）团队
- 部署：位于 Kubernetes 外部，作为唯一面向公众的端点，为集群之外的用户提供服务和应用。作为一种更通用的应用，旨在提高安全防护，并促进交付更高级别的网络管理。
- Ingress controller:
- 管理者：平台运维团队或 DevOps 团队
- 部署：位于 Kubernetes 内部，提供细粒度的南北向负载均衡功能（HTTP2、HTTP/HTTPS、SSL/TLS 卸载、TCP/UDP、WebSocket、gRPC）。允许应用团队使用的某些配置（如 URI 或路径）以及高级反向代理或 API 网关功能。
下图显示了负载均衡器处理跨多个集群的流量分发，同时集群部署了 Ingress controller 来确保对 service 的平均分发。
![](data:image/svg+xml;charset=utf-8,<svg height="1778" width="2176" xmlns="http://www.w3.org/2000/svg" version="1.1"/>)
Ingress controller = 安全防护工具
Ingress controller 可为应用安全防护提供一个细粒度的集成层，该层适用于确保“左移”安全防护，并能够更紧密地集成应用团队（而非 NetOps 或全局安全防护团队）所用的较低级别的安全防护工具。
Ingress controller 可成为安全工具库中的关键工具，帮助您将安全防护向左迁移，从而更好地满足微服务和现代应用的需求并从容地应对它们带来的风险。Ingress controller 的一些主要安全防护优势包括：
- 防止通过配置不当的负载均衡器直接访问 Pod
Ingress controller 可充当第二层访问控制，以防全局负载均衡器配置变为不安全设置。 - 执行 mTLS
因为 Ingress controller 在节点和 Pod 级别运行，而且是运行于 service 之上的控制回路，所以它是执行加密行为的最佳位置 — 最靠近实际应用。 - 异常检测和执行
Ingress controller 支持更轻松地实施逻辑规则，以处理可能代表有不良行为的异常情况。在全局层面，这些异常情况可能难以理解或衡量。对于管理微服务的小型团队而言，生成这种逻辑的最佳人员是 DevOps 和 service 开发人员本身；他们知道其流量的合理状况以及适用的规则。 - 更紧密地集成 WAF
大多数情况下，在 Kubernetes 中部署生产应用的任何人员均需使用 Web 应用防火墙 (WAF) 来保护应用和集群。WAF 能够过滤恶意流量，并保护暴露的应用。不过，与异常检测一样，配置为在企业环境的全局层面提供保护的 WAF 犹如钝器，不太适合在应用层实施更细粒度的安全防护。因此，许多团队现在都在 Kubernetes 内的 Ingress 层运行自己的 WAF，并与全局 WAF 分开管理。这些应用特定的 WAF 更易于在 Ingress controller 级别进行管理、集成和配置。在该级别，了解应用的团队可以同时设置入向/出向和安全防护策略。
Ingress controller = API 网关
Ingress controller 以 Kubernetes 原生方式整合了大多数 API 网关功能，可降低复杂性和成本，同时提高性能。
采用 Ingress controller 的最重要理由之一是节约成本和简单易用。因为 Ingress controller 是一种专用代理，所以它能够满足传统代理（负载均衡器/反向代理或 ADC）可实现的许多相同用例需求。其中包括多项负载均衡和 API 网关功能，例如：
- TLS/SSL 卸载
- 客户端身份验证
- 速率限制、重启和超时
- 细粒度的访问控制
- 四层和七层按请求路由
- 蓝/绿部署和灰度部署
- 传统协议（UDP、TCP）路由
- 新协议 (gRPC) 路由
- 请求头和请求/响应操作
- SNI 路由
- 基于高级 service/Pod 健康规则的路由
注：“API 网关”经常被视为一种单一产品。事实上，它是一组可通过代理实现的用例。大多数情况下，负载均衡器、ADC 或反向代理被部署为 API 网关。但在 NGINX，我们看到越来越多的 Ingress controller 和 service mesh（服务网格）被用于 API 网关功能。
您不一定能看出 Ingress controller 和标记为 API 网关的工具之间的相似性，这也无妨。在 Kubernetes 中，您实际上并不需要所有这些额外的特性，而且试图实现它们可能会给您带来麻烦。Kubernetes 中最适用的两个 API 网关用例是流量管理（协议、整形、精分）和安全防护（身份验证、端到端加密）。有鉴于此，您需要使用 Ingress controller 来处理以下操作：
- 方法级路由/匹配
- 身份验证/授权卸载
- 基于授权的路由
- 协议兼容性（HTTP、HTTP/2、HTTP/3、WebSockets、gRPC）
您的开发人员定会对您不胜感激，因为 Ingress controller 允许他们以可轻松融入工作流的 Kubernetes 原生方式（声明式/命令式 YAML）定义 API 网关或负载均衡器功能。您的法律和财务团队也将获益匪浅，因为成本更低，需要跟踪的许可更少。最后，客户和用户能够享受更佳的体验，因为从流量路径中移除额外的控制元素必定有助于提高性能。
请阅读《API 网关 vs. Ingress Controller vs. Service Mesh，该怎么选？》一文，了解有关该主题的更多信息，包括南北向和东西向 API 流量的示例场景。
Ingress controller = 可观测性和监控能力
Ingress controller 可监控所有进出流量，这意味着 Ingress controller 能够提供一个轻量级、集成式且易于管理的监控和可观测性层。
因为位于集群的前面并控制着四层—七层流量和传统或非 HTTP 协议流量，所以 Ingress controller 可提供应用和基础架构健康状态的特别视图。这一特性强大且实用。您可以轻松地将流量监控从现有数据和控制平面扩展到 Prometheus 等可观测性工具。事实上，大多数 Ingress controller 均原生集成了卓越的 CNCF 监控和可观测性工具，例如前面提到的 Prometheus 及与之密切相关的平台 Grafana。您可以使用 Ingress controller 处理以下两种用例：
- 应用运行缓慢：如果您的应用运行缓慢或崩溃了！— 具有实时监控功能的 Ingress controller 可帮助您准确找出问题所在。每秒请求数低可能表明出现配置错误，而响应时间延迟则可能表明上游应用存在问题。
- HTTP 错误：如果集群或平台资源耗尽，您可以使用 Ingress controller 中的历史数据来找出趋势。这正是 Grafana 等工具对数据可视化的用武之地。
《如何提高 Kubernetes 环境的可见性》深入介绍了上述用例，包括演示如何使用 NGINX 工具和 Prometheus 及 Grafana 解决 Kubernetes 问题。
对于一些 service meshes、负载均衡器及其他 Kubernetes 风格的网络工具，创建监控和可观测性可能会增加负载和延迟。此外，它们也无法以与 Ingress controller 相同的细粒度级别解析流量。由于 Ingress controller 无需将额外的 CRD 或对象添加到您的配置文件和 Kubernetes 堆栈中，因此可避免不必要的复杂性和延迟。毕竟，部署的 CRD 越多，Kubernetes 环境就越复杂。
结论：Ingress controller 的功能远不止控制 Ingress
希望现在您已进一步了解为何 Ingress controller 是 Kubernetes 网络中的幕后英雄，意识到若不对其加以利用，可谓一大失误。一些注意事项如下：
- 并非所有 Ingress controller 都能用于本文所述的不同用例。我们的系列博文《Ingress Controller 选型指南》可帮助您确定需求，避免风险，放眼未来并驾驭复杂的 Ingress Controller 环境。
- 如果您的 Ingress 规则设计不合理且 Pod 资源不足，那么 Ingress controller 可能会降低应用运行速度。但如果您的规则设计合理，那么将 Ingress controller 部署到集群边缘的名义成本与您可实现的性能提升相比可谓微不足道。
Ingress controller 将不断改进并添加功能 — 事实上，Gateway API 的发布就是社区投资 Ingress controller 的最佳示例。
选择 Ingress controller 就是选择 Kubernetes 的未来。由于构建现代应用本质上就是构建松散耦合的 service 并赋予开发人员更大的自主权，因此部署 Ingress controller 能够加快应用开发和迭代速度。Kubernetes 网络工具的“瑞士军刀”正是普通开发人员或 DevOps 团队之所需，有助于智能、高效、安全地在应用之间转移流量。