Ingress Controllers:Kubernetes 的瑞士军刀

img

Ingress Controllers可能看起来只是Kubernetes领域中的一个小组件。许多人认为它们的价值不大,但如果部署和配置正确,Ingress Controllers可以从根本上简化 Kubernetes 集群的操作,同时增强其安全性,并提高服务的性能和弹性。

为什么需要Ingress Controllers

Ingress Controllers对于定义和管理 Kubernetes 中的入口(南北)流量至关重要。

默认情况下,外部系统无法访问在 Kubernetes pod(和容器)中运行的应用程序。Kubernetes 有一个用于 HTTP(第 7 层)负载均衡的内置配置对象,称为ingress。该对象定义了 Kubernetes 集群之外的服务如何连接 Kubernetes Service中的 Pod。当你需要从外部访问Kubernetes Service时,你可以创建一个ingress来定义连接规则。这包括 URI 路径、Service名称和其他信息。然而,ingress本身并没有做任何事情。你必须部署和配置Ingress Controllers应用程序来实现ingress中定义的规则。

如果不这样做,意味着要使用Service对象和外部工具的组合来创建更详细的规则,这将会导致无法扩展、成本昂贵且耗费大量时间。

Ingress Controllers如何与负载均衡器一起工作

Ingress Controllers可以独立工作以平衡和调整流量,也可以与负载均衡器一起使用以释放 Kubernetes 的强大功能并提供更好的应用程序性能。

备注:“LoadBalancer”类型的Service与负载均衡器不同。

Ingress Controllers有时被描述为 Kubernetes 的“专用负载均衡器”。所以这就引出了一个问题:你需要负载均衡器和Ingress Controllers吗?嗯,答案是。

组织会同时部署Ingress Controllers和负载均衡器。尽管它们部署在不同的地方,用于不同的目的并由不同的团队管理。以下是他们的区别:

  • 负载均衡器(或 ADC)
    • 管理者:一个 NetOps(或者可能是 SecOps)团队
    • 部署:在 Kubernetes 外部,作为交付给集群外部用户的Service和应用程序的唯一面向公众的入口,旨在促进安全并提供更高级别的网络管理。
  • Ingress Controllers
    • 管理者:平台运维或 DevOps 团队
    • 部署:在 Kubernetes 内部实现细粒度的南北负载均衡功能(HTTP2、HTTP/HTTPS、SSL/TLS 终止、TCP/UDP、WebSocket、gRPC)。授予应用程序团队的某些配置方面(例如 URI 或路径)以及高级反向代理或 API 网关功能。

在此图中,我们让负载均衡器处理跨多个集群的流量分配,而集群具有Ingress Controllers以确保对Service的平均分配。

负载均衡器

Ingress Controllers = 安全工具

Ingress Controllers可以为应用程序安全提供一个细粒度和集成的层,该层适用于“左移”安全立场,并与应用程序团队使用的安全工具更好地集成。

Ingress Controllers可以成为你安全库中的关键工具,帮助你将安全性“左移”,更好地满足微服务和现代应用程序的需求和风险。Ingress Controllers的一些关键安全优势包括:

  • 防止通过配置不当的负载均衡器直接访问: Pod Ingress Controllers充当第二层访问控制,以防全局负载均衡器配置不当,流量漂移到不安全的地方。
  • 执行 mTLS: 因为Ingress Controllers设计为在节点和 pod 级别运行,并且是在Service之上运行的控制循环,所以它们是执行加密行为的最佳位置 – 最接近实际应用程序。
  • 异常检测和执行: Ingress Controllers可以更轻松地制定逻辑规则来处理异常。对于管理微服务的小型团队来说,生成此逻辑的最佳位置是在 DevOps 和服务开发人员本身的级别;他们知道他们的流量应该是什么样子以及应用什么规则。
  • 与 WAF 更紧密的集成: 在大多数情况下,在 Kubernetes 中部署生产应用程序的任何人都需要使用 Web 应用程序防火墙 (WAF) 来保护应用程序和集群。WAF 可以过滤掉不良流量并保护应用程序。但与异常检测一样,这不适合在应用程序层实施更细粒度的安全性。出于这个原因,许多团队现在在入口层在 Kubernetes 中运行自己的 WAF,并与全局 WAF 分开管理。这些特定于应用程序的 WAF 在Ingress Controllers级别更易于管理、集成和配置,了解应用程序的团队可以在其中设置入口/出口和安全策略。

Ingress Controllers = API 网关

Ingress Controllers以 Kubernetes 原生方式整合了大多数 API 网关功能,从而降低了复杂性和成本,同时提高了性能。

