1. 引言
现代软件系统通常需要与外部服务进行通信，比如调用 API 或发送消息。这些交互是系统正常运行的关键。随着越来越多的应用部署在 Kubernetes 集群中，如何安全、可靠地对外暴露这些服务，成为了一个挑战。
Kubernetes 提供了多种机制来管理网络流量，其中两个常用的方案是 Ingress 和 LoadBalancer（负载均衡器）。本文将深入解析它们的工作原理、适用场景以及区别，帮助你在实际项目中做出合适的技术选型。
2. 工作负载与服务
2.1 工作负载与 Pod
在 Kubernetes 中，应用程序通常被打包成 Docker 镜像，然后通过工作负载控制器部署。常见的工作负载类型包括：
- ReplicaSet：确保指定数量的 Pod 始终运行
- StatefulSet：用于有状态应用，提供稳定的网络标识和存储
- DaemonSet：确保每个节点上运行一个 Pod
这些工作负载最终会创建出一个或多个 Pod，Pod 是 Kubernetes 中最小的可部署单元，代表集群中运行的一个应用实例。
每个 Pod 都有唯一的 IP 地址，但直接使用 Pod IP 通信是不推荐的，原因如下：
✅ Pod IP 是动态分配的
✅ Pod 可能随时被重启或调度到其他节点
✅ 应用之间难以维护 IP 列表进行通信
2.2 Service
为了解决上述问题，Kubernetes 提出了 Service 的概念。它是一种抽象机制，将一组 Pod 暴露为网络服务。Service 会自动维护其背后 Pod 的 IP 列表，并分配一个稳定的访问地址。
以下是一个 Service 的 YAML 示例：
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
selector:
app: api-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
该 Service 会将流量转发给标签为 app: api-app 的所有 Pod。即使 Pod 被重建，Service 也能自动发现并更新后端。
3. Ingress
3.1 基本概念
默认情况下，Service 是集群内部的资源，外部无法直接访问。为了对外暴露服务，Ingress 提供了一种集中式的 HTTP/HTTPS 路由机制。
Ingress 的作用是将外部流量路由到集群内的一个或多个 Service。它通常作为所有外部请求的统一入口点，具备以下能力：
✅ 路由规则（基于路径或域名）
✅ SSL 终止
✅ 负载均衡
✅ URL 重写等高级功能
⚠️ 注意：Ingress 本身只是一个资源对象，需要配合 Ingress Controller 才能真正生效。
3.2 Ingress Controller
Kubernetes 并不内置 Ingress Controller，需要由集群管理员自行安装。常见的开源实现有：
- NGINX Ingress Controller
- Traefik
- HAProxy Ingress
以下是一个使用 NGINX Ingress Controller 的示例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
该 Ingress 会将路径 /api 的请求转发给名为 api-service 的 Service。
⚠️ 注意：不同 Ingress Controller 支持的功能和注解不同，需根据实际使用的控制器进行配置。
4. 负载均衡器（LoadBalancer）
4.1 基本概念
LoadBalancer 是 Kubernetes Service 的一种类型，用于将服务暴露到公网。它通常由云厂商提供，比如：
- AWS：Network Load Balancer（NLB）
- GCP：Network Load Balancer
- Azure：Public Load Balancer
以下是一个 LoadBalancer 类型的 Service 示例：
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
selector:
app: api-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer
该 Service 会自动创建一个外部负载均衡器，并将公网 IP 分配给 Service。
4.2 特点与限制
✅ 提供公网访问入口
✅ 支持 SSL 终止
❌ 通常只能绑定一个 Service
❌ 成本较高（云厂商按资源收费）
❌ 配置方式可能依赖 CLI 或图形界面，而非纯 YAML
5. Ingress 与 LoadBalancer 对比总结
| 特性 | Ingress | LoadBalancer |
|---|---|---|
| 类型 | Kubernetes 原生资源 | Service 类型 |
| 控制器 | 需要 Ingress Controller | 通常由云厂商提供 |
| 路由能力 | 支持多 Service 路由 | 仅支持单 Service |
| 协议支持 | 主要是 HTTP/HTTPS | 支持 TCP/UDP 等多种协议 |
| 成本 | 通常不额外收费 | 通常需额外付费 |
| 配置灵活性 | 高（可通过注解扩展） | 依赖云平台配置工具 |
| 适用场景 | 多服务统一入口、Web 应用 | 简单服务暴露、非 HTTP 场景 |
6. 总结
Ingress 和 LoadBalancer 都能实现对外暴露服务，但它们的实现机制和适用场景有所不同：
✅ Ingress 更适合用于统一管理多个 HTTP 服务的路由，尤其适合微服务架构下多个服务共享一个公网入口的场景。
✅ LoadBalancer 更适合用于暴露单一服务，尤其在需要支持 TCP/UDP 协议或对性能有更高要求的场景。
在实际项目中，你可以根据集群规模、服务数量、预算以及云平台支持情况，灵活选择或结合使用这两种方式。
如果你正在搭建微服务系统，推荐优先使用 Ingress + Service 架构，以实现更灵活的流量管理与统一入口控制。