2. K8s 核心概念速览：Pod、Service、Ingress、ConfigMap、Secret 在故障排查中的作用

在分布式事务鉴权拦截的故障场景中，Kubernetes 的五个核心资源——Pod、Service、Ingress、ConfigMap 和 Secret——构成了排查路径上的关键锚点。理解它们在请求链路中的角色，能帮助工程师快速定位鉴权失败、事务超时或配置错误的具体环节。

2.1 核心资源故障排查角色总览

2.2 Pod：事务执行的最小单元

Pod 是 Kubernetes 中可调度的最小计算单元，通常包含一个或多个容器。在分布式事务场景中，Pod 承载着事务协调器、参与者以及鉴权拦截器（如 Sidecar 代理）。

• 日志排查：通过 kubectl logs <pod> -c <container> 查看事务协调日志或鉴权拒绝日志。
• 状态检查：kubectl describe pod <pod> 中的 Conditions 字段显示 Pod 是否就绪，Events 字段记录调度与拉取镜像的异常。
• Sidecar 注入验证：确认 Istio/Linkerd 等 Sidecar 是否成功注入，kubectl get pod <pod> -o jsonpath='{.spec.containers[*].name}' 可列出所有容器。

2.3 Service：稳定的流量入口与负载均衡

Service 为一组 Pod 提供稳定的虚拟 IP 和 DNS 名称，是分布式事务中服务间调用的核心抽象。鉴权策略通常绑定在 Service 上，通过 NetworkPolicy 或服务网格规则生效。

• 端点检查：kubectl get endpoints <service> 确认后端 Pod IP 列表是否与预期一致。空端点列表意味着流量无法到达任何 Pod。
• Session 亲和性：对于需要保持事务上下文的场景，检查 Service 的 sessionAffinity 是否设置为 ClientIP，避免请求被分发到不同 Pod 导致事务状态丢失。
• 端口映射：确认 Service 的 targetPort 与 Pod 容器端口一致，端口不匹配会导致连接被拒绝。

# 检查 Service 后端端点
kubectl get svc transaction-coordinator -o wide
kubectl get endpoints transaction-coordinator

# 检查 Service 的 Session 亲和性配置
kubectl get svc transaction-coordinator -o yaml | grep sessionAffinity

2.4 Ingress：外部流量的鉴权网关

Ingress 管理集群外部访问内部服务的 HTTP/HTTPS 路由。在分布式事务鉴权拦截故障中，Ingress 是外部请求进入集群的第一道关卡，常见的鉴权中间件（如 OAuth2 Proxy、JWT 验证）通过 Ingress 注解或 CRD 配置。

• 注解验证：检查 Ingress 资源上的 nginx.ingress.kubernetes.io/auth-url 或 traefik.ingress.kubernetes.io/router.middlewares 等注解是否正确指向鉴权服务。
• TLS 证书：kubectl describe ingress <ingress-name> 查看 TLS 部分，确认 Secret 名称是否存在且证书未过期。
• 路由规则：确认 host 和 path 规则是否覆盖了事务接口的访问路径，避免请求因路由不匹配而返回 404。

2.5 ConfigMap 与 Secret：配置与凭证的载体

ConfigMap 和 Secret 是 Kubernetes 中配置管理的核心资源。在分布式事务鉴权场景中，它们分别承载非敏感配置（如事务超时时间、鉴权规则 URL）和敏感凭证（如 JWT 签名密钥、数据库密码）。

# 检查 ConfigMap 是否被 Pod 正确引用
kubectl describe pod transaction-service-pod | grep -A5 "ConfigMap"

# 解码并验证 Secret 内容
kubectl get secret jwt-secret -o jsonpath='{.data.jwt-key}' | base64 --decode

# 检查 Secret 是否存在于目标 Namespace
kubectl get secret -n transaction-ns

2.6 核心资源在鉴权拦截链路中的交互关系

下图展示了外部请求经过 Ingress、Service 到达 Pod 的过程中，ConfigMap 和 Secret 如何为鉴权拦截提供配置与凭证支持。

2.7 故障排查中的资源关联分析

在实际故障场景中，五个资源往往相互关联。以下是一个典型的鉴权拦截故障排查流程，展示如何利用这些核心概念逐步缩小问题范围。

1. 确认外部访问是否到达 Ingress：检查 Ingress 控制器日志，确认请求是否被正确路由。如果 Ingress 返回 404，检查 host 和 path 规则。
2. 验证 Service 是否将流量转发到 Pod：使用 kubectl get endpoints 确认后端 Pod 是否就绪。如果端点为空，检查 Pod 的 ReadinessProbe。
3. 检查 Pod 内部鉴权逻辑：通过 kubectl logs 查看事务协调器日志，确认鉴权拦截是否发生在 Sidecar 或应用代码中。
4. 核对配置与凭证：确认 ConfigMap 中的鉴权规则 URL 是否正确，Secret 中的 JWT 密钥是否与颁发者匹配。