采用Ingress Controllers的最佳理由之一是节省成本和简单性。因为Ingress Controllers是一个专门的代理,它可以满足许多传统代理(负载均衡器/反向代理或 ADC)的功能。这包括负载均衡和 API 网关功能,例如:

  • TLS/SSL 终止
  • 客户端认证
  • 速率限制、重试和超时
  • 细粒度的访问控制
  • 第 4 层和第 7 层的请求路由
  • 蓝/绿部署和金丝雀部署
  • 传统协议(UDP、TCP)的路由
  • 较新协议的路由 (gRPC)
  • 请求头和请求/响应操作
  • SNI 路由
  • 基于高级Service/pod 健康规则的路由

注意:“API 网关”经常被认为是一种独特的产品。事实上,它是可以通过代理完成的。大多数情况下,负载均衡器、ADC 或反向代理被实现为 API 网关。然而,在 NGINX,我们越来越多地看到Ingress Controllers和服务网格被用于 API 网关功能。

你不一定会在Ingress Controllers和API 网关之间找到功能差异,这没关系。在 Kubernetes 中,你实际上并不需要这些额外的功能,并且尝试实现它们可能会给你带来麻烦。Kubernetes 中两个最适用的 API 网关用例是流量管理(协议、拆分)和安全性(身份验证、端到端加密)。考虑到这一点,你需要一个Ingress Controllers来处理以下内容:

  • 方法级路由/匹配
  • 认证/授权
  • 基于授权的路由
  • 协议兼容性(HTTP、HTTP/2、HTTP/3、WebSockets、gRPC)

Ingress Controllers允许开发人员以 Kubernetes 原生方式(声明式/命令式 YAML)定义 API 网关或负载均衡器功能,从而轻松融入他们的工作流程。最后,客户和用户可以获得更好的体验,因为从流量路径中删除额外的控制元素总是会带来更好的性能。

可以阅读“我该如何选择?API Gateway vs. Ingress Controller vs. Service Mesh”以获取有关此主题的更多信息,包括南北和东西 API 流量的示例场景。

Ingress Controllers = 可观察性

Ingress Controllers可以监视所有进出的流量,这意味着Ingress Controllers可以提供轻量级、集成且易于管理的监控和可观察层。

因为它位于你的集群前面并控制 L4-L7 流量和非 HTTP 协议流量,所以你的Ingress Controllers对你的应用程序和基础设施的运行状况拥有全局视野。这是强大而有用的。你可以轻松地将流量监控从现有数据和控制平面扩展到Prometheus等可观察性工具。事实上,大多数Ingress Controllers都与知名的CNCF监控和可观察性工具原生集成,例如前面提到的 Prometheus 及Grafana。你可以使用Ingress Controllers解决两个问题:

  • 缓慢的应用程序:如果你的应用程序运行缓慢 – 或出现故障!— 具有实时监控功能的Ingress Controllers可以帮助你准确定位问题所在。每秒请求数变低可能表明配置错误,而响应时间的延迟可能表明上游应用程序存在问题。
  • HTTP 错误:如果你的集群或平台资源不足,你可以使用来自Ingress Controllers的历史数据来分析趋势。这就是像 Grafana 这样的工具对数据可视化特别有帮助的地方。

通过“如何提高 Kubernetes 中的可见性”可以更深入地介绍了这些用例,包括使用 NGINX 工具与 Prometheus 和 Grafana 一起解决 Kubernetes 问题。

对于某些服务网格、负载均衡器和其他 Kubernetes 的网络工具,创建监控和可观察性会增加负载和延迟。此外,它们无法以与Ingress Controllers相同的粒度级别解析流量。由于Ingress Controllers不需要将额外的 CRD 或对象添加到你的配置文件和 Kubernetes 堆栈中,因此你可以避免不必要的复杂性和延迟。毕竟,你部署的 CRD 越多,你的 Kubernetes 架构就越复杂。

结论:Ingress Controllers比控制入口做得更多

希望到现在为止,你对Ingress Controllers为什么是 Kubernetes 网络的无名英雄,有了更多的了解。下面是一些警告:

  • 并非所有Ingress Controllers都能够服务于本文中讨论的各种用例。NGINX 博客系列“Ingress Controllers选择指南”可以帮助你识别需求、规避风险、面向未来并驾驭复杂的Ingress Controllers环境。
  • 如果你的入口规则设计不佳并且你的 pod 资源不足,那么Ingress Controllers可能会降低应用程序的速度。但是,如果你设计得很好,那么将Ingress Controllers成本将只是你可以在创造性地改进性能的一小部分。

网关 API的发布是社区对Ingress Controllers投资的一个很好的例子。

押注Ingress Controllers就是押注 Kubernetes 的未来。因为构建现代应用程序就是构建松散耦合的服务并让开发人员获得更多的独立性,所以Ingress Controllers的部署可以加速应用程序的开发和迭代。Kubernetes 的Ingress Controllers,正是普通开发人员或 DevOps 团队需要智能、高效和安全地将流量进出应用程序的工具。

译文链接: https://thenewstack.io/ingress-controllers-the-swiss-army-knife-of-kubernetes/

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址