CKA备考必看：从零搭建贴近考场的Kubernetes练习环境

备考这件事，很多人把时间都排给了刷题和看文档，结果临考前才发现，最该提前搞定的是CKA考试环境部署。我见过不止一个考生，题目练了十几套，知识点背得滚瓜烂熟，真到模拟考的时候却卡在终端不顺手、集群状态不对、多集群切换不熟练这些小问题上，白白丢掉本该拿的分。这篇文章就围绕CKA考试环境部署，讲清楚怎么从零搭出一套贴近真实考场的Kubernetes练习环境，包括环境选型、部署步骤、考场化适配和日常维护，适合正在准备这项认证考试、或者想系统提升K8s实操能力的开发者和运维同学参考。

1. 备考里最不该省的环节，就是把考试环境先部署好

1.1 为什么很多人挂在了环境而不是题目上

CKA这个考试和普通的笔试不一样，它全程在一个网页终端里完成。你面对的不是本地的IDE，不是图形化的控制台，就是一个黑底白字的终端窗口，里面是你需要操作的节点。所有题目都要求你用kubectl去执行真实的操作，比如部署Pod、创建Service、配置网络策略、备份恢复Etcd等等。这些动作不是你在文档里看看就能会的，是实打实地要在集群里敲命令、看状态、做验证。

所以环境部署这件事，本质上是在为你搭建一个"训练场"。这个训练场如果和考场差距太大，那你平时练得再熟也没用。我举个最简单的例子：如果你平时都在本地的终端工具里操作，复制粘贴靠快捷键，右键菜单用习惯了，到了考场的网页终端里发现粘贴方式完全不同，鼠标行为也不一样，光是适应这些就要浪费好几分钟。在限时两小时的考试里，这几分钟可能就决定你最后能不能做完所有题。

另一个很多人忽略的点是：CKA考题涉及的场景往往需要你在多个集群、多个节点之间切换。考场的终端里默认会配置好几个上下文，你需要在它们之间来回跳转，而不少考生平时的练习环境只有一个单机集群，根本没见过多集群长什么样。等到真正考试时，kubectl config use-context这种最基本的操作都变得陌生，连题目要求的"先切换到某个集群"都搞不明白，后面的题自然没法做。这些都是环境部署不到位引发的连锁反应。

1.2 环境部署应当满足"三个贴近"

我在搭练习环境时，给自己定了三条标准，也是我推荐每个人都参考的。第一是贴近考场的操作形态。考试是Web终端，那我平时就尽量用Web终端去操作，哪怕本地方便也刻意不用，逼自己适应。第二是贴近考场的资源约束。别一上来就整一台高配机器，集群节点特别多、资源特别充裕，那样练出来的操作习惯在考场有限资源下反而会失效。第三是贴近"破坏—修复"的真实工作方式。练习不是只做正向操作，还要故意把集群搞坏再修好，这个过程最能暴露问题，也最接近实际操作中的真实状态。

把这三点想清楚，再去选环境方案、做部署，整个备考节奏都会顺很多。环境不是可有可无的辅助项，它是整个备考计划的地基，地基不稳，后面刷多少题都容易塌。

2. 三条环境路线怎么选：各有代价，别被"听起来省事"骗了

2.1 方案一：本地虚拟机，胜在可控和可回滚

本地虚拟机是我最推荐给大部分人的方案。你可以用常见的虚拟化软件在电脑上跑一台或多台Linux虚拟机，然后在里面部署完整的Kubernetes集群。这个方案最大的好处是快照。虚拟机可以随时打快照，练完一个场景之后一键回滚，环境立刻恢复到初始状态，不用重新装系统、重新初始化集群。CKA备考中会有大量重复练习，比如反复部署同一个工作负载、反复配置同一个存储卷，没有快照回滚能力的话，每次都要花十几分钟重建环境，练习效率会低得让人想放弃。

