面试 · 场景排查型

Pod Pending
├── describe pod → 看 Events 中 FailedScheduling 原因
│   ├── "Insufficient cpu/memory" → 资源不足
│   │   ├── kubectl top node → 确认节点资源使用
│   │   ├── kubectl describe node → 看 Allocated resources
│   │   └── 修复：调低 requests / 扩节点 / 启用 Cluster Autoscaler（如 Karpenter）
│   ├── "node(s) had taint" → Taint/Toleration 不匹配
│   │   ├── kubectl describe node | grep Taints → 查看 Node Taint
│   │   ├── kubectl get pod -o yaml | grep tolerations → 检查 Pod Toleration
│   │   └── 修复：添加匹配的 toleration 或移除 Node Taint
│   ├── "no nodes match pod topology spread" → 拓扑约束过严
│   │   └── 修复：放宽 topologySpreadConstraints 或增加节点
│   ├── "Insufficient aliyun/vpc-eni-ip" → ENI IP 资源耗尽
│   │   ├── kubectl get nodeeni -A → 检查节点 IP 可用数
│   │   ├── 检查是否为 Terway IPAM 泄漏（见综合排障题）
│   │   └── 修复：手动释放泄漏 IP / 升级 Terway / 增加 ENI
│   └── "persistent volume not found" → PVC 绑定失败
│       └── 转到存储排障题

kubectl describe pod <pod> -n <ns>
kubectl get events -n <ns> --sort-by='.lastTimestamp'
kubectl top node
kubectl describe node <node> | grep -A5 "Allocated resources"
kubectl get pods --field-selector spec.nodeName=<node> --all-namespaces

ImagePullBackOff
├── kubectl describe pod → 看 Events 中拉取错误信息
│   ├── "image not found" / "manifest unknown"
│   │   ├── 检查镜像 tag：kubectl get pod -o jsonpath='{.spec.containers[*].image}'
│   │   ├── 本地 docker pull 测试 → 确认镜像是否存在
│   │   └── 修复：修正 tag / 推镜像
│   ├── "401 Unauthorized" / "authentication required"
│   │   ├── 检查 imagePullSecrets：kubectl get pod -o jsonpath='{.spec.imagePullSecrets}'
│   │   ├── 检查 Secret 是否过期（ECR token 每 12 小时）
│   │   ├── 确认 Secret 关联的 ServiceAccount：kubectl get sa -o yaml
│   │   └── 修复：更新 pull secret / 配置 IRSA（AWS） / RAM Role（阿里云）
│   ├── "dial tcp: i/o timeout" → 网络不通
│   │   ├── 从节点测试 registry 连通性
│   │   ├── 检查是否需要配置代理
│   │   └── 修复：配置 VPC Endpoint（如 ECR VPC Endpoint）/ 配置代理
│   ├── "toomanyrequests" → Registry Rate Limit
│   │   ├── Docker Hub 免费用户受限（6h 内 100 pulls）
│   │   └── 修复：使用 ECR/ACR 镜像缓存 / 配置镜像拉取凭据
│   └── Serverless K8s 老 Pod 重启后跨境源拉不到
│       ├── 老 Pod 在节点有镜像缓存 → "镜像可正常拉取"的错觉
│       ├── rollout restart 后新 Pod 分到新 virtual-kubelet → 无缓存
│       └── 修复：跨境源优先换 daocloud mirror / skopeo copy 到内网 ACR

kubectl describe pod <pod> -n <ns> | grep -A10 Events
kubectl get pod <pod> -n <ns> -o jsonpath='{.spec.containers[*].image}'
kubectl get pod <pod> -n <ns> -o jsonpath='{.spec.imagePullSecrets}'
kubectl describe serviceaccount <sa> -n <ns>

CrashLoopBackOff
├── kubectl logs <pod> --previous → 看上一次崩溃日志
│   ├── 日志为空 → 崩溃太快（进程还没来得及写日志就退出）
│   │   ├── 崩溃中的容器无法 exec 进入 → 用 ephemeral container 共享其命名空间排查
│   │   │   kubectl debug -it <pod> --image=busybox:1.36 --target=<container>
│   │   │   （ephemeral container 自 1.25 GA；--target 共享目标容器的 PID/网络 ns，
│   │   │     但如果目标已退出则看不到其进程，此时改用下面的 --copy-to）
│   │   ├── 复制一份 Pod 并把入口改成 sleep，进去看文件系统/环境变量/手动跑启动命令
│   │   │   kubectl debug <pod> --copy-to=debug --container=<container> -- sleep 1d
│   │   └── 检查 ENTRYPOINT/CMD 是否正确、配置/依赖是否就位
│   ├── 日志有堆栈/error → 应用级错误
│   │   ├── 分析错误信息
│   │   └── 修复代码配置
│   └── 日志被截断 → 查看全部 kubectl logs <pod> --tail=200
├── 查看退出码
│   ├── kubectl get pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
│   ├── 退出码 0 → 程序主动退出（配置错误 / 任务完成即退出）
│   ├── 退出码 1 → 应用抛出未捕获异常
│   ├── 退出码 137 → SIGKILL，大概率 OOMKilled（转到 OOMKilled 题）
│   ├── 退出码 139 → SIGSEGV 段错误（C/C++ 扩展 bug）
│   └── 退出码 143 → SIGTERM 优雅终止超时（preStop 超时 / 关闭太慢）
└── 检查 readiness/liveness probe
    ├── liveness 失败 → 健康检查端口不对 / 路径不对 / 阈值太紧
    ├── initialDelaySeconds 太短 → 应用启动慢但 probe 已经开始探测
    └── 修复：调整探针配置；区分 liveness 和 readiness

kubectl logs <pod> -n <ns> --previous --tail=200
kubectl get pod <pod> -n <ns> -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'
kubectl describe pod <pod> -n <ns> | grep -A10 "Last State"
kubectl debug -it <pod> -n <ns> --image=busybox:1.36 --target=<container>

OOMKilled
├── 确认是 cgroup OOM 而非其他 SIGKILL
│   ├── kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'
│   │   → 必须是 OOMKilled（仅 exitCode=137 不够，可能是被 drain/preStop kill）
│   ├── kubectl describe pod | grep -A5 "Last State" → Reason: OOMKilled / Exit Code: 137
│   └── 节点级 OOM 看 Node 事件：kubectl get events --field-selector reason=SystemOOM
│       （kubelet oomWatcher 从内核日志抓到 OOM 后在 Node 上打 SystemOOM 事件，
│         注意没有 reason=OOMKilling 这个事件类型）
├── 分析内存使用模式
│   ├── kubectl top pod → 看当前内存
│   ├── Prometheus：container_memory_working_set_bytes → 看历史趋势
│   ├── 内存持续增长直到 OOM → 内存泄漏
│   │   ├── Java：-XX:+HeapDumpOnOutOfMemoryError 抓 heap dump
│   │   ├── Python：检查循环引用、C 扩展泄漏
│   │   ├── Go：pprof 分析 goroutine 泄漏 / 未关闭的 body
│   │   └── 修复：改代码 + 调高 limit 作为短期止血
│   ├── 内存在某个时间点突然飙升 → 流量洪峰 / 大对象操作
│   │   ├── 检查 HPA 配置 → 是否及时扩容
│   │   ├── 检查是否有批量查询 / 大数据导出操作
│   │   └── 修复：拆分大操作 / 加 pagination / 配置 HPA
│   └── 内存在启动时就接近 limit → limit 设置过低
│       ├── VPA Recommender 查看推荐值
│       └── 修复：调高 limit / 调整 -Xmx
└── 检查节点内存压力
    ├── kubectl top node → 确认节点内存状态
    ├── kubectl describe node | grep MemoryPressure
    └── 节点内存不足时 kubelet 可能主动驱逐 Pod

