什么是 Kubernetes 入口控制器？

现代企业非常依赖的分布式应用和工作负载由数十或数百个微服务构建而成。如果没有适当的流量编排，每个服务都需要自己的公共端点，这将带来严重的管理和安全问题。

例如，医疗保健平台可能需要为患者门户、提供商仪表板、计费系统和合规报告提供单独的访问点，这种方法变得昂贵且操作复杂。

Kubernetes 入口控制器通过在应用程序入口点充当负载均衡器和智能流量路由器来解决此问题。它为外部用户访问内部服务建立了集中的流量路由。

Kubernetes 生态系统提供各种入口控制器，包括可在 GitHub 等平台上使用的开源工具（例如 NGINX、Traefik）和旨在满足特定组织需求的专有解决方案。

Kubernetes 最初由 Google 开发，并于 2015 年捐赠给云原生计算基金会 (CNCF)，目前为众多财富 500 强公司的关键 IT 基础设施提供支持，使入口控制器管理成为了企业运营的关键环节。根据 2022 年的一项调研，96% 的组织正在使用 Kubernetes 或评估这项技术是否适用于生产环境。¹

在 Kubernetes 出现之前，应用程序通常在专用服务器或虚拟机 (VM) 上运行，这使得扩展成本高昂且耗时。Kubernetes 引入了容器，这种轻量级、可移植的单元可将应用程序及其所有依赖项打包在一起。

Kubernetes 彻底改变了 DevOps 开发运维工作流程和应用程序部署，方法是大规模引入容器编排。这个开源平台可自动部署、扩展和管理分布式基础设施中的容器化应用程序，从而实现开发和运营团队之间的无缝协作。

Kubernetes 将应用程序组织成 pod，即由一个或多个容器（通常是 Docker 容器）组成的最小可部署单元。这些 pod 在集群内的工作节点上运行，而控制平面协调所有集群操作。服务为 pod 组提供稳定的网络身份，从而实现可靠的通信模式。

入口控制器通常部署为为专用 Pod，通过 Kubernetes API 监控聚类状态。这类控制器可跟踪入口资源（即定义流量路由规则的配置对象）的变化，并自动更新其路由表以反映新的应用程序部署或配置更新。

要了解入口控制器的工作原理，必须了解 Kubernetes 入口，即定义将外部流量定向到 Kubernetes 集群内服务的路由规则的 API 资源（或入口对象）。

Kubernetes 入口不同于通用术语“入口”，后者是指流入云原生容器化应用程序环境的传入网络流量。在 Kubernetes 中，入口 (Ingress) 特指一组规则和配置，用于管理传入流量如何路由到不同的服务。与之相对，更广泛意义上的入口 (ingress) 仅指进入系统的任何流量（与之相对，出口 (egress) 是指流出系统的流量）。

阅读更多关于 Kubernetes 中入口与出口的信息。

Kubernetes 入口提供了一种声明性方法来管理对 Kubernetes 集群内服务的外部访问。入口不是将单个服务（例如 NodePort、LoadBalancer 服务）直接暴露给互联网，而是创建一个受控访问层，根据多个条件智能路由请求。此功能支持有效管理服务的外部流量，这些流量通常通过在 Kubernetes 集群中使用 ClusterIP 公开。

Kubernetes 入口通过两个互补的组件运行。

入口资源（又称“Kubernetes 资源”或“Kubernetes API 对象”）可定义路由规则。它们以 YAML 或 JSON 形式定义，并指定入口规则、SSL 证书、身份验证要求和流量策略。

例如，用户可以使用 ingressClassName 字段来确定管理资源的入口控制器，当聚类中存在多个控制器时即可将流量定向至特定控制器。

入口控制器是用于读取和应用配置规则的软件组件，可充当具备高级流量管理能力的反向代理。

传统的第 4 层负载均衡器，例如用于 TCP、UDP 和 HTTP/HTTPS 路由的负载均衡器，仅基于 IP 地址和端口分配流量。相比之下，Kubernetes 入口控制器运行在第 7 层（应用程序层），从而可实现更复杂的路由。

利用 Kubernetes 入口 API 和 HTTPRoute 等功能，入口控制器根据详细的 HTTP 特定属性做出路由决策，例如：

• URL 路径和主机名
• HTTP 标头和方法
• 请求内容和 Cookie
• 身份验证令牌和用户上下文

这些决策基于规定路由策略和其他要求的配置规则而制定。入口控制器可持续监控配置变化，自动更新路由行为，且无需人工干预，以确保无缝流量分配和安全管理。

Kubernetes 集群可以同时运行多个入口控制器，各控制器处理不同的流量类型或应用程序。每个控制器都以事件驱动的方式运行，通过读取规范、注释和元数据来响应入口资源的变化，然后将它们转换为可执行的路由指令。

