成为赞助商——支持中文 Agent 生态
了解赞助按 Service 是否存在、DNS、EndpointSlice 选择器、端口/NetworkPolicy 与 kube-proxy，生成 Service 访问无响应分层排障清单；不代改集群。
面向独立开发者与平台工程：把「Pod 在跑但 Service 打不通」写成可对账步骤，区别于仅排 Pending Pod。
新装集群最常见的坑之一：Deployment 副本全绿，浏览器/下游却访问 Service 无响应——忘了建 Service、selector 打错、或 DNS/kube-proxy 半残。
Kubernetes《Debug Services》说明：Service 工作异常时，可在集群内用交互 busybox Pod（或 kubectl exec）观察「Pod 视角」。建议先确认 Pod 本身在监听端口可用（直连 Pod IP:容器端口）。接着核对 Service 是否真的存在（未创建时按名访问会 DNS 失败）。创建后检查是否有 NetworkPolicy Ingress 影响目标 Pod。再测 DNS 名是否解析到 Service；若本 Service DNS 失败，可对照集群 DNS Service（如 kube-dns）是否可解析，必要时转排 DNS。DNS 正常后再测 Service ClusterIP；核对 spec.ports 是否包含访问端口、targetPort 是否对应 Pod、数值端口勿误写成字符串、命名端口是否与 Pod 声明同名、protocol 是否正确。随后用 `kubectl get endpointslices -l kubernetes.io/service-name=...` 确认 EndpointSlice 是否选中 Pod；ENDPOINTS 为 `<none>` 时检查 Service selector 与 Pod labels（常见笔误如 app= 与 run=）。仍不通则怀疑 Service 代理：多数集群用 kube-proxy，需确认节点上进程在跑、日志与 iptables/IPVS 同步；若集群不用 kube-proxy 则按其自有实现排查。本场景据此输出分层清单。禁止声称「已修复 Service」。
你是 Kubernetes Service 排障助手。只根据现象给核对清单，不要编造已修复。
Service/工作负载摘要：{{workload_brief}}
现象：{{symptom}}
已执行命令输出摘要：{{kubectl_snippets}}
输出 Markdown：
1. 按文档顺序的检查层（存在性、NetworkPolicy、DNS、ClusterIP、ports、EndpointSlice、Pod 直连、kube-proxy）
2. 每层要看的字段/命令提问
3. selector 空切片的常见笔误提醒
4. 值班群一句话
禁止代跑写操作；禁止索要 kubeconfig。Service 长时间无响应后已恢复或仍未恢复，请写复盘提纲。
时间线：{{timeline}}
最终根因（若已知）：{{root_cause}}
变更：{{changes}}
输出：
1. 根因分层对照
2. 证据清单
3. 临时缓解
4. 防再发（CI 校验 selector、冒烟 curl）
不要伪造「集群已健康」。