企业官网建设流程全解析

简介：本资源是专为 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 新考试平台行为逻辑的实操沙盒。所有题目都强制运行在candidate@node01（IP: 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 project=echo），Ingress 的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-name（namespace: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 四步命令链：从零构建最小可行授权体系

所有操作均在candidate@node01终端执行，无需sudo -i：

# 步骤1：创建仅允许 create deployments/statefulsets/daemonsets 的 ClusterRole kubectl create clusterrole deployment-clusterrole \ --verb=create \ --resource=deployments,statefulsets,daemonsets

参数说明：--verb=create限定动作为创建（非 get/list/delete），--resource后接逗号分隔的资源类型列表，注意statefulsets是复数形式（非statefulset），daemonsets同理。此命令生成的 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 \ --clusterrole=deployment-clusterrole \ --serviceaccount=app-team1:cicd-token

参数说明：-n app-team1决定 RoleBinding 的存储位置（rolebindings资源属于 namespace 级别），--serviceaccount=app-team1:cicd-token中的app-team1:是必需前缀，表示该 SA 存在于 app-team1 下。若写成--serviceaccount=cicd-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 生效。
  解决：删除错误的 RoleBinding（kubectl -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参数格式错误，如写成--serviceaccount=app-team1/cicd-token（用斜杠而非冒号）或--serviceaccount=cicd-token（缺 namespace 前缀）。
  解决：删除后重建，严格按--serviceaccount=namespace:sa-name格式输入。

• 现象：执行kubectl create clusterrole后，kubectl get clusterrole deployment-clusterrole显示AGE为<unknown>
  原因：集群未启用 RBAC 插件（--authorization-mode=RBAC），或当前 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拼写错误，如--resource=deployment（单数）而非deployments（复数），Kubernetes 资源名必须为复数形式。
  解决：kubectl get clusterrole deployment-clusterrole -o yaml查看rules[].resources字段，修正为deployments。

• 现象：考试时切换 context 失败，提示error: context was not found for name: hk8s
  原因：题库模拟环境仅有一套集群（k8s），hk8scontext 是真实考试多集群场景的占位符，模拟时无需执行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 中所有 Pod），spec.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 # 若无标签，执行打标（project=echo 是题库约定俗成的键值对） kubectl label ns echo project=echo

参数说明：kubectl label ns直接操作 namespace 资源，project=echo是自定义标签，键名project可替换为任意字符串（如team=echo），但必须与后续 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 project=echo 一致 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: <number>，Events无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: null），Kubernetes 要求显式声明作用 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 project=echo执行后，kubectl get ns echo --show-labels仍不显示标签
  原因：kubectl label命令未加--overwrite参数，而 namespace 已存在同名标签但值不同，系统拒绝覆盖。
  解决：kubectl label ns echo project=echo --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 \ --type=NodePort \ --port=80 \ --target-port=80 \ --name=front-end-svc

参数解析：

• --port=80：Service 自身的端口（ClusterIP 模式下为虚拟 IP 的端口，NodePort 模式下为节点上暴露的端口）；
• --target-port=80：转发到后端 Pod 容器的实际端口（必须与 Deployment 中containerPort一致）；
• --type=NodePort：指定 Service 类型，考试中若题干要求ClusterIP则改为--type=ClusterIP；
• --name=front-end-svc：Service 名称，必须与题干要求完全一致（区分大小写）。

提示：考试时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 --type=NodePort后，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 Running；kubectl 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/TCP；kubectl describe ingress ping -n ing-internal检查Rules中Backend字段是否正确。

5. Pod 调度与资源监控：nodeSelector 与 top 命令的精准靶向

5.1 nodeSelector 调度：标签键值对的硬性匹配规则

题干要求「调度 pod 到 disk=ssd 的节点」，需先确认节点标签：

# 查看所有节点及其标签 kubectl get nodes --show-labels # 输出示例： # NAME STATUS ROLES AGE VERSION LABELS # node01 Ready <none> 10d v1.29.0 beta.kubernetes.io/os=linux,disk=ssd,kubernetes.io/os=linux # node02 Ready <none> 10d v1.29.0 beta.kubernetes.io/os=linux,kubernetes.io/os=linux

关键发现：node01有disk=ssd标签，node02无此标签。nodeSelector是硬性约束，若集群中无节点满足disk=ssd，Pod 将永久处于Pending状态。

5.2 构建带 nodeSelector 的 Pod YAML

