第6章 Kubernetes 状态检查与分级处理

对应简历：技能第 5 条「具备 Kubernetes / Docker 生产环境背景，能完成容器平台状态检查与问题初步定位，并按'一线处理—二线转派—原厂协同'流程分级处理」/ 工作职责实-2「承担平台日常技术答疑与问题处理……按'记录—处理—转派—跟踪—闭环'流程协同华为原厂解决疑难问题」/ 项目一 P1-2「驻场承担平台一线技术支持：处理环境异常、登录失败、服务不可用等问题，定位问题层级，疑难问题记录并协同华为原厂二线处理，跟踪闭环」/ 项目三 P3-1~P3-2（7 台 ECS 高可用集群部署、监控告警与 Kuboard 可视化平台）。 支持版定位：按 direction_spec 大幅压缩原理深度（调度/QoS/滚动更新等只在"能讲清楚与交付相关"层面保留），保留状态检查排查树与常见事件解读，分级转判话术全量扩写——什么问题一线处理、什么转二线、怎么记录工单、怎么跟踪闭环、和原厂协同的证据包，是本章的重头。集群搭建级深挖（kubeadm 六步、证书 SAN）见两份项目笔记与第 14 章。

术语约定：Kubernetes（以下简称 K8s，仅正文简写）。内网 IP 一律脱敏为 <VIP>、<master01-ip>。

6.1 架构速览：支持岗要的那一层 【必背】

标准回答： 支持岗讲 K8s 架构不需要背全部细节，但要能把三件事讲给客户听。第一件，两大节点七组件：Master 控制面有 apiserver（集群唯一入口，所有读写必经它）、etcd（存全集群状态的分布式 KV 库）、scheduler（调度器）、controller-manager（控制器集合，靠"期望态与实际态对比"实现自愈）；Node 工作节点有 kubelet（节点代理，管容器启停和探针）、kube-proxy（维护 Service 转发规则）、容器运行时（containerd）。第二件，也是给客户解释故障影响的第一句话：控制面挂了不等于业务挂了——所有组件通过 apiserver 的 list-watch 交互、不直连 etcd，所以 apiserver 故障的表现是 kubectl 全部超时、集群"失联"，但已经运行的业务 Pod 照常服务。我在客户现场处理过 apiserver 异常，第一通报给客户的话就是"业务不受影响，正在恢复管理入口"，这一句话能把客户的焦虑降一半——支持岗的价值就是能精准说出影响面。第三件，我的两个集群版本对照：银行项目 v1.17.3（受华为 BCS 1.2.6 配套约束，生产严格按配套表），移动云项目 v1.28.2（新集群自主选型），配套约束和自主选型两种决策模式我都经历过，这是"生产背景"三个字的实际含量。

追问链：

• 追问1：各组件挂了分别什么现象？ → 答：这套"现象到组件"的映射是我排查 K8s 问题的定位地图：apiserver 挂——kubectl 全超时但业务 Pod 不受影响；etcd 不可用——apiserver 无处读写，集群变只读甚至不可用；scheduler 挂——新 Pod 全卡 Pending 没人调度；controller-manager 挂——副本不自动维持、节点挂了 Pod 不重建；kubelet 挂——节点 NotReady，但节点上已有容器还在跑（只是失管）；kube-proxy 挂——ClusterIP 访问不通但 Pod IP 直连正常。支持岗记这张表的用法：接到"集群出问题了"的模糊报障，先用现象对号入座缩小到组件层，再决定自己查还是转派——这就是"定位问题层级"四个字的落地。
• 追问2：你们集群规模多大？→ 答：两个集群两组数字我都张口就来。银行项目：15 台国产化虚拟机上跑 3 master + 10 worker 的 K8s v1.17.3 集群，承载华为 BCS 区块链（管理面 3 节点 + 数据面 6 节点）和业务应用；移动云项目：7 台 ECS 跨三个可用区——3 台 2C4G master 三副本控制平面、3 台 8C16G worker 业务池、1 台 4C8G 独立监控节点，CLB 四层负载做 apiserver 统一入口，K8s v1.28.2 + containerd 1.7.8 + Flannel VXLAN。规模不算大但形态完整，从部署到运维到故障处理全流程我都亲手做过——这是我对"能完成容器平台状态检查与问题初步定位"这句简历的底气。

6.2 Pod 状态机与状态速查 【必背】

标准回答： Pod 状态是 K8s 工单的"化验单"，我把主线状态和支持岗的判断口径整理成一张嘴边表。主线：Pending（未调度或等镜像）→ ContainerCreating（已绑定节点、kubelet 正在拉镜像/配网络/挂卷）→ Running（容器运行中，探针通过才变 Ready 接流量）→ Succeeded / Failed（跑完的任务类终态）→ Terminating（删除中，优雅退出宽限期默认 30 秒）；Unknown 表示 apiserver 与节点失联。异常态四个高频：CrashLoopBackOff 容器起又崩循环；ImagePullBackOff / ErrImagePull 镜像拉取失败；Evicted 被驱逐（节点资源压力，磁盘满是头号原因）；OOMKilled（在 Last State 里看，退出码 137）。一眼判断法必须会：kubectl get pods -o wide 看 NODE 列——NODE 为空的 Pending 是还没调度上（describe 通常报资源不足、污点不容忍、PVC 没绑定），责任在调度层；NODE 有值但 ContainerCreating 是卡在节点侧（拉镜像、CNI、挂卷），责任在 kubelet 层——两个状态对应完全不同的排查方向，判断错了就全错。我把"先看状态、再看 NODE 列、再 describe 事件"这三步叫做 Pod 工单的三级分诊，是所有 K8s 报障的起点。

追问链：

• 追问1：Running 但 0/1 Ready 是什么问题？ → 答：Ready 计数由就绪探针决定，0/1 说明容器活着但 readiness 没通过、不在接流量。四个高频原因按概率排：探针配置错——路径不对或端口写错（应用监听 8080 探针查 9090）；initialDelaySeconds 太短——应用还没起完探针就开始失败；应用 bind 了 127.0.0.1——探针从节点网络访问不到，这是"本机自测正常就是 Ready 不了"的经典坑；依赖故障——健康检查接口连不上数据库返回 5xx。排查组合拳：describe 里 grep "readiness probe failed" 看具体报错、logs 看应用启动进度、exec 进容器 ss -lntp 确认监听地址端口。这类问题多数我一线能闭环——改探针参数或修配置都在应用层，改完 rollout 重启验证 Ready 变 1/1。
• 追问2：Terminating 一直卡着不消失怎么办？ → 答：先懂原理再动手。Terminating 是 Pod 删除的优雅退出期：kubelet 发 SIGTERM 给主进程、等 terminationGracePeriodSeconds（默认 30 秒）后强杀——卡住超 30 秒说明有东西不对。常见三种：应用收到 SIGTERM 不退出（没按信号处理，最终会被强杀，只是慢）；挂了卷卸不掉（存储层卡住，Finalizer 未清）；节点 NotReady，kubelet 失联没法确认删除。处理顺序：确认节点是否 Ready（NotReady 就先修节点）；确认是不是 Finalizer 卡住（kubectl get pod -o yaml 看 finalizers 字段）；确实需要强制清理时用 kubectl delete pod --grace-period=0 --force——但这个动作我会先跟客户说明风险（可能丢正在写的数据），不悄悄强删。支持岗对"强删"类动作的敬畏，是金融环境教我的纪律。

6.3 排查命令树：get / describe / logs 三件套 【必背】

