Kubernetes 网络基础

NGINX | 2022年1月04日

NodePort、LoadBalancer、Ingress controller……真让人眼花缭乱！

在与客户和社区探讨如何让Kubernetes达到生产级要求时，最常见的问题之一是：是否需要Ingress控制器？这个问题很少能简单地用“是”或“否”来回答。要作出判断，需要先了解将流量引入Pod的不同方式。本文将介绍Kubernetes网络的基础知识，帮助您充分了解相关信息，从而判断是否需要以及何时需要Ingress控制器。

Kubernetes支持通过多种方式和不同层级将外部流量路由到Pod，但这些方式并非都能提供同等能力。默认模式是kube-proxy，它实际上并不是代理，也并非为流量负载均衡、API控制或服务行为监控而设计。

好在还有其他方法可以管理外部流量。不过在继续之前，我们先快速回顾一下Kubernetes组件：

Kubernetes部署由节点组成，节点是物理机或虚拟机。
节点组合在一起形成一个集群。
每个集群管理Pod。Pod是Kubernetes中网络和基础设施层面的最小基本单元。一个或多个Pod共同组成一项服务。
每个pod中包含一个或多个容器（具体取决于应用规模）。

Kubernetes会监控构成服务的Pod，并根据需要进行扩缩容，以满足应用要求。但如何将流量导向这些Pod？这就需要用到两类Kubernetes对象：Service和Ingress控制器。

什么是Kubernetes Service？

根据Kubernetes文档，服务是“一种用于公开在一组Pod上运行的应用的抽象方式”。服务可连接集群或容器网络中的Pod，使其在特定节点上的位置不再重要。这意味着，即使Pod的位置发生变化，甚至被销毁后重新启动，外部流量仍可路由到特定Pod。因此，服务的作用很像一个非常基础的反向代理。

有多种服务类型和服务对象类型可用于将外部流量路由到Kubernetes。它们经常被混淆，但实际上各自的作用截然不同，因此有必要了解它们的功能、用途和缺点。

ClusterIP

ClusterIP是默认服务类型，用于在Kubernetes中提供可供集群内其他服务访问的服务。无法从集群外部访问该服务。公开ClusterIP服务的唯一方法是使用类似kube-proxy的工具，但这种做法仅适用于少数场景，例如在笔记本电脑上访问服务、调试服务，或查看监控信息和指标。

NodePort

NodePort服务会在集群的每个节点上开放一个特定端口，并将发送到节点上该端口的所有流量转发至相应的应用。这是一种将流量传送至应用的基础方式，但在实际流量管理用例中存在诸多限制。每个NodePort只能对应一项服务，并且只能使用30000至32767范围内的端口。虽然2768个端口可能听起来很多，但大规模运行Kubernetes的组织很快就会用完这些端口。此外，NodePort使用第4层路由规则和Linux的iptables实用工具，因此会限制第7层路由。

除了路由方面的限制外，使用NodePort还有另外三大缺点：

下游客户端必须知道每个节点的IP地址才能与其连接。如果节点的IP地址或虚拟机主机发生变化，就会出现问题。
NodePort无法将流量代理到多个IP地址。
如图所示，NodePort不在Kubernetes集群内提供负载均衡，因此流量会随机分配到各项服务。这可能导致服务过载和端口耗尽。

LoadBalancer

LoadBalancer服务可接收外部流量，但需要使用外部负载均衡器作为该流量的接口。只要对外部负载均衡器进行适当调优和重新配置，使其映射到正在运行的Pod，即可支持第7层路由（路由到Pod IP地址）。LoadBalancer是对外公开服务的常用方式之一，最常用于云平台，适合小型静态部署。

