01
调度与资源
关键问题工作负载为什么没有落到预期节点，资源承诺是否真实反映运行峰值？
现场任务用 requests、limits、亲和性与污点构建一套可复现的调度约束，并演练容量不足时的处置顺序。
通过信号FailedScheduling 事件可解释，节点余量可量化，扩容或降载动作有明确触发阈值。
01 / LEARNING MAP
从机制出发，练到信号闭环
五条路径覆盖生产集群的关键边界。每一条都从问题出发，以可执行任务和可验证信号收束。
02
网络与流量
关键问题一次请求经过哪些入口、服务发现与策略边界，失败发生在哪一跳？
现场任务沿 DNS、Service、Gateway 和 NetworkPolicy 验证请求路径，保留每一跳的可观测证据。
通过信号解析延迟、连接失败率和路由权重均有基线，异常能定位到具体边界。
03
存储与状态
关键问题Pod 重建后哪些状态必须保留，卷绑定与故障域如何影响恢复时间？
现场任务验证 PVC 绑定、快照恢复与跨节点重建流程，记录 RPO、RTO 和数据校验结果。
通过信号卷事件无阻塞，恢复演练达到目标时间，业务校验确认数据完整。
04
发布与弹性
关键问题新版本如何分批进入流量，指标恶化时系统能否停止并安全回滚？
现场任务串联预检、灰度、SLO 观察、放量与回滚，并验证 HPA 在发布窗口内的行为。
通过信号每一阶段都有自动门禁，错误预算触线会停止放量，回滚时间被实际测量。
05
安全与治理
关键问题谁能改变集群状态，敏感配置如何流转，越权行为怎样被发现？
现场任务收敛 ServiceAccount 权限、隔离 Secret、启用准入策略，并从审计日志验证控制效果。
通过信号最小权限可验证，违规清单在准入阶段被拒绝，关键变更可追溯到主体。
02 / INCIDENT ATLAS
把故障拆成一条可验证的判断链
先看现象，再提出判断；用证据缩小范围，执行可逆处置，最后把系统性条件写进复盘。
Pod 长时间 Pending
- 现象
- checkout 命名空间的新副本超过 10 分钟仍为 Pending，Deployment 可用副本低于目标值。
- 判断
- 资源请求超过节点可分配量，或污点、亲和性、未绑定 PVC 共同缩小了可调度节点集合。
- 证据
- 先读取 Pod Events 中的 FailedScheduling 原因，再对照候选节点 Allocatable、污点和 PVC 绑定状态。
- 处置
- 暂停继续扩副本；按事件原因修正错误约束，资源确实不足时先扩容节点池，避免无依据地下调 requests。
- 复盘
- 复盘 requests 与七天 P95 用量的偏差，为 Pending 持续时间和节点余量建立告警与容量阈值。
现场命令
kubectl describe pod -n checkout checkout-api-7d9f6c8b7d-k2m4p常见误区
只看 Pod phase 就删除重建；调度约束未变时，新 Pod 会以相同原因继续 Pending。
CrashLoopBackOff 持续重启
- 现象
- checkout-api 重启次数持续增长，实例短暂 Ready 后退出，五分钟错误率升至 18%。
- 判断
- 新镜像启动失败、必需配置缺失，或存活探针在应用完成初始化前反复终止容器。
- 证据
- 读取上一个容器实例的退出日志与 exit code，并将重启时间点和探针失败事件、发布版本对齐。
- 处置
- 暂停发布并回滚到最近健康版本；确认根因后修复配置或探针时序，再用单副本验证启动全过程。
- 复盘
- 补充启动依赖检查、startupProbe 和异常退出告警，并把冷启动 P99 纳入发布预检。
现场命令
kubectl logs -n checkout checkout-api-7d9f6c8b7d-k2m4p -c app --previous --tail=200常见误区
只读取当前容器日志；真正的异常栈常留在已经终止的上一实例中。
OOMKilled 内存终止
- 现象
- worker Pod 在流量高峰被重启，Last State 显示 OOMKilled，队列积压从 300 增至 8,000。
- 判断
- 容器 limit 低于峰值工作集，或新版本存在泄漏、无界缓存和过高并发。
- 证据
- 核对 lastState、limit、工作集曲线和并发量，区分容器 cgroup 触限与节点 MemoryPressure。
- 处置
- 先限流并暂停新版本；泄漏则回滚，容量模型错误则依据峰值和安全余量调整 limit 后小流量验证。
- 复盘
- 保留堆分析与并发压测结果，为内存斜率、limit 使用率和队列深度设置联合告警。
现场命令
kubectl get pod -n jobs invoice-worker-6b98c44f8f-v7q2n -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'常见误区
看到 OOMKilled 就认定节点内存不足；容器触限和节点驱逐需要不同的扩容与修复路径。
集群内 DNS 解析异常
- 现象
- 多个命名空间间歇出现 service name lookup timeout，依赖调用失败率在十分钟内升至 24%。
- 判断
- CoreDNS 饱和或重启、到 kube-dns 的网络策略误拦截，或上游 DNS 延迟导致转发超时。
- 证据
- 从故障 Pod 发起解析，检查 CoreDNS 错误与延迟、EndpointSlice、重启次数及 UDP/TCP 53 策略命中。
- 处置
- 冻结相关网络变更；策略误配则回滚，CoreDNS 饱和则按 CPU 与请求率证据扩副本并降低上游超时风险。
- 复盘
- 增加集群内解析 SLI、CoreDNS 饱和告警和跨命名空间探针，并在策略发布前验证 DNS 基线。
现场命令
kubectl exec -n checkout deploy/checkout-api -- nslookup payments.payments.svc.cluster.local常见误区
只在本机执行 nslookup；本机解析链路绕过集群 DNS 与命名空间网络策略，不能代表 Pod 现场。
滚动发布无法收敛
- 现象
- checkout-api 发布 15 分钟仍停在 7/10 Ready，旧 ReplicaSet 未缩容且错误预算快速消耗。
- 判断
- 新 Pod 就绪探针失败、PDB 与 maxUnavailable 冲突，或镜像拉取和节点容量阻塞新副本。
- 证据
- 对照 rollout 状态、ReplicaSet 数量、Pod Events、探针响应和 PDB disruptionsAllowed 找到停滞条件。
- 处置
- 立即暂停 rollout；新版本不健康就回滚，容量或 PDB 阻塞则先恢复可用副本再修正发布参数。
- 复盘
- 为 ProgressDeadlineExceeded 建告警，演练 PDB 与滚动参数组合，并记录达到稳定副本数的耗时。
现场命令
kubectl rollout status deployment/checkout-api -n checkout --timeout=120s常见误区
只提高 progressDeadlineSeconds；这会延迟失败信号，却不会修复探针、容量或 PDB 冲突。
灰度流量未按预期切换
- 现象
- HTTPRoute 配置 10% 灰度权重，但网关指标显示新版本仅接收 1%，部分会话始终命中旧版本。
- 判断
- 后端权重未被控制器接受、Service selector 指向错误版本，或会话保持与长连接扭曲短窗口分布。
- 证据
- 检查 HTTPRoute Accepted/ResolvedRefs 条件、后端 EndpointSlice、网关请求计数，并按会话和协议拆分流量。
- 处置
- 停止继续放量；先修正未接受的路由或 selector，若为会话效应则延长观察窗并按独立请求统计。
- 复盘
- 在门禁中校验实际流量占比与配置权重偏差，保存路由状态、样本量和控制器版本作为发布证据。
现场命令
kubectl get httproute -n checkout checkout-canary -o yaml常见误区
把声明的 10% 权重当作实际 10% 请求；会话保持、长连接和低样本量都会造成显著偏差。
03 / RELEASE CONTROL
发布不是一次动作，而是一组连续门禁
每个阶段同时定义放行证据和停止信号。没有证据就不推进，触碰阈值就恢复到已知健康状态。
- 01
变更预检
PASS GATE / 放行门禁清单校验通过，镜像签名有效，容量可容纳 surge，回滚版本与负责人已确认。
STOP SIGNAL / 停止信号发现高风险策略变更、容量不足、依赖未就绪或缺少可执行回滚步骤时停止。
RESPONSIBILITY / 责任边界变更提交人补齐清单与回滚方案；发布负责人完成预检并决定是否进入灰度。
- 02
小流量发布
PASS GATE / 放行门禁单副本或 5% 流量健康，启动、就绪、核心事务与依赖调用全部通过。
STOP SIGNAL / 停止信号新版本五分钟错误率超过基线 1 个百分点，或出现重启、积压和数据校验失败时停止。
RESPONSIBILITY / 责任边界发布负责人执行灰度与暂停；服务负责人验证核心事务并对版本健康结论负责。
- 03
SLO 观察
PASS GATE / 放行门禁至少覆盖一个业务高峰窗口，延迟、错误率、饱和度和错误预算均在阈值内。
STOP SIGNAL / 停止信号P95 延迟恶化超过 15%、错误预算燃烧率超过 2，或证据缺失时停止。
RESPONSIBILITY / 责任边界服务负责人解释业务 SLO；SRE 核验观测窗口、阈值和错误预算，任一方可叫停。
- 04
放量或回滚
PASS GATE / 放行门禁每次放量后指标稳定且版本分布符合目标；异常时能在既定时限恢复上一版本。
STOP SIGNAL / 停止信号实际流量权重偏离目标、健康副本下降或回滚演练未通过时停止继续放量。
RESPONSIBILITY / 责任边界发布负责人执行放量或回滚；故障指挥者在用户影响扩大时接管恢复优先级。
- 05
证据归档
PASS GATE / 放行门禁变更、指标、事件、审批、实际版本和回滚结果关联到同一发布记录。
STOP SIGNAL / 停止信号缺少时间窗、查询链接、操作者或最终状态时不关闭发布任务。
RESPONSIBILITY / 责任边界发布负责人归档完整证据；服务负责人确认最终状态，复盘改进项由明确责任人接收。
04 / DECISION LAB
架构选择必须带着约束和代价
工具名称不是答案。把工作负载上下文、硬约束、选择依据和长期代价放在同一张决策卡上。
01
Deployment / StatefulSet
- 上下文
- 订单索引服务需要三个副本，Pod 重建后仍要挂载各自的数据卷并保持稳定成员标识。
- 约束
- 恢复流程依赖固定网络身份与卷一一对应，同时要求滚动更新一次只替换一个成员。
- 选择
- 选择 StatefulSet；若状态完全外置且副本可任意替换，则选择 Deployment 简化运维。
- 代价
- 稳定身份提升恢复确定性，但扩缩容、卷清理和故障成员替换需要显式操作规程。
02
HPA / KEDA
- 上下文
- API 由 CPU 驱动，异步 worker 则随队列深度突发，并要求空闲时缩到零。
- 约束
- API 需要连续可用，worker 要在两分钟内消化峰值且不能依赖常驻副本采集指标。
- 选择
- API 使用 HPA 的 CPU 与请求率指标；worker 使用 KEDA 读取队列长度并配置冷却窗口。
- 代价
- KEDA 支持事件与零副本，但引入 scaler、认证与外部指标链路，必须监控其失效模式。
03
Ingress / Gateway API
- 上下文
- 平台要让多团队共享入口，同时独立管理路由，并支持按权重灰度和跨命名空间授权。
- 约束
- 现有 Ingress 控制器稳定，但注解差异大，路由所有权与能力支持缺少可移植契约。
- 选择
- 新入口采用 Gateway API 的 Gateway、HTTPRoute 与 ReferenceGrant；旧 Ingress 按服务窗口迁移。
- 代价
- 角色边界和路由表达更清晰，但必须验证控制器支持矩阵、CRD 升级与迁移期双栈行为。
04
ConfigMap / Secret
- 上下文
- 应用同时需要公开的功能开关、数据库凭据和第三方 API token，并由 GitOps 发布。
- 约束
- 非敏感配置要可审阅；凭据不得以明文进入 Git，轮换时还要触发工作负载安全更新。
- 选择
- 功能开关放 ConfigMap；凭据放 Secret，并通过外部密钥系统同步和短周期轮换。
- 代价
- 敏感边界明确，但 Kubernetes Secret 仍需加密、RBAC、审计和轮换控制，不能把编码当作保护。
05 / EVIDENCE CHAIN
让每一次判断都能回到证据
时间窗、对象和版本保持一致，才能把分散信号串成因果路径，并找到安全的下一步。
- 01
Events
控制面首先记录了什么失败原因，它从何时开始并影响哪些对象？
Warning FailedScheduling: 0/12 nodes are available; 8 Insufficient cpu, 4 had untolerated taint. - 02
Logs
应用或系统组件在同一时间窗内输出了什么错误，上一个容器实例是否保留关键上下文？
checkout-api previous container: config key PAYMENT_ENDPOINT missing; process exited with code 1. - 03
Metrics
用户影响、资源饱和与变更时间是否相关，当前值相对基线偏离多少？
5m error rate 18% vs 0.4% baseline; ready replicas 7/10; memory working set 98% of limit. - 04
Trace
请求在哪一跳开始变慢或失败，错误是否集中在特定版本、节点或依赖？
trace 8f2c: gateway 12ms → checkout v2 34ms → payments DNS timeout 2,000ms. - 05
Runbook
哪项可逆动作能先恢复服务，执行条件、负责人和验证步骤是否明确？
当 checkout v2 错误率连续 5 分钟高于 2%：暂停 rollout，回滚 v1，确认三个 SLI 恢复。
DIAGNOSTIC NARRATIVE
Events 定位控制面失败，Logs 还原进程上下文，Metrics 量化影响，Trace 锁定失败边界，最后用 Runbook 执行可逆恢复并验证 SLI 回归。
06 / ENGINEERING CASE
从生产学习到可运行 CI/CD 平台
把生产学习中的平台约束、故障证据和验证结果放进一个可审阅的 Jenkins on Kubernetes 工程案例。
Jenkins on Kubernetes
把平台选择变成可验证的工程交付
把调度、RBAC、存储、Ingress、NetworkPolicy 与动态工作负载组合成真实平台。
从生产知识整理，到故障场景训练，再到可运行的平台工程。
Walker 的 Kubernetes 生产工程实践：以证据链完成架构设计、部署验证、故障诊断与可逆运维。
部署区域：Azure East Asia
- 01
JCasC 与完整插件版本锁
- 02
Controller 零执行器
- 03
Namespace 最小权限与默认拒绝网络策略
- 04
非特权临时 Pod Agent
- 05
Secret 安全注入与托管 TLS
为什么构建
为什么构建：目标是把分散的 Kubernetes 知识组合成真实平台，而不是重复安装教程。
动态 Agent 执行与回收链路
- Jenkins Controller（executors = 0）
- Kubernetes Plugin
- 临时 Pod Agent
- 结果回传与自动回收
公网入口超时
- 定位证据
- Azure Load Balancer 后端探针不健康
- 修复
- 为 AKS Ingress 配置 /healthz 探针
- 防复发
- 在入口变更门禁中固化探针路径与后端健康检查
Agent Pod 被拒绝
- 定位证据
- ResourceQuota 要求每个容器声明资源
- 修复
- 为 Agent 全部容器固定 requests 与 limits
- 防复发
- 用策略校验确保每个 Agent 容器都声明资源边界
Pipeline 停在 shell 步骤
- 定位证据
- 共享工作目录归属与工具容器 UID 不一致
- 修复
- 统一非 root UID 并重新验证
- 防复发
- 在 Agent 模板测试中校验 UID 与共享目录写权限
VALIDATION EVIDENCE
部署证据
- Kubernetes 1.36.2
- HTTPS 与托管证书验证通过
- 20 Gi PVC Bound
- Pipeline #4 SUCCESS
- 动态 Pod Agent 已创建、执行并回收
以上是 2026-08-06 的部署验证证据，不是实时监控或持续可用性承诺；为节省云额度，Jenkins 可能暂停运行。
07 / PRACTICE BOARD
把知识变成可以复现的现场动作
每项任务都以可观察结果结束。进度仅保存在当前浏览器，不需要账号，也不会离开本机。
LOCAL PROGRESS
0 / 8 已完成
依据压测 P95 与峰值设置 requests、limits，并用调度事件和资源曲线验证容量余量。
区分 startup、readiness、liveness 探针，验证慢启动和依赖故障不会触发重启风暴。
配置可用副本下限，演练节点排空，并证明 PDB 不会与滚动更新参数形成停滞。
用稳定负载触发扩缩容，记录指标延迟、稳定窗口以及达到目标副本数的时间。
实施默认拒绝与最小放行，并从业务 Pod 验证 DNS、入口和依赖流量的允许与拒绝路径。
按 5%、25%、50% 分批放量，用实际请求计数和 SLO 门禁决定继续、暂停或回滚。
注入探针失败，在目标时限内恢复上一版本，并验证配置、流量和数据兼容性。
构建事件时间线，区分触发因素与系统性条件，产出有负责人、截止日和验证方式的改进项。