标准回答： 我的 K8s 排查是一棵五层命令树，从上往下钻，口诀"一看二描三日志四进五上节点"。第一层看：kubectl get pods -o wide 看状态和所在节点、kubectl get events -A --sort-by=.lastTimestamp | tail -20 看最近事件流、kubectl top pod/node 看资源水位。第二层描：kubectl describe pod <pod> 看详情——九成原因写在 Events 里（调度失败、镜像拉取失败、探针失败、退出码），这是 K8s 的"挂号处"；Service 问题配 kubectl get ep <svc> 看 Endpoints 是否为空（空 = selector 没匹配上或 Pod 没就绪，Service 类故障的头号原因）。第三层日志：kubectl logs <pod> --tail=200 -f 看当前日志，CrashLoop 必用 --previous 看上次崩溃的遗言。第四层进容器：kubectl exec -it <pod> -- sh 进去 ps、ss、env、curl 自证环境。第五层上节点：journalctl -u kubelet -f 看 kubelet 日志（CRI、CNI、挂载错误都在这）、crictl ps -a && crictl logs <id> 看运行时层、df -h && free -m && dmesg | tail 看节点资源。方法论一句话：describe 看"K8s 认为发生了什么"，logs 看"应用自己说了什么"，journalctl 看"节点上发生了什么"——三层信息互为印证，从外到内逐层排除，五步走完基本无漏网。

追问链：

• 追问1：describe 看不出来怎么办？ → 答：说明问题在 K8s 对象层之下，继续下钻的顺序是：kubectl get pod -o yaml 看 status 段的 exitCode 和 reason（比 describe 更原始的数据）；logs --previous 拿崩溃遗言；exec 临时容器进环境复现；上节点 journalctl -u kubelet 加 crictl 看运行时层；最后网络层 tcpdump 抓包验证。整套思路是"每层拿到该层的事实，再决定往哪层去"——我没有玄学排障，只有分层下钻。实际案例：一次应用报"连不上数据库"，describe 没异常、Pod Running，我 exec 进 Pod 用 telnet 测数据库端口不通，再查发现是发布改了安全组没放行——问题根本不在 K8s 层，是网络策略层。"往下钻到有事实的那一层"就是我定位层级的全部方法。
• 追问2：kubectl 全部超时（集群失联）你怎么处理？ → 答：这是支持岗要沉着处理的关键场景，我的动作序：第一，先确认影响面并告知客户——kubectl 失联只是管理面不通，运行中的业务 Pod 不受影响（6.1 的第一句话），先稳住客户；第二，确认故障范围——是 kubectl 客户端问题（本机 kubeconfig 过期、网络不通）还是集群问题：换一台跳板机试、ping/telnet <VIP>:6443 测入口（第 9 章命令树）；第三，telnet 通但 kubectl 报 x509——往证书方向查（openssl x509 -text 看 SAN 和有效期）；telnet 都不通——往 CLB/负载均衡和 master 节点方向查；第四，需要上节点时走堡垒机，用 crictl 和 journalctl 拿节点侧事实；第五，确认是控制面组件故障且超出我权限的（etcd 异常、证书重签），按分级转判打包证据转二线。这套动作我在演练里走过，"先说影响面、再分层验证、最后有序升级"的顺序不会乱。

实操模板（排查命令树，背熟）：

# ① 看
kubectl get pods -o wide                  # 状态+所在节点（NODE 空=没调度上）
kubectl get events -A --sort-by=.lastTimestamp | tail -20
kubectl top pod / node                    # 资源（需 metrics-server）
# ② 描（90% 原因在 Events）
kubectl describe pod <pod> -n <ns>        # 调度失败/拉镜像/探针/退出码
kubectl get ep <svc>                      # Endpoints 空=selector 没匹配或没 Ready
# ③ 日志
kubectl logs <pod> --tail=200 -f
kubectl logs <pod> --previous             # 上次崩溃（CrashLoop 必用）
# ④ 进容器
kubectl exec -it <pod> -- sh              # ps/ss/env/curl 自证
# ⑤ 上节点
journalctl -u kubelet -f                  # CRI/CNI/挂载错误在这
crictl ps -a && crictl logs <id>
df -h && free -m && dmesg | tail

6.4 常见事件解读：Pending / ImagePullBackOff / NotReady 【必背】

标准回答： 三大高频事件的解读和支持岗处置口径，我按"现象→根因→我做什么"背。Pending：NODE 列空 + describe 报 FailedScheduling——细分三类：Insufficient resources（资源不足，看扩容还是清理资源虚占）、taint 没容忍（要上 master 的组件没配 tolerations）、PVC 未绑定（存储没就绪）。我的一线动作：资源类先看集群余量给客户容量结论，配置类能改 YAML 就修，扩容决策转二线或客户定。ImagePullBackOff：describe Events 里 Failed to pull 后面的原因串直接分类——unauthorized 是凭据（secret 名字错、不在同一 namespace，一线修）、manifest not found 是镜像名/tag/架构错（一线修）、timeout 是网络或仓库不可达（转二线查网络策略和仓库）。银行 ARM 项目的镜像清单和移动云的双轨体系（第 5 章 5.11）都是这个问题的实战解法。节点 NotReady：本质是 apiserver 超过宽限期没收到 kubelet 心跳——五步排：describe node 看条件、systemctl status kubelet、查 CNI Pod 状态（九成 NotReady 是镜像拉取导致 CNI 起不来，这是我 9 项避坑清单第 1 条的经验来源）、测节点到 apiserver 的连通性和证书、查节点磁盘内存。NotReady 期间存量 Pod 继续跑但会被逐步驱逐，黄金窗口内先保业务再修节点。

追问链：

• 追问1：worker join 之后一直 NotReady，你的标准处理？ → 答：这是移动云部署时真实踩过并写进避坑清单的场景。我的动作链：先 kubectl get pods -n kube-flannel -o wide 看 CNI 状态——九成的 NotReady 到这一步见分晓，当时看到的是 Flannel Pod ImagePullBackOff，海外镜像在内网拉不下来、CNI 起不来、节点网络没配好自然 NotReady；确认根因后 kubectl edit daemonset 把 init 容器和主容器镜像全局替换成内网仓库地址，Pod 起来后节点几分钟内 Ready。预防动作两条：部署顺序强制"先 CNI 后 worker"、镜像清单提前入内网仓库——这两条写进建设方案。这个案例的价值在于它证明我说的"九成 NotReady 是镜像问题"不是背来的口诀，是踩出来并验证过解法的经验，面试讲出来有完整的细节支撑。
• 追问2：Evicted 的 Pod 大量出现是什么问题？ → 答：驱逐的触发源按概率查：节点磁盘压力最高频（kubelet 的 imagefs/nodefs 阈值触发）、内存压力、PID 耗尽。第一步 kubectl describe node 看 Conditions 里的 DiskPressure/MemoryPressure 标志——直接告诉你是哪类压力；第二步上节点 df -h 看分区，K8s 节点磁盘的头号凶手是容器日志和镜像层（第 5 章 5.14 的治理三件套：日志限额、定期清未用镜像、85% 告警）；第三步清理后 Evicted 的 Pod 不会自动消失，需要批量删除让控制器重建——kubectl get pods -A | grep Evicted | awk '{print $2}' | xargs kubectl delete pod -n <ns> 这类命令我会先过滤确认再执行。驱逐风暴的本质是节点资源治理失守，我处理完一定做两件事：把清理动作固化进巡检脚本、把水位告警阈值前移——让下次在 80% 就被叫到，而不是 95% 处理事故。

6.5 巡检清单：kubectl 侧五分钟健康扫 【理解】

