kubernetes Command
kubectl 排查 Service 和 Ingress 命令
kubectl 排查 Kubernetes Service 与 Ingress 路由不通的常用命令，kubectl get svc,endpoints 看 endpoints 是否为空判断 selector 是否匹配，describe ingress 看 rules 和 IngressClass，用 curl -H Host 复现入口路由并核对 targetPort 与容器端口。
Service 不通先看 endpoints，Ingress 404/502 先 describe ingress，再检查后端 Service endpoints。
Scenario
什么时候用这组命令
这组命令适合在处理“kubectl 排查 Service 和 Ingress 命令”时作为第一轮检查模板。使用时先替换占位符，再在目标机器或目标 namespace 中执行，避免在错误环境里得到误导结论。
Input
你需要先准备什么
- 先确认 namespace、资源名、节点、镜像和最近一次变更。
- 按 Pod → Service/Endpoint → Ingress/外部入口的顺序定位，不要跳层。
- 优先看 describe events 和上一轮容器日志，它们通常比状态字段更接近根因。
Risk Notes
执行风险
- 不要直接删除有状态 Pod 或 PVC 来“试试”，先确认控制器和数据卷策略，避免数据丢失。
- 不要只看当前容器日志，CrashLoop 场景必须看 --previous 获取上一轮崩溃的完整输出。
- 不要在 production 集群上随意修改资源配额或节点标签，这类变更可能触发级联 Pod 调度。
Commands
命令详解
命令 1: 读取 Kubernetes 状态
用于读取 Kubernetes 当前资源状态和 Events。重点看 STATUS、RESTARTS 和 Events 中的调度、探针、镜像错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl get svc,endpoints -n <namespace>命令 2: 读取 Kubernetes 状态
用于读取 Kubernetes Events、状态变化和资源引用关系。排查 Pod、Service、Ingress 时，它通常能直接暴露调度、拉镜像、探针或后端错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl describe svc <service> -n <namespace>命令 3: 读取 Kubernetes 状态
用于读取 Kubernetes 当前资源状态和 Events。重点看 STATUS、RESTARTS 和 Events 中的调度、探针、镜像错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl get pod -n <namespace> --show-labels命令 4: 读取 Kubernetes 状态
用于读取 Kubernetes Events、状态变化和资源引用关系。排查 Pod、Service、Ingress 时，它通常能直接暴露调度、拉镜像、探针或后端错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl describe ingress <ingress> -n <namespace>命令 5: 发起 HTTP/网络探测
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
curl -H "Host: app.example.com" http://<ingress-ip>/命令 6: 读取 Kubernetes 状态
用于读取 Kubernetes 当前资源状态和 Events。重点看 STATUS、RESTARTS 和 Events 中的调度、探针、镜像错误。
- 先替换尖括号占位符，不要原样执行。
- 确认命令运行位置正确。
- 保留关键输出，方便和修复后对比。
kubectl get events -n <namespace> --sort-by=.lastTimestampWorkflow
建议执行顺序
按顺序执行，不要跳过确认类命令
先用只读命令确认状态，再执行会改变状态的命令。Service 不通先看 endpoints，Ingress 404/502 先 describe ingress，再检查后端 Service endpoints。
- 确认 Service 是否有 endpoints。
- 核对 selector 与 Pod labels。
- 检查 targetPort 是否等于容器监听端口。
- Ingress 场景确认 host/path/IngressClass。
- 用带 Host 头的 curl 复现入口路由。
kubectl get svc,endpoints -n <namespace>
kubectl describe svc <service> -n <namespace>
kubectl get pod -n <namespace> --show-labels把命令输出变成结论
命令本身不是结论。每次执行后要回答：目标是否存在、状态是否异常、异常是否能解释用户看到的现象。
- 记录关键字段，而不是整屏复制
- 把正常路径和异常路径输出对比
- 输出为空也要解释：是确实没有，还是权限/过滤条件不对
kubectl describe svc <service> -n <namespace>
kubectl get pod -n <namespace> --show-labels
kubectl describe ingress <ingress> -n <namespace>执行前替换占位符并控制影响范围
包含 <service>、<pod>、<namespace>、<pid>、<container> 的命令必须先替换。涉及 reload、restart、KILL、vacuum、prune 的命令要确认影响范围。
- 优先在测试环境或只读模式验证
- 生产执行前保留回滚路径
- 把最终可用命令写入工单或 runbook
curl -H "Host: app.example.com" http://<ingress-ip>/
kubectl get events -n <namespace> --sort-by=.lastTimestampVerification
怎么判断命令有效
- 命令已在正确机器、正确用户、正确 namespace 或正确仓库下执行。
- 输出能支撑明确判断：正常、异常、权限不足、目标不存在或需要下一跳排查。
- 对有副作用的命令，已确认执行窗口、影响范围和回滚方式。
Prevention
沉淀到日常流程
- 发布模板中强制包含 probes、资源限制和回滚策略，确保所有工作负载都有存活和就绪检查。
- 把 Service selector、端口名和 labels 做成约定，减少手写漂移导致的网络断链问题。
- 为镜像拉取、Pod 重启和 Ingress 5xx 建立基础告警，第一时间发现异常。
- 定期用 kubectl cluster-info dump 和容器运行时检查集群健康状态，提前发现调度和资源问题。
常见问题
endpoints 为空最常见原因是什么？
Service selector 没匹配到 Pod labels，或 Pod readiness 未通过导致没有就绪端点。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- kubectl 查看 service
- kubectl describe ingress
- kubectl get endpoints
- k8s service 不通排查
- kubectl 调试 service
- k8s ingress 排查
Need More Help
这组命令还不够贴合你的场景？
把你的系统环境、目标操作和报错贴过来，我会优先补充更具体的命令模板。