Service 有 ClusterIP 但访问不通，endpoints 为空怎么排？

直接回答：kubectl get endpoints 为空说明 Service 的 selector 没匹配到任何 Ready 的 Pod。检查三板斧：selector 与 Pod 的 label 逐字对照（kubectl get pods --show-labels）、Pod 是否 Ready（探针不过会被踢出 endpoints）、label 是不是打在了别的命名空间——Service 只能发现同 namespace 的 Pod。

展开解析：深挖路径：selector 拼写——运维高频事故，Service 的 app: web 对 Pod 的 app: web-v2，describe service 里的 Selector 字段与 pods --show-labels 并排看；Pod Ready 状态——Running 不等于 Ready，readinessProbe 失败的 Pod 不接流量，kubectl get pods 的 READY 列 0/1 即此意，探针路径、端口、初始延迟逐一验；端口对不上——Service 的 targetPort 要指向容器的 containerPort（名字或数字），targetPort 指错 endpoints 有但流量进不去，症状是连接拒绝而非超时；命名空间——跨 namespace 访问用 ..svc.cluster.local，自建 ExternalName 或手写 Endpoints（已不推荐，用 EndpointSlice API）是跨 namespace 的非常规手段。endpoints 非空但仍不通的下一步：kube-proxy 规则——iptables/ipvs 模式看 NAT 规则是否生成（ipvsadm/iptables-save | grep），CNI 的网络策略是否拦截（NetworkPolicy 默认拒绝的坑）；DNS 层——nslookup 在调试容器里验证，CoreDNS 挂了全员不通。系统性学习路径：Service → Endpoints/EndpointSlice → kube-proxy 数据面 → CNI 四层连通，每层一个验证命令，二分定位。生产建议：服务拓扑画清楚，故障时按链路逐段 curl 比猜快十倍。

追问方向：EndpointSlice 相对 Endpoints 解决了什么规模问题？headless service 的 endpoints 语义差异？

（约 490 字）