CKA认证1.29题库备考：版本差异分析与高频操作避坑指南

简介：面向 Kubernetes CKA 1.29 认证考生整理的考试题库与实战指南，适合已掌握 Kubernetes 基础、希望系统备战 RBAC、Deployment 扩容、NetworkPolicy、Service/Ingress、Pod 调度、节点维护、PV/PVC 与日志管理等考点的运维、开发及架构师。压缩包内为 1 个 PDF 文档，共 6.78MB，内容涵盖环境配置、模拟环境搭建、考题解析、命令参考和易错点提示；从 candidate 账号登录、集群切换到 PSI 新考试平台限制、应对卡顿策略、常见误区与解决办法都有说明，并给出 RBAC 等典型题目的完整操作流程。题库在题干描述上与真实考试一致，同时特别强调真实考试中 Pod、Deployment、Namespace、ServiceAccount 等变量参数可能变化，提醒考生理解题意而非死记硬背答案，并建议用 candidate 账号在 node01 上反复练习。该资源已有 1058 人学习浏览，适合考前强化训练以提高解题速度与实战能力，对熟悉官方考试操作界面和平台限制也有较高参考价值。

1. Kubernetes CKA认证 1.29 题库：背题背得越熟，越要小心版本差

准备 Kubernetes CKA 认证时，我手头那套 1.29 题库是从旧版答案改过来的，练到第三周才发现：背题背得越熟，上考场越容易翻车。1.29 的考试环境换了新组件，etcd 备份命令要带 ETCDCTL_API=3，drain 节点要求写 --ignore-daemonsets，旧题库里这些参数几乎全没提。这不是个例。CKA 认证从 1.28 升到 1.29 后，考试集群、kubectl 行为和日志格式都在变，如果你还停在 1.24 时代的刷题思路，越刷越危险。这里不打算让你背答案，而是帮你把题库拆成可练习、可自检、可避坑的操作清单。适合准备考 CKA 的运维、SRE、平台工程师，也适合刚学完 Kubernetes 基础想拿证的人。

2. CKA 1.29 考点拆解：用大纲反向筛选题库

CKA 考试的核心不是“记住一百道题”，而是“能在限定时间里完成一组集群操作”。所以拿到任何题库，第一件事是把题目归到考点类型里去；也不需要先啃《深入理解 Kubernetes 源码》之类的大部头，那是读内核的人做的事，备考的时间应该花在敲命令上。官网公开的考试大纲范围包括集群架构与安装、工作负载调度、存储、网络、排障、安全与 RBAC，1.29 版本没有把大纲推倒重来，但把不少操作细节改了。

2.1 先看清考试集群的构成

考试环境的集群是预置好的，不需要你从头搭建控制面。打开终端先跑三条命令，花一分钟确认当前环境状态：

kubectl version kubectl get nodes -o wide kubectl get ns

kubectl version 会同时显示 Client 和 Server 版本，两者都落在 1.29.x 说明连接正常，如果客户端是 1.30 而服务端是 1.29，虽然大部分命令兼容，但考试环境里不建议折腾这种事。kubectl get nodes -o wide 可以看节点状态、内部 IP 和运行时版本，kubectl get ns 则确认题目要求用的命名空间是否存在。很多题目会提供一个特意创建的 namespace，比如 cka-lab，如果直接在不存在的命名空间里执行 kubectl run，命令会报错，题目就算浪费了一次测试机会。

另外，考试终端不一定给你配好了 bash-completion，tab 补全时灵时不灵。练习时要习惯把完整命令敲出来，尤其 etcd 那串证书参数，别指望补全。不同 CNI 插件对 READY 状态的判定差异比版本升级还大，偶尔会出现节点 Ready 但调度被禁用的误判，这时加一个 kubectl describe node 看 Taints 和 Ready 条件里的真实报错，比反复看 STATUS 列有用。

2.2 高频操作类型与命令映射

CKA 的实操题基本可以映射到六类操作：etcd 备份还原、节点维护、RBAC、网络策略、PV/PVC、Ingress。下面这张表是我自己刷题时整理的，按“核心命令 + 高频易错参数”设计：

这张表的依据是题目常见的组合：etcd 题通常给你一个控制面节点，要求在限定时间内生成快照；RBAC 题重点在“给某个用户创建只能读某些资源”的细粒度权限；网络策略题则默认集群里已经跑着两个带标签的 Pod。刷题时把每道题贴到表格里，先判断它是哪一类，再看答案里的命令是否落在上述核心命令范围内，不在范围的答案基本是过时或偏题了。这里的一个关键点是：每种题型的价值密度不一样，etcd 题命令长、参数多、必须天天练；Ingress 题只要你理解 host 和 path 的匹配规则，临时查文档也能写出来。时间有限的话，优先级应该是 etcd、网络策略、RBAC 三件套优先。