标准回答： 我给集群定的日常巡检清单，一组命令五分钟出全貌，这是支持岗"主动发现问题"的基本功。① kubectl get nodes——全 Ready 是底线，谁的状态异常、谁 AGE 特别短（频繁重启）要追；② kubectl get pods -A --field-selector=status.phase!=Running | head——过滤出所有非 Running 的 Pod，一眼看到异常堆积；③ kubectl get events -A --sort-by=.lastTimestamp | tail -20——最近事件流，Warning 类逐条看；④ kubectl top nodes——节点资源分布，长期 80% 以上就是容量风险；⑤ 两个"慢故障"：etcd 三副本 endpoint health（带三证书）、kubeadm certs check-expiration 证书有效期——这类不报警但一炸就是大事的项目最容易漏，我固定按周查。巡检和监控告警是互补关系：告警是被动的"越线才响"，巡检是主动的"扫一遍找苗头"——比如刚出现的 Pending Pod 还没触发任何告警，但巡检能提前看到。巡检结果我记进固定表格留趋势，异常项当天闭环或升级。这套清单我在银行驻场和移动云集群都执行过，它让"平台稳定"从感觉变成有记录的事实——客户验收和审计时，这份巡检记录也是硬材料。

追问链：

• 追问1：巡检发现某节点 CPU 长期 85%，怎么决策？ → 答：先归因再动作。kubectl top pods -o wide 看是谁吃的——单个 Pod 异常（它自己的限额缺失或业务高峰）就处理那个应用：加 limit、联系业务方、必要时迁移；整体负载就是容量问题：能调度走的（打散）、该扩容的（提前申请）、该限流的（保护高优先级服务）。决策框架是"先看结构再看总量"——85% 这个数字本身不说明问题，谁占的、什么时段、能不能挪才是答案。给客户的表述我会带数字和建议："节点 A 的 CPU 连续两周 P95 在 85%，主要消耗来自某服务的高峰期，建议两条路：给它加资源限额控制突发，或评估扩一台 worker——我可以先出容量评估报告。"巡检的价值就落在这样的决策支持上，不只是看一眼。
• 追问2：巡检怎么做才不流于形式？ → 答：三条纪律。第一，有清单有记录：固定命令组、固定表格、异常项必须有处理结论（闭环或升级），不留"看了但没记"的空白；第二，有趋势有对比：资源水位、Pod 数量、事件数这些指标按周对比，突变比绝对值更有信息量——磁盘从每周涨 2% 突然涨 8%，比"现在 70%"更值得警觉；第三，有输出有交付：每月给客户一份巡检小结（发现了什么、处理了什么、建议什么），让巡检从我的内部动作变成客户可见的服务交付物——银行客户对"留痕"的重视让我养成了这个习惯，它同时也是绩效和价值的直接证据。

6.6 分级处理总纲：一线 / 二线 / 原厂的边界 【必背】

标准回答： 分级转判是我简历上"一线处理—二线转派—原厂协同"的完整展开，这套口径在银行驻场近两年真实跑了无数单，我按四条边界讲。第一条边界：问题层级。一线处理应用层和配置层——Pod 配置、探针参数、镜像版本、日志分析、端口与凭据这类"现象清晰、有 SOP、改动局限在应用边界内"的问题；二线处理平台层和系统层——需要进节点系统排查、改集群组件配置、查运行时与内核、动网络策略的问题；原厂协同产品层——华为 BCS、FusionCompute 这类产品组件内部机制的疑难，需要原厂工具、补丁或内部知识库的问题。第二条边界：能力与权限。一线的判断标准是"我有把握 + 我有权限 + 改动可回退"三条同时满足；任何一条不满足就升级——尤其在银行环境，权限边界是白纸黑字的，越界操作比慢半步严重得多。第三条边界：影响面。影响单用户单功能的一线从容处理；影响整体业务或涉及数据安全的，无论难度高低立即升级并同步客户——分级看的不只是难度，更是风险。第四条边界：时间盒。一线尝试有预算（一般 30 分钟），超过时间盒没有收敛就升级，把已知信息完整带过去——死磕不是负责，是占用客户的时间。这套边界让我在两年里做到了"该快的快、该转的转、没有一单在我手里失联"。

追问链：

• 追问1：分级处理为什么重要，出过分级不当的问题吗？ → 答：重要性我用正反两面讲。正面：银行环境多方协同（客户、我、华为原厂、开发团队），没有清晰分级就会出三种病——该转不转拖死 SLA、乱转一通浪费二线、转了不管客户失联；我的分级让每一单都有明确的第一责任人。反面教训我也真实见过：有同事接了组件级疑难不转，自己折腾两天，最后客户投诉响应慢——其实那问题转原厂一天就能定位。所以我带新同事时反复强调：转派不是甩锅，是把问题送到最短路径上；判断"该不该转"的能力，本身就是支持岗的核心能力。我的原则是宁可"转早不转晚"——转早了损失的是半小时，转晚了损失的是客户信任。这两面的故事让"分级"听起来不是教条，是踩过坑的方法论。
• 追问2：一线/二线/原厂各举两个真实例子？ → 答：一线例子两个：Pod CrashLoopBackOff 定位到发布改错 Service 名，回滚恢复（20 分钟闭环）；容器日志写满磁盘，truncate 释放加日志限额固化（当天下单）。二线例子两个：集群节点内核参数导致的 CNI 异常——我定位到"不是应用层"后转二线，配合提供 journalctl 和抓包证据；存储挂载在节点上卡死导致 Pod 卡 Terminating——涉及存储驱动层，转二线处理我跟踪结果。原厂例子两个：BCS 区块链平台组件的证书同步异常——平台内部机制问题，我打包证据转华为原厂并跟踪闭环；FusionCompute 平台侧告警的定位——走 iBMC/SEL 证据链按原厂流程换件（细节见华为篇 02/07）。六个例子每个都有"为什么归这一级"的理由，这正是分级能力的体现：不是按难度分，是按层级、权限、影响面、时间盒四条边界分。

6.7 一线处理清单：什么问题我直接处理 【必背】

标准回答： 一线处理清单我按"现象清晰、可复现、有 SOP、改动可回退"四个准入条件整理，满足才动手。清单内容按类分：应用配置类——Deployment 的镜像 tag、环境变量、探针参数、资源限额调整，改前备份 YAML、改后验证、可秒级回滚；状态类——CrashLoop 排查（logs --previous + 退出码分诊）、OOMKilled 调限额、Evicted 后清理重建；镜像类——ImagePull 的凭据修复（secret 核对重建）、tag 修正、内网仓库镜像替换；日志与磁盘类——日志轮转配置、truncate 清理、悬空镜像 prune；发布类——rollout undo 回滚、rollout restart 重启生效（环境变量类配置的标准动作）；常规巡检与告警初判——按第 7 章流程响应告警、按 6.5 清单巡检。清单之外的都不算一线：涉及 etcd 操作、证书重签、节点内核参数、网络插件配置、存储层问题——这些改错了影响面大，全部转二线。还有一个自律条款：清单内的问题，如果解决它需要"临时绕过安全机制"（关探针、删 Finalizer、强删 Pod），也升级处理或至少双人确认——一线清单的本质不是"我会做的都做"，而是"低风险可回退的才做"。

追问链：

