Kubernetes 网络 101

NodePort、LoadBalancer、Ingress 控制器......天哪！

当我们与客户和社区讨论如何使 Kubernetes 达到生产级时，最常见的问题之一是：我需要 Ingress 控制器吗？ 这个问题的答案很少是简单的“是”或“否”，而是需要了解一些有关如何将流量引导至你的 pod 的不同方法。 在这篇博客中，我们介绍了 Kubernetes 网络的基础知识，以便您可以做出明智的决定，确定是否以及何时需要 Ingress 控制器。

Kubernetes 支持多种可能的方法和层来将外部流量路由到 pod - 但它们并不是都是一样的。 默认模型是kube-proxy ，它实际上不是一个代理，也不是为了平衡流量、控制 API 或监控服务行为而设计的。

幸运的是，还有其他方法可以管理外部流量，但在继续之前，让我们快速回顾一下 Kubernetes 组件：

• Kubernetes 部署由节点组成，节点可以是物理机或虚拟机。
• 节点连接在一起形成一个集群。
• 每个集群管理pod ，这是 Kubernetes 中网络和基础设施级别的最低公分母。 一个或多个 pod 共同组成一个服务。
• 每个 pod 内部有一个或多个容器（取决于应用大小）。

Kubernetes 监视组成服务的 pod，并根据需要扩展它们以满足应用程序要求。 但是如何将流量引导至这些 pod 呢？ 这就是两种类型的 Kubernetes 对象的用武之地：服务和 Ingress 控制器。

什么是 Kubernetes 服务？

根据Kubernetes 文档，服务是“公开一组 Pod 上运行的应用程序的抽象方式”。 服务连接容器集群或网络中的 pod，使得它们在特定节点上的位置无关紧要。 这意味着即使特定 pod 的位置发生变化，或者被销毁并重新启动，外部流量也可以被路由到特定的 pod。 通过这种方式，服务的行为很像一个非常基本的反向代理。

有多种类型的服务和服务对象类型与将外部流量路由到 Kubernetes 相关。 它们常常被混淆，但事实上它们各自的功能截然不同，因此值得研究它们的功能、用途和缺点。

集群IP

ClusterIP 是 Kubernetes 中的默认服务，它提供集群内其他服务可以访问的服务。 无法从集群外部访问它。 公开 ClusterIP 服务的唯一方法是使用kube-proxy之类的东西，但在少数情况下这种方法才有意义。 有限的示例包括访问笔记本电脑上的服务、调试服务或查看一些监控和指标。

节点端口

NodePort 服务会在集群中的每个节点上打开一个特定端口，并将发送到该端口上节点的任何流量转发到相应的应用程序。这是将流量传送到应用程序的一种非常基本的方法，在实际的流量管理用例中存在许多限制。 每个 NodePort 只能有一个服务，并且只能使用 30000 到 32767 范围内的端口。 虽然 2768 个端口听起来很多，但大规模运行 Kubernetes 的组织很快就会用完。 此外，NodePort 使用第 4 层路由规则和 Linux iptables实用程序，限制第 7 层路由。

除了路由限制之外，使用 NodePort 还有另外三个大缺点：

• 下游客户端必须知道每个节点的 IP 地址才能与其连接——如果节点的 IP 地址或虚拟机主机发生变化，就会出现问题。

• NodePort 无法将流量代理到多个 IP 地址。

• 如图所示，NodePort 不提供 Kubernetes 集群内的负载均衡，因此流量在服务之间随机分布。 这可能会导致服务过载和端口耗尽。

  

负载均衡器

LoadBalancer 服务接受外部流量，但需要外部负载均衡器作为该流量的接口。 这支持第 7 层路由（到 pod IP 地址），前提是外部负载均衡器经过适当调整和重新配置以映射到正在运行的 pod。 LoadBalancer 是向外部公开服务最流行的方式之一。 它最常用于云平台，是小型静态部署的理想选择。

如果您使用托管的 Kubernetes 服务，您将自动获得云提供商选择的负载均衡器。 例如，在 Google Cloud Platform 上，您可以使用 LoadBalancer 服务类型启动网络负载均衡器，而application负载均衡器 (ALB) 是 AWS 中的默认服务。 您公开的每个服务都有自己的公共 IP 地址，用于转发所有流量，但不进行任何过滤或路由，这意味着您可以发送几乎任何类型的流量（HTTP、TCP/UDP、WebSocket 等）。 或者，如果您不想使用云提供商的工具 - 例如如果您需要更强大的功能或与平台无关的工具 - 您可以将其替换为F5 BIG-IP （作为外部负载均衡器）和F5 Container Ingress Services （作为充当 LoadBalancer 容量的操作员）。 有关此模式的进一步讨论，请参阅我们博客上的在同一架构中部署 BIG-IP 和 NGINX Ingress Controller 。