2.3 版本差异：哪些“标准答案”在 1.29 上失效

题库过时的根源是命令行为变了，而不是题目考的东西变了。最典型的三个例子：

第一，drain 语法。旧题库常用 kubectl drain node01 --force，但在节点上运行了 DaemonSet 时，这条命令会一直等待且不退出。想在 1.29 上顺利 drain 一个跑着 DaemonSet 的节点，就必须补上 --ignore-daemonsets。刷题时如果遇到答案里只有 --force，可以直接标记为失效。

第二，etcdctl 环境变量。1.29 环境里 etcd 默认用 v3 API，但 etcdctl 二进制本身可能是 v3 封装，直接写 etcdctl snapshot save 容易踩到“命令存在但行为不对”的坑。稳妥写法是先 export ETCDCTL_API=3，再执行，旧题库很少提到这一步。另一个容易被忽略的点是：etcd 证书路径不是背出来的，是从控制面节点的静态 Pod 配置里查出来的，后面 3.2 会展开讲怎么查。

第三，静态 Pod 的管理方式。控制面组件在考试环境里以静态 Pod 形式运行，kubectl delete pod kube-apiserver-master 后 kubelet 会自动拉起一个新 Pod。旧题库里“重启节点上的某个服务”这类操作，必须改成修改 /etc/kubernetes/manifests 下的清单文件。把这些差异在题库上标注出来：哪道题的命令已失效、哪道题还能练、哪些题只差一个参数。筛完后的题库才有练习价值。

2.4 用考点清单反向筛选题库

拿到手头的题库，先不要逐题往下背。我的做法是：把上面的题型表打印出来，每一道题归入一个类型，同一个类型连续做三遍；如果三道题的命令不一致，就以 1.29 官方命令为准改写自己的操作步骤。筛选的原则是“命令能否在你的 1.29 集群里跑通”，而不是“答案是不是完整”。版本越老、截图越旧、连 kubectl version 都没写清楚的题库，直接放弃。反过来，如果一份题库在每道题后面标注了“在 1.29 集群中验证通过”，它的可靠性就高一大截。

筛选时还有一个细节值得留意：题库答案里是否频繁出现 kubectl describe 和 kubectl logs。CKA 的排障题和配置题不同，根本没有标准输出，只能靠事件日志定位。一份好题库应该把 describe 作为标准动作，而不是把 kubectl apply 当万能答案。遇到那种所有题目都只给 apply 命令的题库，通常是把配置题改抄成了搭建文档，练到最后只会复制粘贴。

3. 把 1.29 题库当训练集：三类高频操作的可复现练习

题库不是用来“刷”的，是用来“复现”的。下面三个操作类型是我认为投入产出比最高的：RBAC、NetworkPolicy、etcd。它们分别代表权限、网络、存储三条主线，也是考试里最容易失分的点。每个类型我都会给出一套“最小复现”的命令，你可以在自己的笔记本上直接跑。

3.1 在笔记本上用 Kind 跑一个 1.29 集群

我不建议直接用 kubeadm 从零搭集群来练 CKA，原因很简单：你练的是“修集群”而不是“建集群”，考试也不考建集群。用 Kind 最合适——几分钟起一个多节点的 1.29 环境，内存占用比 kubeadm 全量控制面小得多，反复销毁重建不心疼。为什么不推荐 minikube？因为 minikube 会默认帮你配好 StorageClass、Metrics Server，坏集群的状态反而被掩盖了；Kind 默认不预装这些，PV 要自己建，HPA 要自己装 metrics-server，更接近 CKA 考场的“半坏集群”状态。

cat <<EOF > /tmp/cka-kind.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 name: cka129 nodes: - role: control-plane image: kindest/node:v1.29.0 - role: worker image: kindest/node:v1.29.0 - role: worker image: kindest/node:v1.29.0 EOF kind create cluster --config /tmp/cka-kind.yaml

这段配置声明了一个控制面节点和两个 worker 节点。控制面节点里跑着 kube-apiserver、etcd、kube-scheduler、kube-controller-manager 四个静态 Pod，和真实考试集群架构一致；两个 worker 节点用来练习 drain、cordon 这类节点维护操作。image 字段的 tag 可以换成你本机能拉到的任意 1.29 系列镜像，如果本机没有这个镜像，先 docker pull 对应 tag 确认可以拉取，再填到 yaml 里。

启动完成后跑 kubectl cluster-info 确认 API 可达，kubectl get nodes 确认三个节点都是 Ready。如果节点一直 NotReady，先检查本机 Docker 资源，再检查镜像架构和宿主机 CPU 型号，这两项是 Kind 最常见的启动失败原因。

3.2 三类高频操作的最小复现

每个题库题目都可以拆成“操作 + 验证”两步。以 RBAC 为例，最小复现是这样：