kubectl describe pod <pod> -n <ns> | grep -A10 "Last State"
kubectl get pod <pod> -n <ns> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'
kubectl top pod <pod> -n <ns>
kubectl get events -n <ns> --field-selector reason=SystemOOM   # 节点级 OOM（Node 对象上的事件）

Init Container 阻塞
├── kubectl describe pod → 看 Init Containers 状态
│   ├── Init Container 卡在 Running（正常执行但未退出）
│   │   ├── kubectl logs <pod> -c <init-container> → 看输出
│   │   ├── 检查是否在等待外部资源（数据库/API）
│   │   └── 修复：加 timeout / 检查依赖服务可达性
│   ├── Init Container CrashLoopBackOff
│   │   ├── kubectl logs <pod> -c <init-container> --previous
│   │   ├── 检查 init 脚本逻辑 / 依赖服务是否就绪
│   │   └── 修复：修正 init 脚本 / 确保依赖先部署
│   └── Init Container Error / ImagePull
│       ├── 检查 init 容器镜像是否可拉取
│       └── 修复：转到 ImagePullBackOff 排查
└── 常见 Init Container 使用场景排查
    ├── 等待依赖服务：init 用 until curl/wait-for-it.sh 轮询
    │   └── 检查目标 service 和端口是否正确
    ├── 数据库迁移：init 跑 alembic/migrate
    │   └── 检查数据库连接配置、迁移脚本是否有误
    ├── 权限设置：init 执行 chown/chmod
    │   └── 检查 securityContext 和 volume 权限
    └── ConfigMap/Secret 预处理：init 生成配置文件
        └── 检查 ConfigMap 内容是否合法

kubectl describe pod <pod> -n <ns> | grep -A20 "Init Containers"
kubectl logs <pod> -n <ns> -c <init-container-name>
kubectl logs <pod> -n <ns> -c <init-container-name> --previous

