17370845950

Service的核心作用是“稳定寻址”，通过不变的ClusterIP和DNS名屏蔽Pod动态变化；依赖selector匹配Ready Pod，由endpoints controller同步至Endpoints对象；kube-proxy将规则写入内核（iptables/ipvs）实现DNAT转发。

Service 的核心作用不是“转发流量”，而是“稳定寻址”——它用一个不变的虚拟 IP（ClusterIP）和 DNS 名，屏蔽后端 Pod 的动态变化。

Service 怎么找到后端 Pod？靠 selector

+ Endpoints

Service 本身不持有 Pod 地址，它只声明一个 selector（比如 app: nginx），然后由 Kubernetes 内置的 endpoints controller 实时监听：哪些 Pod 满足这个 label、且处于 Ready 状态。满足条件的 Pod IP+端口会被自动写入同名的 Endpoints 对象中。

你执行 kubectl get endpoints app-service 就能看到真实生效的后端列表。如果列表为空，常见原因有：

• Deployment 或 Pod 的 label 写错了，和 Service 的 selector 不匹配
• Pod 处于 Pending 或 CrashLoopBackOff，没通过 readiness probe
• Service 创建早于 Pod，而 endpoints controller 还没来得及同步（通常几秒内会自动修复）

流量怎么真正转发到 Pod？kube-proxy 是关键中间人

Service 的 ClusterIP 是个“虚地址”，不能直接响应网络请求。真正干活的是每个 Node 上的 kube-proxy 组件——它持续监听 Service 和 Endpoints 变化，并把规则刷进系统内核：

• 默认模式是 iptables：为每个 Service 生成一堆 NAT 规则，请求命中 ClusterIP:Port 后，随机选一个 Endpoint 做 DNAT
• 大规模集群建议用 ipvs 模式：性能更高、连接跟踪更稳定，但需内核支持 ip_vs 模块
• userspace 模式已弃用；kernelspace（即 eBPF）是较新方向，但尚未成为默认

注意：kube-proxy 不参与数据包转发路径，它只负责“写规则”。实际转发由 Linux 内核 netfilter 完成，所以延迟极低，也几乎不消耗 CPU。

为什么访问 ClusterIP 有时失败？先查这三件事

不是所有 ClusterIP 都能从任意位置访问。典型故障链路是：

• Pod 自身网络不通（比如 CNI 插件异常，ping 不通其他 Pod）
• Service 的 targetPort 和容器实际监听端口不一致（如容器监听 8080，但写成了 80）
• 集群 DNS 不工作（kube-dns 或 CoreDNS Pod 异常，或 /etc/resolv.conf 配置错误）

验证顺序建议：curl http://..svc.cluster.local: → curl http://: → 直连某个 Pod IP。这样能快速定位是 DNS、Service 还是底层网络问题。

最容易被忽略的一点：ClusterIP 只在集群内部有效，它根本不会路由到 Node 主机网络——这意味着你在 master 节点上 curl ClusterIP 成功，不代表应用 Pod 里也能成功，因为后者走的是 Pod 网络平面，前者可能走的是 host 网络。务必在 Pod 内部测试。