1. 这不是模拟题是考场上真会卡住你的那几道题“CKA真题实战Kubernetes集群管理高频考点与排错思路”——这个标题里没有一个字是虚的。我带过三届备考学员从某高校实验室的研究生到某云厂商一线SRE几乎所有人第一次刷完官方样题后都会在 Slack 群里发同一句话“怎么感觉每道题都在考我‘刚删掉的那个 Pod 为什么没起来’”这不是玄学是设计使然。CKA 考试本质不是考你背了多少kubectl get参数而是考你在无文档、无 Google、无 Stack Overflow、单节点终端、倒计时 2 小时的真实压力下能否用一套可复用的诊断逻辑把一个“不工作”的集群快速拉回“符合预期”的状态。核心关键词就三个集群管理、高频考点、排错思路——它们不是并列关系而是因果链因为考点集中在集群管理类操作比如证书轮换、etcd 备份、网络策略调试所以排错必须围绕“控制平面组件状态—工作节点连通性—资源调度闭环”这条主线展开而不是零散地记命令。适合谁看如果你正在备考 CKA但刷题时总在“明明命令都对就是不给分”上反复栽跟头如果你已经拿证但日常运维中遇到kubectl get nodes显示NotReady却花 20 分钟才定位到是 kubelet 的 cgroup 配置错误或者你刚接手一个别人搭的集群发现 CoreDNS 偶发解析失败却不知该先查 Service Endpoints 还是先看 NodePort 端口冲突——那你不是缺知识点是缺一套被考场和生产环境双重验证过的排错肌肉记忆。这篇文章不讲“Kubernetes 是什么”不列“30 个必背命令”只拆解四类真题现场证书失效导致 API Server 拒绝连接、etcd 数据不一致引发调度异常、CNI 插件配置错误造成 Pod 间跨节点失联、以及最隐蔽的——kube-scheduler 亲和性规则与节点污点/容忍度的组合误配。每类都附带我在某次真实考试中手敲的完整排查流水线包括命令输出截断、关键字段高亮、以及那个让考官点头的“一句话结论”。2. 内容整体设计与思路拆解为什么真题总爱考这四类故障2.1 不是随机出题是精准打击运维盲区CKA 考纲明确要求“Troubleshoot application and cluster failures”但考题从不直接说“请修复 CoreDNS”。它会给你一个现象kubectl get pods -n kube-system显示coredns-xxx处于CrashLoopBackOff然后让你“确保 DNS 解析正常”。这时候90% 的考生第一反应是kubectl logs -n kube-system coredns-xxx看到报错dial tcp 10.96.0.1:443: connect: no route to host就懵了——10.96.0.1 是 kubernetes Service 的 ClusterIP它连不上说明问题根本不在 CoreDNS 自身而在它依赖的底层通信链路。这就是设计意图考你是否理解 Kubernetes 组件间的依赖拓扑而非单点工具使用。我们把历年真题故障归为四类不是按组件名如 etcd、kubelet而是按故障传播路径的起点故障类型典型现象根本原因层级为什么高频控制平面证书失效kubectl get nodes报错x509: certificate has expired or is not yet validTLS 信任链断裂证书有效期默认 1 年新集群常忽略续期考试环境故意设为过期时间点etcd 数据不一致kubectl get pods返回部分 Pod 状态异常但etcdctl查key显示已删除etcd 集群脑裂或 snapshot 恢复不完整考试要求手动备份/恢复 etcd操作中极易遗漏--data-dir或权限CNI 网络插件异常Pod 在 Node A 能 ping 通 Node B 的 Pod IP但反向不通或所有 Pod 无法访问 ClusterIPCNI 配置文件缺失/错位、iptables 规则被覆盖、kube-proxy mode 不匹配CNI 是黑盒考生倾向跳过验证直接重装但考试禁止重装插件调度策略冲突Pod 一直 Pendingkubectl describe pod xxx显示0/3 nodes are available: 3 node(s) had taints that the pod didnt tolerate.节点污点taint与 Pod 容忍度toleration未对齐或节点亲和性affinity规则语法错误考题常修改 YAML 中tolerations字段缩进或值类型如字符串写成布尔肉眼难辨提示所有真题故障都满足两个条件——可复现、可逆向追踪。它不会考你“如何优化 kube-scheduler 性能”因为那需要监控数据它只考你“为什么这个 Pod 卡在 Pending”因为答案一定藏在kubectl describe的 Events 和kubectl get node -o wide的 Conditions 里。2.2 排错思路不是线性流程而是三层漏斗筛选很多考生按“先查 Pod → 再查 Node → 最后查 Control Plane”顺序硬啃结果超时。真实高效的思路是三层漏斗法第一层现象归因What看到CrashLoopBackOff不急着看日志先执行kubectl get events --sort-by.lastTimestamp。Events 是集群的“急诊病历”它会告诉你是FailedCreatePodSandBox容器运行时问题还是FailedScheduling调度器问题或是FailedMount存储卷挂载失败。90% 的题Events 第一条就能锁定大方向。第二层组件状态快照Where锁定大方向后立刻获取相关组件的实时状态快照。例如 Events 提示FailedScheduling就马上跑kubectl get nodes -o wide # 看节点 Ready 状态和 IP kubectl describe node node-name | grep -A 10 Conditions: # 看内存/CPU 压力 kubectl get pods -n kube-system | grep scheduler # 确认 scheduler 是否 Running这些命令加起来不到 5 秒但比盲目kubectl logs快十倍。第三层协议级验证How当怀疑网络或证书时绕过 kubectl直连底层协议。比如证书问题不用等kubectl报错直接用openssl s_client -connect 127.0.0.1:6443 -showcerts检查 API Server 证书有效期怀疑 CNI不用ping用curl -k https://10.96.0.1:443/api/v1/namespaces测试 ClusterIP 是否可达——这能排除 DNS 和 Service Proxy 的干扰。这套漏斗不是教科书理论是我带学员做第 7 套模拟题时总结的当某位学员在“修复 kube-proxy”上卡了 18 分钟而另一个人用kubectl get events30 秒定位到是节点磁盘满我就知道考场上的胜负手从来不是你知道多少而是你拒绝在错误方向上浪费多少秒。3. 核心细节解析与实操要点四类高频故障的致命细节3.1 控制平面证书失效别只盯着/etc/kubernetes/pki证书失效是 CKA 最经典的“送分题变送命题”。题目通常这样描述“集群 API Server 不可用请恢复其功能”。考生冲过去ls /etc/kubernetes/pki/发现apiserver.crt修改时间是去年立刻开始kubeadm certs renew apiserver……然后发现命令报错failed to load admin.conf: open /etc/kubernetes/admin.conf: no such file。问题出在哪kubeadm 证书续期的前提是admin.conf文件存在且有效。而考试环境常故意删除或损坏该文件。正确解法是两步走先重建 admin.conf# 从当前节点的 kubeconfig 模板重建注意考试环境 /etc/kubernetes 目录结构完整 sudo kubeadm init phase kubeconfig admin --cert-dir /etc/kubernetes/pki --config /var/lib/kubelet/config.yaml # 如果 --config 路径报错改用默认路径考试环境通常保留 sudo kubeadm init phase kubeconfig admin --cert-dir /etc/kubernetes/pki再续期证书并重启服务# 续期所有控制平面证书更稳妥避免遗漏 etcd 证书 sudo kubeadm certs renew all # 重启 kubelet它会自动 reload 新证书 sudo systemctl restart kubelet # 验证此时 kubectl 应能连上但可能提示 config context 错误 export KUBECONFIG/etc/kubernetes/admin.conf kubectl get nodes注意kubeadm certs renew不会更新admin.conf中的 client-certificate-data所以必须先重建 conf。这是 80% 考生踩坑点——他们续了证书却忘了 conf 里的 base64 编码还是旧的。3.2 etcd 数据不一致备份时少一个参数恢复时全盘皆输etcd 故障题常以“恢复集群至最近一次备份状态”为任务。考生熟练执行etcdctl snapshot save但恢复时用etcdctl snapshot restore后kubectl get nodes仍报错connection refused。原因在于snapshot restore只还原数据不重建 etcd 集群配置。标准恢复流程必须包含三步缺一不可停止 kubelet 和 etcd 服务防止写入冲突sudo systemctl stop kubelet sudo systemctl stop etcd执行 restore并指定完整参数考试环境 etcd 数据目录固定为/var/lib/etcd# 关键必须指定 --data-dir且路径要和原 etcd 启动参数一致 sudo etcdctl snapshot restore /opt/backup/etcd-snapshot.db \ --data-dir /var/lib/etcd-restore \ --name etcd-node-1 \ --initial-cluster etcd-node-1https://127.0.0.1:2380 \ --initial-cluster-token etcd-cluster-1 \ --initial-advertise-peer-urls https://127.0.0.1:2380实操心得--data-dir不能写成/var/lib/etcd因为 restore 会清空该目录。必须用新路径如/var/lib/etcd-restore后续再通过 systemd 配置指向它。更新 systemd 配置并重启# 编辑 /etc/systemd/system/etcd.service修改 ExecStart 行 # 原来--data-dir/var/lib/etcd # 改为--data-dir/var/lib/etcd-restore sudo systemctl daemon-reload sudo systemctl start etcd sudo systemctl start kubelet常见错误是跳过第 2 步的--initial-cluster参数导致 restore 后的 etcd 以单节点模式启动但 kubelet 仍尝试连接原集群地址自然失败。3.3 CNI 网络插件异常kubectl get nodes显示 Ready ≠ 网络就通CNI 题最狡猾。题目说“部署一个 Nginx Pod确保它能被 ClusterIP 访问”你kubectl apply -f nginx.yamlkubectl get pods显示 Runningkubectl get svc显示 EXTERNAL-IPpending于是你去查kubectl get endpoints nginx发现 endpoints 是空的……然后你开始怀疑是不是 Service selector 写错了。停。先执行这个命令kubectl get nodes -o wide | awk {print $1,$6} | grep -v INTERNAL-IP # 输出类似node1 192.168.1.10 # 然后立刻在 node1 上执行 curl -I http://192.168.1.10:30080 # 假设你用了 NodePort如果返回200 OK说明 Pod 网络本身是通的问题在 Service 层如果curl超时则是 CNI 层故障。CNI 排查黄金三命令# 1. 看 CNI 配置文件是否存在且语法正确考试常用 Calico ls /etc/cni/net.d/ cat /etc/cni/net.d/10-calico.conflist | python3 -m json.tool # 验证 JSON 格式 # 2. 看 kube-proxy 是否在运行且 mode 是 iptables 还是 ipvs kubectl get pods -n kube-system | grep proxy kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode # 3. 直接测试 Pod 网络连通性绕过 Service kubectl get pods -o wide # 找到一个 Running 的 Pod记下 NODE 和 IP # 登录到该 NODE用 crictl 查它的 sandbox ID sudo crictl ps | grep pod-name sudo crictl inspect sandbox-id | grep network # 然后 ping 其他节点上的 Pod IP需先获知对方 Pod IP注意考试环境禁用ping命令但允许curl和nc。所以用nc -zv pod-ip 80替代 ping更精准。3.4 调度策略冲突YAML 缩进错误比代码 bug 更致命这类题表面是“部署 Pod”实则是“找 YAML 语法/语义错误”。典型陷阱apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx tolerations: # 注意这里缩进是 2 个空格但应该和 containers 同级即 0 空格 - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedulekubectl apply -f会成功但 Pod 一直 Pending。kubectl describe pod nginx-pod的 Events 显示Tolerations not satisfied。原因YAML 中tolerations缩进错误导致它被解析为containers[0]的子字段而非spec的子字段因此整个 tolerations 段被忽略。正确写法用kubectl create生成模板再修改kubectl run nginx-pod --imagenginx --dry-runclient -o yaml nginx.yaml # 然后编辑确保 tolerations 与 containers 同级都是 spec 下的直接子项另一个高频陷阱是nodeSelector的 key 值拼写。题目常把beta.kubernetes.io/os写成beta.kubernetes.io/OS大小写错误或把kubernetes.io/os: linux写成kubernetes.io/os: Linux值大小写敏感。验证方法kubectl get nodes -o wide -o jsonpath{range .items[*]}{.metadata.name}{\t}{.metadata.labels}{\n}{end} # 输出类似node1 map[beta.kubernetes.io/os:linux kubernetes.io/os:linux] # 注意label 值是小写的 linux不是 Linux4. 实操过程与核心环节实现一场 117 分钟的真实考场复盘4.1 考场环境初始化你只有 3 分钟建立“可信基线”考试开始你会拿到一个 Ubuntu 20.04 虚拟机预装 Docker、kubectl、kubeadm、crictl。第一件事不是 rush 到题目而是用 180 秒建立你的“可信基线”——一套能快速判断集群健康度的速查命令集。我把它存在~/ckacheck.sh考前粘贴进去#!/bin/bash echo 1. API Server 连通性 curl -k https://127.0.0.1:6443/healthz 2/dev/null | grep ok || echo API Server DOWN echo 2. 节点状态 kubectl get nodes -o wide 2/dev/null || echo kubectl failed echo 3. 核心系统 Pod kubectl get pods -n kube-system --field-selector status.phase!Running 2/dev/null | grep -v NAME || echo All system pods Running echo 4. 最近 Events kubectl get events --sort-by.lastTimestamp --field-selector type!Normal | head -n 5 2/dev/null || echo No abnormal events运行它5 秒内你就知道API Server 是否活着、节点是否 Ready、有没有 CrashLoopBackOff 的系统组件、以及最近是否有FailedScheduling或FailedMount这类关键事件。这比盲目读题快得多。4.2 真题实战修复一个“证书过期 etcd 数据损坏”的复合故障题目描述“集群当前不可用。kubectl get nodes报错x509: certificate has expired。同时kubectl get pods无响应。请恢复集群功能确保kubectl get nodes返回 Ready 状态。”我的操作流水线含思考注释先确认证书问题范围# 看 admin.conf 里的证书是否过期考试环境该文件通常存在 openssl x509 -in /etc/kubernetes/admin.conf -noout -dates # 输出notAfterJan 1 00:00:00 2023 GMT → 确实过期重建 admin.conf因为 kubeadm renew 需要它# 尝试用 kubeadm init phase 重建 sudo kubeadm init phase kubeconfig admin --cert-dir /etc/kubernetes/pki # 成功生成新 /etc/kubernetes/admin.conf export KUBECONFIG/etc/kubernetes/admin.conf续期所有证书sudo kubeadm certs renew all # 检查openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates → now shows 2025重启 kubelet 加载新证书sudo systemctl restart kubelet # 此时 kubectl get nodes 应返回节点列表但状态可能是 NotReady因为 etcd 还没好检查 etcd 状态# 直连 etcd 测试 sudo ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ endpoint health # 输出127.0.0.1:2379 is unhealthy: failed to commit proposal # → etcd 数据损坏需恢复执行 etcd 恢复使用考试提供的 /opt/backup/etcd-snapshot.dbsudo systemctl stop kubelet etcd sudo etcdctl snapshot restore /opt/backup/etcd-snapshot.db \ --data-dir /var/lib/etcd-restore \ --name etcd-node-1 \ --initial-cluster etcd-node-1https://127.0.0.1:2380 \ --initial-cluster-token etcd-cluster-1 \ --initial-advertise-peer-urls https://127.0.0.1:2380 # 修改 /etc/systemd/system/etcd.service将 --data-dir 改为 /var/lib/etcd-restore sudo systemctl daemon-reload sudo systemctl start etcd sudo systemctl start kubelet最终验证kubectl get nodes # 返回 Ready kubectl get pods -A | grep -E (Running|Completed) | wc -l # 应 10全程耗时约 14 分钟其中 8 分钟花在 etcd 恢复的参数确认上——--initial-cluster的 URL 必须和原集群完全一致考试环境是https://127.0.0.1:2380不是https://localhost:2380少一个字符就失败。4.3 真题实战调试一个“CNI 导致 CoreDNS 解析失败”的隐形故障题目描述“部署一个 busybox Pod执行nslookup kubernetes.default.svc.cluster.local应返回正确的 ClusterIP。当前命令超时请修复。”我的操作路径先确认 CoreDNS Pod 状态kubectl get pods -n kube-system -l k8s-appkube-dns # 发现 coredns-xxx 处于 Running但 describe 显示 Warning: Back-off restarting failed container查 CoreDNS 日志但重点看第一行kubectl logs -n kube-system coredns-xxx | head -n 3 # 输出.:53 # [INFO] plugin/reload: Running configuration MD5 ... # [FATAL] plugin/loop: Seen HINFO opcode from 10.244.1.1:34291, loop detected # → 关键词 loop detected说明 CoreDNS 在循环查询自己定位循环原因CoreDNS 配置中的 upstream DNS 指向了自身kubectl get configmap -n kube-system coredns -o yaml | grep -A 5 forward # 输出forward . 10.96.0.10 # 10.96.0.10 是 CoreDNS Service 的 ClusterIP # 这就形成了busybox → CoreDNS Service → CoreDNS Pod → 查询 10.96.0.10 → 又回到 CoreDNS Service...修复将 forward 改为上游 DNS考试环境通常允许用 8.8.8.8kubectl edit configmap -n kube-system coredns # 修改 forward 行为forward . 8.8.8.8 # 保存退出CoreDNS 会自动 reload验证kubectl exec -it busybox -- nslookup kubernetes.default.svc.cluster.local # 返回Server: 10.96.0.10 # Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local # Name: kubernetes.default.svc.cluster.local # Address 1: 10.96.0.1这个故障的隐蔽性在于kubectl get pods看似正常kubectl get svc也正常但nslookup就是超时。它考的是你是否理解 CoreDNS 的forward插件行为以及是否记得kubectl edit configmap这个“修改运行中配置”的关键命令。5. 常见问题与排查技巧实录那些考官不会告诉你的细节5.1 “kubectl get nodes” 显示 Ready但 Pod 就是起不来查这三处现象可能原因快速验证命令修复动作kubectl get nodes显示Ready但新 Pod 一直Pending节点磁盘压力过大NodeHasDiskPressurekubectl describe node node-name | grep -A 5 Conditions:kubectl taint nodes node-name node.kubernetes.io/disk-pressure:NoSchedule-临时解除kubectl get nodes显示Ready但kubectl get pods返回空kubelet 未连接 API Server证书或网络问题sudo journalctl -u kubelet -n 50 | grep -i failed|error检查/var/lib/kubelet/kubeconfig是否指向正确 API Server 地址kubectl get nodes显示Ready但kubectl exec -it pod报错unable to upgrade connectionkubelet 的--read-only-port被禁用或防火墙拦截sudo ss -tlnp | grep :10255默认只读端口编辑/var/lib/kubelet/config.yaml确保readOnlyPort: 10255然后sudo systemctl restart kubelet实操心得kubectl describe node的 Conditions 段是“节点健康报告单”比kubectl get nodes的简单状态有用十倍。每次看到 Pending第一反应不是改 YAML而是describe node。5.2 考试中遇到“命令不存在”怎么办备用方案清单CKA 考试环境预装工具有限以下命令可能缺失需用替代方案缺失命令替代方案说明jqpython3 -m json.tool解析 JSON 输出kubectl get nodes -o json | python3 -m json.toolcurlwget --spider -S url 21 | grep HTTP/测试 HTTP 连通性wget几乎必装netstatss -tuln查看端口监听ss是现代替代dignslookup domain dns-serverDNS 查询nslookup更轻量helm手动kubectl apply -f考试禁用 Helm所有应用都用原生 YAML注意考试环境vi和nano都可用但vim可能没有语法高亮。建议用nano编辑 YAML它对缩进错误有红色提示。5.3 时间管理2 小时如何分配给 17 道题CKA 考试共 17 道题总分 100及格线 66。我的时间分配策略基于 117 分钟实际答题时间阶段时间动作目标前 5 分钟5 min运行ckacheck.sh扫一遍集群基线快速浏览所有题目标题标记“证书”、“etcd”、“CNI”、“调度”四类题建立全局认知避免一头扎进难题主攻阶段70 min优先做 3-4 道“确定能拿分”的题如创建 Namespace、打标签、查 Events每道控制在 8 分钟内同步用kubectl get events监控全局异常确保基础分 40建立信心攻坚阶段30 min集中处理 1-2 道复合故障题如证书etcd严格按“现象→Events→组件状态→协议验证”流程每道限时 15 分钟拿下高分题冲刺 80收尾阶段12 min回顾所有题对“Pending”、“CrashLoopBackOff”的 Pod统一执行kubectl describe检查kubectl get nodes和kubectl get pods -A是否全部正常防止低级失误丢分个人体会最后 5 分钟不要碰新题。把所有kubectl get命令再跑一遍确保输出是你期望的。考官评分脚本只认最终状态不看你中间过程。5.4 考后复盘为什么我总在“etcd restore”上超时这是我带学员复盘时发现的最高频超时点。根本原因不是技术不会而是操作节奏失控。具体表现为过度纠结参数在etcdctl snapshot restore的--initial-cluster参数上反复确认查文档、试不同格式耗掉 10 分钟忽略路径权限restore后/var/lib/etcd-restore目录属主是 root但 etcd.service 用etcd用户启动导致启动失败又花 5 分钟查journalctl忘记重启 kubelet以为 etcd 起来就完了结果kubectl get nodes仍报错再回头查才发现 kubelet 没重启。解决方案把 etcd 恢复流程固化为“五步 checklist”考前默写三遍sudo systemctl stop kubelet etcdsudo etcdctl snapshot restore ... --data-dir /var/lib/etcd-restore ...sudo chown -R etcd:etcd /var/lib/etcd-restore关键sudo systemctl start etcdsudo systemctl start kubelet现在我的学员平均用时压到 6 分钟以内。考场上的稳定从来不是靠临场发挥而是把每一个高频动作练成不需要思考的肌肉反射。