我自己的经验是：先用一台虚拟机做控制平面节点，有条件的话再开一两个工作节点，组成一个一主两从的集群，这就足够覆盖绝大多数CKA考试场景了。虚拟机分配上，主节点至少2核4G，工作节点各2核2G，整个宿主机的物理内存最好不低于16G。如果你电脑配置一般，也可以只做一主一从，甚至单节点的集群，先跑通核心操作，后续再按需加资源。

唯一的缺点是耗资源。开着虚拟机再跑别的软件，电脑风扇会转得比较厉害，磁盘占用也不小。所以建好环境之后，日常练习时尽量关掉浏览器里多余的标签页，给虚拟机留出足够的CPU和内存。

2.2 方案二：云服务器，胜在真实网络环境

如果你本地电脑配置实在带不动虚拟机，或者希望练习环境有一个固定的公网访问入口，那租一台云服务器也是一种选择。云服务器的好处是配置可以自己选，按小时或按月付费，练完就释放，成本可控。而且云服务器上的网络环境更接近生产环境，拉取镜像、访问外部资源的时候遇到的问题，会比你本地虚拟机上遇到的问题更真实。

不过用云服务器做练习环境有几个注意点。一是系统盘的容量要留足，Kubernetes拉取镜像、写入日志都很占空间，我建议至少40G，最好50G以上。二是最好提前把常用容器镜像在本地缓存好，或者配置好镜像源，避免考试前临时拉取失败。三是快照功能也能用，但云服务器的快照回滚速度通常比本地虚拟机慢，操作起来也没有那么顺手，所以我会更倾向于把它作为一个补充方案，比如在本地网络状况不好的时候临时顶上。

2.3 方案三：托管K8s集群，快是快，但别拿它当主力

有些人图省事，直接在某云厂商控制台点几下就申请一个托管的Kubernetes集群，觉得这也是练习。说实话，这个方案只能用来熟悉基础的对象和操作，不适合作为CKA备考的完整训练场。因为托管的控制平面完全由云厂商管理，你根本接触不到Etcd、kube-apiserver、kube-controller-manager这些组件，而CKA考试偏偏特别喜欢考这些组件的备份、恢复、调度和故障排查。你连Etcd的目录结构都没见过，考试时遇到相关题目基本无从下手。

另一个原因是托管集群的操作界面大多很友好，很多功能点上鼠标就能完成，这会让你养成依赖图形界面的习惯。到了真实的CKA考场上，没有控制台给你点，你只能靠命令行，这个反差会让不少人措手不及。所以托管集群我最多只在初期做快速验证用，验证一下某个概念是否理解对了，真正的主力练习环境一定是自己从零搭建的集群。

2.4 三条路线的直观对比

如果要用一句话总结这三条路线怎么选，我的建议是：本地虚拟机为主，云服务器为辅，托管集群只做验证。下面的对比表格可以帮你根据自身情况快速判断。

3. 亲手用kubeadm部署一套可清空重来的练习集群

3.1 准备主机和依赖项：这些细节决定成败

选好方案之后，接下来就是动手部署。我以最推荐的本地虚拟机方案为例，讲一下怎么用kubeadm从零搭起一套练习集群。首先要选一个稳定的操作系统。虽然很多K8s认证的资料里还在用旧版CentOS，但我建议选择长期支持且社区活跃的发行版，比如Ubuntu的某个LTS版本或Rocky Linux，这两个都比较省心。系统版本选定之后，安装时注意分区设置，把根目录的空间给足，因为后面容器镜像、日志文件都集中在根目录下。

系统装好之后，有几个必做的准备步骤。第一是关闭交换分区，Kubernetes默认要求关闭swap，否则kubelet会报错。第二是加载必要的内核模块，比如br_netfilter，同时通过sysctl开启桥接流量转发。这两个配置不做好，后面初始化集群时会出现各种莫名其妙的问题。第三是安装容器运行时。现在主流的做法是使用containerd，它比Docker更轻量，也是Kubernetes社区推荐的方向。安装完成后，需要修改containerd的配置文件，把SystemdCgroup设置为true，这样才能保证节点上的资源统计和Pod生命周期管理正常。

