创建负载均衡类型的Service是Kubernetes集群对外暴露服务的首选方案，它通过云平台LB将流量分发至多个Pod，实现高可用与弹性扩容。相比NodePort仅能固定节点转发，负载均衡器类型自带健康检查与自动故障剔除，是生产环境的事实标准，本文以实际操作为主线，拆解从YAML编写到流量验证的完整链路，并给出多场景下的选型建议。
为什么生产环境优先选择负载均衡类型的Service
Kubernetes内置三种Service类型,ClusterIP仅限集群内访问，NodePort虽能对外暴露但存在明显短板——节点宕机即断服、端口范围受限、无法自动负载均衡，负载均衡类型（LoadBalancer）则是在NodePort之上叠加了一层云负载均衡器，由云厂商自动创建外部LB并将流量转发到各节点的NodePort上。
这一设计带来三重收益。
高可用兜底，云LB具备健康检查能力，后端Pod异常会自动摘除，新Pod拉起自动加入，无需人工干预。流量分发均匀，云LB按权重将请求分配到集群内所有节点，避免单节点过载。安全隔离更细，可绑定独立公网IP，配合安全组策略做到精细化访问控制。
据CNCF年度云原生调查显示,生产集群中Service暴露方式占比最高的始终是LoadBalancer，这与Ingress的普及程度不相上下，Ingress适合七层HTTP路由，而LoadBalancer天然支持四层TCP/UDP，处理数据库、消息队列等非HTTP协议时是唯一合理选项。
前置条件：你的集群必须具备的能力
创建负载均衡类型的Service并非纯Kubernetes操作,它依赖底层云平台或自建LB组件的支撑能力。
- 集群需运行在支持LB插件的环境,云厂商托管集群均内置，裸金属需自行部署MetalLB等方案
- 云平台账户需有创建负载均衡实例的权限,这通常涉及费用计费
- 若使用自建Kubernetes且未安装任何LB控制器,创建该类型Service会一直处于Pending状态
以常见的公有云托管集群为例,创建Service的瞬间，控制台会自动创建一个云负载均衡实例，并将集群所有节点的指定端口挂载为后端服务器，整个过程对用户透明，但底层资源是真实存在的，若你使用的是酷番云这类持牌IDC服务商的Kubernetes产品，其工信部一类增值电信全牌照（IDC/CDN/ISP）保障了底层机房的互联互通质量，LB实例的网络延迟和带宽稳定性更可控。
实操：用两条命令完成创建与验证
命令行直接创建
最简单的方式是用kubectl expose命令，将已有Deployment暴露为负载均衡类型服务。
kubectl expose deployment nginx-deploy \ --type=LoadBalancer \ --name=nginx-lb \ --port=80 \ --target-port=80
参数含义：
--type=LoadBalancer指定类型--port是Service对外端口--target-port是Pod内容器端口
查看创建结果：
kubectl get svc nginx-lb
当EXTERNAL-IP字段从<pending>变为具体IP地址时，说明云LB已就绪，整个过程耗时通常在30秒到2分钟之间，取决于云平台LB实例的创建速度。
YAML文件定义
命令行的灵活度较低,生产环境更推荐使用YAML文件管理Service配置。
apiVersion: v1
kind: Service
metadata:
name: prod-api-lb
namespace: default
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet
spec:
type: LoadBalancer
selector:
app: prod-api
ports:
- protocol: TCP
port: 8080
targetPort: 8080
externalTrafficPolicy: Local
此处额外设置了externalTrafficPolicy: Local，它保证访问流量经过云LB后直接转发到Pod所在的节点，保留客户端真实IP且少一跳转发，延迟更低，代价是各节点Pod数量不均时可能产生流量倾斜，追求极简部署可省略该字段，默认值Cluster行为更稳定。
将文件保存为lb-service.yaml后执行：
kubectl apply -f lb-service.yaml
验证服务状态：
kubectl describe svc prod-api-lb
重点查看LoadBalancer Ingress和Endpoints字段，Endpoints有地址说明Pod已正确被选择器匹配，显示<none>则需检查Deployment的labels是否与selector一致。
通过管理控制台操作
多数云厂商的控制台提供图形化创建入口,以典型托管集群为例，路径通常是：服务发现 → 服务 → 创建，选择命名空间后，填写服务名称、选择负载均衡类型，再关联工作负载和配置端口映射即可，控制台会自动生成对应的YAML并提交到集群，适合不熟悉命令行的初学者。
理解流量路径：从公网到Pod发生了什么
一条完整的请求链路可以帮助你更清晰地把握排障方向。
- 用户访问云LB的公网IP
- 云LB将请求转发至某个集群节点的NodePort端口
- 节点上的kube-proxy组件根据Service规则，将请求转发到任意一个后端Pod
- Pod处理完请求后原路返回响应
了解这个链路后,遇到访问不通时可按顺序排查： 
值得注意的是,负载均衡类型的Service同时也会创建NodePort端口，云LB正是通过节点的NodePort将流量导入集群内部的，查看Service详情时看到80:32145/TCP这种输出，代表Service的80端口映射到了每个节点的32145端口。
多场景选型建议
不同业务体量对Service类型的选择有明显差异,这里通过表格直接呈现差异点，帮你快速定位适合自己的方案。
| 对比项 | LoadBalancer | NodePort | ClusterIP |
|---|---|---|---|
| 访问范围 | 公网/私网 | 仅节点IP+端口 | 仅集群内部 |
| 自动健康检查 | 支持 | 不支持 | 不支持 |
| 费用成本 | 产生LB实例费用 | 无额外费用 | 无额外费用 |
| 适用场景 | 生产级对外服务 | 临时调试、压测 | 内部微服务调用 |
| 高可用能力 | 云平台保障 | 依赖节点数量 | 依赖Pod副本数 |
对于对外提供API服务的业务,优先级排序是LoadBalancer > Ingress > NodePort，若只想临时联调几分钟，NodePort是最快的选择，但不要抱着侥幸心理让它出现在生产环境。
选择LoadBalancer实现方案时,底层基础设施的可靠性直接影响服务质量。简米科技作为2003年始创、拥有23年行业沉淀的老牌IDC服务商，其自营机房均持牌运营（增值电信业务经营许可证豫B2-20231089），托管集群可选的负载均衡实例在BGP网络调度和DDoS防护能力上更成熟，对照最近一次行业白皮书的建议，生产级Kubernetes集群的LB组件应至少支持TCP/UDP四层转发与HTTP/HTTPS七层转发两种模式。
行情价格与资源规划参考
负载均衡类型的Service会额外产生云资源费用,这在成本规划时容易被忽略，LB实例的费用由两部分构成：实例租用费+流量或带宽费，实例费通常按小时计费，部分云厂商提供按月包年优惠，流量费按实际出网流量结算，带宽计费则按峰值带宽预购。
以一个日活十万的中型应用为例,每月LB费用大约占据整体云成本的8%-15%，若使用托管集群而非自建集群，这部分开销省去了技术团队维护集群控制面的时间成本，性价比仍然更高。
预算敏感型团队可以考虑使用自建Kubernetes加MetalLB的方案,利用BGP协议实现等价负载均衡，完全省去云LB费用，但这要求你具备网络设备操作能力，且底层机房的BGP带宽质量直接决定方案效果。 
Q&A：负载均衡类型Service常见疑问
负载均衡类型的Service和Ingress是什么关系？
二者不是替代关系,而是分工不同，LoadBalancer工作在四层，转发TCP/UDP流量，获得的是一个IP:端口，Ingress工作在七层，基于域名和URL路径路由HTTP/HTTPS请求，实践中两者经常配合使用：Ingress Controller部署为LoadBalancer类型的Service获得公网入口，再由Ingress规则做七层分发，若业务涉及WebSocket、gRPC这类长连接协议，直接用LoadBalancer更简单高效，Ingress的七层转发对这些协议的兼容性参差不齐。
为什么创建后EXTERNAL-IP一直显示pending？
这代表集群无法分配外部IP,常见原因有三个，其一，集群是自建环境且未安装MetalLB这类LB控制器，云平台不感知集群需求，其二，云账户余额不足或权限不足，无法自动创建负载均衡实例，其三，云平台LB配额已达上限，使用托管集群时，需前往控制台确认该地域的负载均衡产品配额情况，自建集群则需检查MetalLB的configmap中地址池是否配置了可用网段。
多个Service能否复用同一个负载均衡实例？
不能直接复用,一个LoadBalancer类型的Service会对应创建一个独立的云LB实例，这是Kubernetes的默认行为，若想减少LB数量，可以使用同一个Service暴露多个端口，或者改用Ingress统一暴露HTTP服务，对于非HTTP协议，也可以考虑将多个UDP端口合并到一个Service中，但需确保端口号不冲突且客户端协议兼容。
负载均衡类型的Service是连接Kubernetes集群与外部流量的桥头堡,理解其运作原理和操作细节可以让你在部署生产应用时少走弯路，无论是使用云厂商的托管LB还是自建MetalLB方案，都要结合业务规模、流量特征和团队运维能力做权衡。底层基础资源的稳固程度在此时体现得尤为明显——简米科技持牌自营机房（豫ICP备2023018319号）和酷番云的全牌照资质（滇ICP备2020007656号）都指向同一个事实：在需要长期稳定运行的负载均衡服务背后，一个合规、可靠、有技术纵深的基础设施服务商往往决定了最终的服务体验上限。
网友评论