• 追问1：一线处理完怎么验证才算闭环？ → 答：我的闭环标准是三层验证，缺一层都不算完。第一层，技术层：Pod Ready、业务日志无新错误、监控指标回归正常水位——这只能证明"系统看起来好了"；第二层，业务层：让客户在实际功能上验证——登录一次、下一单、查一条数据，"用户真的能用"才是业务恢复，我吃过"Pod 全 Ready 但功能还是错的"的亏，所以这条铁律；第三层，记录层：工单里补全处理过程和结果，客户确认后关单——记录不是官僚流程，是下次同类问题的检索基础，也是 SLA 统计的依据。闭环后还有个增值动作：自问"会不会复发"——会，就写 FAQ 或加告警（第 11 章的知识库运营）。这三层验证是我在银行环境练出来的：客户方对验收标准很严格，"我这边好了"这种话在那里说不过去，必须给可验证的证据。
• 追问2：改配置前你怎么保证可回退？ → 答：四步纪律。第一步，变更前备份：kubectl get deploy xxx -o yaml > backup-日期.yaml——声明式系统的优势就是备份即恢复，一个 apply 就回去；第二步，最小变更：一次只改一个点，绝不叠加多个变更——出了问题才能唯一归因；第三步，先测试后生产：能走测试环境的走测试环境（银行项目我们有开发虚拟机做预演），生产直改的必须是低风险项；第四步，验证与观察：改完看 rollout status、验证业务、观察 10 分钟再撤——别改完就走。这套纪律在金融环境是硬要求，变更必须有记录、有回退方案、有窗口期——我把它内化成了肌肉记忆，到任何新环境都自动执行。面试被问"你怎么管理生产变更"，这四步加一句"高风险变更一律走审批窗口"就是完整答案。

6.8 转二线的标准与交接材料 【必背】

标准回答： 转二线的触发标准我定了五条，命中任何一条就转：①层级越界——问题定位到需要改集群组件配置、节点系统层、运行时层、网络插件层，超出一线边界；②时间盒超限——一线尝试 30 分钟没有收敛，继续死磕只会拖 SLA；③需要权限——涉及节点 root、数据库管理操作、云控制台变更等我无权限的操作；④影响面大——业务整体受影响或涉及数据安全，需要二线共同决策；⑤反复复发——同问题三次以上复发，说明我的处理是治标，需要二线找根因。转派时我固定准备五样材料，这就是交接包：一，现象描述——一句话说清"什么坏了、从什么时候开始、影响谁"；二，时间线——发现时间、关键事件时间点（告警、变更、复发），用日志和监控时间戳对齐；三，证据——describe 原文、logs 片段、退出码、事件流、抓包文件，原始输出不加工，让二线自己看一手材料；四，已做尝试——我改过什么、结果如何、已回退什么——这条最重要，避免二线重复走我的弯路；五，我的初步判断——"我怀疑是 XX 层，依据是 XX，请您确认"——给出方向但不预设立场。这份材料在我团队里被叫作"接得住的单"，二线拿到就能直接干活，转派效率直接决定 SLA。

追问链：

• 追问1：转派之后你的责任就结束了吗？ → 答：没有，转派只是换人处理，跟踪闭环仍是我的责任——这是"记录—处理—转派—跟踪—闭环"五步里我的完整角色。转后的动作四条：第一，保持可联系——二线排查中经常需要补充信息（再抓个日志、复现一次、提供账号窗口），我是现场的信息通道；第二，定期跟进——按问题优先级定跟进节奏（紧急的每小时、一般的每天），主动要进展而不是等通知；第三，同步客户——客户只需要对我一个人，我把二线进展翻译成客户听得懂的语言定期同步，不让客户感到"报了障就石沉大海"；第四，闭环归档——二线处理完，我验证业务恢复、补全工单记录、向客户确认关单。这套跟踪机制是我在银行做"统一接口人"两年攒出来的：客户和原厂都认我，靠的就是"单子在我手里不会丢"——这句是支持岗最有分量的一句自我证明。
• 追问2：二线处理很慢、客户在催，你怎么办？ → 答：三步应对，核心是"管理预期 + 主动推进"。第一步，给客户如实的时间预期：向二线确认当前进展和预计时间，明确告知客户"当前定位到 XX 层，二线正在处理，预计 X 小时内有阶段结论"——客户最不能接受的不是慢，是不知道在干嘛；第二步，主动加塞推进：我能做的并行做——准备替代方案（临时降级、切备用路径）、准备补充证据、必要时按升级机制向上升级（问题升级到二线主管或走紧急通道），催要有催的技巧：带着新信息去催，而不是空喊"快点"；第三步，留痕：每次跟进都记进工单时间线，后续复盘和责任界定都有据可查。我的经验：把"等待期"变成"服务期"——转派后反而要贴得更紧，客户感知到的服务质量和处理速度同等重要。这套做法让我在多次疑难单里拿到了客户的好评，客户原话是"问题虽然难，但你一直在"。

6.9 协同原厂的证据包与转案话术 【必背】

标准回答： 和华为原厂协同是我简历的亮点句"协同华为原厂解决疑难问题"的实底，我把协同方法总结成证据包加转案话术。证据包七件套（我的实际格式）：①问题概述——一页纸讲清现象、影响、时间线；②环境信息——组件名称与版本（FC 8.3.0、BCS 1.2.6、K8s v1.17.3 这类配套表信息，原厂排查第一个要的就是版本配套关系）、拓扑与规模（4 台 TaiShan、CNA×3+VRM×1）；③原始日志——按时间窗截取的日志原文，标明时间戳和来源节点，敏感信息脱敏但保留结构；④告警与监控——告警截图、时间点、指标曲线，证明问题的客观存在；⑤已做尝试与结果——我们做过哪些排查和处置，避免原厂重复劳动；⑥复现条件——怎么触发、概率多大；⑦期望与约束——希望原厂定位到什么程度、变更窗口限制（银行生产不能随便动）。转案话术的三个要点：问题定性客观（"平台组件在 XX 场景下表现异常"而不是"你们产品有 bug"——话留余地）、信息一次给全（原厂最烦挤牙膏式补充，一次给全反而快）、明确响应预期（约好阶段反馈时间点）。银行项目跑这套流程近两年，原厂那边的评价是"这个现场的单子质量高"——证据包就是跨组织协同的通用语言。

追问链：

• 追问1：举一个你协同原厂解决问题的完整例子？ → 答：讲 BCS 平台证书同步异常那单（脱敏描述）。背景：平台某组件间认证间歇性失败，我按排查树排完了应用层和配置层——日志、证书有效期、网络连通性都正常，现象却反复出现；此时命中转判标准：层级越界（产品组件内部机制）+ 反复复发，启动原厂协同。我的动作：打包七件套证据——关键的是时间线对齐（把组件日志时间戳和 NTP 校准后的标准时间对齐，原厂后来确认这正是破案关键：两组件间时钟偏差导致证书校验间歇性失败）和复现条件（给出稳定触发的时间间隔规律）；转案后我每半天跟一次进展、同步客户一次；原厂定位到组件的时间同步校验机制问题后给出补丁方案，我在变更窗口配合实施、验证恢复、归档工单。这单的沉淀有两条：一是"时间同步检查"从此进了我所有环境的初始化基线（移动云集群的避坑清单第 9 条同源）；二是证据包里"复现条件"这一项从可选项变成了必填——能稳定复现的问题，原厂定位速度翻倍。
• 追问2：和原厂意见不一致怎么办？ → 答：这种情况真实遇到过，我的处理原则是"用证据对齐，不用立场争论"。场景：某次平台异常，我根据日志判断问题在平台组件侧，原厂初步回复"建议检查应用配置"。我的做法：不正面反驳，补交证据——把"配置未变更（对照变更记录）+ 应用日志无异常 + 组件侧日志在同时刻有报错"三组证据整理成时间线再发过去，并附一句"配置侧我们已按清单核对过，同时刻组件日志的报错信息如下，烦请从组件侧协助看下"。证据面前分歧自然收敛，最终确认是组件侧问题。三条心得：一是转案材料质量决定话语权——证据全的现场，原厂不敢敷衍；二是保持合作关系——对事不对人，话术上永远给对方台阶；三是拿不准的事不预设结论——我给方向和怀疑，最终定性让证据说话。跨组织协同里"专业 + 得体"缺一不可，这是我两年驻场学到的软技能，和技术能力一样值钱。