# 关闭交换分区，并修改fstab确保重启后仍关闭 sudo swapoff -a sudo sed -i '/swap/s/^/#/' /etc/fstab # 加载内核模块并设置系统参数 cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system

这里我特别想提醒的是：不要跳过内核参数的设置。很多人觉得不设置也能装，确实短期看好像没问题，但等你创建NodePort类型的Service、或者配置网络策略时，流量转发就会出问题，排查起来时间成本很高。环境部署就是要提前把基础打牢，后面练习时才能少踩坑。

3.2 初始化控制平面与安装网络插件

依赖项都准备好之后，就可以安装kubeadm、kubelet和kubectl三个核心组件了。安装时需要注意版本一致性，这三个工具最好使用相同的版本，并且和你要练习的Kubernetes版本匹配。版本不一致是新手经常遇到的问题，比如kubelet版本低于kubeadm，初始化时就会报出各种校验错误。用系统包管理工具安装时，指定好版本号，不要直接装最新版，除非你已经确认兼容性。

# 添加Kubernetes软件源后安装指定版本 sudo apt-get install -y kubelet=1.28.x kubeadm=1.28.x kubectl=1.28.x # 标记版本，防止升级误操作 sudo apt-mark hold kubelet kubeadm kubectl

安装完成后，在控制平面节点上执行初始化命令。kubeadm init需要指定Pod的网段，这个网段要和你后面要安装的网络插件保持一致。如果用Flannel，通常指定10.244.0.0/16；如果用Calico，通常指定10.10.0.0/16或192.168.0.0/16。不同插件对网段有不同的默认值，选定了插件再确定网段，不要拍脑袋写一个。初始化成功之后，命令行会提示你配置kubeconfig文件，以及将工作节点加入集群的命令，这行加入集群的命令很长，包含token和证书哈希等信息，建议直接保存到本地文件里，后面添加工作节点时还要用。

控制平面初始化完成后，kubectl get nodes就能看到控制节点，但此时它的状态是NotReady，因为还缺少网络插件。网络插件是Kubernetes集群能否正常工作的关键，它负责为每个Pod分配独立的IP，并打通节点之间的容器通信。没有网络插件，集群里所有Pod都会一直处于Pending状态，kube-system里的DNS服务也起不来，整个集群等于废了。安装网络插件的方法很简单，通常就是应用一个清单文件，比如kubectl apply -f某插件的yaml文件。但要注意版本兼容性，不同Kubernetes版本对应的网络插件版本可能不同，插件版本太旧会在高版本K8s里出问题。

3.3 安装命令行工具与命令补全

集群部署完成之后，强烈建议配置kubectl的命令补全。CKA考试虽然不依赖命令补全来答题，但补全能大大减少你输入命令的时间和出错概率。配置方法很简单：安装bash-completion，然后把补全脚本写入当前用户的bashrc文件。另外还可以设置kubectl的别名，我自己就习惯把kubectl简写为k，这样在考试时能省下不少敲击次数。

# 安装bash-completion并启用kubectl补全 sudo apt-get install -y bash-completion echo 'source <(kubectl completion bash)' >> ~/.bashrc echo 'alias k=kubectl' >> ~/.bashrc echo 'complete -o default -F __start_kubectl k' >> ~/.bashrc source ~/.bashrc

需要提醒的是，命令补全在你的本地终端里效果很好，但在考场的网页终端里未必默认开启。所以我建议你在平时练习时，故意每隔一段时间关掉补全，纯靠手敲命令，这样能锻炼你对命令的熟悉程度。补全是提高效率的工具，不是依赖，你需要的是在两种状态下都能顺畅操作。

3.4 用快照策略支撑"清空重来"