如果使用托管式Kubernetes服务，系统会自动提供云提供商选定的负载均衡器。例如，在Google Cloud Platform上，可以使用LoadBalancer服务类型启动Network Load Balancer，而AWS默认使用Application Load Balancer（ALB）。公开的每项服务都会获得一个专属公共IP地址，用于转发所有流量，但不会进行任何筛选或路由。这意味着几乎可以发送任何类型的流量（HTTP、TCP/UDP、WebSocket等）。或者，如果不想使用云提供商的工具，例如需要更丰富的功能或与平台无关的工具，可以将其替换为F5 BIG-IP（用作外部负载均衡器）和F5 Container Ingress Services（用作承担LoadBalancer功能的操作器）。有关此模式的进一步讨论，请参阅博客文章在同一架构中部署BIG-IP和NGINX Ingress Controller。

在动态环境中，应用Pod需要扩缩容以满足不断变化的需求，此时使用LoadBalancer公开应用会面临挑战。由于每项服务都有自己的IP地址，热门应用可能需要管理数百甚至数千个IP地址。在大多数情况下，如下图所示，外部负载均衡器通过NodePort连接到服务。虽然这可以确保流量均匀分布到各个节点，但仍无法对服务进行负载均衡，因此仍会出现服务过载和端口耗尽问题。

使用Kubernetes LoadBalancer和NodePort对象公开Kubernetes服务的拓扑图

什么是Kubernetes Ingress Controller？

根据Kubernetes文档，“控制器是监视集群状态的控制循环，并根据需要执行或请求变更。每个控制器都会尝试让集群的当前状态更接近期望状态。”控制器用于管理Kubernetes中多种任务的状态，包括正确分配资源、指定持久化存储以及管理CronJob。

在路由场景中，Ingress控制器可用于克服NodePort和LoadBalancer的局限性。

Ingress控制器用于配置和管理外部与已标记为归属特定服务的Pod之间的交互。Ingress控制器在设计上将动态第7层路由作为核心功能。这意味着Ingress控制器能以更少的运维工作提供更精细的控制和管理。Ingress控制器不仅可用于控制入站流量，还可提供服务级性能指标，并作为安全策略的一部分。Ingress控制器具备传统外部负载均衡器的许多功能，例如TLS终止、处理多个域和命名空间，以及流量负载均衡。Ingress控制器可按请求而非按服务对流量进行负载均衡，从而更有效地呈现第7层流量，并更好地实施SLA。

此外还有一项优势：Ingress控制器还可以强制执行出站规则，仅允许特定Pod的出站流量访问指定的外部服务，或使用mTLS确保流量双向加密。在医疗、金融、电信和政府等行业提供受监管的服务时，强制使用mTLS至关重要；它也是端到端加密（E2EE）策略的关键组成部分。使用同一工具控制出站流量，还能简化业务逻辑在服务中的应用。将入站和出站流量关联到同一控制平面后，可以更轻松地设置适当的资源规则。

下图展示了Ingress控制器如何降低客户端的复杂性，使客户端无需再了解服务的IP地址或端口。流量可确保分配到各项服务。部分Ingress控制器支持多种负载均衡算法，可提供更高的灵活性和更精细的控制。

使用Ingress控制器部署负载均衡器

正如我们在《在同一架构中部署BIG-IP和NGINX Ingress Controller》中所述，许多组织的用例可受益于将外部负载均衡器与Ingress Controller（多数情况下为多个Ingress Controller实例）结合部署。当组织需要扩展Kubernetes或在高合规性环境中运营时，这种做法尤为常见。这些工具通常由不同的团队管理，并用于不同的目的：

负载均衡器（或ADC）：
- 负责人：NetOps团队（也可能是SecOps团队）
- 用例：部署在Kubernetes外部，作为面向公众的唯一端点，向集群外部用户交付服务和应用。作为一种更通用的设备，旨在增强安全性并提供更高级别的网络管理。
Ingress控制器：
- 负责人：平台运维或DevOps团队
- 用例：在Kubernetes内部对南北向流量（HTTP2、HTTP/HTTPS、SSL/TLS终止、TCP/UDP、WebSocket、gRPC）进行精细化负载均衡，并提供API网关功能以及集中式安全和身份管理。

此图显示负载均衡器如何在多个集群之间分配流量，而各集群中的Ingress控制器可确保流量均匀分配到各项服务。