6.10 工单记录规范：五步流程在 K8s 场景的落地 【必背】

标准回答： "记录—处理—转派—跟踪—闭环"五步是我的工单主线（第 9 章有完整展开），这里讲它在 K8s 场景的具体落地。记录：接单时把四要素（现象、时间、范围、变更）和关键证据写进工单——K8s 场景的必记项：Pod 名与 namespace、集群与节点、状态与退出码、Events 原文、时间戳；记录的原则是"原始、可追溯、脱敏"——原始输出不加工、时间戳精确、内网 IP 与密钥脱敏。处理：一线清单内的问题按 6.7 处理，每一步动作记时间线（什么时候改了什么、验证结果），为可回退和复盘留底。转派：按 6.8 的标准和交接包转二线/原厂，工单状态流转要留痕（谁接的、什么时候、预期回来时间）。跟踪：转出后按优先级定跟进节奏，每次跟进记进展，客户侧同步不间断。闭环：三层验证（技术、业务、记录）后关单，高频问题沉淀 FAQ 进知识库、根因类问题补告警或检查项。我在银行用这套流程跑了近两年，数据上最有说服力的是：客户问题响应获得认可（简历项目成果原话），且我沉淀的 FAQ 和文档成了公司标准。工单对支持岗不只是任务管理，是"组织记忆"——我的知识库、我的避坑清单、我的案例库，全是从工单里长出来的。

追问链：

• 追问1：工单记录里你觉得最重要的字段是什么？为什么？ → 答：三个字段我认为是灵魂。第一是时间线：故障排查本质是对时间的推理，所有证据（日志、告警、变更）都要对齐到统一时间轴上——我处理过的间歇性证书失败案例，正是靠时间戳对齐发现时钟偏差的；第二是变更记录："最近改了什么"是故障定位命中率最高的问题，工单里必须记录关联变更（发布单号、配置变更、窗口操作），六成故障和变更相关这句经验我有大量工单佐证；第三是已做尝试：处理过程如实记录包括失败的尝试——它防止二线重复弯路，也是复盘时"当时的判断依据"的原始材料。这三个字段的共同点：都服务于"下一个看这单的人"——工单的读者不只是我自己，还有二线、审计和三个月后的我，写的时候想着他们，记录质量自然就高。
• 追问2：怎么用工单数据改进支持工作？ → 答：我做三层分析。量与结构：每月统计工单量、分类占比（应用类/平台类/咨询类）、各层级的转派率——转派率异常升高说明某类问题该补 SOP 或者该给客户做培训了；时长与 SLA：响应时长、处理时长、闭环时长的分布，找最长的尾部——那通常是最值得优化的环节；重复度：同类问题占比统计，重复 TOP 的问题就是知识库建设的优先级清单——我的登录类 FAQ、容器日志 FAQ 都是这么排出来的。这套分析把工单从"干完就归档"变成"运营数据"，也是我简历"降低重复答疑成本"的量化来路：重复问题进知识库后，同类工单量下降是可以用数据说话的。面试讲工单，能讲到"用数据分析改进服务"这个层面，就超出了普通支持岗的叙事。

6.11 跟踪闭环与升级机制 【必背】

标准回答： 跟踪闭环机制我按优先级定义了清晰的 SLA 口径（银行环境沉淀的）。优先级四级：P1 业务中断/安全事件——立即响应，处理不收敛 30 分钟内升级；P2 核心功能受损但有绕行——30 分钟内响应，2 小时无阶段进展升级；P3 一般功能异常——4 小时内响应，当日给出方案；P4 咨询与优化类——1 个工作日内响应。升级机制三档：第一档升级二线/二线主管（一线时间盒用完或客户对处理不满意时）；第二档升级到我方项目经理和客户方对接人（P1 超时、跨团队资源需要协调时）；第三档升级到原厂高级支持/紧急通道（产品级缺陷、影响扩大时）。跟踪纪律：每单有唯一责任人和下次跟进时间点——"我会再联系你"必须带上具体时间，"稍后跟您同步"这种模糊话术在银行环境是扣分项；每次跟进记录进工单时间线。闭环动作：业务验证、客户确认、记录归档三件套（6.7 讲过）。这套机制的价值用一句话概括：让每一单都有主、每一步都有痕、每个承诺都有时间点——支持岗的"靠谱"不是形容词，是这套机制跑出来的事实。我在移动云和内部 IT 支持里也复用了这套口径，只是 SLA 按内部场景放宽。

追问链：

• 追问1：客户报的问题其实不是你们的责任（比如客户自己网络问题），你怎么处理？ → 答：这类"归属判断"单是支持岗的高频难点，我的处理三原则。第一原则，先帮客户解决再说归属：排查发现是客户侧办公网断电、或客户端配置问题，我不会先说"这不归我们管"，而是能远程指导的就指导解决——支持的价值是"你的问题有人管"，归属判断放后面；第二原则，如实记录并温和澄清：处理完在工单里如实记录根因归属，跟客户同步时用事实说话："这次排查下来根因在办公网侧的 XX，我们平台侧没有异常，我把处理步骤也整理给您了"——不指责、不邀功，下次同类问题客户自己就能判断找谁；第三原则，边界但要有关怀：确实超出服务范围的（客户内部第三方系统），明确告知边界的同时给建议路径。这样处理的结果是：即使"不是我们的问题"，客户对服务的评价依然高——归属清晰 + 态度到位，两头都不丢。
• 追问2：怎么预防"升级太晚"或"动不动就升级"两个极端？ → 答：两个极端对应两种人，防法不同。防"升级太晚"：靠时间盒制度——每级处理有时限预算，超时必须升级，这是机制不是靠自觉；我在银行见过爱死磕的同事，问题拖大被投诉，所以我把"30 分钟无收敛就升级"写进了自己的工作纪律，还配合"升级不丢人、拖大才丢人"的团队文化。防"动不动就升级"：靠转派质量门槛——升级必须带齐证据包和已做尝试，二线/主管对低质量转派有反馈机制，几次下来就倒逼一线先做足功课；同时升级前先问自己三个问题：我的判断是什么？我做了什么？我需要对方做什么？——答不出来就还不到升级的时候。一句话总结：机制管时间盒，质量管内容，文化管心态——三个抓手一起上，升级频率自然落在一个健康的区间。这套平衡也是我带过新同事、组织过培训的实证。

6.12 支持场景速答：客户常见 K8s 问题 TOP6 【理解】

标准回答： 把客户侧最高频的六类 K8s 报障整理成速答卡，每张卡"一句话安抚+第一动作+去向"。①"系统打不开"：先安抚并问范围（个别人还是全部），全部人打不开查入口链路——第 4 章 Nginx 排障链、Service Endpoints、Pod 状态；个别人打不开查客户端（第 15 章桌面思路：代理、缓存、DNS）。②"服务又挂了"：kubectl get pods 看状态，CrashLoop 走 logs --previous，退出码分诊（137 内存、1 应用），20 分钟内给"根因+已恢复+预防"三段式回复。③"发布后出问题了"：第一反应回滚——rollout undo 恢复业务优先，之后再对比版本找根因；"先恢复再修根因"永远是对的。④"系统很卡"：kubectl top 看资源、看是单 Pod 还是节点级、有没有 HPA 拉不起来/限流，给出容量结论和数据。⑤"数据不对/丢了"：立即停止破坏性操作、保留现场（日志、副本），涉及数据类第一时间上报并拉开发/二线——数据类问题我从不单人处理。⑥"帮我重启一下"：先留证据再重启（5.6 追问 1 的三件套），重启后必须业务验证。速答卡的价值：客户报障的第一分钟，我的回复就有方向、有动作、有预期——这是响应质量的最短路径。