集群部署完成、网络插件装好、基础镜像都拉取完成之后，这一刻请务必打一个干净快照。这个快照是你整个备考周期里最宝贵的东西。为什么要强调这个？因为CKA练习的本质是高频重复操作，你练一遍不熟，第二遍、第三遍需要的是一个干净的起点，而不是一个被你上一轮练习搞乱的环境。

我自己的操作习惯是：每完成一个主题的练习，比如练完了Deployment的伸缩和滚动更新，就拍一个快照，命名为clean-state。下一次练新主题之前，先回滚到这个快照，确保环境从干净状态开始。这样做有两个好处。第一，每次练习的起点完全一致，复现性好，你可以清晰地知道自己这一步操作是否真的造成了预期效果，不用被旧状态干扰。第二，快照回滚速度也快，通常一两分钟就能搞定，比重新初始化集群快得多。

工作节点的加入也是一样，如果你打算练习多节点场景，就在工作节点也配置好快照。快照回滚时要特别注意：集群内的虚拟机关机、回滚、再开机，这个过程中节点之间的时间同步可能会出问题，后面我在避坑章节里会详细展开。

4. 把练习环境调成"考试模式"

4.1 多集群上下文：练熟切来切去的原生操作

很多CKA考生平时只在一个集群里操作，完全没体会过在多个集群之间切换的感觉。但考试的时候，界面里会预先配置好几个上下文，每道题都明确要求你切换到一个指定集群，然后再在那个集群里完成操作。如果你不熟悉context的概念，第一道题就会损失大量时间。

所以在练习环境里，我建议你至少配置两个集群上下文。怎么做？最简单的方式是，虚拟机上装两套集群，或者一个本地集群加一个云服务器上的集群，然后把它们的kubeconfig文件合并到同一个配置文件里。合并后的文件会让~/.kube/config里出现多个context，你就能随时用kubectl config use-context来切换。练习时给自己出题：先切换到集群A创建一个命名空间，再切到集群B查一下节点状态，反复操练，直到切换动作变成肌肉记忆。

还有一点要注意，很多人习惯用kubectx这个工具来切换上下文，确实好用，但在考场的默认终端里不一定预装了这种插件。所以平时练习时，我建议你以原生的kubectl config命令为主，既练切换，也顺便练查看当前上下文的命令。把基础原生命令练扎实，不管考场环境怎么变，你都不会慌。

4.2 浏览器终端适应计划：别让操作习惯拖后腿

真实考场是网页终端，而且那个终端和你平时本地的终端工具在交互上有些区别。最常见的差异是复制粘贴。本地终端通常用快捷键，网页终端里则是通过鼠标选中之后用右键菜单或特定快捷键完成，不同品牌的内嵌终端控件行为还不一样。这些细小的交互差异如果不提前适应，考试时你会感觉到处都别扭。

我的做法是给虚拟机装一个开源的网页终端服务，把虚拟机里的SSH终端搬到浏览器里操作。这样我每天的练习都直接在浏览器里进虚拟机，刻意不用本地终端工具，几天之后就完全适应了网页终端的操作节奏。还有一点就是网页终端里输入长命令时容易遇到光标跳转不灵敏的情况，这会逼着我尽量减少超长命令，把复杂的操作拆分成简单的几步，这在考场里其实是很好的习惯。

另外一个值得专门练的是字体和界面。网页终端默认字体可能比较小，长时间看眼睛会累。提前熟悉考场终端那种等宽字体排版，练习时就用类似的环境，减少临场的不适感。这些都是细节，但细节叠加起来，就是二十分钟和五分钟做完一道题的差别。

4.3 考场时间模型：给每个操作配上节拍

CKA考试总共两个小时，题目数量在17道左右，每道题平均只有7分钟多一点。这个时间是非常紧的，因为你还要留出时间读题、验证结果、复查错误。很多人不是不会做，是做得太慢，或者在某一道题上纠结太久，导致后面的简单题都没时间写。