apiVersion: 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 name=cpu-loader 找到占用 CPU 最高的 pod，并将名称写入文件」：

# 按 CPU 使用率排序，取第一行（最高占用） kubectl top pod -l name=cpu-loader --sort-by=cpu -A | head -n 1 | awk '{print $1}' > /opt/KUTR000401/KUTR00401.txt # 验证文件内容 cat /opt/KUTR000401/KUTR00401.txt

参数说明：-l name=cpu-loader过滤带name=cpu-loader标签的 Pod；--sort-by=cpu按 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为Pending，kubectl describe pod nginx-kusc00401中Events显示0/3 nodes are available: 3 node(s) didn't match node selector.
  原因：集群中无节点拥有disk=ssd标签，或标签键名拼写错误（如disk:ssd用冒号而非等号）。
  解决：kubectl get nodes --show-labels确认标签存在且键名准确；若无标签，kubectl label node node01 disk=ssd手动添加。

• 现象：kubectl top pod -l name=cpu-loader --sort-by=cpu -A返回error: Metrics not available for pod
  原因：metrics-server 未部署或未就绪，或name=cpu-loader标签的 Pod 不存在。
  解决：kubectl get pods -A -l name=cpu-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-by=cpu排序才能识别峰值。
  解决：直接使用kubectl top pod -l name=cpu-loader --sort-by=cpu -A | head -n 1获取最高占用 Pod，无需人工解读数值。

6. 考试环境生存指南：PSI 平台卡顿下的 7 个反脆弱操作习惯

6.1 火狐浏览器的中文官网导航链：三步定位 API 文档的确定性路径

考试平台的火狐浏览器加载缓慢，但官网中文页结构稳定。我总结出一条 15 秒内必达的路径：

1. 打开https://kubernetes.io/zh-cn/→ 点击左上角Documentation（文档）；
2. 在左侧菜单栏找到Reference（参考）→ 点击kubectl Commands（命令参考）；
3. 在搜索框输入create clusterrole，结果页中点击kubectl create clusterrole，即可看到--verb和--resource的完整用法。

提示：不要依赖官网顶部搜索框，其排序算法与日常不同；右侧语言切换按钮（中文/English）必须在页面加载完成后点击，否则可能触发重定向错误。

6.2 快照管理的黄金法则：还原前必须执行的五步检查清单

VMware 快照错误是 99% 集群异常的根源。每次练习前，严格执行：

1. 关闭所有虚拟机（sudo shutdown -h now）；
2. 在 VMware 中选中「初始化快照」→ 右键还原到此快照；
3. 启动node01，等待 5 分钟（让 etcd/kubelet 完全就绪）；
4. ssh candidate@11.0.1.112登录，执行kubectl get pod -A，确认所有 PodSTATUS为Running；
5. kubectl get nodes检查STATUS为Ready，且ROLES无NotReady。

血泪经验：若跳过第 4 步，kubectl get pod -A出现ContainerCreating，说明镜像拉取失败或 CNI 插件未启动，此时强行做题会导致后续所有题目失败。

6.3 命令补全的隐藏开关：PSI 环境中 kubectl 自动补全的启用条件

题库说明「新考试平台默认 kubectl 命令已可自动补全」，但需满足：

• 当前 shell 为 bash（echo $SHELL输出/bin/bash）；
• ~/.bashrc中已启用source <(kubectl completion bash)（题库环境已预置）；
• 输入命令后按Tab键，而非Enter。

验证方法：输入kubectl get po<Tab>，若自动补全为kubectl get pod，则补全生效；若无反应，执行source /usr/share/bash-completion/bash_completion临时启用。

6.4 故障排查优先级：当平台卡顿时，必须优先完成的三件事

根据 70% 考生反馈，卡顿环境下应放弃「查文档」，转向确定性操作：

1. 立即执行kubectl get componentstatuses：确认etcd,scheduler,controller-manager为Healthy，若etcd为Unknown，说明集群核心组件故障，需还原快照；
2. 运行kubectl get nodes：若节点STATUS为NotReady，执行ssh node01 sudo systemctl status kubelet检查 kubelet 服务状态，重启命令为sudo systemctl restart kubelet；
3. 聚焦高分题：题库强调「排查集群中故障节点 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验证上下文——这三行命令已刻进肌肉记忆，比任何文档都可靠。希望帮到你。

本文还有配套的精品资源，点击获取