在Kubernetes集群中配置负载均衡和自动化服务发现需结合云原生工具与架构经验。以下是实践总结:
-
负载均衡实现
- Service类型选择:使用
LoadBalancer
类型自动集成云厂商负载均衡器(如AWS ELB),本地环境可部署MetalLB实现BGP或Layer2负载均衡。 - Ingress Controller:通过Nginx Ingress或Traefik实现七层流量分发,支持路径/域名路由,减少外部LB实例数量以降低成本。
- 健康检查配置:在Service中定义
readinessProbe
和livenessProbe
,确保负载均衡器仅将流量路由至健康Pod。
- Service类型选择:使用
-
服务发现机制
- 内置DNS:CoreDNS为Service提供
<service>.<ns>.svc.cluster.local
的DNS记录,跨命名空间需显式指定命名空间。 - Headless Service:通过设置
clusterIP: None
暴露Pod IP,适用于需直接访问Pod的场景(如数据库集群)。
- 内置DNS:CoreDNS为Service提供
-
实践经验与挑战
- 云成本控制:曾因过度使用
LoadBalancer
导致AWS费用激增,后改用Ingress集中管理入口流量,降低LB实例数量。 - 网络策略冲突:Calico网络策略曾阻塞CoreDNS通信,需添加
egress
规则允许DNS流量(UDP 53)。 - 会话保持难题:部分有状态服务需
sessionAffinity: ClientIP
,但云厂商LB的源IP保留需配置externalTrafficPolicy: Local
。 - 多集群发现:通过ExternalDNS与Consul实现跨集群服务注册,需解决DNS缓存延迟问题。
- 云成本控制:曾因过度使用
-
监控与调试
- 使用
kubectl describe svc
验证Endpoints是否正常 - 通过
dig +short <service>.ns.svc.cluster.local
检查DNS解析 - 在LB节点抓包分析流量丢弃原因(如MTU不匹配或安全组限制)
- 使用