# 1. 查看当前命名空间和已有服务账号 kubectl get ns kubectl get sa -n cka-lab # 2. 创建一个只能读取 Pod 的 role，并绑定到指定服务账号 kubectl -n cka-lab create role pod-reader \ --verb=get,list \ --resource=pods kubectl -n cka-lab create rolebinding pod-reader-bind \ --role=pod-reader \ --serviceaccount=cka-lab:app-sa # 3. 模拟该服务账号身份，验证权限是否生效 kubectl auth can-i list pods -n cka-lab \ --as=system:serviceaccount:cka-lab:app-sa

--resource=pods 的取值要与资源单数一致，写成 pod 也能跑但部分校验工具不认；--verb=get,list 是权限动词列表，如需写权限再加 create,update,patch,delete。验证命令里的 --as=system:serviceaccount:cka-lab:app-sa 是关键，它能让你不用切换 kubeconfig 就能测试身份权限。如果 can-i 返回 no，不是命令写错，而是角色名称或绑定关系配错了，先 kubectl get rolebinding -n cka-lab 看绑定对象。

NetworkPolicy 的最小复现比较适合用两个带标签的 Pod 对比。先启动测试环境，再 apply 一条默认拒绝策略，最后用 wget 验证连通性：

kubectl run frontend -n cka-lab --image=nginx --labels=app=frontend kubectl run backend -n cka-lab --image=nginx --labels=app=backend kubectl expose pod frontend -n cka-lab --port=80 kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: cka-lab spec: podSelector: {} policyTypes: - Ingress EOF kubectl exec -n cka-lab backend -- wget -T 2 -O- http://frontend.cka-lab.svc.cluster.local

podSelector 写空对象 {} 代表选择命名空间内全部 Pod；policyTypes 只写 Ingress，表示只为入站流量生效，Egress 不受影响。wget 后面如果输出 timeout 或 Connection timed out，说明默认拒绝生效；如果还能拿到 HTML，说明 CNI 插件没有正确支持 NetworkPolicy，或者策略 apply 到了错误的命名空间。用 kubectl get netpol -A 核对策略所在命名空间是最快的排查方式。

etcd 备份的最小复现稍微特殊，它只在控制面节点上执行。练习时先确认证书路径，再读取 etcd 静态 Pod 的启动参数：

export ETCDCTL_API=3 etcdctl --endpoints=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 \ snapshot save /tmp/etcd-snapshot.db

endpoints 不一定固定是 127.0.0.1:2379，要以 etcd 静态 Pod 里的启动参数为准。用 kubectl -n kube-system get pods | grep etcd 拿到实际 Pod 名，再 -o yaml 查看容器启动命令里的 --listen-client-urls 和证书路径。生产环境不要省略证书参数，否则 etcdctl 会报证书验证失败，执行完还看不到报错很容易误判为成功。备份完后必须检查文件大小，ls -lh /tmp/etcd-snapshot.db 小于 100KB 基本说明备份失败。

注意：备份文件的大小是第一个校验指标，小于常规大小的文件不能用于还原。别等到 restore 时才追悔。

3.3 用 Checklist 验证自己是否真的会了

练完一个类型，不要急着进下一题。用下面的表格做一次自检，检查点全部通过再换题型：

这张表本质上把“我觉得我会了”变成“命令输出证明我会了”。考试环境里没有人在旁边帮你判断，唯一的裁判就是命令的输出。

4. CKA 1.29 备考避坑：五条血泪经验

我备考时最大的开销不在背题，在踩坑。下面五条都是我在 1.29 集群上真实翻过车的点，每一条按“现象、原因、解决”的结构展开。考前两周把这五条过一遍，比临时背十道新题管用。

4.1 现象：etcd 备份命令执行成功，文件却只有几百字节

原因：没有设置 ETCDCTL_API=3，或者 endpoints 指向了并不存在的地址。etcdctl 在部分环境里默认走 v2 协议，命令不会报错，但备份结果基本是空的；endpoints 写错时，有些构建版本会直接连到空集群，文件同样很小。 解决：执行前先 export ETCDCTL_API=3，然后按 3.2 的方式从 etcd 静态 Pod 的 yaml 里复制真实的 endpoints、ca.crt、server.crt、server.key 路径。备份完用 etcdctl snapshot status /tmp/etcd-snapshot.db 校验，看到 revision 不为 0 才算成功。

4.2 现象：kubectl delete 掉 kube-apiserver Pod 后，它又自动出现了

原因：控制面组件是静态 Pod，kubelet 会持续监控 /etc/kubernetes/manifests 目录并保证里面的 Pod 存活。用 kubectl delete 更像是“给一个永远不会退出的进程打招呼”，配置也没有真正改变。 解决：要改的是 manifests 目录里的 yaml 文件。比如把 etcd 数据目录移到新位置，就要修改 etcd.yaml 里的 hostPath 和 volume，改完后 kubelet 检测到文件变动会自动重建静态 Pod。想临时停止某个控制面组件，把对应 yaml 文件移出目录即可。