我建议你在环境部署完成之后，为自己建立一套时间练习模型。具体做法是：把每天的练习内容分成若干个小任务，每个任务给自己设定一个时间上限，比如15分钟。到时间就停下来，哪怕没完成也要停下来复盘原因，是因为命令敲得慢，还是知识点记忆不牢，还是操作顺序有误。这样练出来的不只是操作熟练度，还有一种对时间的感知能力。上了考场你会在潜意识里知道哪一步该加快、哪一步不能省。

我自己练题时会把每道题拆成"读题—定位考点—操作—验证"四个阶段，其中验证阶段往往是被忽略的。很多人做完一个题目就去下一题了，不检查Service端口是否真的通了、Pod是否真的Running了，等最后一起检查时才发现前面好几题都是状态不对的。平时练习里养成"操作后必验证"的习惯，考试时你会本能地回头看，减少因为小疏漏导致的丢分。

5. 环境健康巡检：别在考前一天发现集群坏了

5.1 五分钟快速巡检清单

CKA备考周期一般以周计算，这么长的时间里，你练习用的集群可能会出现各种问题。比如磁盘空间被日志塞满、kubelet因为某些原因重启失败、某个节点状态变成NotReady等等。这些问题如果不及时发现，很可能在考前集中爆发，而你又没有时间再去排查。

我习惯在每次练习开始前花五分钟做一次快速巡检，检查内容和命令都很固定。首先看节点状态，kubectl get nodes，确保所有节点都是Ready。然后看核心组件状态，kubectl get pods -n kube-system，确保DNS、网络插件这些系统Pod都在Running状态。接着看系统资源，df -h检查磁盘余量，free -h检查内存，因为内存或磁盘不足会直接影响集群里的Pod调度。最后用systemctl status kubelet看一下节点上的kubelet服务是否正常。

# 快速巡检命令一页纸 kubectl get nodes kubectl get pods -A df -h free -h systemctl status kubelet

这组命令只要跑一遍，基本就能确定集群是否处于健康状态。如果发现异常，优先排查系统资源，不要一上来就怀疑是Kubernetes配置出了问题。实际经验里，大部分集群故障的根因都是磁盘满了、内存不足、或者节点的服务没起来，而不是什么高深复杂的K8s内部错误。

5.2 故意破坏再修复：最高效的练习法

巡检只是保证环境能用，而要让环境真正成为你的练习场，最好的方式反而是主动去破坏它。我在备考中期开始进行故障演练，做法很简单：故意搞坏集群的关键组件，然后尝试把它修复。比如删除kube-system命名空间下的某个核心Pod，让它被控制器重新拉起；或者手动停掉kubelet服务再重新启动；再进阶一点，可以尝试模拟Etcd数据损坏后的恢复过程。

这些故障演练的价值在于，它逼着你去理解组件之间的依赖关系。你光知道kubectl get pods只能看到表象，等你真的把Etcd快照备份、恢复流程走一遍，才能理解为什么Etcd是集群里最需要备份的组件。CKA考试中有不少题目就是考查这种故障处理能力，比如备份Etcd、恢复集群、排查节点状态异常。平时把这些场景反复练过，考试时碰到类似题目，你就是在做熟悉的事，心态完全不一样。

还有一个很重要的点是，故障演练能帮你建立"修复后的验证思维"。比如你修好了一个失败的工作节点，你不仅要让这个节点变回Ready，还要在上面重新调度Pod，验证业务真的恢复了。这种验证习惯在考试里特别加分，因为阅卷是看结果状态的，你验证得越充分，越不容易因为漏掉某个隐藏状态丢分。

5.3 考前三天预检清单

到了考前两三天，我不建议再做大量新题，而是把环境彻底检查一遍，确保考试当天状态万无一失。下面这个预检清单是我每次大考前必做的，你可以直接照抄。

这份清单看起来琐碎，但每一条都对应着实际翻车案例。比如系统时间错误，会直接导致kubelet的证书校验失败，节点状态一直NotReady，你排查很久才发现是虚拟机关机后再开机导致时间漂移了。考前花二十分钟跑一遍这份清单，能帮你避开考试当天大多数环境类的意外。

