1. 这不是模拟题，是真实考场里被反复验证过的“故障指纹库”
我带过不少准备CKA认证的开发者，也参与过某云厂商内部K8s运维能力评估体系的设计。最常听到的一句话是：“题库刷了三遍，考试还是卡在排错题上。”不是知识点没掌握，而是考场上那5分钟——面对一个Pod持续Pending、一个Service死活不通、一个etcd集群突然失联——你根本来不及翻文档，更没时间查Stack Overflow。这时候真正起作用的，不是你背了多少kubectl命令，而是你脑子里有没有一套可快速触发的故障联想链。
CKA的排错题从来不是考“你会不会修”，而是考“你第一眼看到现象，脑子里自动弹出哪几个检查点”。比如看到kubectl get nodes输出里某个节点状态是NotReady，老手会立刻分三层推进：
- 网络层：节点上的kubelet进程是否在跑？
systemctl status kubelet返回什么？ - 组件层：kubelet是否能连上API Server？
journalctl -u kubelet -n 100 --no-pager | grep -i "connection refused\|timeout"有没有报错？ - 依赖层：容器运行时（containerd或docker）是否健康？
crictl ps能不能列出容器？systemctl status containerd有没有异常日志？
这三步不是凭空来的，是我在某实验室部署200+节点集群时，被同一类问题反复打脸后，用Excel表格一条条记下来的“故障指纹”。每条指纹都对应一个真实场景：
NodeNotReady + kubelet日志里出现"failed to run Kubelet: unable to load bootstrap kubeconfig"→ 一定是/etc/kubernetes/bootstrap-kubelet.conf文件权限错误或路径不对；Pod Pending + Events里显示"No nodes available that match all of the predicates"→ 八成是节点taint没配toleration，或者资源请求超限；Service ClusterIP不通 + kubectl describe svc显示Endpoints为空→ 不是Service写错了，而是Selector标签和Pod实际label对不上，这种错误在YAML里肉眼极难发现。
关键词里虽然没填，但所有CKA考生心里都清楚：排错 = 现象 → 日志 → 配置 → 依赖 → 验证，五步闭环缺一不可。而高频考点，就是这五步里最容易卡壳的那几个“断点”。这篇内容不讲概念，只拆解6个真实考场高频故障的完整排查链路，每一步都附带我当时在模拟环境里复现时截下的命令输出、错误日志原文、以及为什么必须按这个顺序查——因为跳步，真的会浪费掉宝贵的3分钟。
2. Pod卡在Pending状态：从调度器日志到节点污点的全链路推演
这是CKA实操题里出现频率最高的开场白：“Deploy a pod named nginx-pod in default namespace using nginx image. The pod should be in Running state.” 结果你kubectl apply -f nginx.yaml之后，kubectl get pods却一直显示Pending。别急着删重来，先做三件事：
2.1 第一反应：看Events，不是看Pod状态
很多人习惯直接kubectl describe pod nginx-pod，然后盯着Events那一栏猛看。但注意，Events里的信息是聚合后的摘要，关键细节往往被折叠。正确做法是：
kubectl get events --sort-by=.lastTimestamp这条命令按时间倒序列出所有事件，把最新发生的排在最上面。你大概率会看到类似这样的行：
2m15s Warning FailedScheduling pod/nginx-pod 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 2 node(s) didn't match Pod's node affinity/selector.这句话的信息密度极高。我们逐词拆解：
0/3 nodes are available：调度器扫了全部3个节点，一个都没选上；1 node(s) had taint {node-role.kubernetes.io/control-plane: }：其中1个节点打了control-plane污点；that the pod didn't tolerate：你的Pod YAML里没写对应的toleration；2 node(s) didn't match Pod's node affinity/selector：剩下2个节点，因为affinity规则或nodeSelector不匹配，也被筛掉了。
提示：如果Events里只写“0/3 nodes are available”而没展开原因，说明你的集群启用了自定义调度器（如kube-batch），或者调度器日志级别太低。此时必须切到master节点，查
kubectl logs -n kube-system $(kubectl get pods -n kube-system | grep scheduler | awk '{print $1}')。
2.2 深挖根源：为什么调度器认为节点“不可用”？
假设Events明确指向了污点问题，下一步不是改YAML，而是先确认节点真实状态：
kubectl get nodes -o wide kubectl describe node <node-name>在describe node输出里，重点看两块：
- Taints字段：确认该节点是否真有
node-role.kubernetes.io/control-plane:NoSchedule； - Conditions字段：检查
Ready、MemoryPressure、DiskPressure、PIDPressure是否全为True。哪怕只有一个False，调度器也会把它踢出候选池。
我见过最坑的一次，是某同学在describe node里看到Conditions全绿，就以为没问题，结果kubectl get pods -A发现kube-proxy和coredns都在CrashLoopBackOff。他没意识到：调度器只看节点Condition，不看系统组件健康度。kube-proxy挂了，节点网络插件就失效，新Pod即使调度上去，也无法获得IP地址——所以调度器宁可让它Pending，也不愿制造一个“活着但无法通信”的僵尸Pod。
2.3 实操验证：用dry-run定位配置硬伤
如果Events没给出明确线索，或者你怀疑是自己写的YAML有硬伤（比如resources.request写成了1000m而不是1000Mi），请立刻执行：
kubectl apply -f nginx.yaml --dry-run=client -o yaml | kubectl create --dry-run=client -o yaml -f -这个组合命令会强制YAML通过客户端校验，并输出最终生成的资源对象。重点检查：
spec.containers[0].resources.requests.memory是否是合法单位（Mi、Gi，不是MB或GB）；spec.nodeSelector的key是否在kubectl get nodes -o jsonpath='{.items[*].metadata.labels}'里真实存在；spec.tolerations的effect、key、operator是否与describe node输出完全一致（大小写敏感！）。
注意：
--dry-run=server在CKA考试环境里通常被禁用，因为会真实调用API Server。务必用client模式，它只做本地语法和schema校验，不发网络请求。
2.4 终极兜底：手动指定节点绕过调度器
当时间只剩2分钟，而你还没定位到根因，有个保命技巧：
kubectl patch pod nginx-pod -p '{"spec":{"nodeName":"<target-node-name>"}}'这条命令强制把Pod绑定到指定节点，跳过整个调度流程。只要该节点kubelet正常、容器运行时可用、磁盘空间充足，Pod大概率会在10秒内进入ContainerCreating状态。
但这只是“绕过问题”，不是“解决问题”。考试结束后，你必须回过头来查：为什么调度器拒绝了这个节点？是taint没配？是资源不足？还是节点本身Condition异常？——因为下一道题，很可能就是让你修复这个调度策略。
3. Service不通：从Endpoint缺失到iptables规则失效的三层穿透
CKA里另一类高频题是：“Create a service named nginx-service that exposes the nginx-pod on port 80.” 你kubectl expose完，curl http://<cluster-ip>:80却返回Connection refused。别猜，按以下三层结构化排查：
3.1 第一层：Endpoint是否存在？这是90%问题的起点
执行：
kubectl get endpoints nginx-service kubectl describe service nginx-service如果get endpoints返回空，或者describe service里Endpoints:字段后面是<none>，说明Service根本没关联到任何Pod。原因只有两个：
Selector不匹配：
kubectl get pod nginx-pod -o jsonpath='{.metadata.labels}'输出的label，和kubectl get service nginx-service -o jsonpath='{.spec.selector}'输出的selector，字符串必须逐字节相等。常见错误包括：- Pod label是
app: nginx，Service selector写成app: "nginx"（多了引号）； - Pod label是
tier: backend，Service selector写成tier: frontend（拼写错误）； - Pod label是
version: v1.2，Service selector写成version: 1.2（类型不一致，YAML里数字会被解析为int）。
- Pod label是
Pod状态异常：
kubectl get pods里nginx-pod必须是Running，不能是Pending、CrashLoopBackOff或Error。因为Endpoint Controller只会把Running且Ready的Pod加进Endpoint列表。
提示：用
kubectl get pods --show-labels可以同时看到Pod名和所有label，比describe pod更快定位selector问题。
3.2 第二层：ClusterIP能否被节点访问？验证kube-proxy工作流
如果Endpoint存在，但curl仍失败，问题大概率出在kube-proxy。CKA考试环境默认使用iptables模式（非ipvs），所以要查：
# 在任意worker节点上执行 iptables -t nat -L KUBE-SERVICES | grep nginx-service你应该看到类似这样的规则：
KUBE-SVC-XXXXXX tcp -- anywhere anywhere /* default/nginx-service: cluster IP */ tcp dpt:http接着查这条链的跳转目标：
iptables -t nat -L KUBE-SVC-XXXXXX正常输出应该包含至少一行：
KUBE-SEP-YYYYYY all -- anywhere anywhere /* default/nginx-service: */这表示流量被转发到了具体的Endpoint（即Pod的IP）。如果这里为空，说明kube-proxy没把Endpoint同步进iptables——原因通常是：
- kube-proxy Pod在
CrashLoopBackOff状态（kubectl get pods -n kube-system | grep proxy）； - kube-proxy配置文件里
--proxy-mode=iptables被误写成--proxy-mode=userspace（已废弃）； - 节点防火墙（如firewalld）拦截了iptables规则生效。
3.3 第三层：Pod内部端口是否真在监听？用exec直连容器验证
即使前两层都OK，curl仍可能失败。这时要穿透到容器内部：
kubectl exec nginx-pod -- netstat -tuln | grep :80 kubectl exec nginx-pod -- curl -I http://localhost:80- 如果
netstat没输出，说明Nginx进程根本没启动，或者监听的是127.0.0.1:80而非0.0.0.0:80； - 如果
curl -I返回200 OK，但外部curl失败，说明问题出在Pod网络层（CNI插件故障）； - 如果
curl -I也失败，说明容器内应用本身有问题（比如Nginx配置文件语法错误，导致进程启动后立即退出）。
我踩过最深的坑，是在某次模拟中，kubectl exec进去发现Nginx进程在，netstat也显示监听0.0.0.0:80，但curl -I超时。最后发现是容器里/etc/hosts被篡改，localhost解析到了错误IP。这种问题只能靠strace curl -I http://localhost:80抓系统调用才能定位——但考试时没时间，所以我的经验是：只要exec能进容器，优先检查/etc/hosts和/etc/resolv.conf。
4. etcd集群失联：从证书过期到peer通信中断的精准定位
CKA里最难的排错题，往往藏在kubectl get componentstatuses（已弃用但考试仍考）或kubectl get cs里。当你看到etcd-0状态是Unknown，而其他组件（scheduler、controller-manager）都是Healthy，这就是典型的etcd单点故障。别慌，按以下顺序查：
4.1 快速确认：etcd进程是否存活？端口是否监听？
登录到etcd所在节点（通常是master节点），执行：
ps aux | grep etcd sudo ss -tuln | grep :2379- 如果
ps没输出，说明etcd进程已崩溃； - 如果
ss没输出，说明etcd没监听2379端口（可能是启动参数--listen-client-urls配错了）； - 如果两者都有，但
kubectl get cs仍是Unknown，说明etcd进程在，但API Server连不上它。
4.2 根本原因：证书是否过期？这是CKA最爱埋的雷
etcd通信依赖双向TLS证书。考试环境里，etcd证书有效期通常设为30天，而很多考生拖到第28天才开始备考。查证书有效期：
sudo openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -text -noout | grep -A1 "Validity"如果Not After日期已过，API Server会拒绝连接etcd，报错日志在kubectl logs -n kube-system kube-apiserver-<master-name>里，关键词是x509: certificate has expired or is not yet valid。
修复方法不是重装，而是用kubeadm工具轮换：
sudo kubeadm certs renew etcd-server sudo systemctl restart etcd注意：
kubeadm certs renew必须在master节点上以root权限运行，且要求/etc/kubernetes/pki/etcd/目录下有完整的CA证书（ca.crt和ca.key）。如果CA丢失，整个集群将无法恢复——所以考试前务必确认ls /etc/kubernetes/pki/etcd/ca.*存在。
4.3 网络层：peer端口2380是否通？etcd集群脑裂的征兆
如果证书OK，但etcdctl命令报context deadline exceeded，问题可能出在peer通信。查etcd peer端口：
sudo ss -tuln | grep :2380再从其他etcd节点ping当前节点的peer IP（通常是--initial-advertise-peer-urls参数指定的地址）：
# 在etcd-1节点上执行 curl -k https://<etcd-0-peer-ip>:2380/health如果返回{"health":"false"}或超时，说明peer网络不通。常见原因：
- 节点防火墙（ufw/firewalld）阻止了2380端口；
- 云平台安全组没放行2380；
--initial-cluster参数里etcd-0的peer URL写错了IP或端口。
提示：
etcdctl的--endpoints参数必须指向--listen-peer-urls，不是--listen-client-urls。考试时如果记混，直接ps aux | grep etcd看启动命令最稳妥。
4.4 数据层：wal目录是否写满？磁盘IO瓶颈的隐性杀手
即使网络和证书都OK，etcd也可能因磁盘问题假死。查：
df -h /var/lib/etcd sudo iostat -x 1 3 | grep -A1 "await\|%util"- 如果
/var/lib/etcd使用率超90%，etcd会拒绝写入，日志里出现write timeout； - 如果
%util持续100%，说明磁盘IO饱和，etcd WAL日志刷盘慢，导致Raft心跳超时。
解决方案不是清理磁盘，而是临时降低etcd写压力：
# 缩短etcd快照间隔，减少WAL堆积 sudo sed -i 's/--snapshot-count=[0-9]*/--snapshot-count=10000/g' /etc/kubernetes/manifests/etcd.yaml sudo systemctl restart kubelet考试环境里，/var/lib/etcd通常挂载在独立小磁盘上，所以磁盘满比IO瓶颈更常见。我的建议是：考前先df -h扫一眼，比啥都强。
5. kubelet异常：从cgroup驱动不匹配到镜像拉取失败的现场还原
kubectl get nodes显示NotReady，但systemctl status kubelet显示active (running)，这种“看似正常实则瘫痪”的状态，最消耗考试时间。以下是我在某次压测中复现并记录的4种典型kubelet异常：
5.1 cgroup驱动冲突：Docker与kubelet的“语言不通”
如果你的节点用Docker作为容器运行时，而kubelet配置的cgroup驱动是systemd，但Docker daemon用的是cgroupfs，就会出现：
journalctl -u kubelet | grep -i "cgroup"报错：failed to run Kubelet: failed to get root cgroup stats；docker info | grep "Cgroup Driver"显示cgroupfs；cat /var/lib/kubelet/config.yaml | grep cgroupDriver显示systemd。
解决方法是统一驱动：
# 修改Docker配置 echo '{"exec-opts": ["native.cgroupdriver=systemd"]}' | sudo tee /etc/docker/daemon.json sudo systemctl restart docker # 重启kubelet sudo systemctl restart kubelet关键点：
/etc/docker/daemon.json必须是JSON格式，引号和逗号一个都不能错。考试时如果手敲出错，直接cp /etc/docker/daemon.json.bak /etc/docker/daemon.json回滚。
5.2 镜像拉取失败：私有仓库认证缺失的静默陷阱
kubectl describe pod里Events显示：Failed to pull image "private-registry.com/nginx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://private-registry.com/v2/: x509: certificate signed by unknown authority。
这不是网络问题，而是kubelet没配置私有仓库CA证书。修复步骤：
# 将私有仓库CA证书复制到节点 sudo mkdir -p /etc/docker/certs.d/private-registry.com:5000 sudo cp ca.crt /etc/docker/certs.d/private-registry.com:5000/ca.crt sudo systemctl restart docker注意：/etc/docker/certs.d/下的目录名必须和镜像URL的host:port完全一致（包括端口），否则Docker会忽略证书。
5.3 磁盘压力：ImageGCFailed引发的连锁雪崩
journalctl -u kubelet | grep "image garbage collection"出现大量failed to garbage collect required amount of images。原因是：
- kubelet配置了
--image-gc-high-threshold=85（磁盘使用率超85%触发清理）； - 但节点上存了大量未被Pod引用的悬空镜像（dangling images）；
- kubelet清理时发现磁盘IO太慢，超时失败，进而导致
NodeDiskPressureCondition变为True，调度器停止往该节点调度新Pod。
查悬空镜像：
docker images -f "dangling=true" -q | wc -l如果数量巨大（>100），手动清理：
docker rmi $(docker images -f "dangling=true" -q)提示：考试环境里，
docker system prune -a通常被禁用（会删掉正在运行的容器），所以必须用rmi精准删除悬空镜像。
5.4 配置漂移：bootstrap-kubelet.conf被意外覆盖
journalctl -u kubelet | grep "bootstrap kubeconfig"报错：failed to load bootstrap kubeconfig。原因往往是：
- 考生在练习时执行了
kubeadm init，生成了新的/etc/kubernetes/bootstrap-kubelet.conf； - 但考试环境里，这个文件是预置的，且权限为
600； - 新生成的文件权限是
644，kubelet拒绝读取。
验证权限：
ls -l /etc/kubernetes/bootstrap-kubelet.conf如果权限不是-rw-------，修复：
sudo chmod 600 /etc/kubernetes/bootstrap-kubelet.conf sudo systemctl restart kubelet这个坑之所以致命，是因为它不报具体错误，只显示failed to load，新手会以为文件路径错了，疯狂查/etc/kubernetes/下有没有这个文件，却忽略了权限。
6. API Server 503错误：从静态Pod管理到证书链断裂的深度复盘
kubectl get pods返回Error from server (ServiceUnavailable): the server is currently unable to handle the request，这是CKA里最让人头皮发麻的报错。它意味着API Server本身挂了，但systemctl status kubelet可能还显示active。因为API Server是以静态Pod方式运行的，它的生命周期由kubelet管理，而非systemd。
6.1 定位源头：查静态Pod清单和容器日志
API Server静态Pod清单在/etc/kubernetes/manifests/kube-apiserver.yaml。先确认文件存在且未被修改：
ls -l /etc/kubernetes/manifests/kube-apiserver.yaml再查该Pod是否被kubelet成功创建：
sudo crictl ps | grep apiserver如果没输出，说明kubelet没加载这个yaml；如果有输出但状态不是Running，查日志：
sudo crictl logs <apiserver-container-id>最常见的日志错误是：
x509: certificate signed by unknown authority：API Server证书的CA不在/etc/kubernetes/pki/ca.crt里；bind: address already in use：8080或6443端口被其他进程占用；open /etc/kubernetes/pki/apiserver.crt: no such file or directory：证书文件被误删。
6.2 证书链断裂：CA证书与服务端证书的“信任危机”
API Server证书必须由集群CA签发，且CA证书必须和/etc/kubernetes/pki/ca.crt完全一致。查证书链：
# 查API Server证书的Issuer sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep "Issuer:" # 查CA证书的Subject sudo openssl x509 -in /etc/kubernetes/pki/ca.crt -text -noout | grep "Subject:"如果Issuer和Subject不匹配，说明证书不是用这个CA签的。修复方法：
# 用现有CA重新签发 sudo kubeadm certs renew apiserver # 重启kubelet让新证书生效 sudo systemctl restart kubelet注意：
kubeadm certs renew会同时更新apiserver.crt、apiserver-kubelet-client.crt等多个证书，确保整个链完整。
6.3 端口冲突：8080与6443的“双面间谍”
API Server默认监听两个端口：
--secure-port=6443：HTTPS端口，用于kubectl等客户端；--insecure-port=8080：HTTP端口（默认关闭，但考试环境有时开启）。
查端口占用：
sudo ss -tuln | grep -E ":8080|:6443"如果看到LISTEN状态的进程不是kube-apiserver，说明端口被占。杀掉它：
sudo ss -tulnp | grep ":8080" | awk '{print $7}' | cut -d',' -f2 | xargs kill -9这条命令提取占用8080端口的PID并强制终止。考试时如果记不住，就用sudo lsof -i :8080替代。
6.4 静态Pod机制失效：kubelet没监控manifests目录
最后一种情况最隐蔽：/etc/kubernetes/manifests/目录权限被改，导致kubelet无法读取yaml。查：
ls -ld /etc/kubernetes/manifests/正常权限是drwxr-xr-x。如果变成drw-------，修复：
sudo chmod 755 /etc/kubernetes/manifests/ sudo systemctl restart kubelet因为kubelet是以root用户运行的，它需要r-x权限才能遍历目录、读取yaml文件。权限丢失后，kubelet会静默跳过该目录，既不报错，也不创建Pod。
7. 我的考场实战笔记：3个必须写在草稿纸上的黄金检查表
考前最后10分钟，我建议你把下面3张表抄在草稿纸上。它们不是知识点罗列，而是我根据近5年CKA真题统计出的最高频故障触发条件，每一条都对应一个真实扣分点：
7.1 Pod排错速查表（5秒决策）
| 现象 | 第一检查点 | 第二检查点 | 第三检查点 |
|---|---|---|---|
Pending | kubectl get events --sort-by=.lastTimestamp | kubectl describe node <node-name>看Taints和Conditions | kubectl get pods -o wide看节点分配 |
ContainerCreating | kubectl describe pod看Events里FailedMount或FailedAttachVolume | kubectl get pv,pvc看绑定状态 | `kubectl logs -n kube-system $(kubectl get pods -n kube-system |
CrashLoopBackOff | kubectl logs <pod-name> --previous看上一次崩溃日志 | kubectl exec <pod-name> -- ps aux看主进程是否启动 | kubectl describe pod看LivenessProbe是否配置过激 |
注意：
--previous参数在CKA考试里是允许的，它能拿到容器上次崩溃的日志，比当前日志更有价值。
7.2 Service排错速查表（3步闭环）
- Endpoint层：
kubectl get endpoints <svc-name>→ 不为空？否→查Selector和Pod状态；是→进第二步； - kube-proxy层：
kubectl get pods -n kube-system | grep proxy→ Running？否→查日志；是→在节点上iptables -t nat -L KUBE-SERVICES | grep <svc-name>； - Pod层：
kubectl exec <pod-name> -- netstat -tuln | grep :<port>→ 监听？否→改应用；是→kubectl exec <pod-name> -- curl -I http://localhost:<port>。
7.3 etcd/kubelet/API Server联合诊断表（防漏网之鱼）
当多个组件同时异常（如kubectl get cs全Unknown），按此顺序查：
- 第一步：
systemctl status etcd kubelet→ 哪个是inactive？优先修它； - 第二步：
sudo crictl ps | grep -E "(etcd|apiserver|controller-manager)"→ 哪个容器没起来？查对应/etc/kubernetes/manifests/下的yaml； - 第三步：
sudo openssl x509 -in /etc/kubernetes/pki/ca.crt -text -noout \| grep "Validity"→ CA证书是否过期？过期则kubeadm certs renew all。
这张表的价值在于：它把“同时修多个组件”的焦虑，转化成“按顺序修一个，再看全局是否恢复”的确定性动作。我在某次模拟中，就是靠这张表，在4分钟内从kubectl get cs全红，恢复到全绿。
最后分享一个小技巧：考试时，如果遇到完全没见过的报错，不要死磕。先执行kubectl version确认客户端和服务端版本是否兼容（CKA考试环境通常是v1.27+），再执行kubectl api-resources看API组是否正常加载。这两个命令耗时不到1秒，但能帮你快速排除“环境本身是否可用”这个元问题。剩下的，就交给上面那三张表——它们不是答案，而是你大脑的外挂索引。
