NodePort、LoadBalancer 与 Ingress 的对比：选择最佳的服务暴露方式

NodePort、LoadBalancer 与 Ingress 对比：如何选择最佳服务暴露方式

Kubernetes Service 是基础对象，为动态的 Pod 集合提供稳定的网络连接。虽然 Service 负责处理集群内部通信，但若要对外暴露这些服务（允许用户或外部应用程序与之交互），则需要特定的配置。选择正确的暴露方法至关重要，它会影响安全性、成本和复杂性。

本文将专家级地比较暴露 Kubernetes Service 的三种主要方法：NodePort、LoadBalancer 和 Ingress。我们将分析它们的工作机制、合适的用例以及实际因素，以指导您为容器化应用选择最佳解决方案。

1. 服务暴露类型：NodePort

NodePort 服务类型是外部暴露服务最简单、最原始的方式。当您将服务定义为 NodePort 时，Kubernetes 会在集群中的每个节点上打开一个特定的静态端口。导向到任何节点上该端口的流量都会直接路由到该服务。

NodePort 的工作原理

自动选择指定范围（默认：30000-32767）内的一个随机端口。
此端口在所有集群节点上打开。
Service 在此 NodePort 上监听，并将流量转发到相应的 Pod。

要访问应用程序，您可以使用 http://<Node_IP>:<NodePort>。

用例和局限性

特性	描述
用例	开发、测试环境，或由外部的非云设备处理外部负载均衡的场景。
复杂度	非常低。
成本	零（如果忽略底层虚拟机成本）。
局限性	需要手动管理外部防火墙规则。节点 IP 通常是动态的。存在端口范围限制 (30000-32767)。

NodePort 示例

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Optional: specify a NodePort, otherwise one is chosen automatically
      # nodePort: 30001

⚠️ 警告： NodePort 通过所有节点暴露服务。如果某个节点被移除或其 IP 发生变化，外部访问就会中断。因此，通常不建议在依赖稳定性的生产环境中使用此方式。

2. 服务暴露类型：LoadBalancer（负载均衡器）

LoadBalancer 服务类型是在云环境（AWS EKS、GCP GKE、Azure AKS）中将应用程序暴露到公共互联网的标准方法。

当服务被定义为 LoadBalancer 时，Kubernetes 会自动预置一个专用的第 4 层 (L4) 云负载均衡器（例如，AWS 经典 ELB/NLB、Azure Load Balancer、GCP Network Load Balancer）。这提供了一个稳定、高可用的外部 IP 地址，可将流量直接路由到服务 Pod。

云提供商集成

LoadBalancer 的主要区别在于其与底层云基础设施的深度集成。云提供商负责处理负载均衡器的生命周期、健康检查和路由。

用例和成本影响

特性	描述
用例	需要专用、稳定 IP 地址的简单、面向公众的应用程序。适用于非 HTTP/S 协议 (TCP/UDP)。
复杂度	低（配置方面）。
成本	高。每个 LoadBalancer 服务都会预置一个专用的云资源，通常会产生小时费用。
优点	立即提供高可用性和自动健康检查。

LoadBalancer 示例

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: my-api-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

创建后，集群将分配一个由云提供商管理的外部 IP 地址（可在服务状态中查看）。

3. Kubernetes Ingress：第 7 层路由

Ingress 与 NodePort 和 LoadBalancer 有根本区别。Ingress 不是 Service 类型，而是一个 API 对象，它定义了外部访问的规则，通常针对 HTTP 和 HTTPS（第 7 层，L7）。

Ingress 充当中央入口点，允许基于主机名和 URL 路径进行复杂的路由。这种方法对于在单个 IP 地址后管理多个服务至关重要。

Ingress Controller 的作用

要使 Ingress 规则生效，您必须首先部署一个 Ingress Controller（例如 Nginx、Traefik、Istio）。Controller 会监视 Ingress 资源定义，并根据这些规则配置底层的反向代理/L7 负载均衡器。

至关重要的是，Ingress Controller 本身通常是使用单个 LoadBalancer 或 NodePort 服务暴露的。

Ingress 的高级特性

当您需要高级流量管理功能时，Ingress 优势明显：

成本优化： 使用单个云 LoadBalancer（用于暴露 Controller），而不是为每个应用程序服务都使用一个 LoadBalancer。
虚拟主机： 基于主机名路由流量（api.example.com 到 Service A；www.example.com 到 Service B）。
基于路径的路由： 基于 URL 路径路由流量（/v1/users 到 Service A；/v2/posts 到 Service B）。
SSL/TLS 终止： 集中处理证书管理和解密。

Ingress 资源示例

此示例将 api.example.com/v1 的流量路由到 my-api-v1 服务。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Specify the controller in use
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... other rules for different services/hosts

4. 比较与选择指南

选择最佳方法需要权衡环境、复杂度、功能集和运营成本等因素。

功能比较表

特性	NodePort	LoadBalancer	Ingress
层级	L4 (TCP/UDP)	L4 (TCP/UDP)	L7 (HTTP/S)
稳定性 (IP)	不稳定（使用节点 IP）	稳定（专用云 IP）	稳定（使用 Controller 的 IP）
成本	低（但运营开销高）	高（按服务计算资源成本）	中等（Controller 仅需一个 LoadBalancer）
路由逻辑	简单端口转发	简单端口转发	主机名、路径、SSL 终止
云依赖性	无	高	高（需要通过 LoadBalancer 暴露 Controller）
生产就绪度	否	是（简单应用）	是（复杂应用）

决策标准：选择您的暴露方法

仅用于内部或测试： 如果您只需要测试集群内部的连接性，或者您自行管理外部网络（例如在裸金属环境中），请使用 NodePort。
用于简单、专用的 L4 暴露： 如果您的应用程序使用非 HTTP 协议（如自定义 TCP 协议或 UDP），或者您只有一个需要立即、专用 L4 访问的公共应用程序，请使用 LoadBalancer。
用于复杂、多服务的 L7 暴露： 如果您需要暴露多个服务，需要基于路径或主机名进行路由，需要集中式 SSL 终止，或者希望通过共享单个外部 IP 来最大程度地降低云成本，请使用 Ingress。

最佳实践： 对于托管云环境中的生产部署，Ingress 通常是首选。它为管理不断增长的微服务数量提供了必要的复杂性、安全集中化和成本效益。

结论

Kubernetes 为服务暴露提供了一系列解决方案，从基本的 L4 NodePort，到云集成的 L4 LoadBalancer，再到 Ingress 复杂的 L7 路由能力。通过理解每种方法的运行层级、成本模型和所需的路由逻辑，工程师可以设计出可扩展、安全且具有成本效益的生产工作负载网络架构。