6. 环境部署中常见的坑与我的应对习惯

6.1 内存不够导致的假死

本地虚拟机方案最容易踩的坑就是内存分配不足。Kubernetes本身跑起来占用的内存不高，但如果你创建了较多的Pod，再加上系统自带的组件，内存很容易吃紧。典型的表现是：kubectl get nodes能看到节点Ready，但一执行创建Pod的命令，Pod就一直在Pending，或者偶尔能Running但运行几秒就被OOM杀掉。

遇到这种情况，不要急着反复删Pod、重建Pod，先看一下节点资源。free -h确认剩余内存，dmesg或journalctl查看是否有内存不足的日志。如果确认是内存不够，最彻底的解决方式是在虚拟化软件里把虚拟机的内存调大，比如从4G调到6G或8G，调完之后重启虚拟机让配置生效。所以在建虚拟机时，我建议你给自己留一点余量，宁可初始分配大一点，也不要反复折腾。

6.2 容器运行时配置与镜像拉取问题

另一个高频故障是镜像拉取失败。这可能是网络环境导致的，也可能是镜像地址本身的问题。容器运行时安装好之后，默认的配置可能没有针对你的网络环境做优化，导致拉取Kubernetes组件镜像时超时。我在部署集群时会提前把需要用到的镜像都拉一遍，而不是等kubeadm init时现场拉，这样能提前发现网络问题。

还有一些时候，即使镜像能拉下来，containerd也可能因为配置里的沙箱镜像版本与Kubernetes版本不匹配，导致Pod启动失败。遇到这种情况，检查/etc/containerd/config.toml里的sandbox_image配置，确认它指向的镜像版本是当前集群版本对应的版本。这种问题很隐蔽，Pod状态看着是CreateContainerError，但根本原因其实在运行时配置上。

6.3 快照回滚后的时间漂移与证书问题

快照回滚虽然好用，但有一个副作用：虚拟机的系统时间可能会在回滚后发生漂移。如果回滚到的是很久之前的快照，而宿主机时间早已往前走了，虚拟机里的时间就会落后，这会导致kubelet使用的证书在验证时被认为过期或无效，节点状态变成NotReady。

遇到这个问题，我的处理习惯是回滚完成后第一件事就是检查系统时间，跑一遍chrony或ntp同步。建议在虚拟机里提前配置好时间同步服务，并设置为开机自启。这样即使回滚导致时间漂移，也会在开机后很快被纠正过来。不要等到kubectl get nodes发现节点NotReady，才想到去查时间，那样排查链路会拉得很长。

6.4 网络插件与NodeReady状态

最后说说网络插件和节点状态的问题。很多人在初始化集群之后发现，节点虽然join了，但状态一直NotReady，而kube-system里的网络插件Pod一直在CrashLoopBackOff。这种情况大多数时候是网络插件的清单文件与Kubernetes版本不匹配，或者Pod网段和插件默认网段冲突。

我的建议是：在初始化控制平面之前就确定好网络插件，在kubeadm init时传入与之匹配的Pod网段。安装插件时也用官方当前推荐版本，别用太老的版本。如果节点已经陷入NotReady循环，最干净的解决方式是把节点重新加入一次，而不是反复patch节点状态，因为NotReady的本质原因没有解决，patch只是掩盖症状。

从我自己的备考经历来看，CKA考试环境部署这些事，看起来花时间，实际上每一步都在为考试扫清障碍。尤其到备考后期，当我不再需要为环境问题分心，可以完全专注于题目本身的时候，才体会到前期把环境打扎实有多重要。最后再分享一个我自己的习惯：每次回滚快照、重新开始练习之前，我会顺手验证一次集群是否能从零承载任务，跑一条最简单的命令把结果看一遍，确认环境确实在可用状态，再开始正式的练习。这个习惯帮我避免了很多次"练到一半发现集群早坏了"的尴尬，也让我走上考场的时候，对身后的这套部署体系有十足的把握。