在动态环境中，使用 LoadBalancer 来公开您的应用程序会变得很有挑战性，因为您的应用程序 pod 需要扩展以满足不断变化的需求水平。 由于每个服务都有自己的 IP 地址，因此一个流行的应用程序可能需要管理数百个甚至数千个 IP 地址。 大多数情况下，外部负载均衡器通过 NodePort 连接到服务，如下图所示。 虽然这可以保证流量在各个节点之间均匀分布，但仍然无法实现服务的负载均衡，因此仍然会遇到服务过载和端口耗尽的情况。

什么是 Kubernetes Ingress Controller？

根据Kubernetes 文档，“控制器是监视集群状态的控制循环，然后在需要时进行或请求更改。 每个控制器都试图使当前集群状态更接近期望状态。” 控制器用于管理 Kubernetes 中的许多任务的状态：正确分配资源、指定持久存储以及管理 cron 作业。

在路由环境中， Ingress 控制器是克服 NodePort 和 LoadBalancer 限制的方法。

Ingress 控制器用于配置和管理与标记为特定服务的 pod 的外部交互。 入口控制器旨在将动态第 7 层路由视为一等公民。 这意味着 Ingress 控制器能够以更少的辛劳提供更精细控制和管理。 您可以轻松使用 Ingress 控制器，不仅控制入口流量，还可以提供服务级别性能指标并作为安全策略的一部分。 入口控制器具有传统外部负载均衡器的许多功能，例如 TLS 终止、处理多个域和命名空间，当然还有负载均衡流量。 Ingress 控制器可以按请求而不是按服务级别平衡流量负载，这是第 7 层流量的更有用的视图，也是执行 SLA 的更好方法。

还有另外一项福利！ 入口控制器还可以强制执行出口规则，仅允许从某些 pod 传出的流量流向特定的外部服务，或者确保使用 mTLS 相互加密流量。 要求 mTLS 对于在医疗保健、金融、电信和政府等行业提供受监管的服务至关重要 - 并且它是端到端加密 (E2EE) 策略中的关键组成部分。 从同一工具控制传出流量也简化了业务逻辑对服务的应用。 当入口和出口都链接到同一个控制平面时，设置适当的资源规则要容易得多。

下图展示了 Ingress 控制器如何降低客户端的复杂性，客户端不再需要知道服务的 IP 地址或端口。 保证各个服务的流量分配。 一些 Ingress 控制器支持多种负载平衡算法，以实现更大的灵活性和控制力。

使用入口控制器部署负载均衡器

正如我们在同一架构中部署 BIG-IP 和 NGINX Ingress 控制器中讨论的那样，许多组织都有使用案例，这些案例受益于部署带有 Ingress 控制器（或在大多数情况下，多个 Ingress 控制器实例）的外部负载均衡器。 当组织需要扩展 Kubernetes 或在高合规性环境中运行时，这种情况尤其常见。 这些工具通常由不同的团队管理并用于不同的目的：

• 负载均衡器（或 ADC）：

  • 所有者： NetOps（或者可能是 SecOps）团队
  • 用例： 在 Kubernetes 之外，作为向集群外的用户提供服务和应用的唯一面向公众的端点。 用作更通用的设备，旨在促进安全性并提供更高级别的网络管理。

• 入口控制器：

  • 所有者： 平台运营或 DevOps 团队
  • 用例： Kubernetes 内部用于南北流量（HTTP2、HTTP/HTTPS、SSL/TLS 终止、TCP/UDP、WebSocket、gRPC）的细粒度负载均衡、API 网关功能以及集中式安全和身份。

该图显示了负载均衡器处理跨多个集群的流量分配，而集群具有 Ingress 控制器以确保平等地分配服务。

下一步

如果您已经阅读了所有这些内容但仍然感到困惑，请查看 Linux 基金会网络研讨会“为什么需要入口控制器以及如何选择一个” ，其中 NGINX 的专家提供了 Kubernetes 网络入门知识，深入研究了入口控制器，并讨论了入口控制器概况。

有关如何使用 Ingress 控制器以及如何选择最适合您需求的控制器的更多信息，请阅读“选择 Ingress 控制器的指南，第 1 部分”： 确定您的需求 在我们的博客上。