做美图 网站,天津滨海新区地图全图,营销类网站如何优化,北京房地产网官网原文作者#xff1a;Brian Ehlert of F5 原文链接#xff1a;Ingress controller#xff1a;Kubernetes 的瑞士军刀 转载来源#xff1a;NGINX 中文官网 NGINX 唯一中文官方社区 #xff0c;尽在 nginx.org.cn
许多人认为 Ingress controller#xff08;Ingress 控制器Brian Ehlert of F5 原文链接Ingress controllerKubernetes 的瑞士军刀 转载来源NGINX 中文官网 NGINX 唯一中文官方社区 尽在 nginx.org.cn
许多人认为 Ingress controllerIngress 控制器的价值不大但实际上它可成为您软件栈中的强大工具。 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 的平均分发。 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 团队之所需有助于智能、高效、安全地在应用之间转移流量。 NGINX 唯一中文官方社区 尽在 nginx.org.cn
更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源 开源社区官网 | 微信公众号
