简介这是一份针对Kubernetes Certified Kubernetes AdministratorCKA认证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 账号、节点与快照三台虚拟机怎么用模拟环境有三台虚拟机node0111.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 \ --verbcreate \ --resourcedeployments,statefulsets,daemonsets kubectl -n app-team1 create serviceaccount cicd-token kubectl -n app-team1 create rolebinding cicd-token-rolebinding \ --clusterroledeployment-clusterrole \ --serviceaccountapp-team1:cicd-token第一段创建 ClusterRole--verbcreate 表示授予的权限是“创建”--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-ikubectl 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 --replicas4 kubectl get deployments presentation kubectl get pod -l apppresentation先 get 看一下当前副本数再 scale。最后一个 get pod -l apppresentation 的作用是核对 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 projectecho先看 echo 是否已有标签没有就手动打一个 projectechopolicy 里用它做 namespaceSelector 的匹配。模拟环境里其实有 kubernetes.io/metadata.nameecho 这个内置标签但考试环境未必有所以最好自己打。然后写 yamlapiVersion: 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模拟环境是 appfront-end考试以实际为准。edit 时在 containers 段找到 name: nginx 的位置加入ports: - name: http containerPort: 80 protocol: TCP端口名 http 会被后面创建的 service 引用。保存后执行kubectl expose deployment front-end \ --typeNodePort \ --port80 \ --target-port80 \ --namefront-end-svc--typeNodePort 是题目要求--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忘了核对 selectorservice 建了跟没建一样。4.3 Ingress路径转发到后端 Service第 5 题创建名为 ping 的 Ingressnamespace 是 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创建后 applykubectl 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/hellohello:5678 --classnginx --annotationnginx.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 namecpu-loader --sort-bycpu -A 报错提示 metrics 不可用或 no resources found。原因kubectl top 依赖 metrics-server 聚合的指标数据。快照还原后 metrics-server 可能还没完全启动或者刚开机还没采集到数据。解决先 kubectl get pod -n kube-system 看 metrics-server 是否 Running等 2-3 分钟再重试。考试环境这套指标一般可用但练习时建议用 --sort-bycpu 排序后把第一名的 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 为 noneexpose 之后必须对照 deployment现象kubectl get svc -o wide 看到 front-end-svc 的 SELECTOR 是 nonecurl 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 wideSELECTOR 列显示 appfront-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 和 rolebindingsNetworkPolicy 查 Concepts → Services, Load Balancing, and Networking → Network PoliciesIngress 查同一棵树的 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-IPdeployment 看 READY 和 SELECTORingress 看 ADDRESS。网络题全部可以用这两个命令收尾不用进 pod 验证。这也是把单题时间压进 15 分钟的关键习惯。6.4 考前练习标尺十道里至少八道不查官网题库前言说得很实在新考试平台访问官方文档很卡多数人反馈延迟高部分人因此没做完题。我的校练标尺是随机挑一套题从切换集群到做完检查十道题里至少八道不打开浏览器能做到就说明这题库的模拟基本过关。CKA 的通过策略不是“会做”而是“在远程桌面卡顿的环境里身体比脑子先行动”。我备考那阵每次练习都强制自己先敲 use-context 再做下一题坚持两周后进考场基本是肌肉记忆在答题。从那以后我每次给新同事建议 CKA 冲刺都会要求他们先做一遍“不查官网”模拟能做完就是合格的选手状态。希望帮到你。本文还有配套的精品资源点击获取