Pod Evicted
├── 确认驱逐原因
│   ├── kubectl describe pod → 看 Status 和 Message
│   ├── kubectl get events -A --sort-by='.metadata.creationTimestamp' | grep Evicted
│   ├── 驱逐类型判断：
│   │   ├── "low on resource: ephemeral-storage" → 磁盘压力
│   │   ├── "low on resource: memory" → 内存压力
│   │   └── "low on resource: inodes" → inode 耗尽
├── 磁盘压力排查（ephemeral-storage）
│   ├── ssh 到节点查磁盘（现代集群运行时是 containerd，node 上没有 docker）
│   │   ├── df -h / df -i → 查看磁盘和 inode 使用率
│   │   ├── du -sh /var/log/pods/* | sort -rh | head -20
│   │   ├── du -sh /var/lib/containerd/* | sort -rh | head -10   # 老集群才看 /var/lib/docker
│   │   └── crictl rmi --prune（清无用镜像）/ crictl rmp -a（清已退出的 sandbox）
│   ├── kubectl describe node <node> | grep DiskPressure
│   └── 修复：清理日志和镜像 / 配置日志轮转（Fluentd/Filebeat / logrotate）
├── 内存压力排查
│   ├── kubectl top node
│   ├── kubectl describe node | grep MemoryPressure
│   └── 修复：降低 Pod requests / 扩节点 / 排查内存泄漏
└── 驱逐后的连锁反应（关键！驱逐是"强制删除"，不走优雅关闭）
    ├── 可能触发 CNI IP 泄漏（Terway / Calico IPAM）→ 完整案例见【综合排障 · 题目 1】
    │   └── 一句话：强删跳过 preStop/回收钩子 → IP 未释放 → 后续 Pod 无 IP 可分 → Pending
    ├── 检查是否引发"调度风暴"（大量 Pod 同时被驱逐+重调度 → 瞬时资源压力）
    │   └── 修复：配置 PDB 限制同时不可用副本数
    └── 检查数据库/消息队列连接：强制驱逐不等 in-flight 处理 → 连接丢失 / 消息丢失

kubectl get events -A --sort-by='.metadata.creationTimestamp' | grep -i evict
kubectl describe node <node> | grep -A10 Conditions
kubectl top node
kubectl get nodeeni -A     # Terway CRD 模式下检查 IP 状态

Service 不通
├── 逐层排查（从下往上）
├── 第一层：Pod 自身
│   ├── kubectl get pod <pod> -o wide → 确认 Running + Ready
│   ├── kubectl exec <pod> -- curl http://localhost:<port>/health → 容器内自检
│   └── Pod 不 Ready → 检查 readiness probe / 应用启动日志
├── 第二层：同节点 Pod 间通信
│   ├── kubectl exec <debug-pod> -- curl http://<pod-ip>:<port> → 用 Pod IP 直连
│   └── 不通 → CNI 插件问题（Calico/Flannel/Cilium/Terway 故障）
├── 第三层：跨节点 Pod 间通信
│   ├── 在另一节点的 Pod 里 curl Pod IP
│   └── 不通 → CNI 跨节点路由问题 / 安全组 / VPC 路由表
├── 第四层：Service 访问
│   ├── kubectl exec <pod> -- curl http://<service-clusterip>:<port>
│   ├── 不通 → 检查 EndpointSlice / kube-proxy
│   └── kubectl get endpointslices -n <ns> -l kubernetes.io/service-name=<service>
│       （Endpoints API 自 1.33 已弃用，kube-proxy 实际消费的是 EndpointSlice；
│         kubectl get endpoints 仍可用但只是兼容视图）
│       ├── 无 ready 端点 → Service selector 不匹配 Pod labels，或 Pod 未 Ready
│       │   ├── kubectl get pod -n <ns> --show-labels
│       │   ├── kubectl describe svc <service> -n <ns> | grep Selector
│       │   └── 修复：对齐 selector 和 Pod labels / 修 readinessProbe
│       └── 有端点但仍不通 → kube-proxy 数据面规则问题（先确认 kube-proxy 模式）
│           ├── kubectl get cm kube-proxy -n kube-system -o yaml | grep mode
│           ├── iptables 模式：iptables -t nat -L KUBE-SERVICES -n | grep <clusterIP>
│           ├── IPVS 模式：ipvsadm -Ln | grep <clusterIP>（缺 ip_vs 等内核模块会静默失败）
│           ├── nftables 模式（1.33 GA，新集群渐成默认）：nft list table ip kube-proxy
│           └── 修复：重启 kube-proxy DaemonSet / 补内核模块 / 核对模式配置
├── 第五层：DNS 解析
│   ├── kubectl exec <pod> -- nslookup <service>.<namespace>.svc.cluster.local
│   └── 不通 → 转到 DNS 排障题
└── 第六层：跨 namespace 访问
    ├── 确认用了完整 DNS 名：<service>.<namespace>.svc.cluster.local
    └── 确认 NetworkPolicy 未拦截跨 namespace 流量

kubectl get endpointslices -n <ns> -l kubernetes.io/service-name=<service>
kubectl get endpoints <service> -n <ns>          # 兼容视图，1.33 起 Endpoints API 已弃用
kubectl exec <pod> -n <ns> -- curl -v http://<service>:<port>/healthz
kubectl describe svc <service> -n <ns>
kubectl get pod -n <ns> --show-labels

DNS 解析失败
├── 第一步：确认 CoreDNS Pod 是否健康
│   ├── kubectl get pods -n kube-system -l k8s-app=kube-dns
│   ├── kubectl logs -n kube-system -l k8s-app=kube-dns --since=5m
│   └── CoreDNS OOMKilled → 调高 memory limit（大集群默认 170Mi 不够）
├── 第二步：查看故障 Pod 的 resolv.conf
│   ├── kubectl exec <pod> -- cat /etc/resolv.conf
│   │   输出示例：nameserver 10.96.0.10 / search production.svc.cluster.local svc.cluster.local cluster.local / options ndots:5
│   └── 确认 nameserver 指向 CoreDNS Service ClusterIP
├── 第三步：逐步测试 DNS 解析
│   ├── kubectl exec <pod> -- nslookup <service>
│   ├── kubectl exec <pod> -- nslookup <service>.<namespace>
│   ├── kubectl exec <pod> -- nslookup <service>.<namespace>.svc.cluster.local
│   └── kubectl exec <pod> -- nslookup <service>.<namespace>.svc.cluster.local 10.96.0.10
│       └── 直接指定 CoreDNS IP 绕过 resolv.conf 的 search 域
├── 第四步：区分域名类型
│   ├── 集群内域名不通 → CoreDNS 的 kubernetes 插件问题
│   │   └── 检查 CoreDNS ConfigMap 中 cluster.local 域配置
│   ├── 外部域名不通 → CoreDNS forward 上游问题
│   │   ├── 检查节点的 /etc/resolv.conf（CoreDNS 默认用节点 DNS 作上游）
│   │   └── 修复：在 Corefile 中指定可靠上游 DNS（如 8.8.8.8, 1.1.1.1）
│   └── 间歇性 NXDOMAIN → CoreDNS 缓存 / 副本问题
│       └── 修复：增加副本数（建议 3-4）+ 配置 Pod 反亲和性
└── 第五步：ndots:5 深度排查（见题目 4 综合排障）

kubectl exec <pod> -n <ns> -- cat /etc/resolv.conf
kubectl exec <pod> -n <ns> -- nslookup <service>.<namespace>.svc.cluster.local
kubectl exec <pod> -n <ns> -- nslookup <service>.<namespace>.svc.cluster.local 10.96.0.10
kubectl get configmap coredns -n kube-system -o yaml

DNS 5 秒延迟
├── 验证是否 conntrack 竞态
│   ├── tcpdump 抓包分析
│   │   ├── kubectl exec <pod> -- tcpdump -i any -nn port 53
│   │   ├── 触发高并发 DNS 查询：for i in $(seq 1 100); do nslookup api.example.com &; done
│   │   └── 观察抓包：正常 `query → response (3ms)` / 异常 `query → 5s 后重传 → response`
│   └── 确认并发 DNS 场景存在
├── 根因：Linux conntrack 竞态条件
│   ├── CoreDNS Service ClusterIP 经 DNAT 转换
│   ├── 两个 UDP DNS 包同时到达 → conntrack 表插入冲突
│   ├── 一个包被丢弃 → UDP 无重传 → 等 5 秒超时
│   └── 影响：ndots:5 时每个查询 4 次 UDP → 并发场景入口翻 4 倍
├── 修复方案优先级
│   ├── 方案0（生产首选、根治）：部署 NodeLocal DNSCache
│   │   ├── 每节点一个 DaemonSet 缓存代理，Pod 通过 link-local 地址（默认 169.254.20.10）访问本机缓存
│   │   ├── 本机命中直接返回、不过 DNAT/conntrack → 从源头消除竞态；miss 时以 TCP 回源 CoreDNS
│   │   └── 附带收益：大幅降低 CoreDNS QPS 与跨节点 DNS 流量
│   ├── 方案1：dnsConfig 加 single-request-reopen
│   │   ├── glibc 让 A/AAAA 用不同 socket（不同源端口）查询 → 避开同 5 元组竞态
│   │   ├── 注意：只对 glibc 有效，Alpine/musl 无此选项（musl 本就并发查询，需换 glibc 基础镜像或用方案0）
│   │   └── Pod spec: dnsConfig.options: [{name: single-request-reopen}, {name: ndots, value: "2"}]
│   ├── 方案2：CoreDNS 用 TCP
│   │   ├── Corefile forward 中加 force_tcp
│   │   └── 完全避免 UDP 竞态，代价是 TCP 三次握手开销
│   ├── 方案3：调 conntrack 参数（节点级、缓解非根治）
│   │   └── sysctl net.netfilter.nf_conntrack_udp_timeout / 增大 nf_conntrack_max（新内核已修复部分插入竞态）
│   └── 方案4：调整 ndots → ndots:2 减少 search 域放大倍数（配合方案0/1）

# 在 Pod 中抓包
kubectl exec <pod> -n <ns> -- tcpdump -i any -nn port 53 -c 100

# 复现测试
kubectl exec <pod> -n <ns> -- sh -c 'for i in $(seq 1 100); do nslookup api.example.com &; done; wait'

# 方案1 配置（Pod spec）
spec:
  dnsConfig:
    options:
      - name: single-request-reopen
      - name: ndots
        value: "2"
      - name: timeout
        value: "5"
      - name: attempts
        value: "2"

Ingress 不生效
├── 第一层：确认 Ingress Controller 运行正常
│   ├── kubectl get pods -n ingress-nginx / istio-system
│   ├── kubectl logs -n ingress-nginx <ingress-controller-pod> --tail=100
│   └── Controller Pod 不 Ready → 排查 Pod 异常（转到 Pod 排障题）
├── 第二层：确认 Ingress 资源状态
│   ├── kubectl describe ingress <name> -n <ns>
│   ├── kubectl get ingress <name> -n <ns> -o yaml
│   ├── 检查 Address 字段是否有 LB 地址（为空 = Controller 未处理此 Ingress）
│   ├── 检查 Events 中是否有错误
│   └── 常见问题：
│       ├── Ingress class 不匹配：ingressClassName 为空或写错
│       ├── TLS secret 不存在或 namespace 不一致
│       └── host 规则不匹配请求的 Host header
├── 第三层：确认后端 Service 可达
│   ├── kubectl get svc <backend-service> -n <ns>
│   ├── kubectl get endpoints <backend-service> -n <ns> → 是否为空
│   ├── 检查 serviceName 和 servicePort 是否与 Ingress 声明一致
│   └── Endpoints 为空 → Service selector 不匹配
├── 第四层：确认 DNS 解析
│   ├── dig @8.8.8.8 <domain> → 确认公网 DNS 解析到 LB
│   ├── 检查是否 wildcard DNS 兜底导致打到错误集群
│   │   └── dig @8.8.8.8 +short <同环境已知域名> vs <新增域名> 比较 IP
│   └── 新增域名前必须验证 wildcard 指向
├── 第五层：HTTPRoute 特殊排查（Gateway API）
│   ├── Gateway 资源是否就绪（status.addresses 有值）
│   ├── HTTPRoute 的 parentRefs 是否正确引用 Gateway
│   └── 注意：HTTPRoute（南北流量）和 Istio VS（东西流量）是两套独立路由
└── 第六层：NetworkPolicy 和 TLS
    ├── NetworkPolicy 是否拦截了 Ingress Controller 到后端 Pod 的流量
    └── TLS 证书是否已过期

kubectl describe ingress <name> -n <ns>
kubectl get ingress -A
kubectl get svc,endpoints -n <ns>
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=100
dig @8.8.8.8 <domain>

怀疑 NetworkPolicy 拦截
├── kubectl get networkpolicy -n <ns> → 列出所有策略
├── kubectl describe networkpolicy <policy> -n <ns>
│   ├── 检查 podSelector → 哪些 Pod 受此策略影响
│   ├── 检查 ingress/egress 规则 → 允许/拒绝哪些流量
│   └── 注意：NetworkPolicy 默认拒绝所有（如果有一条 policy 匹配 Pod，则只允许 policy 声明的流量）
├── 常见误拦截场景
│   ├── 新增 Policy 选择所有 Pod（podSelector: {}），意外拦截基础设施流量
│   │   └── 修复：显式允许 kube-system / monitoring 命名空间的流量
│   ├── namespaceSelector 规则写反
│   │   └── 修复：确认目标 namespace 确实有匹配的 label
│   ├── 只允许了 ingress 但 egress 默认拒绝，DNS 查询被拦截（UDP 53）
│   │   └── 修复：加 egress 规则允许 UDP 53 到 kube-system
│   └── Istio sidecar + NetworkPolicy 叠加
│       └── 修复：确保 NetworkPolicy 允许 Pod 到 sidecar（15006/15001）和 sidecar 到 Pod 的流量
├── 诊断方法
│   ├── 临时删除 NetworkPolicy 验证：kubectl delete networkpolicy <name> -n <ns>
│   ├── 在 Pod 中测试目标端口（区分 timeout vs connection refused）
│   │   └── timeout = NetworkPolicy DROP，refused = 端口未监听
│   └── 使用 netshoot 调试 Pod：kubectl run tmp --rm -it --image=nicolaka/netshoot -- /bin/bash

kubectl get networkpolicy -A
kubectl describe networkpolicy <name> -n <ns>
kubectl exec <pod> -n <ns> -- timeout 3 bash -c 'echo > /dev/tcp/<target-ip>/<port> && echo "OK" || echo "FAIL"'

Istio Sidecar 问题
├── 确认 sidecar 是否注入
│   ├── kubectl get pod <pod> -o jsonpath='{.spec.containers[*].name}' → 应有 istio-proxy
│   ├── sidecar 未注入 → 检查 namespace label：istio-injection=enabled
│   └── sidecar 注入但异常 → kubectl logs <pod> -c istio-proxy
├── 503 UC（Upstream Connection Failure）排查
│   ├── 目标服务未就绪或 mTLS 不匹配
│   │   ├── kubectl exec <client-pod> -c istio-proxy -- pilot-agent request GET /clusters | grep outbound
│   │   └── 看不到目标 cluster → Sidecar egress 未配置
│   ├── excludeOutboundPorts 导致流量绕过 envoy
│   │   ├── 检查 Deployment annotation：traffic.sidecar.istio.io/excludeOutboundPorts
│   │   └── 排除的端口走不了 mesh 路由 → 删除 annotation 或加 ServiceEntry
│   ├── mTLS STRICT 但目标未注入 sidecar
│   │   └── 修复：给目标服务注入 sidecar 或改用 PERMISSIVE 模式
│   └── DNS 代理导致外部域名被解析为假 IP（240.240.0.x）
│       ├── mesh 启用后 ISTIO_META_DNS_CAPTURE=true
│       ├── 配合 excludeOutboundPorts → DNS 返回假 IP 但流量绕过了 sidecar → 不可达
│       └── 修复：excludeOutboundPorts 对应的端口加 ServiceEntry
├── 验证路由是否生效
│   ├── 必须从 business 容器 curl，不能从 istio-proxy 容器
│   │   └── istio-proxy 以 uid=1337 运行，iptables 规则跳过此 uid，curl 直接走 kube-proxy
│   ├── kubectl exec <client-pod> -c <app-container> -- curl <target-svc>
│   └── 查 Istio 访问日志：upstream_host IP → kubectl get pods -o wide | grep <ip> 反查 Pod
└── 故障预防
    ├── 启用 mesh 前：扫所有 workload 的 excludeOutboundPorts
    ├── 启用 mesh 后：至少观察 60 分钟（覆盖 Kafka metadata refresh 周期）
    └── 基础 Service selector 不能加 version 标签限制（会破坏 DR subset 路由）

节点 NotReady
├── kubectl describe node <node> → 检查 Conditions
│   ├── MemoryPressure: True → 内存不足（转到本子类 题目 4）
│   ├── DiskPressure: True → 磁盘不足（转到本子类 题目 2）
│   ├── PIDPressure: True → PID 耗尽（转到本子类 题目 5）
│   ├── NetworkUnavailable: True → CNI 网络插件未就绪（DaemonSet 未 Ready）
│   └── Ready: False → 看 Reason，最常见两类：
│       ├── "kubelet stopped posting node status" → kubelet 挂了/断连
│       └── "PLEG is not healthy" → 运行时卡死（见下方 PLEG）
├── 检查 kubelet 状态
│   ├── ssh 到节点：systemctl status kubelet
│   ├── journalctl -u kubelet -f --since "10 min ago" → 查看日志
│   ├── 常见问题：
│   │   ├── kubelet 进程挂掉 → systemctl restart kubelet
│   │   ├── kubelet 证书过期 → openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -noout -dates（转到 题目 3）
│   │   ├── kubelet 磁盘满 → 无法写入日志/checkpoint → df -h 检查
│   │   └── kubelet 与 API Server 通信断开 → 检查网络 / DNS / 防火墙 / kube-apiserver 是否可达
├── PLEG（Pod Lifecycle Event Generator）不健康
│   ├── 日志出现 "PLEG is not healthy: pleg was last seen active Xm ago"
│   ├── 根因：kubelet 周期 relist 容器超时 → 通常是容器运行时（containerd）卡死、
│   │   节点 IO 打满、僵尸容器过多、镜像层损坏
│   └── 修复：先查运行时（crictl 是否响应）→ 必要时重启 containerd → 再重启 kubelet
└── 检查容器运行时（现代集群默认 containerd，dockershim 自 1.24 已移除）
    ├── systemctl status containerd     # 老集群才是 docker
    ├── crictl ps / crictl info → 确认运行时正常工作（crictl 才是排障工具，node 上没有 docker）
    └── 运行时挂了 → kubelet 无法管理 Pod → 修复运行时后重启 kubelet

kubectl describe node <node> | grep -A10 Conditions
kubectl get node <node> -o jsonpath='{.status.conditions}' | jq
systemctl status kubelet
journalctl -u kubelet --no-pager -n 100
systemctl status containerd

kubectl cordon <node>                       # 只标记不可调度，不动现有 Pod（先止血，防新 Pod 进来）
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --grace-period=120
#   drain = cordon + 优雅驱逐 Pod（遵守 PDB，逐个迁走）；修复无望时用于安全下线
kubectl uncordon <node>                      # 修复后恢复调度

DiskPressure
├── 确认磁盘使用情况
│   ├── ssh 到节点：df -h（空间）+ df -i（inode，inode 耗尽也会 DiskPressure）
│   ├── du -sh /var/log/pods/* 2>/dev/null | sort -rh | head -20
│   ├── du -sh /var/lib/containerd/* 2>/dev/null | sort -rh | head -10  # 老集群才是 /var/lib/docker
│   └── du -sh /var/lib/kubelet/* 2>/dev/null | sort -rh | head -10
├── 确定根因
│   ├── /var/log/pods 暴涨 → 某个 Pod 日志输出过大
│   │   └── 修复：限制 Pod stdout 输出 / 配置 kubelet containerLogMaxSize+MaxFiles / EFK|Loki 收集
│   ├── /var/lib/containerd 过大 → 镜像层缓存 / overlayfs snapshot 膨胀
│   │   └── 修复：crictl rmi --prune；确认 kubelet 镜像 GC（imageGCHighThresholdPercent）是否失效
│   ├── /var/lib/kubelet 中 emptyDir 未清理 → Pod 使用了 emptyDir 且数据量大
│   │   └── 修复：给 emptyDir 设 sizeLimit / 排查用法
│   └── 系统日志 /var/log/syslog 或 /var/log/messages 过大
│       └── 修复：配置系统 logrotate
├── 短期清理命令（containerd 集群用 crictl，node 上没有 docker）
│   ├── crictl rmi --prune           # 删除无引用镜像
│   ├── crictl rmp -a                # 删除已退出的 sandbox（Pod）
│   └── 清理 /var/log/pods 中旧 Pod 日志（注意不要删运行中 Pod 的日志）
└── 驱逐连锁反应排查（重要！）
    └── DiskPressure 驱逐是强制删除（不等 preStop），可能连锁引发 CNI IP 泄漏 /
        调度风暴 / DB 连接异常断开 —— 完整链路见【综合排障 · 题目 1：Terway IP 泄漏】

# 1. 检查证书有效期
ssh <node>
openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -noout -dates
# 输出示例：notAfter=Jan 15 12:00:00 2026 GMT （已过期）

# 2. 检查 kubelet 日志
journalctl -u kubelet --no-pager -n 50 | grep -i "cert\|expire\|tls"

# 3. 手动轮转证书（kubeadm 部署）
# 检查证书
kubeadm certs check-expiration
# 轮转所有证书
kubeadm certs renew all
# 重启 kubelet
systemctl restart kubelet

# 4. 如果是 managed K8s（如 ACK/EKS）→ 证书由云厂商自动管理
# 检查 kube-controller-manager 的 cluster-signing-cert-file 和 cluster-signing-key-file

MemoryPressure + Pod 被杀
├── kubectl describe node <node> | grep -A5 "Allocated resources"
├── kubectl top node → 查看实际内存使用
├── kubectl top pod -A --sort-by=memory → 找出内存消耗最大的 Pod
├── 区分是 kubelet 驱逐还是内核 OOM（describe pod 看 reason：Evicted vs OOMKilled）
├── 根因分析
│   ├── Pod requests 设置过低 → 调度器超卖节点（requests 之和 < 实际用量）
│   │   └── 修复：调高 requests 至接近实际用量（参考 VPA 推荐）
│   ├── 某个 Pod 内存泄漏 → 持续增长
│   │   └── 修复：修泄漏 + 临时调高 limit
│   ├── Limit 未设置 → 无上限 Pod 吃光节点内存
│   │   └── 修复：加 LimitRange 兜底 + ResourceQuota 限总量
│   └── 节点规格不足 → 提升节点规格 / 扩节点
└── 内核 OOM killer 的挑选逻辑（按 oom_score_adj，越大越先被杀）
    ├── BestEffort（无任何 request/limit）      → oom_score_adj = 1000（最先杀）
    ├── Burstable（设了 request/limit 但 req≠limit）→ oom_score_adj ∈ [2, 999]，内存 request 越大越难被杀
    ├── Guaranteed（每个容器 CPU+内存 request==limit）→ oom_score_adj = -997（最后杀）
    └── 修复：关键服务设为 Guaranteed QoS；给关键 Pod 设高 PriorityClass 降低被驱逐概率

# 1. 查看节点 PID 使用情况
ssh <node>
cat /proc/sys/kernel/pid_max
# 默认 32768 或 4194304
ps aux | wc -l

# 2. 找出 PID 消耗大户
ps aux --sort=-pid | head -20

# 3. 容器内 PID 消耗
for p in $(crictl pods -q); do
  crictl inspectp $p | jq '.status.linux.namespaces.options.pid'
done

PVC Pending
├── kubectl describe pvc <pvc> -n <ns> → 查看 Events
│   ├── "storageclass.storage.k8s.io <name> not found"
│   │   → 检查 StorageClass 是否存在：kubectl get sc
│   │   → 修复：创建 StorageClass 或修正 PVC 上的 storageClassName
│   ├── "failed to provision volume" → Provisioner 创建失败
│   │   → kubectl logs -n kube-system deploy/ebs-csi-controller（以 AWS EBS 为例）
│   │   → 常见原因：IAM 权限不足 / 云配额耗尽 / AZ 不匹配
│   ├── "no persistent volumes available" → 静态 PV 不匹配
│   │   → kubectl get pv → 检查已有 PV 的 storageClassName / accessMode / capacity
│   │   → 修复：创建匹配的 PV 或改用动态 provisioning
│   └── "waiting for first consumer to be created before binding"
│       → StorageClass 的 volumeBindingMode: WaitForFirstConsumer（正常行为）
│       → 只有在 Pod 使用 PVC 时才会触发绑定和创建
└── 检查 PV 绑定约束
    ├── accessModes 是否匹配（RWO/RWX/ROX）
    ├── storage 容量是否满足（PV capacity < PVC request → 不匹配）
    └── nodeAffinity（静态 PV 绑定了特定节点）

kubectl get pvc -n <ns>
kubectl describe pvc <pvc> -n <ns>
kubectl get sc
kubectl get pv

Pod 挂载失败
├── Multi-Attach Error（RWO PV 核心问题）
│   ├── kubectl describe pod <pod> → 查看 Volume 挂载错误
│   ├── PV 的 accessModes 是 RWO（只能同时挂载到一个节点）
│   ├── 旧 Pod 还在 Terminating → PV 未释放
│   │   └── kubectl get pods -A -o wide | grep <node> → 找旧 Pod
│   └── 修复：
│       ├── 等待旧 Pod 完全终止（包括 detach volume）
│       ├── 强制删除旧 Pod：kubectl delete pod <old-pod> --force --grace-period=0
│       └── 或改用 RWX 存储（如 EFS/NFS）
├── Mount 权限错误
│   ├── Permission denied → Pod securityContext 与目录权限不匹配
│   │   └── 修复：Pod spec 加 securityContext.fsGroup 匹配存储权限
│   └── 或加 initContainer chown/chmod
├── NFS/EFS mount timeout
│   ├── EFS security group 未放行 NFS 端口（2049）
│   │   └── 修复：检查并更新安全组规则
│   ├── EFS mount target 不在同一 VPC/子网
│   └── DNS 解析 EFS endpoint 失败
├── CSI Driver 问题
│   ├── kubectl get pods -n kube-system | grep csi → CSI Controller / Node Pod 是否 Running
│   ├── kubectl logs -n kube-system deploy/ebs-csi-controller --tail=100
│   └── CSI Node 未运行 → DaemonSet 调度失败
└── 节点 Attach/Detach 限制
    ├── AWS EC2 每实例最多挂载 28 个 EBS（包括 root）
    └── 修复：减少 EBS 挂载 / 使用更大实例

# 1. 检查 PVC 状态
kubectl get pvc -n <ns>
kubectl describe pvc <pvc> -n <ns>

# 2. 检查 StorageClass 是否允许扩容
kubectl get sc <sc-name> -o yaml | grep allowVolumeExpansion
# 必须是 true

# 3. 扩容步骤要求
# - 步骤1：PVC spec.resources.requests.storage 已更新 → Status 显示 Resizing
# - 步骤2：PV 已扩容（云厂商侧已调整）→ 但 filesystem 未 resize
#    → 需要 Pod 重启或在线 resize（取决于 CSI driver 和 FS 类型）
# - 步骤3：Pod 重启后 CSI Node Driver 执行 filesystem resize

# 4. 如果 Pod 使用了此 PVC 的子路径（subPath）
# → subPath 不支持在线扩容 → 必须重建 Pod

# 1. 查找孤儿 PVC（无 Pod 使用）
kubectl get pvc -A -o json | jq -r '
  .items[] | select(.status.phase == "Bound") |
  .metadata.namespace as $ns | .metadata.name as $name |
  "\($ns)/\($name)"
' | while read ns_pvc; do
  ns=$(echo "$ns_pvc" | cut -d/ -f1)
  pvc=$(echo "$ns_pvc" | cut -d/ -f2)
  count=$(kubectl get pods -n "$ns" -o json | jq --arg pvc "$pvc" \
    '[.items[].spec.volumes[]? | select(.persistentVolumeClaim.claimName == $pvc)] | length')
  [ "$count" -eq 0 ] && echo "ORPHAN: $ns/$pvc"
done

# 2. StatefulSet 删除 PVC 策略
kubectl get statefulset <name> -n <ns> -o jsonpath='{.spec.persistentVolumeClaimRetentionPolicy}'
# 检查 WhenDeleted 是 Retain（保留）还是 Delete（删除）

RBAC 权限不足
├── 确认错误详情
│   ├── kubectl logs <pod> → 找到完整错误信息
│   ├── 记录：SA 名、namespace、操作动词（verb）、API 资源、资源名
│   └── 关键信息：cannot get/list/create/update/delete/watch <resource>
├── 分析权限链路
│   │
│   │   ServiceAccount → RoleBinding/ClusterRoleBinding → Role/ClusterRole
│   │
│   ├── kubectl get sa <sa> -n <ns> -o yaml → 确认 SA 存在
│   ├── kubectl get rolebinding,clusterrolebinding -A -o json |
│   │   jq '.items[] | select(.subjects[]?.name=="<sa>" and .subjects[]?.namespace=="<ns>")'
│   │   → 找到绑定了此 SA 的 RoleBinding/ClusterRoleBinding
│   ├── kubectl describe role <role> -n <ns> / kubectl describe clusterrole <role>
│   │   → 查看规则是否包含所需 verb + resource
│   └── 缺少权限 → 创建/修改 Role/ClusterRole + RoleBinding/ClusterRoleBinding
└── 常见权限缺口
    ├── Pod 需要读 ConfigMap → 缺少 "get" configmaps
    ├── ArgoCD SA 缺少对目标 namespace 的 create/update 权限
    ├── CI/CD SA 需要 create pods
    ├── Prometheus 需要 list/get/watch pods,services,endpoints（跨所有 namespace）
    └── Ingress Controller 需要 get/watch secrets（TLS）

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: read-pods
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

# 1. 验证当前用户（或指定 SA）能否执行某个操作
kubectl auth can-i get pods -n production
kubectl auth can-i create deployments -n production --as system:serviceaccount:production:deployer

# 2. 列出当前用户在某个 namespace 的所有权限
kubectl auth can-i --list -n production

# 3. 查看 RBAC 关系
kubectl get rolebindings,clusterrolebindings -A -o json | \
  jq '.items[] | {name: .metadata.name, namespace: .metadata.namespace, roleRef: .roleRef, subjects: .subjects}'

# 4. 从资源反向查谁有权限（需要 kubectl-who-can 插件）
kubectl who-can delete pods -n production

kubectl get networkpolicy -A                          # K8s 原生
kubectl get networkpolicies.crd.projectcalico.org -A  # Calico namespaced
kubectl get globalnetworkpolicies.crd.projectcalico.org  # Calico 全局（易被忽略！）
kubectl get ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies -A  # Cilium

# Cilium：Hubble 实时看被策略 DROP 的流（最直观）
hubble observe --verdict DROPPED --pod <ns>/<pod>
# Calico：开 policy drop 日志后看内核 calico-packet 日志，或用 calicoctl 查策略命中
kubectl exec -n <ns> <pod> -- nc -zv <target-ip> <port>   # timeout=被拦截

# 1. 检查 namespace 的 PSA 标签
kubectl get ns <ns> -o yaml | grep pod-security
# 输出示例：pod-security.kubernetes.io/enforce: restricted

# 2. 查看违规详情
kubectl describe pod <pod> -n <ns> | grep -A5 Warning

# 3. PSA 三级别对照
# privileged: 无限制
# baseline: 禁止已知提权（hostNetwork/hostPID/privileged 容器等）
# restricted: 最严格（要求 runAsNonRoot、seccompProfile、drop ALL capabilities 等）

# 4. 修复方向
# a) 修改 Pod spec 符合安全策略
# b) 降低 namespace 的 enforce 等级（仅用于过渡期）
# c) 使用 admission controller 豁免特定 SA

# 第一层：看到 Pod Pending，首查 Pod Events
kubectl describe pod my-app-7d9f8b-xxxxx -n production
# Events:
#   Warning  FailedScheduling  3m   default-scheduler
#     0/6 nodes are available: 6 Insufficient aliyun/vpc-eni-ip.
# 报错不是常见的 CPU/内存，而是 ENI IP——信号很不寻常

# 第二层：看节点状态
kubectl get nodes
# 所有节点都显示 Ready —— 和直觉（节点正常但 Pod 无法调度）矛盾

# 第三层：拉时间线找线索（关键动作！）
kubectl get events -A --sort-by='.metadata.creationTimestamp' | tail -60
# 发现 T0-T0+5min 间大量 Evicted 事件
# production   Warning   Evicted   Pod/my-app-old    kubelet
#   The node was low on resource: ephemeral-storage. Threshold: 10%, available: 7%.

# 第四层：确认 DiskPressure
kubectl describe node cn-hangzhou.x.x.x.x | grep -A10 Conditions
# DiskPressure: True

# 第五层：逻辑推理
# 磁盘满 → 驱逐 → 强制删除 Pod
# 但为什么 Pod 驱逐后反而调度不上去了？问题应该在网络层

# 第六层：排查 Terway CRD IPAM
kubectl get nodeeni -A
# NAME                    AVAILABLE   TOTAL   STATUS
# cn-hangzhou.x.x.x.x    0           14      Ready    ← IP 全部耗尽
# cn-hangzhou.x.x.x.x    0           14      Ready

# 但实际运行的 Pod 数只有 6 个！
kubectl get pods -A -o wide | grep cn-hangzhou.x.x.x.x | grep Running | wc -l
# 输出：6

# 第七层：确认 IP 泄漏
kubectl get nodeeni cn-hangzhou.x.x.x.x -o yaml
# status.enis[].assignedPrivateIPs[].podInfo.name → 指向已不存在的 Pod（被驱逐的）

# 第八层：查看 terway-daemon 日志
kubectl logs -n kube-system -l app=terway-daemon --tail=200 | grep -i "error\|recycle"
# ERR  failed to release IP for pod: pod not found, skip cleanup
# WARN gc: pod already deleted, but IP still allocated

磁盘 >90% → kubelet DiskPressure → 强制驱逐 Pod（不等 preStop）
→ Terway preStop/删除钩子未执行 → IP 未回收（CRD 状态仍为"已分配"）
→ 节点 ENI IP 耗尽 → 新 Pod 调度时无可用 IP → Pending
→ 所有业务部署挂掉

# 第一步：查看 Pod DNS 配置
kubectl exec <pod> -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search production.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

# ndots:5 的含义：
# 查询的域名中点号 < 5 → 在每个 search 域逐一尝试后缀
# 例如查 api.example.com（2 个点）：
# 1. api.example.com.production.svc.cluster.local → NXDOMAIN
# 2. api.example.com.svc.cluster.local            → NXDOMAIN
# 3. api.example.com.cluster.local                → NXDOMAIN
# 4. api.example.com.                             → 成功（但已经是第 4 次查询）
# 一次业务请求 → 4 次 UDP DNS 查询

# 在高并发下，这 4 倍放大再叠加上 conntrack 竞态条件 → 灾难

# 第二步：测量实际 DNS 延迟
kubectl exec <pod> -- time for i in $(seq 1 10); do nslookup api.example.com; done

# 第三步：对比直接查上游 DNS
kubectl exec <pod> -- time nslookup api.example.com 8.8.8.8

集群级响应变慢 / 周期性 32 秒超时
├── 观察超时模式
│   ├── 周期性（每 N 分钟一波）→ 有定时 reconcile 的组件在超时
│   ├── 32 秒 = client-go / kube-apiserver 默认超时
│   └── 检查 ArgoCD controller 日志中的 reconcile 耗时
├── 排查 ArgoCD
│   ├── kubectl get applications -n argocd → 是否有 Unknown/Error 状态
│   ├── kubectl get secrets -n argocd | grep cluster → cluster secret 数量
│   ├── 检查是否有已删除的集群残留 cluster secret
│   │   → ArgoCD controller 每次 reconcile 都要连所有 cluster
│   │   → 死集群每次 32s timeout × N apps → controller 卡死
│   └── 修复：删除不再使用的 ArgoCD cluster secret
├── 排查代理/网络层
│   ├── 检查 tinyproxy/squid 状态（代理过载或死锁）
│   ├── 检查 NO_PROXY 列表是否完整（不该走代理的内部流量走了代理）
│   └── 检查 DNS 解析延迟
└── 排查 etcd
    ├── etcdctl endpoint health
    ├── etcdctl endpoint status
    ├── 磁盘 IO 饱和 → etcd 响应变慢 → apiserver 超时 → 全集群超时
    └── etcd 必须用 SSD（NVMe 最佳），不能与其他服务共享磁盘

# 1. 检查 ownerReferences
kubectl get application <name> -n argocd -o yaml | grep ownerReferences -A5
# 如果有 ownerReferences.kind: ApplicationSet → 由 ApplicationSet 管理

# 2. 查出是哪个 ApplicationSet
OWNER=$(kubectl get application <name> -n argocd -o jsonpath='{.metadata.ownerReferences[0].name}')
echo "Owner ApplicationSet: $OWNER"

# 3. 正确删除方式：从 git 源头入手
# 方式A：删除 gitops 仓库中对应 generator 的目录（如 clusters/<env>/applications/<path>/）
# 方式B：修改 ApplicationSet generator 的过滤规则排除此 app
# 方式C：在 ApplicationSet 中修改 prune 策略

# 不可用 kubectl delete，ApplicationSet controller 检测到 child 缺失会立即重建

# 1. 检查 Prometheus 的 ruleSelector
kubectl get prometheus -n monitoring -o jsonpath='{.items[0].spec.ruleSelector}'
# 输出示例：{"matchLabels":{"release":"monitoring"}}

# 2. 检查 PrometheusRule 的 labels
kubectl get prometheusrule -A -o json | jq -r '.items[] | "\(.metadata.name): \(.metadata.labels)"'
# 某条输出：sandbox-rules: {"app":"monitoring"}  ← label 不匹配！

# 3. 对比规则数量
# yaml 中的告警规则数
kubectl get prometheusrule -A -o json | jq '[.items[].spec.groups[].rules[] | select(.alert)] | length'
# Prometheus 实际加载的告警规则数
curl -s http://prometheus.monitoring:9090/api/v1/rules | jq '[.data.groups[].rules[] | select(.type=="alerting")] | length'
# 两个数不一致 → 有规则未加载

# 第一层：从用户反馈倒推
# - QA 环境老项目出现了 AI 环境用户的数据 → 确定是交叉污染

# 第二层：查数据链路
# - 消息表 realtime_messages 的 project_id 在 1-274 区间
# - env-AI 的自增 id 才到 274，env-QA 的老项目大量分布在 1-274
# - 新消息的 created_at >= env-AI 上线日，但 project 创建日期 < env-AI 上线日 → 确认脏消息来源

# 第三层：查配置中心
# - Nacos 中 env-AI 的 RabbitMQ host 指向 QA 的 broker
# - env-AI 的 dispatcher 没有按 dispatch_env 过滤 → 两个环境的消息混在同一个 fanout exchange

# 第四层：查基础设施
# - Aurora cluster 共用 → 虽然不同 schema 但 AUTO_INCREMENT 起点都是 1
# - 两个环境的消息通过同一个 RabbitMQ exchange 分发 → 消费者无差别处理

# DestinationRule 定义版本子集
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: user-service
spec:
  host: user-service
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

---
# VirtualService 流量权重路由
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
    - user-service
  http:
    - route:
        - destination:
            host: user-service
            subset: v1
          weight: 90
        - destination:
            host: user-service
            subset: v2
          weight: 10

# 观察 P99 延迟和错误率 30 分钟
kubectl port-forward svc/kiali 20001:20001 -n istio-system

# 无异常后：50% 验证
kubectl patch vs user-service --type json \
  -p '[{"op":"replace","path":"/spec/http/0/route/0/weight","value":50},
       {"op":"replace","path":"/spec/http/0/route/1/weight","value":50}]'

# 再观察 30 分钟 → 100% 全量

# 第一步：确认发布历史
kubectl rollout history deployment/user-service -n production

# 第二步：查看故障 Pod 日志（保留现场）
kubectl logs -l app=user-service,version=v2 -n production --tail=500 > /tmp/v2-logs.txt
kubectl describe pod -l app=user-service,version=v2 -n production > /tmp/v2-events.txt

# 第三步：立即回滚
kubectl rollout undo deployment/user-service -n production

# 如果有特定版本（REVISION=5）
kubectl rollout undo deployment/user-service --to-revision=5 -n production

# 第四步：确认回滚进度
kubectl rollout status deployment/user-service -n production

# 确认所有 Pod 运行在旧版本
kubectl get pods -l app=user-service -o jsonpath='{.items[*].spec.containers[0].image}'

# 监控错误率是否恢复
kubectl top pods -l app=user-service

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  feature-flags.yaml: |
    new_checkout_flow: false
    rate_limit_qps: 1000
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: config
              mountPath: /etc/app/config
              readOnly: true
      volumes:
        - name: config
          configMap:
            name: app-config

# 每次配置变更创建新的 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v2    # 版本化命名
---
# 更新 Deployment 引用
spec:
  template:
    spec:
      containers:
        - name: app
          envFrom:
            - configMapRef:
                name: app-config-v2   # 改变引用触发滚动更新

# 在集群中部署 sealed-secrets controller
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/latest/download/controller.yaml

# 本地用 kubeseal 加密 Secret
kubectl create secret generic db-creds \
  --from-literal=password=MySecret123 \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > sealed-db-creds.yaml

# sealed-db-creds.yaml 可以安全存入 Git
# 集群内 controller 自动解密为真实 Secret

# 在 Git 中存 ExternalSecret CR（不存数据，只存引用）
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-creds
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds        # 目标 Secret 名称
  data:
    - secretKey: password
      remoteRef:
        key: prod/my-service/db
        property: password

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
spec:
  decryption:
    provider: sops
    secretRef:
      name: sops-age-key

# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"          # gp3 用绝对值 iops/throughput（iopsPerGB 是 io1/io2 的写法，gp3 无效）
  throughput: "125"     # MiB/s
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer   # 延迟绑定：Pod 调度后再创建卷（确保卷在 Pod 所在 AZ）
allowVolumeExpansion: true                # 允许在线扩容
reclaimPolicy: Retain                     # 保留删除策略
---
# StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka
spec:
  serviceName: kafka-headless
  replicas: 3
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: ebs-gp3
        resources:
          requests:
            storage: 20Gi
  template:
    spec:
      containers:
        - name: kafka
          volumeMounts:
            - name: data
              mountPath: /var/lib/kafka/data

# 第一步：确认 StorageClass 支持扩容
kubectl get sc ebs-gp3 -o jsonpath='{.allowVolumeExpansion}'
# 应返回 true

# 第二步：扩容单个 PVC（从 20Gi → 50Gi）
kubectl patch pvc data-kafka-2 -n kafka --patch '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'

# 第三步：等待扩容完成
kubectl get pvc data-kafka-2 -n kafka -w

# 第四步：进入 Pod 验证
kubectl exec -it kafka-2 -n kafka -- df -h /var/lib/kafka/data

# 第五步：逐个扩容其余 PVC
for i in 1 0; do
  kubectl patch pvc data-kafka-$i -n kafka --patch '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'
  kubectl wait --for=jsonpath='{.status.capacity.storage}'=50Gi pvc/data-kafka-$i -n kafka --timeout=300s
done

# app-common-config（跨环境共用）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-common-config
data:
  LOG_LEVEL: "info"
  METRICS_PORT: "9090"
  GRPC_KEEPALIVE: "60s"
---
# app-production-config（生产环境特定）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-production-config
  namespace: production
data:
  DB_HOST: "prod-db-master.internal:5432"
  REDIS_HOST: "prod-redis-cluster.internal:6379"
  REPLICA_COUNT: "5"
---
# Deployment 中按顺序引用
spec:
  template:
    spec:
      containers:
        - name: app
          envFrom:
            - configMapRef:
                name: app-common-config
            - configMapRef:
                name: app-production-config
            - secretRef:
                name: app-production-secret
          # 关键覆盖项用 env 显式声明（优先级最高）
          env:
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: production
rules:
  # 只给 Deployment 相关权限
  - apiGroups: ["apps"]
    resources: ["deployments", "deployments/scale"]
    verbs: ["get", "list", "watch", "update", "patch"]
  # 允许读取 Service 和 Endpoints（验证部署）
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get", "list", "watch"]
  # 允许读取 ConfigMap（配置管理）
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "update", "patch"]
  # 允许读取/创建 Events（发布状态跟踪）
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["get", "list", "watch", "create"]
  # 允许读取 Pods（查看日志验证）
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer
  namespace: production
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: production
roleRef:
  kind: Role
  name: ci-deployer
  apiGroup: rbac.authorization.k8s.io

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted      # 强制拦截
    pod-security.kubernetes.io/enforce-version: v1.29
    pod-security.kubernetes.io/audit: restricted        # 审计日志记录
    pod-security.kubernetes.io/warn: restricted         # 警告提示

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
      containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: false
            privileged: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          volumeMounts:
            - name: tmp
              mountPath: /tmp        # 需要写临时文件时挂 emptyDir
            - name: app-cache
              mountPath: /var/cache  # 需要写缓存时挂 emptyDir
      volumes:
        - name: tmp
          emptyDir: {}
        - name: app-cache
          emptyDir: {}

# 第一步：ClusterSecretStore 连接 Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "production-reader"    # Vault Kubernetes Auth Role

---
# 第二步：ExternalSecret 同步数据库密码
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-creds
  namespace: production
spec:
  refreshInterval: 1h                  # 每 1 小时同步
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-creds                     # 目标 K8s Secret 名称
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: prod/database
        property: username
    - secretKey: password
      remoteRef:
        key: prod/database
        property: password
    - secretKey: connection-string
      remoteRef:
        key: prod/database
        property: connection_string

---
# 第三步：Deployment 引用同步后的 Secret
spec:
  containers:
    - name: app
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-creds
              key: password

# 安装 Reloader
helm install reloader stakater/reloader

# Deployment annotation 触发自动重启
metadata:
  annotations:
    reloader.stakater.com/auto: "true"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      # Pod 级别 SecurityContext
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          image: myapp:v1.5.2
          # Container 级别 SecurityContext
          securityContext:
            allowPrivilegeEscalation: false
            privileged: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          # 挂载可写路径
          volumeMounts:
            - name: tmp
              mountPath: /tmp
            - name: app-log
              mountPath: /var/log/app
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 100Mi
        - name: app-log
          emptyDir:
            sizeLimit: 500Mi

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "1000"       # 每个 Pod 目标 1000 QPS
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0   # 扩容立即响应
      policies:
        - type: Percent
          value: 100                   # 每次最多翻倍
          periodSeconds: 60
        - type: Pods
          value: 10                    # 或每次最多加 10 个
          periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容等 5 分钟，防抖
      policies:
        - type: Percent
          value: 10                    # 每次最多缩 10%
          periodSeconds: 60
      selectPolicy: Min                # 缩容取最小值，保守

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    memory: "2Gi"
    # CPU limits 不设，避免 throttling

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-consumer-scaler
  namespace: order
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-consumer
  pollingInterval: 15           # 每 15 秒检查 lag
  cooldownPeriod: 300           # 无 lag 后等 5 分钟再缩
  idleReplicaCount: 0           # 缩到 0
  minReplicaCount: 0            # 最小 0（KEDA 特色）
  maxReplicaCount: 30
  fallback:
    failureThreshold: 3
    replicas: 3                 # Kafka 不可达时保持 3 个副本兜底
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 600
          policies:
            - type: Percent
              value: 50
              periodSeconds: 60
        scaleUp:
          stabilizationWindowSeconds: 0
          policies:
            - type: Percent
              value: 100
              periodSeconds: 15
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-bootstrap.kafka:9092
        consumerGroup: order-consumer-group
        topic: orders
        lagThreshold: "500"          # 每个 Pod 承担 500 lag
        offsetResetPolicy: latest
        allowIdleConsumers: "false"
        excludePersistentLag: "true"  # 排除死分区 lag
      authenticationRef:
        name: kafka-trigger-auth

# 第一步：给 GPU 节点打 taint
kubectl taint nodes gpu-node-01 nvidia.com/gpu=present:NoSchedule

# 同时打标签（亲和性使用）
kubectl label nodes gpu-node-01 node-type=gpu

apiVersion: v1
kind: Pod
metadata:
  name: inference-pod
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: "present"
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: node-type
                operator: In
                values:
                  - gpu
  containers:
    - name: inference
      image: myapp:inference-v2
      resources:
        limits:
          nvidia.com/gpu: 1       # 声明 1 个 GPU
        requests:
          nvidia.com/gpu: 1
          cpu: "4"
          memory: "16Gi"

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 9
  template:
    spec:
      topologySpreadConstraints:
        # 跨 AZ 分布约束
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule    # 严格满足
          labelSelector:
            matchLabels:
              app: order-service
        # 跨 Node 分布约束
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway   # 尽力满足
          labelSelector:
            matchLabels:
              app: order-service
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app: order-service
                topologyKey: kubernetes.io/hostname

kubectl get pods -l app=order-service -o wide | awk '{print $7}' | sort | uniq -c