★ FEATURED ARTICLE 备考这件事很多人把时间都排给了刷题和看文档结果临考前才发现最该提前搞定的是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 三条路线的直观对比如果要用一句话总结这三条路线怎么选我的建议是本地虚拟机为主云服务器为辅托管集群只做验证。下面的对比表格可以帮你根据自身情况快速判断。对比维度本地虚拟机云服务器托管K8s集群部署成本中等依赖本机配置较低按小时计费最低一键创建可控性最高可快照回滚较高可重置系统很低控制平面不可见贴合考场程度最贴合较贴合不贴合适合人群本机内存大于16G的备考者本机性能不足或网络受限者仅用于快速概念验证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 kubelet1.28.x kubeadm1.28.x kubectl1.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 kkubectl ~/.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 考前三天预检清单到了考前两三天我不建议再做大量新题而是把环境彻底检查一遍确保考试当天状态万无一失。下面这个预检清单是我每次大考前必做的你可以直接照抄。检查项检查方式达标标准快照可用性尝试回滚到干净快照回滚后集群可正常启动系统时间同步date命令与标准时间对比无分钟级偏差磁盘余量df -h根目录剩余空间大于10Gcontext配置kubectl config get-contexts多个context显示正常网络插件状态kubectl get pods -n kube-system所有系统Pod处于Running命令补全与别名打开新终端验证k和补齐均生效这份清单看起来琐碎但每一条都对应着实际翻车案例。比如系统时间错误会直接导致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考试环境部署这些事看起来花时间实际上每一步都在为考试扫清障碍。尤其到备考后期当我不再需要为环境问题分心可以完全专注于题目本身的时候才体会到前期把环境打扎实有多重要。最后再分享一个我自己的习惯每次回滚快照、重新开始练习之前我会顺手验证一次集群是否能从零承载任务跑一条最简单的命令把结果看一遍确认环境确实在可用状态再开始正式的练习。这个习惯帮我避免了很多次练到一半发现集群早坏了的尴尬也让我走上考场的时候对身后的这套部署体系有十足的把握。
阅读完成 · 觉得有帮助？