Kubernetes 入口控制器检查传入请求并根据预定义的规则（例如主机名和 DNS 名称）做出路由决策。它们处理 HTTP 和 HTTPS 流量，执行 SSL 终止，并在多个服务实例之间做出智能的负载均衡决策。

Kubernetes 入口控制器可持续监控 Kubernetes API，以了解跨命名空间的入口资源变化。无论这些变化是通过 kubectl、CI/CD 管道还是其他工具（例如 Helm、Terraform）实现，控制器都会自动更新路由规则，而无需人工干预或重启服务。

负载均衡功能内置于大多数 Kubernetes 入口控制器中，可在同一服务的多个实例之间分配传入请求，从而确保最佳性能并防止任何单个实例不堪重负。

现代 Kubernetes 入口控制器包括复杂的 SSL/TLS 管理能力，例如 TLS 终止、自动证书配置、续订和安全通信实施。

高级 Kubernetes 入口控制器可持续监控后端服务的健康状况，并自动将流量路由至故障实例以外的节点，以确保高度可用性并提升用户体验。

• 基础设施整合：传统架构通常需要为每个应用程序配备专用的负载均衡器，从而产生大量的硬件和运营成本。入口控制器使组织能够整合共享基础设施背后的多个应用程序，从而降低负载均衡成本并提高资源利用率。
• 加快开发周期：开发团队可以部署和测试新功能，而无需网络管理员或配置外部负载均衡器。入口控制器支持 GitOps 工作流，其中路由更改通过版本控制和自动部署管道进行管理。
• 增强的可观测性：为了提供增强的可观测性，现代入口控制器提供有关应用程序使用模式、用户行为和性能瓶颈的详细分析。这种可见性使得有关容量规划、功能采用和用户体验优化的数据驱动决策成为可能。
• 自动安全实施：组织无需跨多个系统配置安全策略，而是可以通过入口控制器策略强制执行身份验证、授权、速率限制、WAF（网络应用程序防火墙）规则和 DDoS 保护。可以在所有应用程序中即时部署安全更新。
• 云可移植性：与特定于云的负载均衡服务不同，入口控制器在不同的云供应商和本地部署基础设施之间提供一致的功能。应用程序可以在不同环境之间迁移，而无需更改架构。
• 动态扩展能力：入口控制器可根据实时流量条件、后端容量和配置策略自动调整路由模式。此功能支持复杂的流量整形，以适应不断变化的业务条件。

• 性能考虑因素：所有外部流量都流经入口控制器，使其成为生产环境中的潜在瓶颈。组织必须仔细规划容量，实施适当的监控并设计冗余战略，以确保高可用性。
• 学习曲线和运营开销：团队需要培养 Kubernetes 网络概念、YAML 配置管理和分布式系统故障排除方面的专业知识，这可能需要大量的培训和操作调整。

选择合适的 Kubernetes 入口控制器取决于组织要求、现有基础设施和团队功能。每种实施方式都针对特定用例提供独特的优势：

• NGINX 入口控制器：NGINX 入口控制器 (ingress-nginx) 是采用最广泛的选项，提供企业级性能和广泛的定制功能。NGINX 成熟的生态系统提供全面的文档、商业支持选项和经过验证的可扩展性。
• Traefik 入口控制器：Traefik 专为现代云原生环境而设计，强调自动服务发现和易用性。Traefik 在 Kubernetes 服务频繁变化的动态环境中表现出色，提供与服务网格和容器注册表的内置整合。
• HAProxy 入口控制器：HAProxy 入口控制器基于行业标准 HAProxy 负载均衡器构建，为高流量场景提供稳健的性能。该控制器支持高级负载均衡算法、详细的统计数据和精细的流量控制。
• Istio Gateway：作为综合 Istio 服务网格平台的一部分，Istio Gateway 具有高级流量管理、安全性和可观测性特征。Istio Gateway 还支持复杂的功能，例如流量分割、故障注入和分布式跟踪。
• 云供应商解决方案：主要云供应商提供与其平台深度集成的优化入口控制器。AWS 负载均衡器控制器、Google Cloud 负载均衡器、Azure Application Gateway 入口控制器和 IBM® Cloud Application 负载均衡器可提供与云原生服务、自动扩展和简化计费的无缝整合。
• 基于 Envoy 的控制器：基于 Envoy 代理构建的入口控制器（包括 Ambassador 和 Emissary-Ingress）可提供具有高级可观测性的高性能流量管理。这些解决方案通常包括内置身份验证、速率限制和 API 网关功能，使其适合构建全面 API 管理策略的组织。