追问链：

• 追问1：客户问"你们 K8s 平台到底稳不稳定"，怎么答？ → 答：这个问题要用数据和机制回答，不用形容词。我的答法分三层：第一层给机制：控制平面三副本跨可用区、CLB 健康检查秒级摘除、业务多副本自动重建——"按 99.99% 可用性目标设计"，注意口径是设计目标，讲保障机制不讲实测 SLA；第二层给数据：近 X 个月可用性统计、故障次数与平均恢复时长、告警响应 SLA 达成率——巡检和工单记录这时候就变成了汇报材料；第三层给改进：最近一次故障后我们做了什么加固（告警前移、预案补充）——展示的不是"从不出问题"，而是"出了问题有完整的发现-响应-改进闭环"。客户真正想听的不是"永远不坏"（没人信），而是"坏了有人管、管得快、不会再犯"——这三层答法在银行客户那里验证过，比拍胸脯有效得多。
• 追问2：如果客户的问题当场解决不了，你怎么收尾这次沟通？ → 答：我的收尾固定四要素，绝不让对话以"再看看吧"结束。一是明确结论：已经确认什么、排除什么——让客户知道不是白等，"网络是通的、服务在运行，问题收敛在应用配置层"；二是明确下一步：谁在做什么、什么时候有结果——"我现在转二线深查，2 小时内给您阶段结论"；三是给临时方案：有绕行路径先给（备用入口、导出数据的手工办法），降低客户业务损失；四是留联系方式和跟进承诺："进展我会主动同步您，不用您反复问"。这四要素的本质是：把"没解决"变成"有掌控的进行时"——客户对未知的焦虑远大于对问题本身的焦虑，收尾质量决定了这单服务在客户心里的分数。这个收尾套路是我在无数电话和现场沟通里打磨出来的，现在已成本能。

6.13 给客户的 K8s 名词白话对照与"能不能"三问 【必背】

标准回答： 支持岗讲 K8s 的基本功是"翻译"——我备了一张名词白话对照表，客户问什么都能落到人话。Pod="应用的一个运行实例，像一间装好程序的标准化房间"；Deployment="管这批房间的管家，坏一间补一间"；节点="放房间的大楼楼层"；Service="房间的固定门牌号，房间换了门牌不变，来访不受影响"；探针="管家定时敲门确认住户还能干活，不能干就换人"。这张表最大的价值在故障通报：说"两个 Pod CrashLoopBackOff"客户懵，说"有两个应用实例启动失败，管家正在自动补齐，另外两个实例在正常服务"客户秒懂。客户常问的三个"能不能"我也备了标准答案："能不能直接重启服务器？"——能但要按流程：先 cordon 让它不再接新任务、再 drain 把上面的业务搬走、然后重启、回来后 uncordon，全程业务无感，直接拔电源是大忌；"能不能把数据库放进容器平台？"——我的标准口径是有状态重服务不建议：数据一致性和滚动更新模型冲突，我们用云数据库主备、应用进集群，各得其所；"能不能保证 100% 不出问题？"——不承诺 100%，承诺三件事：问题能被快速发现（监控告警）、有人快速处理（分级响应）、同类问题不再发生（复盘沉淀）——这个诚实的回答在银行客户那里比拍胸脯得分高得多。

追问链：

• 追问1：客户领导问"K8s 到底给我们带来了什么"，怎么答？ → 答：用业务语言答四条，不提技术名词。第一，上线快：新业务环境从按天申请变成分钟级发放；第二，更稳：应用出问题自动补位，业务方感知不到单点故障；第三，省资源：按需分配，利用率比传统部署高一截；第四，好维护：升级回滚以应用为单位秒级完成，不用停机窗口。每条都能带我们环境的事实支撑（分钟级交付、故障自愈实测、副本数维持）——"讲收益不讲架构"是对领导层的表达纪律。这个题我在银行和移动云都被问过，答案的一致性也是专业度的体现：不同听众不同语言，同一套事实。
• 追问2：客户看到 Pod 名和端口一串随机字符很不安，觉得"不正规"，怎么解释？ → 答：用"门牌与住户"的类比解开：容器世界的设计哲学是"个体随时可换、身份永远稳定"——Pod 名字带随机后缀说明它是可替换的实例，真正对用户提供服务的名字（Service 名、域名、VIP）是固定不变的；就像酒店房间可以换人住，但房间号和电话永远不变。客户不安的本质是拿"固定服务器"的心智模型套"弹性实例"，把模型差异讲透，不安自然消失。顺手给一句安心话："您访问的地址从来没变过，也不会变——变的是后面干活的实例，而且换得越快说明系统越健康。"这类"心智模型校准"是支持岗在云原生客户现场的日常，也是我简历"能把技术讲给客户听"的日常素材。

6.14 和开发团队协同：应用类问题的转派交接 【理解】

标准回答： 分级转判的另一半是"转开发"——应用类问题（代码异常、性能问题、连接泄漏）不是二线也不是原厂，责任在开发团队，而支持岗是开发的"证据供应商"。我的转开发交接包四件：现象与复现——什么操作触发、概率多大、影响范围；日志证据——按时间窗截取的应用日志原文，关键报错行高亮，不整段贴；环境信息——版本号、发布时间、配置变更记录（"昨天的发布把连接池改小了"这种信息是开发定位的捷径）；资源与监控数据——CPU/内存/连接数曲线，是代码问题还是容量问题让数据先说话。协同的三个节奏要点：转出去前我会先做"归因初判"——把现象分成"代码 bug（报错栈明确）"、"容量不足（资源曲线顶格）"、"配置问题（变更关联）"三类，分类准确开发接手就快；开发修复后我负责验证与回归——按客户实际场景验证功能，不只是看日志无错；最后我负责对客户交代——用客户听得懂的话讲"问题是什么、已修复、怎么防"。我和开发的协作口碑来自一件事：我转过去的单，开发说"信息全、不用来回问"——支持岗在研发协同里的信用，就是转派质量攒出来的。

追问链：

• 追问1：开发说是"环境问题"，你说是"代码问题"，僵持不下怎么办？ → 答：用对照实验切分变量，不搞口水战。我的三板斧：第一，对照环境——同样代码在测试环境正常、生产异常，差异变量在环境配置；反过来生产回滚到旧版本正常、新版本异常，变量在代码；第二，证据定位——报错栈指向代码模块就是代码方向，资源曲线和变更记录指向环境就是环境方向；第三，必要时拉共同复盘会——双方各带证据，十分钟收敛。我处理过一次接口 500 的分歧：开发坚持数据库问题，我拿出"数据库侧无慢查询无报错 + 应用日志明确 NPE 空指针"的栈信息，方向立刻统一。原则一句话：环境与代码之争，让对照实验和报错栈当裁判——支持岗在这类争执里的价值就是提供干净的证据。

6.15 K8s 场景工单记录模板（实操模板） 【必背】

标准回答： 把第 6 章的方法固化成一张工单模板，是我交班、转派、复盘的载体，也是我"记录—处理—转派—跟踪—闭环"在 K8s 场景的落地形态。模板的价值在三个场景兑现：转派时二线照单全收不用来回问、复盘时时间线完整可追溯、月度统计时分类字段可直接汇总——一份模板喂三个场景。我在银行和移动云都用这张结构，字段经过实战取舍：保留"变更关联"和"已做尝试"这两个最常被漏填但最有价值的字段，砍掉一切形式字段——工单模板的每个字段都必须有人读，没人读的字段是负担。

实操模板（K8s 工单记录结构，可背）：