4.3 现象：NetworkPolicy 明明 apply 了，两个 Pod 之间还是能通信

原因：最常见的是策略选择器没写对。podSelector: {} 表示全部 Pod，但如果你写成 matchLabels: app: frontend，而实际 Pod 的标签是 run: frontend，策略就不会匹配任何源或目的；另一个常见原因是策略被 apply 到了默认的 default 命名空间，而两个 Pod 在 cka-lab 里。 解决：用 kubectl get pods --show-labels -n cka-lab 复制准确的标签，再用 kubectl get pods -l app=frontend -n cka-lab 核对匹配到的 Pod 数量，同时用 kubectl describe netpol deny-all -n cka-lab 看策略本身的选择器，两相对照。数量为 0 时，策略等于白写，先改标签再谈连通性。

4.4 现象：PVC 一直 Pending，describe 里提示 storageclass 不存在

原因：PV 和 PVC 靠 storageClassName 绑定，考试环境里提供的 StorageClass 名字往往不是标准的 standard，而是带有集群特性的名字。手写 PVC 时把大小写或前缀写错，PV 和 PVC 就永远对不上。 解决：先 kubectl get storageclass 查看准确的类名，复制到 PVC 的 spec.storageClassName 里。如果题目要求的是静态供给，还要检查 PV 的 capacity 和 accessModes 是否与 PVC 匹配，这两个字段不一致也会 Pending。

4.5 现象：题目要求 deny，你按 allow 写完了，自检时还觉得没问题

原因：CKA 题目是英文题干，not、prevent、deny 这类否定词经常藏在长句子里，刷中文题库刷习惯了，看到 create NetworkPolicy 就默认写一条放行规则，把题面看漏了。 解决：考前一周开始，每次练习先把题面复制到记事本，用笔圈出“允许、拒绝、只允许”三个语义词，再动手。考场里同样先圈再敲，这条习惯花不了两分钟，一次失误能省下十几分钟的翻案时间。

这五条不是并列关系，而是层层递进：第一条和第二条是环境层面的坑，命令和组件行为不对；第三条和第四条是配置层面的坑，选择器和存储类写错；第五条是审题层面的坑，语义看反。备考时我建议按这个顺序排查：环境先跑通，配置再匹配，最后才是题面理解。如果你练题时也遇到同样的报错，先别急着改命令，停下来跑一遍 kubectl describe，让事件信息帮你定位，这比重新 apply 五次有效得多。

5. 考前两周的收尾打法：快练序列与考场排查顺序

考前两周我的原则是不再追求题量，拼的是稳定复现。给自己定了一套每天早上的快练序列：etcd 备份 5 分钟、drain/uncordon 5 分钟、RBAC 5 分钟、NetworkPolicy 5 分钟。这个顺序故意把长命令放在前面，短命令放后面。长命令尤其容易手生，需要每天过一遍肌肉记忆；短命令靠理解，隔天练习也能保持手感。

5.1 每天早晨 20 分钟快练序列

快练时不要重新搭环境，直接用 3.1 的 Kind 集群。每练完一个类型就把上一题留的资源清理干净，保证下一题从初始状态开始。我的固定清理命令是：

kubectl delete ns cka-lab kubectl delete clusterrole pod-reader kubectl delete clusterrolebinding pod-reader-bind

清理后可以用 kubectl get netpol -A 和 kubectl get rolebinding -n cka-lab 两个命令确认环境还原，如果还有残留，先 delete 再继续。这套流程的意义是模拟考场里每道题之间的环境隔离，避免上一题的资源污染下一题的结果。两周下来，每个类型被完整跑了十四遍，考场里即使紧张，手也不会停。

5.2 考场上的四步排查顺序

进考场后，我一般按四步处理一道题：先读题圈语义，再 kubectl get 看现状，然后用 kubectl describe 查细节，最后才开始写命令。有一次我在 NetworkPolicy 题里把标签选择器写错，连续 apply 了五遍都没效果，后来 kubectl describe netpol 看到选择器对不上，回头对照标签立刻改通。那段经历让我养成了一个习惯：任何“改了没反应”的情况，先 describe 再猜。

另外，命令执行失败时不要急着删除重写，先看报错的最后一行。kubectl 的报错信息已经点名了九成的问题：找不到命名空间、资源名拼写错误、证书不匹配，都会直接写出来。真正需要人工花时间排查的，是那些“命令成功但结果不对”的情况，比如备份文件过小、PVC 卡 Pending。处理完一套若还有时间，就按题面关键词再检查对应资源一次，重点看有没有多建、少建、名字写错。希望帮到你。

本文还有配套的精品资源，点击获取