简介：这是一份针对Kubernetes Certified Kubernetes Administrator（CKA）认证1.29版本的完整考试题库与备考指南，主要面向已掌握K8s基础、计划冲刺CKA认证的运维、开发及架构师。文档系统梳理了RBAC权限控制、Deployment扩容、NetworkPolicy配置、Service与Ingress创建、Pod调度、节点维护、PV/PVC使用、日志管理等核心考点，并提供模拟环境搭建方法、命令参考与解题套路。资源以单一PDF文件形式打包，大小约6.78MB，便于离线阅读和反复查阅。内容还特别强调了新考试平台（PSI）的操作限制、常见卡顿问题、登录账号与集群切换等注意事项，并给出不同考试环境下题目参数变化的应对思路，帮助考生减少临场失误。目前该资源已有1058人学习，适合在备考阶段配合实操反复演练，提升解题速度与实战信心。
1. Kubernetes CKA 1.29 题库这套资源，第一次拿到手我先看的是模拟环境说明，而不是题目——经历过旧版考试的人都懂，挂掉的人大多不是不会做题，而是死在“环境和节奏”上。这套题库的价值不是押中几个命令，而是把考试现场还原得很具体：在 node01 上用 candidate 账号操作、通过 kubectl config use-context 切换集群、kubectl 自动补全可用、PSI 远程桌面里的火狐浏览器直接访问官方文档。选题覆盖 RBAC、Deployment 扩容、NetworkPolicy、Service、Ingress、CPU 查询、节点调度这些高频考点，适合已有 Kubernetes 基础、想集中刷题拿证的运维和开发。多说一句：CKA 考的是操作速度，不是源码，底层原理可以看《深入理解 kubernetes 源码》，但先把手速练起来。
2. 模拟环境与考试环境：先把做题的“姿势”对齐
2.1 账号、节点与快照：三台虚拟机怎么用
模拟环境有三台虚拟机：node01（11.0.1.112）、master01、node02，统一账号 candidate，密码 123。这个账号下可以免密 ssh 到 master01 和 node02，也可以直接 sudo -i 切换 root。但有个细节很容易被忽略：真实考试时不是让你在 master 上操作，而是在 node-1 上用 candidate 或 cli 账号做题。所以模拟环境下也别养成“先 ssh master01 再操作”的习惯，直接默认自己在 node01 上就行。
快照还原后开机会看到一堆 ContainerCreating，不用慌。题库里明确提醒：开机后等 5 分钟，先 kubectl get pod -A 确认所有 pod 都是 Running 再开始练习。我一般会顺带看一眼 kube-system 里的组件，因为如果快照是开机状态下打的，而不是关机状态下打的，还原后 kubelet 和 etcd 状态容易错乱，后面几道题全受影响。正确做法是每次还原到关机状态的初始化快照，等 5 分钟再做。
2.2 集群上下文与 kubectl 自动补全
考试时每道题前面都会给一行红色提示：在哪个账号、哪台机器上、切换到哪个集群。比如第 3 题的 Context 是 hk8s，其它题多半是 k8s，务必先执行再做题：
kubectl config use-context k8s kubectl config use-context hk8s这两条命令是切换 kubeconfig 里的当前上下文。真实 CKA 考试有多套集群，不同题目分布在不同集群里，但都让你在 node-1 上操作。不切换的后果是：命令执行成功，但资源落在错误的集群里，题目等于白做。模拟环境没有配置多套集群，所以执行会报错，但题库作者建议每道题都敲一遍，把切换动作固化进肌肉记忆。
另外，模拟环境和新的 PSI 考试环境都默认配好了 kubectl 自动补全。tab 键可以直接补出资源名、参数名，这是省时间的大杀器。如果你在自己电脑上练习时没有自动补全，先执行 source <(kubectl completion bash) 再继续。
2.3 YAML 缩进与编辑习惯：翻车往往从空格开始
题库里专门留了一节讲 YAML 格式，小白确实该看。简单说，YAML 的层级靠空格区分，同一个字段下的子项缩进必须一致，冒号后面必须跟空格。用 vim 编辑 YAML 时，我习惯先 :set paste 再粘贴，避免自动缩进把空格弄乱。还有一个官方文档没写清楚、但对考试很有用的行为：kubectl edit 时如果改错了，第一次 :wq 会报错，第二次 :wq 会回滚并退出，相当于给了一次后悔药，不用慌。
3. RBAC 与扩容：两道性价比最高的“送分题”
3.1 创建 ClusterRole 并绑定到指定 ServiceAccount
第 1 题考 RBAC，题干要求：创建 ClusterRole deployment-clusterrole，只允许创建 Deployment、StatefulSet、DaemonSet；在 app-team1 里创建 ServiceAccount cicd-token；把 ClusterRole 绑定到该 ServiceAccount，且只作用于 app-team1 namespace。
kubectl create clusterrole deployment-clusterrole \ --verb=create \ --resource=deployments,statefulsets,daemonsets kubectl -n app-team1 create serviceaccount cicd-token kubectl -n app-team1 create rolebinding cicd-token-rolebinding \ --clusterrole=deployment-clusterrole \ --serviceaccount=app-team1:cicd-token第一段创建 ClusterRole，--verb=create 表示授予的权限是“创建”，--resource 用逗号分隔多个资源。第三段是这道题最容易错的地方：题目写了“限于 namespace app-team1 中”，所以必须用 rolebinding，而不是 clusterrolebinding。如果题干没有“限于 namespace”这类限定词，才用 kubectl create clusterrolebinding。rolebinding 的名字 cicd-token-rolebinding 是自定义的，题目没规定就不用纠结；但 --serviceaccount 的格式必须是 namespace:serviceaccount，即使前面已经指定了 -n app-team1，这里也要写全。
3.2 用 auth can-i 验证 RBAC 是否真的生效
检查 RBAC 最稳的方式不是 describe，而是模拟用户视角的 auth can-i：
kubectl auth can-i create deployment \ --as system:serviceaccount:app-team1:cicd-token -n app-team1 kubectl auth can-i create deployment \ --as system:serviceaccount:app-team1:cicd-token第一条返回 yes，表示在 app-team1 内能创建 deployment；第二条不指定 namespace 返回 no，恰好证明权限被 namespace 限制住了。这套验证逻辑考试时不要求写，但练习时强烈建议跑一遍，能帮你在十分钟内理解 RBAC 的“范围”到底是怎么工作的。注意 --as 后面的主体必须是 serviceaccount 的完整格式 system:serviceaccount: : ，少一段都会报错。
3.3 deployment 扩容到指定副本数
第 2 题就一句话：把 deployment presentation 扩展到 4 个 pod。
kubectl get deployments presentation kubectl scale deployment presentation --replicas=4 kubectl get deployments presentation kubectl get pod -l app=presentation先 get 看一下当前副本数，再 scale。最后一个 get pod -l app=presentation 的作用是核对 4/4，-l 标签过滤很重要，不写会把无关 pod 也列出来，产生误判。如果显示 ContainerCreating 且一直不转 Running，九成是快照还原到了开机状态，回到 2.1 节的处理方式。这道题没有隐藏参数，value 值就是目标副本数，唯一要练的是在卡顿环境下也能快速敲完。
4. NetworkPolicy、Service 与 Ingress：网络三连问
4.1 NetworkPolicy：谁访问谁，防火墙就放在谁身上
第 3 题是被“双重否定”句式坑得最惨的一题。题干原话：允许 namespace echo 中的 Pod 连接到 namespace my-app 中的 Pod 的 9000 端口；不允许访问没有监听 9000 的 Pod；不允许非 echo 命名空间的 Pod 来访问。拆开看就是：echo 是访问者，my-app 是被访问者。A 访问 B，就应该在 B 上放一个 ingress 防火墙，允许 A 进来，所以 NetworkPolicy 要建在 my-app namespace 里。
kubectl get ns echo --show-labels kubectl label ns echo project=echo先看 echo 是否已有标签，没有就手动打一个 project=echo，policy 里用它做 namespaceSelector 的匹配。模拟环境里其实有 kubernetes.io/metadata.name=echo 这个内置标签，但考试环境未必有，所以最好自己打。然后写 yaml：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-port-from-namespace namespace: my-app spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: project: echo ports: - protocol: TCP port: 9000两个必背细节：spec.podSelector: {} 表示选择 my-app 下所有 pod，这一行不能省略；ingress 的 from 列表里只能有 namespaceSelector，不能顺手加 podSelector: {}，否则 my-app 里的 pod 也能互相访问 9000 端口，最后一句“不允许非来自 echo 的访问”就被破了。metadata.namespace 写的是被访问者的命名空间，matchLabels 匹配的是访问者的 label，这两个方向最容易写反。每次做题我都是先在草稿纸上标注“谁访问谁”再动笔。
4.2 Service 暴露：先补 deployment 端口，再 expose
第 4 题分两步：在 deployment front-end 里添加名为 http 的端口规范，暴露容器 nginx 的 80/tcp；再创建 NodePort 类型 service front-end-svc。
kubectl get deployment front-end -o wide kubectl edit deployment front-endget 拿到 deployment 的 selector label，模拟环境是 app=front-end，考试以实际为准。edit 时在 containers 段找到 name: nginx 的位置，加入：
ports: - name: http containerPort: 80 protocol: TCP端口名 http 会被后面创建的 service 引用。保存后执行：
kubectl expose deployment front-end \ --type=NodePort \ --port=80 \ --target-port=80 \ --name=front-end-svc--type=NodePort 是题目要求；--port 是 service 对外暴露的端口；--target-port 是 pod 容器端口。创建完必须回头检查：
kubectl get svc front-end-svc -o wide kubectl get deployment front-end -o wide如果 svc 的 SELECTOR 是 ，或者跟 deployment 的 label 对不上，就得手动 kubectl edit svc front-end-svc，在 ports 下面补 selector: app: front-end。考试环境里 svc 的 selector 可能为空，这是题库里特别提醒过的坑——很多人只记得 expose，忘了核对 selector，service 建了跟没建一样。
4.3 Ingress：路径转发到后端 Service
第 5 题创建名为 ping 的 Ingress，namespace 是 ing-internal，把 http 路径 /hello 转发到 service hello 的 5678 端口。创建前先确认 ingressClass 的名字：
kubectl get ingressclass模拟环境答案是 nginx，考试以实际输出为准，写 yaml 时 spec.ingressClassName 必须对应这个值。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ping namespace: ing-internal annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx rules: - http: paths: - path: /hello pathType: Prefix backend: service: name: hello port: number: 5678创建后 apply：
kubectl apply -f ingress.yaml kubectl -n ing-internal get ingressIngress 创建后不会立刻有 IP，通常要等约 3 分钟。拿到 ADDRESS 后，用 curl -kL <INTERNAL_IP>/hello 验证，能返回 hello 文本就算成功。这里 rewrite-target: / 注解是必要的，否则路径会带着 /hello 转给后端。官方文档给的 yaml 示例里不包含这个注解，考试时如果 curl 不通，先检查注解，再看 ingressClassName 是不是环境里真实存在的类名。更省事的命令式写法是 kubectl create ingress ping --rule=/hello=hello:5678 --class=nginx --annotation=nginx.ingress.kubernetes.io/rewrite-target=/ -n ing-internal，但模拟练习建议手写一遍 yaml，理解结构比记住命令更重要。
这三道题连在一起做一遍，能建立完整的流量路径直觉：NetworkPolicy 控制 Pod 间访问，Service 暴露端口，Ingress 做七层路径转发。分层想清楚，题干再怎么换名字都不会乱。
5. 避坑与排查：CKA 练习里最值得背的“血泪经验”
5.1 kubectl top 没数据：先确认 metrics-server 是否健康
现象：执行 kubectl top pod -l name=cpu-loader --sort-by=cpu -A 报错，提示 metrics 不可用或 no resources found。
原因：kubectl top 依赖 metrics-server 聚合的指标数据。快照还原后 metrics-server 可能还没完全启动，或者刚开机还没采集到数据。
解决：先 kubectl get pod -n kube-system 看 metrics-server 是否 Running，等 2-3 分钟再重试。考试环境这套指标一般可用，但练习时建议用 --sort-by=cpu 排序后，把第一名的 pod 名称写入 /opt/KUTR000401/KUTR00401.txt，再用 cat 核对内容，这道题的流程就完整闭环了。
5.2 kubectl edit 改错：第二次 :wq 是后悔药
现象：kubectl edit deployment front-end 里加了端口配置，保存时提示错误，或者保存成功后 pod 没有按预期暴露端口。
原因：YAML 缩进错了。比如 ports 少缩进两格，字段被解析成别的层级；或者字段名写错，containerPort 写成 containerport。
解决：vim 第一次 :wq 报错说明有语法问题，不要尝试强制保存；第二次 :wq 会自动回滚到修改前的内容。所以每次 edit 完先 :wq，如果报错再 :wq 一次确认回滚，然后重新进入编辑。想更保险，就先用 kubectl get deployment front-end -o yaml 导出一份备份再改。
5.3 service selector 为 <none>：expose 之后必须对照 deployment
现象：kubectl get svc -o wide 看到 front-end-svc 的 SELECTOR 是 <none>，curl CLUSTER-IP 不通。
原因：kubectl expose 在部分环境下不会自动继承 deployment 的 label，导致 service 选不中任何 pod。
解决：kubectl edit svc front-end-svc，在 spec.ports 下面加 selector 字段，内容与 deployment 的 selector 完全一致，比如 selector: app: front-end。注意 YAML 里是冒号，不是等号。改完再看 get svc -o wide，SELECTOR 列显示 app=front-end 才算正常。
5.4 curl 不通 NodePort：先看你在哪台机器上 curl
现象：第 4 题创建 NodePort 后，在 node01 上 curl CLUSTER-IP:80 一直没反应，curl 节点 IP:NodePort 也超时。
原因：CLUSTER-IP 是虚拟 IP，在部分网络插件下从非 Pod 网络的节点直接 curl 不通；NodePort 也受防火墙或安全组影响。
解决：题库里给了明确建议——本地只要 kubectl get svc -o wide 看到 CLUSTER-IP 分配成功即可，不必强求 curl 通。要 curl 验证就 ssh 到工作节点（比如 ssh node02）再 curl。考试时别在这道题上耗时间，看到 CLUSTER-IP 存在就直接下一题。
5.5 切换集群命令在模拟环境报错，别慌
现象：练习第一道题，执行 kubectl config use-context k8s 返回 error: no context exists with the name "k8s"。
原因：模拟环境只有一套集群，没有配置多上下文；考试环境才会暴露多套集群，这套命令是考试时必须执行的。
解决：模拟环境报错是预期行为，继续做题即可。但题库作者特别强调每道题都要敲一遍切换命令，目的不是执行成功，而是把“先切换再做题”形成固定动作，避免考试时跳步。把这条当肌肉记忆练，比背任何命令都值。
6. 把“要查官网”变成“秒杀”：定位文档与自检习惯
6.1 官方文档的固定路径
PSI 考试平台的浏览器是 Ubuntu 桌面里的火狐，默认打开 K8S 官方文档。英文不好可以点右上角切换到中文。每道题对应的参考章节基本固定在几条路径里：RBAC 查 roles 和 rolebindings；NetworkPolicy 查 Concepts → Services, Load Balancing, and Networking → Network Policies；Ingress 查同一棵树的 Ingress；调度查 Tasks → Configure Pods and Containers → Assign Pods to Nodes。不建议用题内嵌的参考链接，跳转太深，不如直接从主页 Documentation 进。注意考试环境里官网搜索结果排序和本地不一样，别依赖搜索，按目录找更稳。PSI 平台不允许外接第二块屏幕，也不允许访问自己的浏览器书签，所有资料都得靠记忆和这个火狐窗口。
6.2 用 auth can-i 做 RBAC 检查
第 3 章提过的 auth can-i 是少数能模拟“另一个身份”的检查命令。考试时看不到题目里 pod 的实际访问结果，但你能通过它验证权限是否被限制在预期 namespace 内。整个检查不会超过 20 秒，比 describe rolebinding 判断得更直接。
6.3 用 -o wide 快速核对关联关系
做 Service、Ingress 这类题，最后一步我会用 kubectl get -o wide 一把梭：svc 看 SELECTOR 和 CLUSTER-IP，deployment 看 READY 和 SELECTOR，ingress 看 ADDRESS。网络题全部可以用这两个命令收尾，不用进 pod 验证。这也是把单题时间压进 15 分钟的关键习惯。
6.4 考前练习标尺：十道里至少八道不查官网
题库前言说得很实在：新考试平台访问官方文档很卡，多数人反馈延迟高，部分人因此没做完题。我的校练标尺是：随机挑一套题，从切换集群到做完检查，十道题里至少八道不打开浏览器，能做到就说明这题库的模拟基本过关。CKA 的通过策略不是“会做”，而是“在远程桌面卡顿的环境里，身体比脑子先行动”。我备考那阵每次练习都强制自己先敲 use-context 再做下一题；坚持两周后，进考场基本是肌肉记忆在答题。从那以后我每次给新同事建议 CKA 冲刺，都会要求他们先做一遍“不查官网”模拟，能做完就是合格的选手状态。希望帮到你。
本文还有配套的精品资源，点击获取