【基本信息】工单号/级别(P1-P4)/状态/责任人
【四要素】现象（含报错原文）/ 开始时间 / 影响范围 / 关联变更(发布单号/配置变更)
【环境】集群与命名空间 / Pod名与节点 / 镜像版本
【证据】kubectl describe Events 原文 / logs --previous 片段 / 退出码 / 监控曲线截图
【处理时间线】HH:MM 动作（每条一行：改了什么、验证结果）
【转派】转给谁/交接包清单/约定回复时间
【闭环】技术验证 / 业务验证(客户确认) / 沉淀动作(FAQ/告警/SOP)

6.16 高危误操作与红线清单 【必背】

标准回答： K8s 的声明式和自愈能力让很多人放松了对"误操作"的警惕，我给自己划了七条红线，每条背后都有真实风险。① 不 delete 全命名空间——kubectl delete ns 会级联删除里面一切资源，且删除是异步的（Finalizer 残留期重建会冲突，避坑清单第 8 条的来源），删 ns 前必须逐类确认资源清单；② 不对运行对象裸 edit——edit 改完不进版本库，下次 apply 全部覆盖回去，我的纪律是"生产变更一律 apply 文件，edit 只做排障临时动作且当天补回文件"；③ 不 --force --grace-period=0 删 Pod——跳过优雅退出可能丢正在写的数据，强删前必须评估数据影响并向客户说明；④ 不动 master 污点——删掉 control-plane 污点会让业务 Pod 挤占控制面资源，这是生产纪律；⑤ 不在生产跑未读过的 YAML——apply 前先 --dry-run=client -o yaml 预览，复制来的清单必须逐段看过；⑥ 不在未知状态时叠加变更——故障排查期不做第二个变更动作，变量失控就没法归因；⑦ 不绕过变更窗口——"就改一行很安全"是事故名言，任何生产变更走窗口和审批。这七条我在银行和移动云都执行，把"敬畏生产"从口号变成动作清单——支持岗在客户环境里，红线就是职业生命线。

追问链：

• 追问1：误删了资源怎么救？ → 答：按资源形态分三条路。声明式管理的资源（Deployment/Service 等清单在 git 或文件里的）：kubectl apply 秒级重建——这正是"配置 git 化"的最大回报；Pod：控制器会自动重建（这就是 K8s 自愈），确认新 Pod 正常即可；ConfigMap/Secret 这类无控制器管理的：从备份或源文件重建——所以我的基线是所有清单进 git、关键配置有备份。最怕的是"删了没清单没备份的"——只能从其他环境导出或重写，这也是我把"资源清单化"列为环境接管第一天要检查的事项的原因。误删后的处置顺序：先确认影响面和自愈情况（很多"误删"被控制器消化了，客户无感）、再补建、最后复盘权限和流程（为什么能误删——回收危险权限比事后救火重要）。
• 追问2：怎么从权限上防止误操作？ → 答：分层控制。RBAC 最小化：日常操作账号不给 cluster-admin，按命名空间授权——大权限只在明确需要时申请、用完回收（我自己的账号也遵守）；操作入口收敛：生产操作走堡垒机加审计（Kuboard 的操作审计就是这层），个人终端直连生产 apiserver 的 kubeconfig 收回；高危命令护栏：delete 类操作先 --dry-run、批量删除前先 kubectl get 列清单人工确认。权限设计的哲学和分级处理一脉相承：让错误发生的成本高一点、让正确操作的路径顺一点——防误操作七分靠权限设计，三分靠人的谨慎。

6.17 支持岗的 K8s 能力边界与学习路径 【理解】

标准回答： 面试支持岗时被问"你 K8s 什么水平"，我的回答策略是主动画边界——清楚地说"能什么、熟什么、储备什么"，诚实比虚胖可信。能（生产做过、随便深挖）：集群部署（kubeadm 两套环境）、状态检查与故障定位（排查树、分级转判）、日常运维（发布回滚、节点维护、巡检告警）；熟（标准回答层，深挖有兜底）：核心原理（调度、探针、Service 转发机制）能讲清但没读过源码级；储备（理解概念、未生产实操）：Helm、Operator、服务网格、多集群治理——如实说"知道什么时候该用、生产没用过"。然后我会接一句学习路径："我的深化计划是往两条线走——一是排障纵深（etcd 深层运维、网络插件底层），二是体系能力（Helm 化交付、可观测性完善）"——把"现在在哪、往哪去"一起讲，这个回答比"精通"二字值钱十倍。定位声明还有一个作用：把面试官的深挖引到我的主场（排查、转判、客户沟通），而不是被迫在原理深水区和专职 K8s 岗候选人拼刺刀——定位清晰本身就是一种面试策略。

追问链：

• 追问1：你会不会只是"会用 kubectl"的操作员？ → 答：用三个反证区分"操作员"和"工程师"。第一，我懂"为什么"：探针为什么由 kubelet 发起、Pod 为什么卡 ContainerCreating、NotReady 为什么九成是镜像——因果链能讲到底；第二，我有沉淀：9 项避坑清单每条都是"现象→根因→解法→预防"的完整闭环，操作员不会长出这种资产；第三，我有设计：移动云的监控体系、镜像双轨体系是我选型设计的——从"用工具"到"建体系"是分水岭。当然我也坦承：和专职 K8s 运维比，我在源码级原理和超大规模治理上有差距——但支持岗需要的是"定位准、讲得清、转得对"，这三样我有生产级证明。这个回答自卑和自大都没有，只有定位。
• 追问2：如果新公司的 K8s 版本/发行版和你用过的都不一样（比如 OpenShift、托管 ACK），你怎么快速上手？ → 答：我的上手方法四步，且被验证过（从 Docker 18.09/K8s 1.17 到 containerd/1.28 的跨越就是这么走的）。第一步分层定位差异：发行版的差异通常在"管理面封装和生态工具"，K8s 的核心对象模型和排查逻辑不变——先把"哪些是熟悉的内核、哪些是封装层"分清；第二步对着官方文档过"差异清单"：登录入口、权限模型、网络方案、日志位置这些"每家的第一公里"；第三步用排查树跑一遍日常场景：巡检、查日志、看事件——工具变逻辑不变；第四步两周内处理几单真实工单完成肌肉记忆迁移。我的总结一句话：学平台不如学排障的分层思想——平台会换，"从现象收敛到层级"的方法不换。

6.18 K8s 支持速查表：状态 → 第一动作 → 去向 【必背】

标准回答： 把本章的排查与转判压成一张速查表，配合第 6.15 的工单模板使用——接单先对状态入座，第一动作拿证据，按去向分流。这张表是我给团队交接时的"一页纸"，新同事照表操作，K8s 工单的响应动作就不会变形；面试时被问任何状态，我都从这张表进入完整故事。

状态/现象	第一动作	常见根因	去向
Pending（NODE 空）	describe 看 Events	资源不足/污点/PVC	一线改配置；扩容转二线
ContainerCreating 卡住	describe + journalctl -u kubelet	拉镜像/CNI/挂卷	镜像一线；存储转二线
CrashLoopBackOff	logs --previous + 退出码	配置/依赖/OOM	一线分诊；代码转开发
ImagePullBackOff	describe Events 原因串	凭据/名字/网络	凭据一线；仓库网络转二线
Running 但 0/1 Ready	describe 查 readiness	探针配错/bind 127	一线
节点 NotReady	describe node → CNI Pod	九成是镜像拉取	一线修镜像；内核/存储转二线
Evicted 大量出现	describe node 查压力	磁盘/内存压力	一线清理；容量转二线
Service 访问不通	kubectl get ep	selector/未就绪	一线
kubectl 全超时	telnet VIP:6443	入口/证书/控制面	一线分诊；控制面转二线
Terminating 卡住	查节点与 Finalizer	优雅退出/卷卸载/节点失联	谨慎强删（先告知客户）
证书报错 x509	openssl x509 -text	SAN 缺失/过期	按流程重签（高风险转二线协同）

