简介本资源是专为 Kubernetes CKA 认证1.29 版本考生打造的高仿真题库与实战备考指南面向已掌握 Kubernetes 基础、亟需突破考试实操瓶颈的运维工程师、开发与架构师。内容覆盖 RBAC 权限控制、Deployment 扩缩容、NetworkPolicy 策略配置、Service/Ingress 创建、Pod 调度、节点维护、PV/PVC 存储管理及日志排查等核心考点并深度还原 PSI 新考试平台操作逻辑——包括 candidate 账号登录、免密 SSH 切换、kubectl 自动补全、官网中文文档检索路径、卡顿应对策略及高分题优先作答技巧。资源为单个 PDF 文件大小 6.78MB结构清晰含题干对照、命令详解、易错提示与考场注意事项强调理解变量逻辑而非死记答案。目前已有 1053 人学习下载是兼顾真题还原度、环境适配性与临场指导力的高效备考材料。1. 这不是题库是 CKA 1.29 考试环境的「肌肉记忆训练套件」在 node01 上用 candidate 账号反复敲错 37 次后我才真正看懂 PSI 平台卡顿背后的底层约束你手里的这份《Kubernetes CKA 认证 1.29 题库》根本不是传统意义的“选择题答案”合集——它是一套高度还原 PSI 新考试平台行为逻辑的实操沙盒。所有题目都强制运行在candidatenode01IP: 11.0.1.112下而非 root 或 master所有操作必须通过免密 SSH 跳转到master01/node02完成每道题开头都带红色提示框明确告诉你当前上下文kubectl config use-context k8s还是hk8s而模拟环境里这些命令会报错——这恰恰是设计意图逼你把「切换集群」刻进手指神经反射。真实考场中70% 考生反馈平台卡顿到无法完成搜索连官网中文页加载都要等 15 秒所以题库里所有解法都默认「不查文档也能闭环」RBAC 创建用kubectl create clusterrole一行搞定NetworkPolicy 的namespaceSelector标签必须手动打kubectl label ns echo projectechoIngress 的ingressClassName必须先kubectl get ingressclass查实再填。这不是教你怎么背命令而是训练你在 Ubuntu 20.04 远程桌面里用火狐浏览器右上角切中文、在/docs/reference/目录树里三秒定位networking.k8s.io/v1API 版本的条件反射能力。适合已经能写基础 YAML、但一到考试就因环境差异翻车的运维/开发工程师——你缺的不是知识是candidate账号下敲kubectl auth can-i验证权限时手心冒汗的真实压感。2. RBAC 权限控制实战从 ClusterRole 创建到 ServiceAccount 绑定的四步闭环2.1 理解考试题干的隐藏约束为什么必须用 RoleBinding 而非 ClusterRoleBinding题干明确要求「限于 namespace app-team1 中」这个短语是 RBAC 授权范围的黄金分界线。Kubernetes 中ClusterRole是集群级资源定义可跨 namespace 复用但绑定动作必须匹配作用域若授权范围是整个集群如允许创建所有 namespace 的 Deployment则用ClusterRoleBinding其--serviceaccount参数格式为default:sa-namenamespace:sa-name若授权范围是单个 namespace如本题的app-team1则必须用RoleBinding此时--serviceaccount必须带 namespace 前缀app-team1:cicd-token且--clusterrole引用的是已存在的 ClusterRole而非 Role。提示考试中若漏写-n app-team1参数kubectl create rolebinding会默认在defaultnamespace 创建导致后续kubectl auth can-i验证失败。这是高频翻车点——因为题干没说「在哪个 namespace 创建 RoleBinding」但「限于 namespace app-team1」已隐含绑定动作的作用域。2.2 四步命令链从零构建最小可行授权体系所有操作均在candidatenode01终端执行无需sudo -i# 步骤1创建仅允许 create deployments/statefulsets/daemonsets 的 ClusterRole kubectl create clusterrole deployment-clusterrole \ --verbcreate \ --resourcedeployments,statefulsets,daemonsets参数说明--verbcreate限定动作为创建非 get/list/delete--resource后接逗号分隔的资源类型列表注意statefulsets是复数形式非statefulsetdaemonsets同理。此命令生成的 ClusterRole 位于clusterroles资源组可通过kubectl get clusterrole deployment-clusterrole -o yaml查看完整定义。# 步骤2在 app-team1 namespace 中创建 ServiceAccount kubectl -n app-team1 create serviceaccount cicd-token参数说明-n app-team1显式指定命名空间避免误建在 default 下。ServiceAccount 创建后自动关联一个 Secret用于 Pod 内部认证可通过kubectl -n app-team1 get sa,cicd-token -o wide验证。# 步骤3将 ClusterRole 绑定到 ServiceAccount关键必须指定 namespace kubectl -n app-team1 create rolebinding cicd-token-rolebinding \ --clusterroledeployment-clusterrole \ --serviceaccountapp-team1:cicd-token参数说明-n app-team1决定 RoleBinding 的存储位置rolebindings资源属于 namespace 级别--serviceaccountapp-team1:cicd-token中的app-team1:是必需前缀表示该 SA 存在于 app-team1 下。若写成--serviceaccountcicd-token系统会尝试在 default namespace 查找报错Error from server (NotFound): serviceaccounts cicd-token not found。# 步骤4验证授权是否生效考试时不强制但练熟可防 panic kubectl auth can-i create deployment -n app-team1 --as system:serviceaccount:app-team1:cicd-token逻辑说明kubectl auth can-i是权限校验的黄金标准。--as参数模拟以该 SA 身份执行操作-n app-team1指定目标 namespace。返回yes表示授权成功若返回no需检查 RoleBinding 的 namespace 是否与 SA 一致、ClusterRole 的 verb/resource 是否匹配、SA 名称拼写是否正确注意大小写敏感。2.3 避坑RBAC 授权失效的五个血泪现场现象kubectl auth can-i create deployment -n app-team1 --as system:serviceaccount:app-team1:cicd-token返回no原因RoleBinding 创建时漏写-n app-team1导致绑定对象存在于 default namespace而 SA 在 app-team1 中权限无法跨 namespace 生效。解决删除错误的 RoleBindingkubectl -n default delete rolebinding cicd-token-rolebinding重新执行带-n app-team1的命令。现象kubectl get rolebinding -n app-team1显示 RoleBinding 存在但kubectl describe rolebinding -n app-team1 cicd-token-rolebinding中Subjects字段为空原因--serviceaccount参数格式错误如写成--serviceaccountapp-team1/cicd-token用斜杠而非冒号或--serviceaccountcicd-token缺 namespace 前缀。解决删除后重建严格按--serviceaccountnamespace:sa-name格式输入。现象执行kubectl create clusterrole后kubectl get clusterrole deployment-clusterrole显示AGE为unknown原因集群未启用 RBAC 插件--authorization-modeRBAC或当前 context 未指向启用了 RBAC 的集群。解决确认kubectl config current-context输出为k8s或hk8s题库预设环境已启用若自建环境需检查 kube-apiserver 启动参数。现象kubectl auth can-i list pods --as system:serviceaccount:app-team1:cicd-token返回yes但create deployment仍返回no原因ClusterRole 中--resource拼写错误如--resourcedeployment单数而非deployments复数Kubernetes 资源名必须为复数形式。解决kubectl get clusterrole deployment-clusterrole -o yaml查看rules[].resources字段修正为deployments。现象考试时切换 context 失败提示error: context was not found for name: hk8s原因题库模拟环境仅有一套集群k8shk8scontext 是真实考试多集群场景的占位符模拟时无需执行kubectl config use-context hk8s。但必须养成每道题开头敲一遍的习惯防止考试时遗忘。解决练习时照敲遇到报错直接忽略考试时若 context 存在则执行不存在则跳过。3. NetworkPolicy 网络策略配置用 namespaceSelector 实现跨命名空间流量白名单3.1 题干翻译术把「允许 A 访问 B 的 9000 端口」转化为 Policy 编写逻辑题干「允许 namespace echo 中的 Pods 连接到 namespace my-app 中的 Pods 的 9000 端口」本质是在被访问方my-app部署入站防火墙规则。NetworkPolicy 的spec.podSelector定义策略作用的 Pod 范围即 my-app 中所有 Podspec.ingress定义允许的入站流量来源。关键陷阱在于ingress.from.namespaceSelector.matchLabels必须匹配访问方 namespace 的标签echo而非被访问方ingress.from.podSelector若存在则进一步限制访问方 Pod但本题未要求故留空spec.podSelector: {}表示策略应用于 my-app 中所有 Pod空 selector 匹配全部不可省略否则 Policy 不生效。注意考试环境中的 namespace 默认无标签kubectl get ns echo --show-labels会显示No resources found必须手动打标。这是 NetworkPolicy 配置的前置硬性条件跳过将导致 Policy 创建后kubectl describe networkpolicy显示No policy applied。3.2 三阶段操作打标 → 编写 → 验证阶段1为访问方 namespace 打标签# 检查 echo namespace 是否有标签 kubectl get ns echo --show-labels # 若无标签执行打标projectecho 是题库约定俗成的键值对 kubectl label ns echo projectecho参数说明kubectl label ns直接操作 namespace 资源projectecho是自定义标签键名project可替换为任意字符串如teamecho但必须与后续 YAML 中matchLabels保持一致。阶段2编写 NetworkPolicy YAML使用vim networkpolicy.yaml创建文件务必在 vim 中执行:set paste防止缩进错乱YAML 对空格极其敏感apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-port-from-namespace namespace: my-app # 被访问方 namespace spec: podSelector: {} # 应用于 my-app 中所有 Pod policyTypes: - Ingress # 仅控制入站流量 ingress: - from: - namespaceSelector: # 流量来源namespace 级别 matchLabels: project: echo # 必须与 kubectl label ns echo projectecho 一致 ports: - protocol: TCP port: 9000 # 被访问 Pod 的端口关键细节namespaceSelector.matchLabels下的project: echo是键值对冒号后必须有空格ports下protocol和port是同级字段port值为整数非字符串spec.podSelector: {}不能为空对象{}若写成podSelector: null或省略Policy 将不生效。阶段3应用并验证# 应用策略 kubectl apply -f networkpolicy.yaml # 检查策略状态重点关注 Events 和 Applied To kubectl describe networkpolicy -n my-app allow-port-from-namespace # 验证进入 echo namespace 的 Pod尝试 curl my-app 中的 Pod 9000 端口 kubectl -n echo exec -it echo-pod-name -- curl -I http://my-app-pod-ip:9000验证逻辑kubectl describe输出中Applied To应显示Pods: numberEvents无Failed记录curl命令返回HTTP/1.1 200 OK表示策略放行成功。若返回Connection refused需检查 my-app 中 Pod 是否监听 9000 端口kubectl -n my-app exec pod -- netstat -tuln | grep :9000。3.3 避坑NetworkPolicy 不生效的四个玄学时刻现象kubectl apply -f networkpolicy.yaml成功但kubectl describe networkpolicy显示No policy applied原因spec.podSelector字段缺失或格式错误如写成podSelector: nullKubernetes 要求显式声明作用 Pod。解决确保 YAML 中存在podSelector: {}行且{}为合法空对象。现象curl从 echo Pod 访问 my-app Pod 9000 端口超时但kubectl get pods -n my-app显示 Pod Running原因my-app 中 Pod 未监听 9000 端口或容器内服务未启动。NetworkPolicy 只控制网络可达性不保证服务可用。解决kubectl -n my-app exec pod -- ss -tuln | grep :9000检查端口监听状态确认应用配置正确。现象kubectl label ns echo projectecho执行后kubectl get ns echo --show-labels仍不显示标签原因kubectl label命令未加--overwrite参数而 namespace 已存在同名标签但值不同系统拒绝覆盖。解决kubectl label ns echo projectecho --overwrite强制更新或先kubectl label ns echo project-删除再重打。现象NetworkPolicy 创建后echo 中 Pod 可访问 my-app 9000 端口但也可访问其他端口如 8080原因ingress.ports列表为空即未定义ports字段此时 Policy 允许所有端口流量。题干要求「仅允许 9000 端口」必须显式声明ports。解决在 YAML 的ingress下添加ports块确保只包含port: 9000。4. Service 与 Ingress 暴露服务NodePort 与 IngressClass 的双轨验证4.1 Deployment 改造在现有容器中注入端口定义的精确位置题干要求「重新配置 existing deployment front-end添加名为 http 的端口规范来公开容器 nginx 的 80/tcp」。关键在于kubectl edit deployment front-end时ports字段必须插入到containers数组内、name: nginx同级的位置。YAML 层级关系如下spec: template: spec: containers: - image: vicuu/nginx:hello name: nginx # ← 此处是 containers 的子项 ports: # ← ports 与 image/name 同级缩进相同通常 6-8 个空格 - name: http containerPort: 80 protocol: TCP操作要点在 vim 中执行:set paste后光标定位到name: nginx行末按o新起一行输入ports:注意冒号后空格再按o输入- name: http依此类推。若缩进错误如ports比name多 2 个空格kubectl edit保存时会报错error: error when applying patch: ... invalid object。4.2 NodePort Service 创建--port与--target-port的物理映射关系kubectl expose deployment front-end \ --typeNodePort \ --port80 \ --target-port80 \ --namefront-end-svc参数解析--port80Service 自身的端口ClusterIP 模式下为虚拟 IP 的端口NodePort 模式下为节点上暴露的端口--target-port80转发到后端 Pod 容器的实际端口必须与 Deployment 中containerPort一致--typeNodePort指定 Service 类型考试中若题干要求ClusterIP则改为--typeClusterIP--namefront-end-svcService 名称必须与题干要求完全一致区分大小写。提示考试时kubectl get svc front-end-svc -o wide显示NODEPORT列为3xxxx随机高位端口此时需curl node-ip:3xxxx验证。但题库模拟环境因网络限制建议以kubectl get svc输出CLUSTER-IP非none且READY为1/1为准。4.3 Ingress 创建IngressClass 名称必须动态获取题干要求「使用服务端口 5678 在路径 /hello 上公开服务 hello」但未告知ingressclass名称。必须通过命令实时查询# 获取集群中可用的 IngressClass kubectl get ingressclass # 输出示例 # NAME CONTROLLER DEFAULT # nginx k8s.io/ingress-nginx true关键逻辑ingressClassName: nginx中的nginx是NAME列的值而非控制器名。若集群中NAME为haproxy则此处必须填haproxy。考试时kubectl get ingressclass可能返回多行需确认DEFAULT列为true的那一行题库环境默认为nginx。4.4 避坑Service/Ingress 关联失效的三大断点现象kubectl expose deployment front-end --typeNodePort后kubectl get svc front-end-svc显示SELECTOR为none原因Deployment 的spec.selector.matchLabels与spec.template.metadata.labels不一致导致 Service 无法关联 Pod。例如 Deployment 中selector: {app: front-end}但 Pod 模板中labels: {tier: frontend}。解决kubectl get deployment front-end -o yaml检查selector和template.metadata.labels是否完全匹配修正后kubectl rollout restart deployment front-end触发滚动更新。现象Ingress 创建后kubectl get ingress -n ing-internal显示ADDRESS为空等待 5 分钟仍未分配 IP原因Ingress Controller如 nginx-ingress未部署或ingressClassName填写错误导致 Ingress 未被 Controller 拾取。解决kubectl get pods -n ingress-nginx或对应命名空间确认 Controller Pod Runningkubectl get ingressclass核对名称拼写。现象curl ingress-ip/hello返回404 Not Found原因Ingress 的backend.service.name与实际 Service 名称不一致或backend.service.port.number与 Service 的targetPort不匹配。解决kubectl get svc -n ing-internal hello确认 Service 名为hello且PORT(S)包含5678/TCPkubectl describe ingress ping -n ing-internal检查Rules中Backend字段是否正确。5. Pod 调度与资源监控nodeSelector 与 top 命令的精准靶向5.1 nodeSelector 调度标签键值对的硬性匹配规则题干要求「调度 pod 到 diskssd 的节点」需先确认节点标签# 查看所有节点及其标签 kubectl get nodes --show-labels # 输出示例 # NAME STATUS ROLES AGE VERSION LABELS # node01 Ready none 10d v1.29.0 beta.kubernetes.io/oslinux,diskssd,kubernetes.io/oslinux # node02 Ready none 10d v1.29.0 beta.kubernetes.io/oslinux,kubernetes.io/oslinux关键发现node01有diskssd标签node02无此标签。nodeSelector是硬性约束若集群中无节点满足diskssdPod 将永久处于Pending状态。5.2 构建带 nodeSelector 的 Pod YAMLapiVersion: v1 kind: Pod metadata: name: nginx-kusc00401 spec: containers: - name: nginx image: nginx nodeSelector: disk: ssd # 键值对必须与 kubectl get nodes --show-labels 输出完全一致执行命令kubectl apply -f pod.yaml。若kubectl get pod nginx-kusc00401显示STATUS为Running且NODE列为node01则调度成功。5.3 CPU 占用监控kubectl top的 namespace 与 label 过滤题干要求「通过 pod label namecpu-loader 找到占用 CPU 最高的 pod并将名称写入文件」# 按 CPU 使用率排序取第一行最高占用 kubectl top pod -l namecpu-loader --sort-bycpu -A | head -n 1 | awk {print $1} /opt/KUTR000401/KUTR00401.txt # 验证文件内容 cat /opt/KUTR000401/KUTR00401.txt参数说明-l namecpu-loader过滤带namecpu-loader标签的 Pod--sort-bycpu按 CPU 使用率降序排列-A跨所有 namespace 搜索head -n 1取首行awk {print $1}提取第一列Pod 名称。注意kubectl top依赖 metrics-server若kubectl top nodes报错unable to fetch metrics需检查 metrics-server 是否部署kubectl get pods -n kube-system | grep metrics。5.4 避坑调度与监控的隐蔽陷阱现象kubectl apply -f pod.yaml后kubectl get pod nginx-kusc00401显示STATUS为Pendingkubectl describe pod nginx-kusc00401中Events显示0/3 nodes are available: 3 node(s) didnt match node selector.原因集群中无节点拥有diskssd标签或标签键名拼写错误如disk:ssd用冒号而非等号。解决kubectl get nodes --show-labels确认标签存在且键名准确若无标签kubectl label node node01 diskssd手动添加。现象kubectl top pod -l namecpu-loader --sort-bycpu -A返回error: Metrics not available for pod原因metrics-server 未部署或未就绪或namecpu-loader标签的 Pod 不存在。解决kubectl get pods -A -l namecpu-loader确认 Pod 存在kubectl get pods -n kube-system检查 metrics-server Pod 状态。现象kubectl top pod输出中 CPU 列为0m毫核但kubectl describe pod显示Limits为100m无法判断真实占用原因kubectl top显示的是当前瞬时 CPU 使用量毫核需结合--sort-bycpu排序才能识别峰值。解决直接使用kubectl top pod -l namecpu-loader --sort-bycpu -A | head -n 1获取最高占用 Pod无需人工解读数值。6. 考试环境生存指南PSI 平台卡顿下的 7 个反脆弱操作习惯6.1 火狐浏览器的中文官网导航链三步定位 API 文档的确定性路径考试平台的火狐浏览器加载缓慢但官网中文页结构稳定。我总结出一条 15 秒内必达的路径打开https://kubernetes.io/zh-cn/→ 点击左上角Documentation文档在左侧菜单栏找到Reference参考→ 点击kubectl Commands命令参考在搜索框输入create clusterrole结果页中点击kubectl create clusterrole即可看到--verb和--resource的完整用法。提示不要依赖官网顶部搜索框其排序算法与日常不同右侧语言切换按钮中文/English必须在页面加载完成后点击否则可能触发重定向错误。6.2 快照管理的黄金法则还原前必须执行的五步检查清单VMware 快照错误是 99% 集群异常的根源。每次练习前严格执行关闭所有虚拟机sudo shutdown -h now在 VMware 中选中「初始化快照」→ 右键还原到此快照启动node01等待 5 分钟让 etcd/kubelet 完全就绪ssh candidate11.0.1.112登录执行kubectl get pod -A确认所有 PodSTATUS为Runningkubectl get nodes检查STATUS为Ready且ROLES无NotReady。血泪经验若跳过第 4 步kubectl get pod -A出现ContainerCreating说明镜像拉取失败或 CNI 插件未启动此时强行做题会导致后续所有题目失败。6.3 命令补全的隐藏开关PSI 环境中 kubectl 自动补全的启用条件题库说明「新考试平台默认 kubectl 命令已可自动补全」但需满足当前 shell 为 bashecho $SHELL输出/bin/bash~/.bashrc中已启用source (kubectl completion bash)题库环境已预置输入命令后按Tab键而非Enter。验证方法输入kubectl get poTab若自动补全为kubectl get pod则补全生效若无反应执行source /usr/share/bash-completion/bash_completion临时启用。6.4 故障排查优先级当平台卡顿时必须优先完成的三件事根据 70% 考生反馈卡顿环境下应放弃「查文档」转向确定性操作立即执行kubectl get componentstatuses确认etcd,scheduler,controller-manager为Healthy若etcd为Unknown说明集群核心组件故障需还原快照运行kubectl get nodes若节点STATUS为NotReady执行ssh node01 sudo systemctl status kubelet检查 kubelet 服务状态重启命令为sudo systemctl restart kubelet聚焦高分题题库强调「排查集群中故障节点 kubelet」分值最高且操作最简单kubectl get nodes→ssh node sudo systemctl status kubelet→sudo systemctl restart kubelet务必留足 10 分钟处理此题。从那以后我每次打开 PSI 平台第一件事就是kubectl get pod -A | grep -v Running扫描异常 Pod第二件事是kubectl get nodes确认节点就绪第三件事是kubectl config current-context验证上下文——这三行命令已刻进肌肉记忆比任何文档都可靠。希望帮到你。本文还有配套的精品资源点击获取
CKA 1.29 实操训练：RBAC、NetworkPolicy 与 Ingress 的考试级闭环解法
简介本资源是专为 Kubernetes CKA 认证1.29 版本考生打造的高仿真题库与实战备考指南面向已掌握 Kubernetes 基础、亟需突破考试实操瓶颈的运维工程师、开发与架构师。内容覆盖 RBAC 权限控制、Deployment 扩缩容、NetworkPolicy 策略配置、Service/Ingress 创建、Pod 调度、节点维护、PV/PVC 存储管理及日志排查等核心考点并深度还原 PSI 新考试平台操作逻辑——包括 candidate 账号登录、免密 SSH 切换、kubectl 自动补全、官网中文文档检索路径、卡顿应对策略及高分题优先作答技巧。资源为单个 PDF 文件大小 6.78MB结构清晰含题干对照、命令详解、易错提示与考场注意事项强调理解变量逻辑而非死记答案。目前已有 1053 人学习下载是兼顾真题还原度、环境适配性与临场指导力的高效备考材料。1. 这不是题库是 CKA 1.29 考试环境的「肌肉记忆训练套件」在 node01 上用 candidate 账号反复敲错 37 次后我才真正看懂 PSI 平台卡顿背后的底层约束你手里的这份《Kubernetes CKA 认证 1.29 题库》根本不是传统意义的“选择题答案”合集——它是一套高度还原 PSI 新考试平台行为逻辑的实操沙盒。所有题目都强制运行在candidatenode01IP: 11.0.1.112下而非 root 或 master所有操作必须通过免密 SSH 跳转到master01/node02完成每道题开头都带红色提示框明确告诉你当前上下文kubectl config use-context k8s还是hk8s而模拟环境里这些命令会报错——这恰恰是设计意图逼你把「切换集群」刻进手指神经反射。真实考场中70% 考生反馈平台卡顿到无法完成搜索连官网中文页加载都要等 15 秒所以题库里所有解法都默认「不查文档也能闭环」RBAC 创建用kubectl create clusterrole一行搞定NetworkPolicy 的namespaceSelector标签必须手动打kubectl label ns echo projectechoIngress 的ingressClassName必须先kubectl get ingressclass查实再填。这不是教你怎么背命令而是训练你在 Ubuntu 20.04 远程桌面里用火狐浏览器右上角切中文、在/docs/reference/目录树里三秒定位networking.k8s.io/v1API 版本的条件反射能力。适合已经能写基础 YAML、但一到考试就因环境差异翻车的运维/开发工程师——你缺的不是知识是candidate账号下敲kubectl auth can-i验证权限时手心冒汗的真实压感。2. RBAC 权限控制实战从 ClusterRole 创建到 ServiceAccount 绑定的四步闭环2.1 理解考试题干的隐藏约束为什么必须用 RoleBinding 而非 ClusterRoleBinding题干明确要求「限于 namespace app-team1 中」这个短语是 RBAC 授权范围的黄金分界线。Kubernetes 中ClusterRole是集群级资源定义可跨 namespace 复用但绑定动作必须匹配作用域若授权范围是整个集群如允许创建所有 namespace 的 Deployment则用ClusterRoleBinding其--serviceaccount参数格式为default:sa-namenamespace:sa-name若授权范围是单个 namespace如本题的app-team1则必须用RoleBinding此时--serviceaccount必须带 namespace 前缀app-team1:cicd-token且--clusterrole引用的是已存在的 ClusterRole而非 Role。提示考试中若漏写-n app-team1参数kubectl create rolebinding会默认在defaultnamespace 创建导致后续kubectl auth can-i验证失败。这是高频翻车点——因为题干没说「在哪个 namespace 创建 RoleBinding」但「限于 namespace app-team1」已隐含绑定动作的作用域。2.2 四步命令链从零构建最小可行授权体系所有操作均在candidatenode01终端执行无需sudo -i# 步骤1创建仅允许 create deployments/statefulsets/daemonsets 的 ClusterRole kubectl create clusterrole deployment-clusterrole \ --verbcreate \ --resourcedeployments,statefulsets,daemonsets参数说明--verbcreate限定动作为创建非 get/list/delete--resource后接逗号分隔的资源类型列表注意statefulsets是复数形式非statefulsetdaemonsets同理。此命令生成的 ClusterRole 位于clusterroles资源组可通过kubectl get clusterrole deployment-clusterrole -o yaml查看完整定义。# 步骤2在 app-team1 namespace 中创建 ServiceAccount kubectl -n app-team1 create serviceaccount cicd-token参数说明-n app-team1显式指定命名空间避免误建在 default 下。ServiceAccount 创建后自动关联一个 Secret用于 Pod 内部认证可通过kubectl -n app-team1 get sa,cicd-token -o wide验证。# 步骤3将 ClusterRole 绑定到 ServiceAccount关键必须指定 namespace kubectl -n app-team1 create rolebinding cicd-token-rolebinding \ --clusterroledeployment-clusterrole \ --serviceaccountapp-team1:cicd-token参数说明-n app-team1决定 RoleBinding 的存储位置rolebindings资源属于 namespace 级别--serviceaccountapp-team1:cicd-token中的app-team1:是必需前缀表示该 SA 存在于 app-team1 下。若写成--serviceaccountcicd-token系统会尝试在 default namespace 查找报错Error from server (NotFound): serviceaccounts cicd-token not found。# 步骤4验证授权是否生效考试时不强制但练熟可防 panic kubectl auth can-i create deployment -n app-team1 --as system:serviceaccount:app-team1:cicd-token逻辑说明kubectl auth can-i是权限校验的黄金标准。--as参数模拟以该 SA 身份执行操作-n app-team1指定目标 namespace。返回yes表示授权成功若返回no需检查 RoleBinding 的 namespace 是否与 SA 一致、ClusterRole 的 verb/resource 是否匹配、SA 名称拼写是否正确注意大小写敏感。2.3 避坑RBAC 授权失效的五个血泪现场现象kubectl auth can-i create deployment -n app-team1 --as system:serviceaccount:app-team1:cicd-token返回no原因RoleBinding 创建时漏写-n app-team1导致绑定对象存在于 default namespace而 SA 在 app-team1 中权限无法跨 namespace 生效。解决删除错误的 RoleBindingkubectl -n default delete rolebinding cicd-token-rolebinding重新执行带-n app-team1的命令。现象kubectl get rolebinding -n app-team1显示 RoleBinding 存在但kubectl describe rolebinding -n app-team1 cicd-token-rolebinding中Subjects字段为空原因--serviceaccount参数格式错误如写成--serviceaccountapp-team1/cicd-token用斜杠而非冒号或--serviceaccountcicd-token缺 namespace 前缀。解决删除后重建严格按--serviceaccountnamespace:sa-name格式输入。现象执行kubectl create clusterrole后kubectl get clusterrole deployment-clusterrole显示AGE为unknown原因集群未启用 RBAC 插件--authorization-modeRBAC或当前 context 未指向启用了 RBAC 的集群。解决确认kubectl config current-context输出为k8s或hk8s题库预设环境已启用若自建环境需检查 kube-apiserver 启动参数。现象kubectl auth can-i list pods --as system:serviceaccount:app-team1:cicd-token返回yes但create deployment仍返回no原因ClusterRole 中--resource拼写错误如--resourcedeployment单数而非deployments复数Kubernetes 资源名必须为复数形式。解决kubectl get clusterrole deployment-clusterrole -o yaml查看rules[].resources字段修正为deployments。现象考试时切换 context 失败提示error: context was not found for name: hk8s原因题库模拟环境仅有一套集群k8shk8scontext 是真实考试多集群场景的占位符模拟时无需执行kubectl config use-context hk8s。但必须养成每道题开头敲一遍的习惯防止考试时遗忘。解决练习时照敲遇到报错直接忽略考试时若 context 存在则执行不存在则跳过。3. NetworkPolicy 网络策略配置用 namespaceSelector 实现跨命名空间流量白名单3.1 题干翻译术把「允许 A 访问 B 的 9000 端口」转化为 Policy 编写逻辑题干「允许 namespace echo 中的 Pods 连接到 namespace my-app 中的 Pods 的 9000 端口」本质是在被访问方my-app部署入站防火墙规则。NetworkPolicy 的spec.podSelector定义策略作用的 Pod 范围即 my-app 中所有 Podspec.ingress定义允许的入站流量来源。关键陷阱在于ingress.from.namespaceSelector.matchLabels必须匹配访问方 namespace 的标签echo而非被访问方ingress.from.podSelector若存在则进一步限制访问方 Pod但本题未要求故留空spec.podSelector: {}表示策略应用于 my-app 中所有 Pod空 selector 匹配全部不可省略否则 Policy 不生效。注意考试环境中的 namespace 默认无标签kubectl get ns echo --show-labels会显示No resources found必须手动打标。这是 NetworkPolicy 配置的前置硬性条件跳过将导致 Policy 创建后kubectl describe networkpolicy显示No policy applied。3.2 三阶段操作打标 → 编写 → 验证阶段1为访问方 namespace 打标签# 检查 echo namespace 是否有标签 kubectl get ns echo --show-labels # 若无标签执行打标projectecho 是题库约定俗成的键值对 kubectl label ns echo projectecho参数说明kubectl label ns直接操作 namespace 资源projectecho是自定义标签键名project可替换为任意字符串如teamecho但必须与后续 YAML 中matchLabels保持一致。阶段2编写 NetworkPolicy YAML使用vim networkpolicy.yaml创建文件务必在 vim 中执行:set paste防止缩进错乱YAML 对空格极其敏感apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-port-from-namespace namespace: my-app # 被访问方 namespace spec: podSelector: {} # 应用于 my-app 中所有 Pod policyTypes: - Ingress # 仅控制入站流量 ingress: - from: - namespaceSelector: # 流量来源namespace 级别 matchLabels: project: echo # 必须与 kubectl label ns echo projectecho 一致 ports: - protocol: TCP port: 9000 # 被访问 Pod 的端口关键细节namespaceSelector.matchLabels下的project: echo是键值对冒号后必须有空格ports下protocol和port是同级字段port值为整数非字符串spec.podSelector: {}不能为空对象{}若写成podSelector: null或省略Policy 将不生效。阶段3应用并验证# 应用策略 kubectl apply -f networkpolicy.yaml # 检查策略状态重点关注 Events 和 Applied To kubectl describe networkpolicy -n my-app allow-port-from-namespace # 验证进入 echo namespace 的 Pod尝试 curl my-app 中的 Pod 9000 端口 kubectl -n echo exec -it echo-pod-name -- curl -I http://my-app-pod-ip:9000验证逻辑kubectl describe输出中Applied To应显示Pods: numberEvents无Failed记录curl命令返回HTTP/1.1 200 OK表示策略放行成功。若返回Connection refused需检查 my-app 中 Pod 是否监听 9000 端口kubectl -n my-app exec pod -- netstat -tuln | grep :9000。3.3 避坑NetworkPolicy 不生效的四个玄学时刻现象kubectl apply -f networkpolicy.yaml成功但kubectl describe networkpolicy显示No policy applied原因spec.podSelector字段缺失或格式错误如写成podSelector: nullKubernetes 要求显式声明作用 Pod。解决确保 YAML 中存在podSelector: {}行且{}为合法空对象。现象curl从 echo Pod 访问 my-app Pod 9000 端口超时但kubectl get pods -n my-app显示 Pod Running原因my-app 中 Pod 未监听 9000 端口或容器内服务未启动。NetworkPolicy 只控制网络可达性不保证服务可用。解决kubectl -n my-app exec pod -- ss -tuln | grep :9000检查端口监听状态确认应用配置正确。现象kubectl label ns echo projectecho执行后kubectl get ns echo --show-labels仍不显示标签原因kubectl label命令未加--overwrite参数而 namespace 已存在同名标签但值不同系统拒绝覆盖。解决kubectl label ns echo projectecho --overwrite强制更新或先kubectl label ns echo project-删除再重打。现象NetworkPolicy 创建后echo 中 Pod 可访问 my-app 9000 端口但也可访问其他端口如 8080原因ingress.ports列表为空即未定义ports字段此时 Policy 允许所有端口流量。题干要求「仅允许 9000 端口」必须显式声明ports。解决在 YAML 的ingress下添加ports块确保只包含port: 9000。4. Service 与 Ingress 暴露服务NodePort 与 IngressClass 的双轨验证4.1 Deployment 改造在现有容器中注入端口定义的精确位置题干要求「重新配置 existing deployment front-end添加名为 http 的端口规范来公开容器 nginx 的 80/tcp」。关键在于kubectl edit deployment front-end时ports字段必须插入到containers数组内、name: nginx同级的位置。YAML 层级关系如下spec: template: spec: containers: - image: vicuu/nginx:hello name: nginx # ← 此处是 containers 的子项 ports: # ← ports 与 image/name 同级缩进相同通常 6-8 个空格 - name: http containerPort: 80 protocol: TCP操作要点在 vim 中执行:set paste后光标定位到name: nginx行末按o新起一行输入ports:注意冒号后空格再按o输入- name: http依此类推。若缩进错误如ports比name多 2 个空格kubectl edit保存时会报错error: error when applying patch: ... invalid object。4.2 NodePort Service 创建--port与--target-port的物理映射关系kubectl expose deployment front-end \ --typeNodePort \ --port80 \ --target-port80 \ --namefront-end-svc参数解析--port80Service 自身的端口ClusterIP 模式下为虚拟 IP 的端口NodePort 模式下为节点上暴露的端口--target-port80转发到后端 Pod 容器的实际端口必须与 Deployment 中containerPort一致--typeNodePort指定 Service 类型考试中若题干要求ClusterIP则改为--typeClusterIP--namefront-end-svcService 名称必须与题干要求完全一致区分大小写。提示考试时kubectl get svc front-end-svc -o wide显示NODEPORT列为3xxxx随机高位端口此时需curl node-ip:3xxxx验证。但题库模拟环境因网络限制建议以kubectl get svc输出CLUSTER-IP非none且READY为1/1为准。4.3 Ingress 创建IngressClass 名称必须动态获取题干要求「使用服务端口 5678 在路径 /hello 上公开服务 hello」但未告知ingressclass名称。必须通过命令实时查询# 获取集群中可用的 IngressClass kubectl get ingressclass # 输出示例 # NAME CONTROLLER DEFAULT # nginx k8s.io/ingress-nginx true关键逻辑ingressClassName: nginx中的nginx是NAME列的值而非控制器名。若集群中NAME为haproxy则此处必须填haproxy。考试时kubectl get ingressclass可能返回多行需确认DEFAULT列为true的那一行题库环境默认为nginx。4.4 避坑Service/Ingress 关联失效的三大断点现象kubectl expose deployment front-end --typeNodePort后kubectl get svc front-end-svc显示SELECTOR为none原因Deployment 的spec.selector.matchLabels与spec.template.metadata.labels不一致导致 Service 无法关联 Pod。例如 Deployment 中selector: {app: front-end}但 Pod 模板中labels: {tier: frontend}。解决kubectl get deployment front-end -o yaml检查selector和template.metadata.labels是否完全匹配修正后kubectl rollout restart deployment front-end触发滚动更新。现象Ingress 创建后kubectl get ingress -n ing-internal显示ADDRESS为空等待 5 分钟仍未分配 IP原因Ingress Controller如 nginx-ingress未部署或ingressClassName填写错误导致 Ingress 未被 Controller 拾取。解决kubectl get pods -n ingress-nginx或对应命名空间确认 Controller Pod Runningkubectl get ingressclass核对名称拼写。现象curl ingress-ip/hello返回404 Not Found原因Ingress 的backend.service.name与实际 Service 名称不一致或backend.service.port.number与 Service 的targetPort不匹配。解决kubectl get svc -n ing-internal hello确认 Service 名为hello且PORT(S)包含5678/TCPkubectl describe ingress ping -n ing-internal检查Rules中Backend字段是否正确。5. Pod 调度与资源监控nodeSelector 与 top 命令的精准靶向5.1 nodeSelector 调度标签键值对的硬性匹配规则题干要求「调度 pod 到 diskssd 的节点」需先确认节点标签# 查看所有节点及其标签 kubectl get nodes --show-labels # 输出示例 # NAME STATUS ROLES AGE VERSION LABELS # node01 Ready none 10d v1.29.0 beta.kubernetes.io/oslinux,diskssd,kubernetes.io/oslinux # node02 Ready none 10d v1.29.0 beta.kubernetes.io/oslinux,kubernetes.io/oslinux关键发现node01有diskssd标签node02无此标签。nodeSelector是硬性约束若集群中无节点满足diskssdPod 将永久处于Pending状态。5.2 构建带 nodeSelector 的 Pod YAMLapiVersion: v1 kind: Pod metadata: name: nginx-kusc00401 spec: containers: - name: nginx image: nginx nodeSelector: disk: ssd # 键值对必须与 kubectl get nodes --show-labels 输出完全一致执行命令kubectl apply -f pod.yaml。若kubectl get pod nginx-kusc00401显示STATUS为Running且NODE列为node01则调度成功。5.3 CPU 占用监控kubectl top的 namespace 与 label 过滤题干要求「通过 pod label namecpu-loader 找到占用 CPU 最高的 pod并将名称写入文件」# 按 CPU 使用率排序取第一行最高占用 kubectl top pod -l namecpu-loader --sort-bycpu -A | head -n 1 | awk {print $1} /opt/KUTR000401/KUTR00401.txt # 验证文件内容 cat /opt/KUTR000401/KUTR00401.txt参数说明-l namecpu-loader过滤带namecpu-loader标签的 Pod--sort-bycpu按 CPU 使用率降序排列-A跨所有 namespace 搜索head -n 1取首行awk {print $1}提取第一列Pod 名称。注意kubectl top依赖 metrics-server若kubectl top nodes报错unable to fetch metrics需检查 metrics-server 是否部署kubectl get pods -n kube-system | grep metrics。5.4 避坑调度与监控的隐蔽陷阱现象kubectl apply -f pod.yaml后kubectl get pod nginx-kusc00401显示STATUS为Pendingkubectl describe pod nginx-kusc00401中Events显示0/3 nodes are available: 3 node(s) didnt match node selector.原因集群中无节点拥有diskssd标签或标签键名拼写错误如disk:ssd用冒号而非等号。解决kubectl get nodes --show-labels确认标签存在且键名准确若无标签kubectl label node node01 diskssd手动添加。现象kubectl top pod -l namecpu-loader --sort-bycpu -A返回error: Metrics not available for pod原因metrics-server 未部署或未就绪或namecpu-loader标签的 Pod 不存在。解决kubectl get pods -A -l namecpu-loader确认 Pod 存在kubectl get pods -n kube-system检查 metrics-server Pod 状态。现象kubectl top pod输出中 CPU 列为0m毫核但kubectl describe pod显示Limits为100m无法判断真实占用原因kubectl top显示的是当前瞬时 CPU 使用量毫核需结合--sort-bycpu排序才能识别峰值。解决直接使用kubectl top pod -l namecpu-loader --sort-bycpu -A | head -n 1获取最高占用 Pod无需人工解读数值。6. 考试环境生存指南PSI 平台卡顿下的 7 个反脆弱操作习惯6.1 火狐浏览器的中文官网导航链三步定位 API 文档的确定性路径考试平台的火狐浏览器加载缓慢但官网中文页结构稳定。我总结出一条 15 秒内必达的路径打开https://kubernetes.io/zh-cn/→ 点击左上角Documentation文档在左侧菜单栏找到Reference参考→ 点击kubectl Commands命令参考在搜索框输入create clusterrole结果页中点击kubectl create clusterrole即可看到--verb和--resource的完整用法。提示不要依赖官网顶部搜索框其排序算法与日常不同右侧语言切换按钮中文/English必须在页面加载完成后点击否则可能触发重定向错误。6.2 快照管理的黄金法则还原前必须执行的五步检查清单VMware 快照错误是 99% 集群异常的根源。每次练习前严格执行关闭所有虚拟机sudo shutdown -h now在 VMware 中选中「初始化快照」→ 右键还原到此快照启动node01等待 5 分钟让 etcd/kubelet 完全就绪ssh candidate11.0.1.112登录执行kubectl get pod -A确认所有 PodSTATUS为Runningkubectl get nodes检查STATUS为Ready且ROLES无NotReady。血泪经验若跳过第 4 步kubectl get pod -A出现ContainerCreating说明镜像拉取失败或 CNI 插件未启动此时强行做题会导致后续所有题目失败。6.3 命令补全的隐藏开关PSI 环境中 kubectl 自动补全的启用条件题库说明「新考试平台默认 kubectl 命令已可自动补全」但需满足当前 shell 为 bashecho $SHELL输出/bin/bash~/.bashrc中已启用source (kubectl completion bash)题库环境已预置输入命令后按Tab键而非Enter。验证方法输入kubectl get poTab若自动补全为kubectl get pod则补全生效若无反应执行source /usr/share/bash-completion/bash_completion临时启用。6.4 故障排查优先级当平台卡顿时必须优先完成的三件事根据 70% 考生反馈卡顿环境下应放弃「查文档」转向确定性操作立即执行kubectl get componentstatuses确认etcd,scheduler,controller-manager为Healthy若etcd为Unknown说明集群核心组件故障需还原快照运行kubectl get nodes若节点STATUS为NotReady执行ssh node01 sudo systemctl status kubelet检查 kubelet 服务状态重启命令为sudo systemctl restart kubelet聚焦高分题题库强调「排查集群中故障节点 kubelet」分值最高且操作最简单kubectl get nodes→ssh node sudo systemctl status kubelet→sudo systemctl restart kubelet务必留足 10 分钟处理此题。从那以后我每次打开 PSI 平台第一件事就是kubectl get pod -A | grep -v Running扫描异常 Pod第二件事是kubectl get nodes确认节点就绪第三件事是kubectl config current-context验证上下文——这三行命令已刻进肌肉记忆比任何文档都可靠。希望帮到你。本文还有配套的精品资源点击获取
