k8s中服务的类型-LoadBalancer详解

LoadBalancer 是 Kubernetes Service 的另一种类型，它是专为云环境设计的，用于将服务直接暴露给互联网。

如果说 ClusterIP 是内网地址，NodePort 是在每个节点上开窗户，那么 LoadBalancer 就是云厂商为你专门搭建的一座外部桥梁。它会自动请求云提供商（如阿里云、AWS、腾讯云、Azure 等）创建一个外部的负载均衡器实例，并将流量转发到集群内部。

1. 核心定义

• 云原生集成：LoadBalancer 类型严重依赖云提供商的支持。当你创建这种类型的 Service 时，Kubernetes 会通过云控制器管理器（Cloud Controller Manager）调用云厂商的 API，自动申请并配置一个外部的负载均衡器（例如阿里云的 SLB、AWS 的 ELB）。
• 独立公网 IP：云厂商会分配一个独立的公网 IP 地址（External IP）给这个负载均衡器。外部用户只需访问这个 IP，无需关心集群节点的 IP。
• 自动运维：如果后端 Pod 变化或节点故障，Kubernetes 会自动更新云负载均衡器的后端配置，确保高可用。
• 底层机制：在大多数云实现中，外部负载均衡器接收流量后，实际上是将流量转发到集群节点的 NodePort 上，然后再由 kube-proxy 转发给 Pod。

2. 工作流程

1. 用户创建 Service：用户在 K8s 中定义一个 type: LoadBalancer 的 Service。
2. 调用云 API：K8s 控制平面检测到该请求，通知云控制器管理器。
3. 创建云资源：云控制器调用云厂商 API，创建一个实际的负载均衡器实例（包括监听器、后端服务器组等）。
4. 分配 IP：云厂商分配一个公网 IP，并将其更新到 Service 的 EXTERNAL-IP 字段中。
5. 流量接入：
   • 外部用户访问 http://<External-IP>:<Port>。
   • 流量到达云负载均衡器。
   • 云负载均衡器将流量转发到集群中任意节点的 <NodeIP>:<NodePort>。
   • 节点上的 kube-proxy 将流量最终转发给目标 Pod。

3. YAML 配置示例

apiVersion: v1
kind: Service
metadata:
  name: my-public-service
  annotations:
    # 不同云厂商可能有特定的注解来配置 LB 的类型、带宽、计费方式等
    # 例如阿里云指定负载均衡类型为公网：
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: "internet"
spec:
  type: LoadBalancer
  selector:
    app: my-web-app
  ports:
    - protocol: TCP
      port: 80        # 负载均衡器监听的端口
      targetPort: 8080 # 容器端口
      # nodePort: 30080 # 通常不需要手动指定，系统会自动分配
  loadBalancerIP: ""  # (可选) 某些云支持指定固定的公网 IP，留空则自动分配

查看状态： 创建后，可以通过以下命令查看分配到的外部 IP：

1kubectl get svc my-public-service

输出示例：

1NAME                TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
2my-public-service   LoadBalancer   10.96.12.34    47.100.xx.xx     80:30567/TCP   2m

此时，用户直接访问 http://47.100.xx.xx 即可。

4. 优缺点分析

✅ 优点

• 极简操作：一行 YAML 配置即可搞定外部访问，无需手动购买和配置云负载均衡器。
• 标准公网入口：提供标准的公网 IP，屏蔽了内部节点 IP 的变化，客户端配置简单稳定。
• 高可用与弹性：直接利用云厂商负载均衡器的高可用能力（多可用区容灾、自动健康检查）。
• 支持高级特性：可以利用云厂商 LB 的高级功能，如 SSL 卸载、会话保持、访问日志等（通常通过 Annotation 配置）。

❌ 缺点

• 成本较高：每个 LoadBalancer 类型的 Service 通常对应一个云负载均衡器实例。云厂商通常按实例数量或流量收费。如果你为每个微服务都创建一个 LB，费用会非常高昂。
• 云厂商锁定：这是最大的缺点。LoadBalancer 的实现依赖于特定的云提供商。如果你在 AWS 上创建的 YAML 文件直接拿到阿里云或本地私有云（如 VMware）运行，通常会失效或需要大量修改。
• 数量有限制：云账号下能创建的负载均衡器实例数量通常有限额。
• 配置灵活性受限：虽然可以通过 Annotation 配置一些参数，但无法像 Ingress 那样灵活地基于域名和路径进行复杂的七层路由管理。

5. 三种 Service 类型的对比总结

image

6. 最佳实践建议

在生产环境中，不建议为每一个微服务都创建一个 LoadBalancer 类型的 Service，原因主要是成本和管理的复杂性。

推荐架构模式：

1. 单一入口：只创建 1 个 LoadBalancer 类型的 Service（或者使用云厂商的 Ingress Controller），作为整个集群的统一流量入口。
2. Ingress 路由：在这个唯一的入口后面部署 Ingress Controller（如 Nginx Ingress, Traefik, ALB Ingress）。
3. 内部服务：所有的后端微服务继续使用 ClusterIP。
4. 七层路由：通过 Ingress 规则，根据域名（api.example.com, www.example.com）和路径（/api, /web）将流量分发到不同的 ClusterIP 服务。

总结： LoadBalancer 是连接 Kubernetes 集群与外部世界的“官方桥梁”，特别适合云环境下的生产应用。但为了节省成本和提高管理效率，通常将其作为总网关使用，配合 Ingress 来实现复杂的流量分发，而不是为每个服务单独开通。