6.19 本章案例

• 【真实项目·NotReady 镜像坑（STAR）】背景：移动云集群部署，三台 worker join 后全部 NotReady，部署卡住。任务：让节点就绪推进部署。行动：get pods -n kube-flannel 看到 Flannel Pod ImagePullBackOff；describe 确认海外镜像内网不可达；kubectl edit daemonset 将 init 和主容器镜像全局替换为内网仓库地址；滚动更新后节点 Ready。结果：三台节点几分钟恢复，"先 CNI 后 worker"与"镜像清单预导入"写进建设方案，成为 9 项避坑清单第 1 条——这单同时是分级示范：根因在镜像供给层，我一线能改 DaemonSet 就改了，仓库建设这类体系问题转入方案层推进。
• 【真实项目·原厂协同证据包（STAR 精简版）】背景：BCS 平台组件认证间歇性失败，应用层和配置层排查全部正常。任务：定位并解决。行动：命中"层级越界+反复复发"转判标准；打包七件套证据（重点：NTP 校准后的时间线对齐、稳定复现条件）；转华为原厂并每半天跟进、每阶段同步客户；原厂定位到组件时间同步校验机制问题，我在变更窗口配合实施补丁并验证。结果：问题闭环；"时间同步检查"进初始化基线（与移动云避坑第 9 条同源）；证据包模板沉淀为团队标准——完整版在第 14 章案例 S3。
• 【真实工单·kubectl 失联应急处置（演练+实战结合）】背景：某次变更窗口 apiserver 短暂不可用，kubectl 全部超时。行动：第一句话先告知客户"业务不受影响，正在恢复管理入口"；telnet <VIP>:6443 确认入口不通，范围收敛到控制面；上节点 journalctl 看组件状态，确认是变更窗口内的预期波动，等待自动恢复并验证 kubectl 返回正常。结果：全程业务零影响，客户侧无感知——"先说影响面"这句话的价值这单体现得最充分。
• 【经典故障·全量重启 Pending（指向第 14 章 S6 同源）】修改公共 Secret 触发 200+ Pod 同时重启全部 Pending——分批拉起恢复，"公共配置变更=全量重启风暴"的容量意识；完整 STAR 与教训在第 14 章通用案例区。

6.20 章末自测清单（快问快答）

1. 七组件和两大节点？ → Master：apiserver/etcd/scheduler/controller-manager；Node：kubelet/kube-proxy/运行时。
2. apiserver 挂了业务受影响吗？ → 不受影响（业务 Pod 照跑），只是 kubectl 失联、管理操作不可用——给客户解释的第一句话。
3. Pod 状态主线？ → Pending → ContainerCreating → Running（Ready）→ Succeeded/Failed/Terminating；Unknown=失联。
4. Pending 和 ContainerCreating 怎么区分责任层？ → 看 NODE 列：空=没调度上（调度层），有值=卡在节点侧（kubelet 层）。
5. K8s 排查五层命令树？ → 看（get/events/top）→ 描（describe/ep）→ 日志（logs/--previous）→ 进容器（exec）→ 上节点（journalctl/crictl）。
6. Service 访问不通第一查什么？ → kubectl get ep——Endpoints 空即 selector 没匹配或 Pod 未就绪。
7. NotReady 排查五步？ → describe node → systemctl status kubelet → CNI Pod 状态（九成是镜像）→ 连通性/证书 → 节点磁盘内存。
8. 九成 NotReady 的根因？ → CNI 镜像拉取失败——先 CNI 后 worker 的部署顺序是预防。
9. 一线处理的准入条件？ → 现象清晰、可复现、有 SOP、改动可回退，四条同时满足。
10. 转二线的触发标准？ → 层级越界/时间盒超限/无权限/影响面大/反复复发——命中任一即转。
11. 转派交接包五件？ → 现象描述、时间线、原始证据、已做尝试、初步判断。
12. 证据包七件套（原厂）？ → 概述、环境版本配套、原始日志、告警监控、已做尝试、复现条件、期望与约束。
13. 闭环的三层验证？ → 技术层（Pod/日志/指标）→ 业务层（客户实际功能验证）→ 记录层（工单归档确认）。
14. 升级机制三档？ → 二线/二线主管 → 我方 PM 与客户对接人 → 原厂高级支持/紧急通道。
15. 99.99% 怎么说？ → 设计目标，靠三副本+CLB 秒级摘除等机制保障，不说实测 SLA。
16. Evicted 大量出现先查什么？ → describe node 看 DiskPressure/MemoryPressure，磁盘压力最高频。
17. 发布出问题第一反应？ → 回滚（rollout undo）恢复业务，再对比版本找根因。
18. 工单记录最重要的三个字段？ → 时间线、变更记录、已做尝试——都服务于"下一个看单的人"。
19. 数据类问题的纪律？ → 停止破坏性操作、保留现场、立即上报拉人——从不单人处理。
20. 一线处理时间盒？ → 30 分钟无收敛即升级——转早不转晚，拖大才丢人。
21. "能不能重启服务器"的标准答案？ → 能，按 cordon → drain → 重启 → uncordon 流程，业务无感；直接断电是大忌。
22. "能不能保证 100% 不出问题"怎么答？ → 不承诺 100%，承诺发现快（告警）、响应快（分级）、不二犯（复盘沉淀）。
23. 转开发交接包四件？ → 现象复现、日志证据（高亮关键行）、环境与变更信息、资源监控曲线。
24. 环境 vs 代码之争怎么裁？ → 对照实验切变量 + 报错栈当裁判——支持岗提供干净证据。
25. Pod 随机名让客户不安怎么解释？ → 个体可换、身份稳定——Service 名和访问地址永远不变。
26. "能不能重启服务器"的标准答案？ → 能，按 cordon → drain → 重启 → uncordon 流程，业务无感；直接断电是大忌。
27. "能不能保证 100% 不出问题"怎么答？ → 不承诺 100%，承诺发现快（告警）、响应快（分级）、不二犯（复盘沉淀）。
28. 转开发交接包四件？ → 现象复现、日志证据（高亮关键行）、环境与变更信息、资源监控曲线。
29. 环境 vs 代码之争怎么裁？ → 对照实验切变量 + 报错栈当裁判——支持岗提供干净证据。
30. Pod 随机名让客户不安怎么解释？ → 个体可换、身份稳定——Service 名和访问地址永远不变。
31. 七条红线是什么？ → 不删全 ns、不裸 edit、不强删 Pod、不动 master 污点、不跑未读 YAML、不叠加变更、不绕过窗口。
32. 误删资源怎么救？ → 声明式资源 apply 重建、Pod 控制器自愈、无清单的靠备份——所以配置必须 git 化。
33. 防误操作靠什么？ → 七分权限设计（RBAC 最小化+审计）三分谨慎（dry-run+列清单确认）。
34. K8s 能力边界怎么讲？ → 能（部署/排查/运维）/熟（原理）/储备（Helm/Operator）——主动画边界加学习路径。
35. 换发行版怎么快速上手？ → 分层定位差异→过差异清单→排查树跑日常→两周工单迁移——平台会换、分层思想不换。
36. 速查表的用法？ → 状态入座→第一动作拿证据→按去向分流——一线/二线/开发/谨慎强删四类去向。
37. 强删 Pod 的前提？ → 评估数据影响并向客户说明，--grace-period=0 是最后手段不是习惯。