测验：明明正常，为什么配送失败？

Pod 处于 Running，但 Service 请求失败。首先要区分什么事实？

• 直接请求 Pod 与请求 Service 的差异
• 重启集群所有节点的顺序
• 强制重新拉取新镜像的周期
• 删除所有正常 Pod 的优先级

只把 Service selector 改为 app=missing，最符合的观测是什么？

• Pod 的标签也会自动改成相同值
• Pod 仍能响应，但被选中的地址消失
• Deployment 修订号一定增加
• 同一容器的重启次数增加

EndpointSlice 的 endpoints 为 null 时，观测工具应如何处理？

• 立即断定控制平面已宕机
• 继续使用上一个正常地址
• 解释为当前没有目标地址
• 改用第一个 Pod 的地址

kubectl patch 成功，但立即发送的请求失败。应如何解释？

• API 已成功，所以忽略请求失败
• 同时修改其他命名空间
• 重新构建全部容器镜像
• 检查生效延迟和真实数据路径

直接请求 Pod 成功，只能证明什么？

• 该 Pod 的相应 HTTP 路径能够响应
• 外部 DNS 和 TLS 全部正常
• Service 的目标端口一定正确
• 所有客户业务均已恢复

Pod IP 的 8080 端口成功，但有 Ready 地址的 Service IP 的 8080 端口失败。下一步最直接比较什么？

• 直接请求 ClusterIP 时的外部 DNS 传播时间
• Service targetPort 与应用实际监听端口
• Pod 重启次数与请求正文字符数
• Ingress TLS 证书与 Pod 镜像标签