一、CKA 考试到底是什么值不值得考CKACertified Kubernetes Administrator是云原生领域认可度最高的 Kubernetes 管理员认证之一由云原生计算基金会CNCF联合 Linux 基金会推出。考试全程在线实操不考选择题所有题目都要求在真实集群环境中用 kubectl 或 kubeadm 完成任务比如部署应用、配置网络策略、排查故障、备份恢复 etcd 等。简单说它就是检验你是否真的会“用” Kubernetes而不是会不会背概念。很多人问这个证含金量到底如何。我的看法是CKA 不是“考完就能涨薪”的万能钥匙但它是一块很硬的敲门砖。尤其对于运维工程师、SRE、平台工程师、以及刚转云原生的开发者来说CKA 的备考过程本身就能帮你把 Kubernetes 的核心原理和日常操作彻底捋一遍。就算你已经在生产环境摸爬滚打过考试中的很多场景比如固定时间内的故障排查、集群初始化依然能逼你补齐知识盲区。这篇指南我尽量按“备考规划 知识点拆解 实战技巧 踩坑记录”来写目标是让准备考 CKA 的人少走弯路同时也让不打算考证的人把它当一份 Kubernetes 实操手册来用。文中命令和 YAML 都基于我实际练习过的场景版本以当前主流环境为准。如果你正打算报考或者已经在备考路上这篇内容应该能帮你节省不少时间。二、CKA 考试的核心信息与备考策略2.1 考试形式与报名前必须知道的事CKA 考试时长 2 小时全程线上进行需要摄像头监考。考试环境是一套独立的终端界面左侧是题目列表右侧是操作终端终端里预装了 kubectl、kubeadm、kubelet 等工具但集群需要你自己搭、自己修。考试过程中可以访问官方文档kubernetes.io/docs这一点非常关键等于是开卷考但开卷不代表简单因为时间压力非常大。报名之后你会获得两次考试机会一次正式 一次重考有效期内可以预约时间。重考政策偶尔会有调整建议报名前到官网确认最新条款。另外考试对网络要求比较高需要稳定的国际网络连接这一点在报名前就要评估好别考试中途掉线导致前功尽弃。正式考试前一定要做一次“模拟考试”不是指刷题而是指完整走一遍考场环境测试摄像头、麦克风、网络、终端操作流畅度。2.2 官方考纲五大板块与权重拆解CKA 考纲以当前最新版为准分为五大域每块权重不同直接决定你的备考时间分配。域权重核心考察点集群架构、安装与配置25%kubeadm 初始化集群、kubeconfig 配置、证书管理、etcd 备份与恢复工作负载15%Deployment、StatefulSet、DaemonSet、Job/CronJob、Pod 调度服务与网络20%Service、Ingress、NetworkPolicy、DNS、ServiceAccount存储10%PV/PVC、StorageClass、持久化卷配置故障排查30%节点异常、Pod 异常、网络故障、etcd 故障、控制平面故障权重只是参考但很有指导意义。故障排查占比最大这符合真实运维场景——出问题了你能不能快速定位。很多考生在集群安装和故障排查上耗时最多因为这两块最容易出意外状况比如网络插件装不上、节点 NotReady、etcd 备份失败等。所以备考初期就应该把重心放在这两块不要只盯着 Deployment 怎么写。2.3 备考时间规划3 个月 vs 2 周冲刺如果你有 3 个月建议这样安排前两个月系统学习每天保证 1 到 1.5 小时周末可以加码到 3 到 4 小时。学习顺序从基础概念开始然后手动搭建一次集群再逐个吃透工作负载、网络、存储、排障。第三个月进入冲刺阶段每天至少刷 1 到 2 套模拟题考前一周只做一件事反复练习高频场景把“看题 → 敲命令 → 验证结果”的流程练到肌肉记忆。如果你只有 2 周也不是完全没可能但需要每天 3 到 4 小时高强度投入。此时不能再按部就班学概念了建议直接刷高频场景遇到不会的知识点再回头查文档、看示例。这个策略比较激进适合已经有 Kubernetes 使用经验的人纯新手不建议这么干。我的个人建议是无论时间多少都要至少完整走一遍 kubeadm 搭建集群的过程。哪怕你平时都在用托管的 Kubernetes 服务这一步能帮你理解控制平面、etcd、kubelet 之间的关系对考试和实际工作都有不可替代的价值。三、核心知识点逐项拆解附实操命令3.1 集群安装与配置kubeadm 是绝对主角CKA 考试中kubeadm 是你初始化集群的主要工具。考试环境会预装 kubeadm、kubelet、kubectl但不会帮你把集群搭好你需要自己在主节点上初始化并把工作节点加入进来。最经典的主节点初始化命令kubeadm init \ --pod-network-cidr10.244.0.0/16 \ --apiserver-advertise-address主节点IP初始化完成后按提示执行以下命令配置 kubeconfigmkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config然后安装 Pod 网络插件。以 Flannel 为例kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml工作节点加入命令可以在初始化结果末尾找到也可以手动生成kubeadm token create --print-join-command这里面最容易出坑的是 Pod 网段 CIDR。Flannel 默认使用10.244.0.0/16Calico 默认使用192.168.0.0/16如果 CIDR 配置不一致节点之间网络不通kubectl get nodes会一直看到 NotReady。所以初始化之前先确定要装哪个网络插件再决定 CIDR。还有一个常见问题是初始化失败后想重新初始化必须先执行kubeadm reset否则会报“port already in use”之类的错误。重置完之后再清空旧的 CNI 配置一般在/etc/cni/net.d目录否则就算重新初始化成功网络插件也可能不生效。3.2 证书与 kubeconfig上下文切换是基本功考试中每一道题都会说明“你必须在某个 context 下操作”比如kubectl config use-context k8s-cluster1。如果不切换上下文你在第二个集群上做的操作会被记到第一个集群那就等于白做。常用命令# 查看当前上下文 kubectl config current-context # 查看所有上下文 kubectl config get-contexts # 切换上下文 kubectl config use-context 上下文名除了切换考试还可能让你为某个用户创建新的 context。这时候需要用到证书文件和 kubeconfig 的结构kubectl config set-cluster 集群名 --serverAPI Server地址 --certificate-authorityCA文件 kubectl config set-credentials 用户名 --client-certificate证书 --client-key私钥 kubectl config set-context 上下文名 --cluster集群名 --user用户名 kubectl config use-context 上下文名注意set-credentials和set-cluster只是修改 kubeconfig 文件里的条目不会验证证书是否有效所以生成后最好用kubectl --kubeconfig文件 auth whoami来验证身份是否可用。这一步在考试里虽然不常考但真实排障时非常有用。3.3 工作负载Deployment、StatefulSet、DaemonSet、Job工作负载这块占 15%看似不多但几乎每场考试都会考。最核心的是 Deployment它的滚动更新、回滚、扩缩容、暂停/恢复必须非常熟练。常用命令# 扩缩容 kubectl scale deployment 名称 --replicas5 # 滚动更新镜像 kubectl set image deployment/名称 容器名新镜像名:标签 # 查看滚动更新状态 kubectl rollout status deployment/名称 # 回滚到上一个版本 kubectl rollout undo deployment/名称 # 暂停/恢复滚动更新 kubectl rollout pause deployment/名称 kubectl rollout resume deployment/名称StatefulSet 主要考稳定的网络标识和持久化存储。创建时要注意serviceName必须指向一个无头 ServiceclusterIP: NonevolumeClaimTemplates定义了每个 Pod 独占的 PVC。如果你发现 StatefulSet 的 Pod 一直不动先检查无头 Service 是不是建了再检查 PVC 是否绑定成功。DaemonSet 的考点通常结合节点选择器nodeSelector和污点容忍tolerations。例如要求只在带有node-typeworker标签的节点上运行或者让 DaemonSet 忽略某个节点的污点。这类题需要你同时掌握kubectl label和 DaemonSet 的 YAML 字段。Job 和 CronJob 相对简单但常考一个细节restartPolicy必须设置为OnFailure或Never不能是Always否则 Job 创建时会报错。CronJob 的调度语法就是 cron 表达式比如*/5 * * * *表示每 5 分钟一次注意和系统 cron 的区别——Kubernetes 的 CronJob 用的是标准 5 段式但分钟在前这个别搞混了。3.4 服务与网络Service、Ingress、NetworkPolicyService 是服务与网络域的绝对核心考得最多的是三类ClusterIP、NodePort、LoadBalancer。你必须清楚port、targetPort、nodePort的区别port是 Service 的端口targetPort是后端 Pod 的端口nodePort是节点上暴露的端口范围 30000-32767。如果 selector 写错Service 的 Endpoints 就会为空访问自然不通。检查 Service 后端是否就绪的命令kubectl get endpoints service名如果 Endpoints 下面没有 IP说明 selector 没匹配到任何 Pod这是最常踩的坑。Ingress 考察的是 7 层路由规则。当前版本一般用networking.k8s.io/v1这个 API 版本。创建 Ingress 时需要指定ingressClassName如果是 ingress-nginx 等控制器或者使用旧版的kubernetes.io/ingress.class注解。考试中常见的路径匹配有两种Prefix和Exact。Prefix可以匹配子路径Exact必须完全一致这块很容易写错。NetworkPolicy 是丢分高发区。记住一个原则NetworkPolicy 默认拒绝未匹配到的流量所以你在写规则时先想清楚要放行哪些流量再逆向补全规则。一个典型场景是“只允许来自特定标签 Pod 的流量访问数据库”你需要写一个 ingress 规则from 里放podSelector或namespaceSelector。写完规则后用kubectl describe networkpolicy 名称检查一下确认 selectors 是否正确。另外要注意NetworkPolicy 只在支持 CNI 网络策略的插件下生效比如 Calico、CiliumFlannel 默认不支持。3.5 存储PV、PVC、StorageClass 的绑定逻辑存储只占 10%但题目很直接不绕弯子。难点在于理解 PV、PVC、StorageClass 三者之间的绑定关系。PV 是集群层面的存储资源由管理员创建。PVC 是用户申请的存储请求。StorageClass 是动态供给的模板PVC 可以通过storageClassName指定 StorageClass系统会自动创建 PV。手工创建的 PV 要和 PVC 绑定必须满足三个条件storageClassName匹配或者都为空并启用默认 StorageClass、accessModes匹配比如ReadWriteOnce和ReadOnlyMany不能混绑、容量满足要求PV 的容量要大于等于 PVC 请求的容量。考试中如果要你创建一个 PVC然后让 Pod 使用它注意 Pod 的 volumes 部分要写persistentVolumeClaim的claimName而不是直接写 PV 名。很多人在这里踩坑把 PV 名直接写在 Pod 里导致创建失败。3.6 故障排查重头戏中的重头戏故障排查占 30%是决定你能否通过考试的关键。虽然题目场景千奇百怪但底层思路是有套路的。节点 NotReady 的排查顺序kubectl get nodes确认哪个节点异常。kubectl describe node 节点名看 Conditions 和 Events。登录到异常节点检查 kubelet 状态sudo systemctl status kubelet如果没启动看日志找原因。检查容器运行时比如 containerd 是否正常sudo systemctl status containerd。检查网络插件是否就绪比如看 CNI 配置目录是否存在、Pod 是否拉起来。Pod 一直 Pending 的排查重点在kubectl describe pod Pod名的 Events 部分。常见原因节点资源不足CPU/内存不满足 requests、节点有污点且 Pod 没有 toleration、节点亲和性/反亲和性不匹配、PVC 未绑定。如果你的 Pod 一直 Pending 且下面没有事件大概率是调度条件不满足这时候别慌逐一排除。Pod 一直 CrashLoopBackOff 的排查顺序kubectl logs Pod名看应用日志。检查退出码。退出码 137 一般是内存被杀掉OOM退出码 1 或 2 一般是启动命令错误。检查启动探针livenessProbe和就绪探针readinessProbe配置是否合理有时候应用启动慢但探针给的时间很短就会反复重启。Service 无法访问的排查顺序kubectl get svc 名称确认 Service 存在。kubectl get endpoints 名称确认后端 Pod 有 IP。kubectl describe svc 名称看 selector 是否匹配到 Pod。从 Pod 内部访问 Service 的 ClusterIP 看是否通第一步确认 kube-proxy 有没有问题。etcd 备份与恢复也是高频考点。备份命令如下ETCDCTL_API3 etcdctl \ --endpointsetcd端点 \ --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-backup.db恢复时先停止 API Server通常通过移动静态 Pod 清单文件的方式再执行ETCDCTL_API3 etcdctl snapshot restore /tmp/etcd-backup.db \ --data-dir/var/lib/etcd-restore然后把 etcd 的>kubectl run nginx --imagenginx --dry-runclient -o yaml nginx-pod.yaml这样生成出来的 YAML 是 API 官方结构的比手写快得多也少了缩进错误。用kubectl create deployment加--dry-run生成 Deployment 模板再配合kubectl set image或kubectl scale调整。不要从零手写 Deployment太浪费时间。用kubectl explain检查字段含义。比如你不确定 Deployment 里strategy下有哪些字段直接kubectl explain deployment.spec.strategy编辑文件时cat 文件名.yaml EOF这种方式最不容易出错。不要用 vi考试环境里没有 vim 插件键盘操作不熟悉容易把人逼疯。nano 相对友好一点但最简单的还是 EOF 方式一次性把内容写进去。熟练使用kubectl get的-o wide参数可以看到 Pod 所在的节点、IP 等信息这对排查网络问题很有用。学会快速验证做完一道题后用一条命令确认结果比如kubectl get pods -l 标签或kubectl get svc。不要糊弄自己考试里每道题的验证时间只有几秒钟要练到条件反射。4.3 官方文档的高效查法考试允许访问 kubernetes.io/docs但页面很多如果不会查很容易陷入“查文档 5 分钟做题 30 秒”的困境。我的经验是优先用搜索框输入英文关键词比如 “ingress pathType”第一个结果通常就是你要的。另外收藏几个高频页面会有奇效任务Tasks下的 “Run applications” 部分比如 “Scale the StatefulSet”、“Update API objects in place”。概念Concepts下的 “Network Policies”、“Services”。参考Reference下的 “kubectl cheat sheet”这个页面讲了很多常用命令的速查强烈建议考前过一眼。不要试图背下所有 YAML 字段那是低效的。知道“哪个操作查哪个页面”才是考试过关的关键。比如 NetworkPolicy 的写法你不需要记全知道去搜 “networkpolicy” 然后照着示例改就行。五、考场实战中的关键技巧和踩坑经验5.1 时间分配与做题节奏CKA 一共 2 小时通常有 15 到 20 道题。平均每题只有 6 到 8 分钟时间非常紧张。我的策略是先快速浏览所有题目遇到不会的或者看一眼没思路的直接跳过先把会做的、分值高且把握大的做完。考试界面是按题计分的所以先把稳拿的分拿满最后再回头啃硬骨头。有一个容易忽略的点每道题里可能包含多个小任务。比如“创建一个 Deployment并把它暴露为一个 NodePort Service”如果你只完成了 Deployment没建 Service那这道题只能拿一半分。所以做题时要仔细读题干按步骤拆解做完一个 check 一个用 kubectl get 验证确保每个子任务都完成。5.2 上下文切换是第一优先级所有题目都会在题干里写明“你必须使用 k8s-cluster1 这个 context”。这句话不是废话是操作前提。如果你懒得多敲一条kubectl config use-context命令那么你后续的 kubectl 命令都作用在错误的集群上结果自然是 0 分。我自己的习惯是每道题开始前先看一眼题目的 context 要求然后在终端执行一次 use-context。做完题之后如果这道题涉及多个集群再做下一题之前再切换一次。这看起来是重复劳动但能避免最冤枉的失分。另外有些题目要求你用kubectl config view --minify查看当前上下文信息或者创建一个新的 kubeconfig 文件这类题切不可偷懒直接修改默认 kubeconfig因为后面的题目可能依赖默认配置。5.3 不要忽略集群节点的具体情况考试中你可能会遇到某个节点处于 NotReady 状态但题目只要求你“修复集群”并不告诉你具体原因。这时候你要学会“主动探查”先kubectl get nodes再kubectl describe node然后登录对应节点检查 kubelet、容器运行时、网络插件。我踩过的坑是一开始遇到节点 NotReady我以为只要重启 kubelet 就行结果发现是网络插件没装。重启之后节点依然 NotReady直到我安装了 flannel 或 calico才恢复正常。所以看到 NotReady第一个念头不是“重启”而是“看看 kubelet 和网络插件有没有就绪”。5.4 验证结果的常用命令速查做题不是写完 YAML 就结束了一定要验证。下面这几条命令几乎每场考试都能用上# 查看 Pod 状态 kubectl get pods -o wide # 查看 Pod 详细信息 kubectl describe pod 名称 # 查看 Pod 日志 kubectl logs 名称 # 查看 Service Endpoints kubectl get endpoints Service名 # 查看节点状态 kubectl get nodes # 查看集群事件 kubectl get events --sort-by.lastTimestamp小技巧kubectl get events用来排查“为什么这个 Pod 没创建出来”非常有效因为 Events 会列出调度失败、拉镜像失败、探针失败等具体原因。如果你在 describe 里看不到想找的信息就去 events 里翻。5.5 避免在 YAML 的缩进和引号上浪费时间YAML 对缩进极其敏感一个空格错位就可能导致整个文件解析失败。考试时最容易因为缩进问题浪费 3 到 5 分钟所以推荐用kubectl run/create ... --dry-runclient -o yaml生成初始模板然后只改关键字段不要大幅手写。如果你的 YAML 写好了但 apply 失败先别慌用kubectl apply --dry-runclient -f file.yaml做一次本地校验。它会告诉你语法错误还是字段错误避免你把错误配置提交到集群里再改。还有一个小套路如果你不确定某个字段的写法用kubectl explain看定义不要靠猜。举例来说某个资源中strategy的 type 是 RollingUpdate 还是 Recreate看一眼 explain 就知道了完全没必要背。六、常见问题与避坑清单6.1 高频问题救急问题排查思路答案 / 规避方式节点 NotReadykubelet 起不来看 kubelet 日志检查容器运行时确认 containerd 或 docker 正常再启动 kubeletPod 一直 Pending看 describe 的 Events检查节点污点、资源、PV/PVCPod 反复重启看日志和退出码调整探针超时时间或检查启动命令Service 不通按顺序查 Service → Endpoints → Pod先确认 selector 匹配再查 kube-proxyetcd 备份失败看证书、端点、环境变量确认 ETCDCTL_API3 以及证书路径正确kubeadm init 报端口占用kubeadm reset后重试或者检查 6443、10250 端口是否被占用6.2 我自己的血泪教训第一个教训练习时不要跳过kubeadm reset这一步。很多人以为初始化失败之后直接重新 init 就行实际上不 reset 的话之前的配置会残留导致各种莫名其妙的错误。每次练习完一轮就主动把环境清干净再重新搭。第二个教训不要忽略namespace。考试中很多资源默认创建在 default 命名空间但有的题目要求创建在特定 namespace 下比如 kube-system、ingress-nginx。如果你忘了带-n namespace参数创建出来的资源就在 default 里结果自然是 0 分。所以提笔写命令前先确认这道题涉及的命名空间是什么。第三个教训做 NetworkPolicy 题的时候我一开始习惯性把所有流量都拒掉结果应用访问完全瘫痪。后来我总结了一个套路先画一个简单的逻辑图标注“谁访问谁、从哪个端口进”再照着逻辑写规则这样基本不会漏放行或过度放行。6.3 关于考试心态的最后一点CKA 是一门实操型考试它考察的既是知识也是临场状态。我在模拟考的时候遇到过节点网络崩溃、etcd 数据丢失等极端场景几乎心态崩了但冷静下来按部就班去排查最后还是能恢复。考试里遇到不会做的题先跳过把会做的做对比在一道难题上死磕更划算。如果你按照这个指南把基础概念、kubeadm 集群搭建、工作负载、网络、存储、排障这六块都练熟了考试通过率会非常高。最后再分享一个小经验考前一周我每天都会花 20 分钟默写常用命令和常见 YAML 片段不是为了背而是为了让手筋先热起来。真正进入考场后你会发现大部分操作都是在靠肌肉记忆完成而不是现想。祝你顺利拿下 CKA。