深入浅出 Kubernetes Service：详解 type: LoadBalancer 的工作原理与流量生命周期-尧图网络科技

深入浅出 Kubernetes Service：详解 type: LoadBalancer 的工作原理与流量生命周期

在云原生架构中，我们将应用部署到 Kubernetes (K8s) 集群后，面临的第一个核心问题就是：如何让集群外部的用户或系统安全、高效地访问我们的服务？

Kubernetes 提供了多种 Service 类型，其中type: LoadBalancer是生产环境暴露服务最常用的标准方案。本文将结合一个实际的 YARP 反向代理网关配置，带你彻底搞懂LoadBalancer的核心作用、流量流向以及它背后的工作机制。

一、先看一段典型的 K8s 配置

假设我们正在集群中部署一个基于 .NET 的YARP (Yet Another Reverse Proxy)网关，为了让外部流量能够打到这个网关上，我们编写了如下的 Service 配置文件service.yaml：

apiVersion:v1kind:Servicemetadata:name:yarp-ingress-lbnamespace:defaultspec:selector:app:yarp-gateway# 1. 寻找带有该标签的 Pod 容器ports:-name:custom-portprotocol:TCPport:9999# 2. 负载均衡器/Service 对外开放的 9999 端口targetPort:9999# 3. 流量最终直接转发到容器内部监听的 9999 端口type:LoadBalancer# 4. 声明服务类型为外部负载均衡器

二、 type: LoadBalancer 的核心作用是什么？

简单来说，type: LoadBalancer的核心作用是：自动在集群外部创建一个负载均衡器实例，为集群提供一个统一、固定且高可用的外网（或内网）访问入口。

在没有LoadBalancer之前，K8s 暴露服务主要靠以下两种方式，但它们都有各自的局限性：

ClusterIP：默认类型。只能在集群内部访问，外部完全隔绝。
NodePort：在每个节点上随机开放一个大端口（30000-32767）。如果节点 IP 变动或节点宕机，外部客户端就需要手动修改连接地址，极不稳定。

而LoadBalancer完美解决了这些痛点。它像是集群大门外的一位高级向导，无论后端的服务器（Node）如何漂移，或者容器（Pod）如何扩缩容，外部用户只需要认准负载均衡器这一个固定 IP 即可。

三、拆解：流量是如何一步步进到容器的？

结合上面的 YAML 配置，当一个外部请求试图访问我们的 YARP 网关时，流量会经历以下4 个生命周期阶段：

[ 外部客户端 ]│ 访问公网 IP:9999
[ 云厂商负载均衡器 (SLB/ALB/NLB) ]│ 分发流量到集群节点
[ K8s 节点网络 / Service (Port: 9999) ]│ 通过 iptables/IPVS 路由
[ 目标 Pod 容器 (targetPort: 9999) ] -> 成功进入 YARP 网关！
第一步：客户端发起请求
用户访问云厂商分配给该 LoadBalancer 的External IP（外部公网 IP），指定端口为port: 9999。
第二步：云端负载均衡分发
外部负载均衡器接收到流量后，会自动将请求分发到 Kubernetes 集群中健康的工作节点（Worker Nodes）。
第三步：Service 内部路由
流量到达节点后，K8s 的kube-proxy组件会通过内核的 iptables 或 IPVS 规则，识别出这是发送给yarp-ingress-lb这个 Service 的流量。
第四步：容器精准接收
Service 根据selector: app: yarp-gateway标签，找到当前存活的 Pod，并将流量精准投递到容器内部正在监听的targetPort: 9999上。

四、平台差异：公有云 vs 自建本地集群

细心的同学可能会发现，在不同的环境下部署相同的 YAML，结果却完全不同：

1. 托管公有云环境（如阿里云、腾讯云、AWS、Azure）

这是LoadBalancer的标准舞台。当你提交这段 YAML 后，云厂商的 Cloud Provider 控制器会立刻识别，并在你的云账号下自动创建并计费一个物理负载均衡器（如阿里云 SLB、AWS NLB）。

成功后，通过kubectl get svc可以看到EXTERNAL-IP一栏会显示一个真实的公网 IP。

2. 本地自建裸金属集群（Bare-metal / Minikube / K3s）

如果你在自己搭建的虚拟机或物理机上运行这段 YAML，你会发现EXTERNAL-IP会长时期卡在<pending>状态。

原因：自建集群没有对接云厂商的 API，K8s 找不到谁来帮它生成这个“外部负载均衡器”。
本地解决方案：
- 测试环境：可以使用kubectl port-forward进行端口转发。
- 生产环境：需要额外在集群内安装开源组件MetalLB或OpenELB，它们可以在局域网内通过 ARP/BGP 协议模拟出 LoadBalancer 的效果。