Kubernetes 如何实现集群内部的负载均衡配置-linux运维-PHP中文网

kubernetes集群内部负载均衡主要通过clusterip service与kube-proxy实现，无需外部组件；kube-proxy在各节点注入iptables或ipvs规则，将发往虚拟ip的流量按轮询等策略分发至匹配标签的健康pod，并支持会话保持与规模优化。

kubernetes 如何实现集群内部的负载均衡配置

Kubernetes 集群内部的负载均衡主要通过 Service（类型为 ClusterIP） + kube-proxy 实现，不依赖外部组件，也不暴露到集群外。它的核心是让服务消费者（比如另一个 Pod）能稳定访问一组动态变化的后端 Pod，而无需关心具体 IP 和生命周期。

ClusterIP 是默认且最常用的内部负载均衡方式

当你定义一个 Service 且未指定 type，Kubernetes 自动设为 ClusterIP。它会分配一个仅在集群内可解析的虚拟 IP（如 10.96.0.100），所有流量发往这个 IP，最终被分发到匹配标签的健康 Pod 上。

这个 IP 不真实监听——没有进程绑定它，而是靠 kube-proxy 在每个节点注入规则来“拦截并转发”
DNS 名称自动注册（如 my-service.default.svc.cluster.local），Pod 可直接用服务名通信

kube-proxy 决定实际转发行为

它运行在每个 Node 上，监听 Service 和 Endpoints 变化，并同步生成底层转发规则。当前主流使用两种模式：

iptables 模式（兼容性好，适合中小规模）

Kubernetes Network Policy Generator
使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载
- 生成链式 NAT 规则，按概率跳转到不同 Pod IP
- 轮询效果是“伪随机”实现：三条规则分别对应 1/3、1/2、1 的命中概率，最终各 Pod 接收请求概率均等
- 缺点：规则数量随 Pod 增多线性增长，大规模时性能下降
IPVS 模式（推荐用于中大型集群）
- 基于 Linux 内核的 LVS（Linux Virtual Server），用哈希表管理后端，支持 rr（轮询）、wrr（加权轮询）、lc（最少连接）等算法
- 启用方式：编辑 kube-proxy ConfigMap，将 mode: "ipvs"，重启 kube-proxy
- 优势：10 万级规则下延迟更低、CPU 占用更少，支持连接跟踪和会话保持（sessionAffinity: ClientIP）

如何配置一个带负载均衡的内部服务

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  # type 默认就是 ClusterIP，可省略
  # sessionAffinity: ClientIP  # 如需会话粘滞，加上这行

同时确保后端 Pod 有对应 label（如 app: api-server），Service 就能自动发现并纳入负载池。

注意几个关键细节

Service 的负载策略只作用于匹配的 Pod，不感知 Pod 是否就绪——所以务必配合 readinessProbe，避免流量打到未启动完成的实例
ClusterIP 本身不提供健康检查逻辑，全靠 kube-proxy 定期同步 Endpoints 对象（由控制器根据 Pod 状态更新）
如果 Pod 数量超过 500，强烈建议切换到 IPVS 模式，否则 iptables 规则加载慢、更新延迟高
想让某些客户端始终访问同一个 Pod？设置 sessionAffinity: ClientIP 并指定 sessionAffinityConfig.clientIP.timeoutSeconds（默认 10800 秒）

不复杂但容易忽略