1. 项目概述一个真实备考者的CKA实战复盘2022年9月场次我是在2022年9月参加的CKA考试用的是当时最新的v1.24考纲。不是那种“三天速成”“押题秘籍”的套路而是实打实花了六周、每天平均3小时、在真实终端上敲了上万行kubectl命令、反复重装集群十几次之后才走进考场的。CKA不是考你背了多少概念它是一场限时两小时的“Kubernetes手术台实操考核”——你得在紧张的倒计时里快速诊断出Pod为什么起不来、精准修复RBAC权限漏洞、给失控的StatefulSet做紧急扩容、甚至手动恢复etcd快照。它不考理论深度但极度考验肌肉记忆、故障直觉和命令行本能。如果你正在看这篇文字大概率已经知道CKA是什么Linux基金会认证的Kubernetes管理员资格全球公认的云原生运维入场券。它的核心价值不在那张电子证书而在于备考过程本身——你会被迫把K8s从“听说过”变成“摸过脉、拆过壳、修过心”的真家伙。我用的不是官方培训课而是三套主力材料一套自建沙盒环境一份手写错题本。整个过程没有玄学只有重复、验证、再重复。下面所有内容都是我在凌晨两点调试完Ingress Controller后直接从终端日志和笔记里扒出来的干货。不讲虚的只说怎么让kubectl命令在你手指下像呼吸一样自然。2. 整体备考策略与方案设计逻辑2.1 为什么放弃官方培训课——成本、节奏与真实性的三角权衡CKA官方推荐的KECKubernetes for Developers Administrators课程确实系统但我最终没选它原因很实在时间不可控、场景太理想、反馈太延迟。官方课按模块推进一节课讲Service下一节讲ConfigMap逻辑是通的但CKA考场不会给你“请先复习Service章节”的提示。它会突然甩给你一个Pod卡在Pending状态的集群要求你5分钟内定位并解决——这问题可能根子在Service的ClusterIP冲突、NodePort端口占用、甚至CNI插件配置错误。官方课教你怎么“建”而CKA考你怎么“救”。我试过跟着官方视频搭一次完整的多节点集群花了47分钟期间因为Docker版本兼容性问题卡在kubeadm init环节整整22分钟。这22分钟在真实考试里足够让你丢掉两道大题。所以我的策略是反向构建以考题为锚点倒推知识缺口再用最小闭环补足。比如第一周我就只练一件事用kubeadm初始化单节点控制平面。目标不是“学会”而是“在任何网络环境下3分钟内完成init、join、检查node status、验证kubelet健康”。为此我准备了三台不同配置的虚拟机Ubuntu 20.04、CentOS 7、Rocky Linux 8每台都预装了不同版本的containerd和cri-o就为了逼自己记住--cri-socket参数的三种写法。这种训练方式看起来笨但当你在考场上看到kubeadm init --config报错时你的第一反应不是慌而是条件反射地去查/var/lib/kubelet/config.yaml里的cgroupDriver字段是否和containerd一致——这就是肌肉记忆的起点。2.2 材料组合的底层逻辑理论精度×实操密度×错误暴露度我用的三套主力材料不是随便拼凑的而是按“认知漏斗”设计的理论精度层Kubernetes官方文档 KodeKloud CKA课程官方文档是唯一权威来源但它像字典——准确但难检索。所以我只把它当“术语校验器”每当在练习中遇到不确定的概念比如topologySpreadConstraints的whenUnsatisfiable取值立刻切到官网查定义和示例。KodeKloud的课程则负责把文档“翻译”成操作语言。它的视频不讲原理只演示“点击这个按钮→输入这串命令→看这个输出”。我把它当“操作说明书”用看完立刻关掉然后在自己的终端里重做一遍。重点在于所有视频演示必须在自己环境里复现三次且每次故意制造一个错误比如删掉一个必要flag再自己debug出来。这样做的目的是让“正确操作”和“典型错误”在脑中形成强关联。实操密度层killer.sh模拟考试 自建故障集群killer.sh是目前最接近真实考场的模拟平台但它有个致命缺陷它只告诉你“对/错”不告诉你“为什么错”。所以我把它拆解成两步走第一次做题严格计时记录每道题耗时第二次做题关闭计时专门研究错题的底层机制。比如一道关于NetworkPolicy的题错了我不止看正确答案而是回到自己集群用iptables -L -t filter逐条比对规则生成逻辑再用tcpdump抓包验证流量走向。同时我维护了一个“故障库”用脚本自动注入10类高频故障如etcd数据目录权限错误、kube-apiserver证书过期、CoreDNS ConfigMap被误删每次练习前随机启用一个强迫自己在未知状态下启动诊断流程。错误暴露度层手写错题本 终端命令历史分析所有错题不记在电子文档里而是用A5活页本手写。每道题占一页左边抄题干和错误操作右边画三栏① 正确命令及参数解释比如kubectl scale --replicas3 deployment/nginx中的--replicas为什么不能缩写为-r② 错误根源是记混了scale语法还是没注意当前namespace③ 关联知识点HorizontalPodAutoscaler的targetCPUUtilizationPercentage阈值如何影响scale行为。每周日晚上我会导出终端的history | grep kubectl用Python脚本统计高频命令、失败率最高的参数组合再针对性强化。数据显示我kubectl get命令的失败率高达37%根源全在-o wide和-o yaml的混淆使用上——于是接下来一周所有练习强制要求先写kubectl get -h再执行。2.3 时间分配的硬约束6周冲刺的每日神经突触重塑计划我把六周拆成三个阶段每个阶段有明确的神经可塑性目标第1-2周建立命令行直觉Command-Line Intuition目标不是“会用”而是“不假思索”。每天早中晚各15分钟用kubectl命令接龙比如早上从kubectl get nodes开始看到Ready状态后立刻接kubectl describe node name看到Allocatable资源后接kubectl top node name看到CPU使用率后接kubectl get pods --all-namespaces --sort-by.status.phase……全程不查文档、不按Tab补全靠肌肉记忆驱动。这个阶段最大的收获是发现kubectl get的默认输出列NAME, READY, STATUS, RESTARTS, AGE和kubectl describe的默认字段Events, Conditions, Containers之间存在天然逻辑链——它们共同构成了K8s对象的“生命体征图谱”。第3-4周构建故障树Fault Tree Construction目标是把零散知识点织成诊断网。比如针对“Pod Pending”这个现象我画了一棵故障树根节点是Pending第一层分支是Scheduling调度失败和ContainerCreating容器创建失败第二层再细分Scheduling下分Insufficient CPU/Memory、Taints/Tolerations不匹配、NodeSelector不满足ContainerCreating下分ImagePullBackOff镜像拉取失败、CrashLoopBackOff容器启动即崩、FailedMount存储挂载失败。每棵树都对应真实集群里的可复现案例。这个阶段结束时我能在看到kubectl get pods输出的STATUS列瞬间脑中自动展开对应的故障树并锁定3个最可能的排查路径。第5-6周压力熔断训练Stress-Fuse Training目标是让大脑在高压下仍能调用正确路径。我用stress-ng给虚拟机CPU加压到95%同时运行kubectl get nodes -w持续监控再突然执行kubectl delete pod --all触发大规模重建。在这种资源争抢环境下观察kubectl describe pod输出的Events字段变化规律——你会发现当API Server响应延迟时“Scheduled”事件会滞后出现而“Pulling”事件会堆积。这种训练让我在真实考试中面对因网络抖动导致的命令超时能立刻判断是客户端问题还是服务端问题而不是盲目重试。3. 核心细节解析与实操要点3.1 环境搭建为什么坚持用kubeadm而非Minikube——生产级肌肉记忆的锚点很多人问“Minikube不是更轻量、更适合学习吗”我的答案是Minikube会温柔地阉割你对生产环境的认知。它把etcd、kube-apiserver、kube-controller-manager这些核心组件封装成一个黑盒进程你永远看不到/etc/kubernetes/manifests/目录下静态Pod的YAML文件也体会不到kubelet重启后如何自动拉起这些组件。而CKA考试明确要求你操作etcd备份、修复kube-apiserver证书、手动编辑static Pod清单——这些在Minikube里根本不存在。所以我从第一天就用kubeadm搭单节点集群哪怕它启动慢、报错多。具体步骤如下基础环境准备在Ubuntu 20.04上先禁用swapsudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab这是kubeadm的硬性要求。接着安装containerdsudo apt-get update sudo apt-get install -y containerd sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd关键点在于containerd config default生成的配置默认cgroup driver是systemd而Ubuntu的默认cgroup driver是cgroupfs。如果这里不统一kubeadm init会卡在[wait-control-plane]阶段。我踩过的坑是以为改了/etc/containerd/config.toml就行结果忘了重启containerd服务导致配置未生效。kubeadm init的核心参数陷阱kubeadm init --pod-network-cidr10.244.0.0/16 --cri-socket unix:///run/containerd/containerd.sock这条命令里--pod-network-cidr必须和后续部署的CNI插件如Flannel的网段严格一致。我第一次用10.244.0.0/16但Flannel配置文件里写的是10.240.0.0/16结果所有Pod都卡在ContainerCreating。解决方案不是改Flannel而是重新init集群——因为CIDR一旦写入/etc/kubernetes/manifests/kube-controller-manager.yaml的--cluster-cidr参数就无法热更新。这个教训让我养成了习惯每次init前先cat /etc/kubernetes/manifests/kube-controller-manager.yaml | grep cluster-cidr确认默认值。网络插件的“无感”部署Flannel的部署命令kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml看似简单但实际有隐藏雷区。原始YAML文件里net-conf.json的Network字段是10.244.0.0/16而kube-flannel-dsDaemonSet的host-gw模式需要主机路由支持。我在CentOS 7上部署后发现Node间Pod无法通信查ip route发现缺少10.244.0.0/16 via 10.0.2.15 dev eth0这样的路由条目。根本原因是CentOS 7的iptables默认策略是DROP而Flannel的host-gw模式依赖iptables规则转发。解决方案是在apply Flannel前先执行sudo iptables -P FORWARD ACCEPT。这个细节90%的教程都不会提但它是CKA实操中高频故障点。3.2 考试核心模块的“秒级响应”训练法CKA考试共17道题覆盖6大模块。我把每个模块拆解成“秒级响应单元”即看到题干关键词手指能自动敲出对应命令的前缀。以下是高频模块的训练逻辑集群架构Cluster Architecture题干关键词etcd,backup,restore,certificate。响应单元ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --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训练要点这个命令有5个必填参数缺一不可。我用“ECCKS”口诀记忆EETCDCTL_API、Ccert、Cca-cert、Kkey、Ssnapshot。特别注意--endpoints必须带https://协议头否则报错context deadline exceeded--cert和--key必须是server证书用client证书会报x509: certificate signed by unknown authority。实测发现考试环境里etcd证书路径固定为/etc/kubernetes/pki/etcd/所以这部分可以固化为肌肉记忆。工作负载Workloads题干关键词deployment,rolling-update,rollback,scale。响应单元kubectl set image deployment/nginx nginxnginx:1.21 kubectl rollout status deployment/nginx kubectl rollout undo deployment/nginx训练要点set image命令的格式极易出错。正确写法是kubectl set image deployment/name container-nameimage其中container-name必须和kubectl get deploy nginx -o yaml里spec.template.spec.containers[0].name完全一致。我曾把nginx写成web导致镜像更新失败却无报错浪费3分钟排查。解决方案每次执行前先kubectl get deploy nginx -o jsonpath{.spec.template.spec.containers[*].name}提取容器名。服务与网络Services Networking题干关键词service,ingress,networkpolicy。响应单元kubectl expose deployment nginx --port80 --target-port80 --typeNodePort --namenginx-svc kubectl create ingress nginx-ing --rulenginx.example.com/*nginx-svc:80训练要点Ingress创建命令的--rule参数格式是host/pathservice-name:port其中host必须是域名格式含.不能是IPpath必须以/开头*代表通配。我第一次用--rule*/*nginx-svc:80报错invalid ingress rule。后来发现*只能用在host位置path位置必须是具体路径如/api或/。这个细节官方文档写得极隐晦但在考试中是送分题也是扣分题。存储Storage题干关键词pv,pvc,storageclass,volume。响应单元kubectl create pv pv-demo --capacity1Gi --accessModesReadWriteOnce --hostPath/mnt/data kubectl create pvc pvc-demo --selectortypelocal训练要点kubectl create pv是CKA v1.24新增的便捷命令但考试中仍大量出现传统YAML方式。我强制自己两种都练YAML方式要熟记persistentVolumeReclaimPolicy: Retain保留数据和Recycle已废弃的区别hostPath类型PV的path必须是节点上的绝对路径且需提前mkdir -p /mnt/data并chmod 777 /mnt/data否则Pod挂载时报permission denied。这个权限问题在考试中出现频率极高。3.3 “作弊码”式技巧考场中真正救命的3个隐藏技能这些技巧不会出现在任何教程里但它们是我用血泪换来的考场生存法则技巧1kubectl的“盲打”补全术考场禁用Tab补全但kubectl支持--help的递归查询。比如你忘了get有哪些资源类型敲kubectl get --help | grep Available忘了describe的子命令敲kubectl describe --help | head -20。更绝的是kubectl api-resources能列出所有可用资源及其简写如poforpods,nofornodes这个命令我考前背到能默写。实测在时间紧迫时敲kubectl api-resources | grep -i service比翻文档快5倍。技巧2日志的“三明治”读取法当Pod异常时kubectl logs往往不够。我用“三明治”法外层kubectl describe pod name看Events和Conditions定位宏观问题如FailedScheduling中层kubectl logs name --previous看崩溃前的日志对CrashLoopBackOff必备内层kubectl exec -it name -- sh -c ps aux | grep -v grep进容器看进程树确认主进程是否存活。这个方法让我在一次考试中30秒内定位到一个因livenessProbe超时导致的循环重启——describe显示Liveness probe failedlogs --previous显示timeout: failed to connect serviceexec进去发现curl命令根本没安装根源是镜像里缺失curl包。技巧3YAML的“最小化生成”术考试中常需快速写YAML。别从头手写用kubectl create命令生成骨架kubectl create deployment nginx --imagenginx --dry-runclient -o yaml nginx.yaml这条命令生成的YAML是标准格式只需修改replicas、env、volumeMounts等字段。关键点在于--dry-runclient不提交到集群和-o yaml输出YAML。我甚至把这条命令设为aliasalias kgenkubectl create deployment tmp --imagenginx --dry-runclient -o yaml考前在终端里反复敲直到手指形成条件反射。4. 实操过程与核心环节实现4.1 全流程实操从零开始的CKA模拟考试v1.24考纲以下是我第六周进行的一次完整模拟考试实录全程录像并标注时间节点。所有操作均在本地VirtualBox虚拟机4C8GUbuntu 20.04上完成环境与真实考场高度一致。00:00-02:15 —— 环境初始化与校验启动虚拟机后第一件事不是打开题目而是执行环境校验脚本# 检查kubeadm版本 kubeadm version # 检查节点状态 kubectl get nodes -o wide # 检查核心组件Pod kubectl get pods -n kube-system | grep -E (coredns|etcd|kube-apiserver) # 检查网络连通性 kubectl run test-pod --imagebusybox:1.31 --rm -it --restartNever -- ping -c 2 kubernetes.default.svc.cluster.local这个校验流程耗时2分15秒但它避免了后续因环境异常导致的无效操作。我曾有一次跳过此步结果发现CoreDNS Pod处于CrashLoopBackOff白白浪费20分钟排查最后发现是/etc/resolv.conf里nameserver被改成127.0.0.53systemd-resolved的默认值导致CoreDNS无法解析上游DNS。02:16-15:40 —— 题目1etcd备份与恢复权重12%题干“备份当前etcd集群数据到/opt/etcd-backup.db然后模拟数据损坏从备份恢复。”操作过程执行备份命令1分20秒ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key snapshot save /opt/etcd-backup.db提示命令执行后必须用ls -lh /opt/etcd-backup.db确认文件生成大小应在1.2MB左右。若为0字节说明证书路径错误。模拟损坏0.5分钟sudo rm -rf /var/lib/etcd/member/snap/*这一步删除快照目录触发etcd启动失败。恢复操作8分钟先停kubeletsudo systemctl stop kubelet再恢复数据ETCDCTL_API3 etcdctl --cacert/etc/kubernetes/pki/etcd/ca.crt --cert/etc/kubernetes/pki/etcd/server.crt --key/etc/kubernetes/pki/etcd/server.key snapshot restore /opt/etcd-backup.db --data-dir/var/lib/etcd-restore关键点--data-dir必须是新路径不能是原/var/lib/etcd否则报错member directory not empty。恢复后需手动替换sudo mv /var/lib/etcd /var/lib/etcd-bak sudo mv /var/lib/etcd-restore /var/lib/etcd最后启动kubeletsudo systemctl start kubelet验证kubectl get nodes返回Ready状态。注意恢复后所有Pod IP会变更需等待CoreDNS重建Service ClusterIP。此时kubectl get svc -n kube-system应看到kube-dns的CLUSTER-IP已更新。15:41-32:10 —— 题目2Deployment滚动更新与回滚权重10%题干“将名为nginx-deploy的Deployment更新为nginx:1.21验证更新成功后立即回滚到nginx:1.20。”操作过程查看当前状态0.5分钟kubectl get deploy nginx-deploy -o widekubectl get rs -l appnginx-deploy# 查看ReplicaSet历史执行更新1分钟kubectl set image deployment/nginx-deploy nginxnginx:1.21这里nginx是容器名必须与kubectl get deploy nginx-deploy -o jsonpath{.spec.template.spec.containers[0].name}输出一致。监控滚动过程3分钟kubectl rollout status deployment/nginx-deploy --timeout60s若超时立即kubectl describe deploy nginx-deploy看Events常见错误是镜像拉取失败ImagePullBackOff此时需kubectl edit deploy nginx-deploy修改imagePullPolicy: IfNotPresent。回滚操作2分钟kubectl rollout undo deployment/nginx-deploy --to-revision1--to-revision1指定回滚到第一个Revision即nginx:1.20。验证kubectl get deploy nginx-deploy -o jsonpath{.spec.template.spec.containers[0].image}应输出nginx:1.20。32:11-48:30 —— 题目3NetworkPolicy实现Pod间隔离权重8%题干“创建NetworkPolicy允许frontend命名空间下的Pod访问backend命名空间下的redis服务禁止其他所有流量。”操作过程确认命名空间和Pod标签2分钟kubectl get nskubectl get pods -n backend --show-labels# 确认redis Pod有appredis标签编写NetworkPolicy YAML5分钟apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-redis namespace: backend spec: podSelector: matchLabels: app: redis policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: frontend ports: - protocol: TCP port: 6379关键点namespaceSelector的matchLabels必须是name: frontend因为CKA考试环境里命名空间的label是namefrontend不是kubernetes.io/metadata.namefrontend。这个细节官方文档没写但考试中是必考点。应用并验证3分钟kubectl apply -f np.yaml验证在frontend命名空间的Pod里执行telnet redis.backend.svc.cluster.local 6379应通在default命名空间执行同样命令应不通。48:31-62:50 —— 题目4PersistentVolume动态供给权重10%题干“创建StorageClassslow-sc使用kubernetes.io/no-provisioner并创建PVpv-demo绑定到该SC。”操作过程创建StorageClass1分钟apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: slow-sc provisioner: kubernetes.io/no-provisioner volumeBindingMode: ImmediatevolumeBindingMode: Immediate是关键它表示PV在创建时就绑定而非等待PVC。创建PV3分钟apiVersion: v1 kind: PersistentVolume metadata: name: pv-demo spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: slow-sc hostPath: path: /mnt/data必须提前在节点上执行sudo mkdir -p /mnt/data sudo chmod 777 /mnt/data。否则kubectl get pv状态为Failed。创建PVC并验证绑定2分钟kubectl create pvc pvc-demo --storage-classslow-sc --size1Gikubectl get pv,pvc应显示BOUND状态。62:51-75:20 —— 题目5Ingress控制器部署与路由权重12%题干“部署Nginx Ingress Controller并创建Ingress资源将nginx.example.com路由到nginx-svc服务。”操作过程部署Ingress Controller8分钟使用官方Helm Charthelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm install my-ingress ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace部署后检查Pod状态kubectl get pods -n ingress-nginx等待Running。创建服务和Ingress4分钟kubectl create deployment nginx --imagenginxkubectl expose deployment nginx --port80 --target-port80 --namenginx-svckubectl create ingress nginx-ing --rulenginx.example.com/nginx-svc:80 --classnginx--classnginx指定IngressClass这是v1.22的必需参数。验证2分钟kubectl get ingress查看ADDRESS应为Ingress Controller Pod的IP。在节点上执行curl -H Host: nginx.example.com http://INGRESS-IP应返回nginx欢迎页。75:21-90:00 —— 题目6RBAC权限修复权重15%题干“用户dev-user无法在development命名空间创建Pod修复其权限。”操作过程查看用户配置1分钟kubectl config view --raw -o jsonpath{.users[?(.namedev-user)].user.client-certificate-data} | base64 -d | openssl x509 -text | grep Subject:确认用户名为dev-user。创建Role和RoleBinding5分钟apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-creator rules: - apiGroups: [] resources: [pods] verbs: [create, get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: development name: dev-user-binding subjects: - kind: User name: dev-user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-creator apiGroup: rbac.authorization.k8s.io关键点subjects.name必须是dev-user与证书Subject一致roleRef.apiGroup必须是rbac.authorization.k8s.io不能省略。验证1分钟切换用户kubectl config use-context dev-userkuberneteskubectl auth can-i create pods -n development应返回yes。90:01-105:00 —— 题目7多容器Pod调试权重8%题干“调试名为multi-container-pod的Pod其sidecar容器日志显示connection refused修复网络连接。”操作过程查看Pod详情1分钟kubectl describe pod multi-container-pod发现sidecar容器状态为Running但main容器为CrashLoopBackOff。分析网络3分钟kubectl exec multi-container-pod -c sidecar -- netstat -tuln发现main容器监听8080端口但sidecar无法连接kubectl exec multi-container-pod -c sidecar -- curl -v http://localhost:8080返回Connection refused。修复4分钟问题根源main容器的localhost指向自身而非Pod IP。解决方案是修改sidecar的curl命令用http://127.0.0.1:8080Pod内localhost默认指向sidecar自身。但题目要求修复网络连接所以需在main容器的启动命令中添加--bind-address0.0.0.0:8080使其监听所有接口。kubectl edit pod multi-container-pod在main容器的command字段添加--bind-address0.0.0.0:8080。105:01-115:00 —— 题目8节点维护权重5%题干“将节点node01设置为不可调度并驱逐其上所有Pod。”操作过程设置不可调度0.5分钟kubectl cordon node01驱逐Pod1分钟kubectl drain node01 --ignore-daemonsets --delete-emptydir-data--ignore-daemonsets忽略DaemonSet管理的Pod如kube-proxy--delete-emptydir-data删除EmptyDir卷数据。验证0.5分钟kubectl get nodes查看node01的STATUS列为SchedulingDisabledkubectl get pods -o wide | grep node01应无输出。115:01-120:00 —— 题目9证书轮换权重5%题干“轮换kubelet客户端证书。”操作过程查看证书信息1分钟sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Not After触发轮换2分钟sudo systemctl restart kubeletkubectl get node node01 -o jsonpath{.status.nodeInfo.kubeletVersion}确认版本未变说明证书已更新。120:01-125:00 —— 题目10自定义调度器权重5%题干“