Kubernetes管理员CKA认证通关指南（2025年12月）
CKA 是由 Linux Foundation 与 Cloud Native Computing Foundation（CNCF）联合认证的 Kubernetes 管理员认证，旨在验证候选人具备管理生产级 Kubernetes 集群的核心技能与实操能力，CKA考试为开卷考试，可访问K8s官方文档，需重点掌握节点切换、资源配置、命令实操等核心技能，以下是详细备考指南。
目录
1、HPA 自动扩缩容
核心任务
在autoscale namespace 中创建一个名为apache-server 的新HorizontalPodAutoscaler(HPA)此 HPA 必须定位到 autoscale namespace 中名为apache-server的现有Deployment 。
将 HPA 设置为每个 Pod 的 CPU 使用率旨在 50% 。将其配置为至少有 1 个 Pod，且不超过 4 个 Pod 。此外，将缩小稳定窗口设置为 30 秒。
操作步骤
- 切换节点：
ssh cka000000（需在student@k8s-master1用户下执行）。 - 创建HPA：
kubectl -n autoscale autoscale deployment apache-server --cpu=50% --min=1 --max=4，提示“autoscaled”即为成功。 - 配置缩小稳定窗口：
kubectl -n autoscale edit hpa apache-server，在maxReplicas:4下方新增behavior配置（注意缩进）。
- 验证：
kubectl -n autoscale get hpa apache-server。 - 退回base节点：
exit。
关键要点
- 区分命名空间与命令中的“autoscale”（前者是命名空间，后者是扩容命令）。
- 稳定窗口配置需严格按照yaml缩进规范。
-
参考链接
https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/
2、Ingress
核心任务
如下创建新的 Ingress 资源：
名称： echo
Namespace： sound-repeater
使用Service 端口 8080 在 http://example.org/echo 上公开echoserver-service Service。
操作步骤
- 切换节点：
ssh cka000000。 - 查询ingressClassName：
kubectl get ingressclasses.networking.k8s.io（通常为nginx）。 - 创建ingress.yaml文件，配置apiVersion、metadata、annotations（重写目标）、spec等字段。
- 应用配置：
kubectl apply -f ingress.yaml，提示“created”即为成功。 - 验证：模拟环境用
curl http://example.org:30080/echo，考试用题目指定命令。 - 退回base节点：
exit。
关键要点
- annotations需添加
nginx.ingress.kubernetes.io/rewrite-target: "/"。 - pathType设为Prefix，service端口需准确匹配8080。
-
参考链接
https://kubernetes.io/docs/concepts/services-networking/ingress/
3、sidecar
核心任务
您需要将一个传统应用程序集成到Kubernetes 的日志架构(例如 kubectl logs)中。实现这个要求的通常方法是添加一个流式传输并置容器。
更新现有的synergy-leverager Deployment，
将使用busybox:stable 镜像，且名为sidecar 的并置容器，添加到现有的Pod 。新的并置容器必须运行以下命令：
/bin/sh -c "tail -n+1 -f /var/log/synergy-leverager.log"
使用挂载在 /var/log 的Volume，使日志文件synergy-leverager.log 可供并置容器使用。
除了添加所需的卷挂载之外，请勿修改现有容器的规范。
操作步骤
- 切换节点：
ssh cka000000。 - 导出Deployment配置：
kubectl get deployment synergy-leverager -o yaml > sidecar.yaml。 - 编辑yaml：添加sidecar容器配置（命令、镜像、卷挂载），并在spec下方添加emptyDir类型卷。
- 应用更新：
kubectl apply -f sidecar.yaml，提示“configured”即为成功。 - 验证：
kubectl get pod | grep synergy-leverager，需显示2/2 Running。
- 退回base节点：
exit。
关键要点
- 卷挂载路径必须为/var/log，确保日志文件共享。
- 国内环境可使用替代镜像，考试时需用题目指定镜像。
- 参考链接
https://kubernetes.io/docs/concepts/cluster-administration/logging
4、StorageClass
核心任务
首先，为名为rancher.io/local-path 的现有制备器，创建一个名为ran-local-path 的新StorageClass
将卷绑定模式设置为WaitForFirstConsumer
注意，没有设置卷绑定模式，或者将其设置为WaitForFirstConsumer 之外的其他任何模式，都将导致分数降低。
接下来，将ran-local-path StorageClass 配置为默认的StorageClass
请勿修改任何现有的 Deployment 和PersistentVolumeClaim，否则将导致分数降低。
操作步骤
- 切换节点：
ssh cka000000。 - 创建storage.yaml文件，配置metadata（含默认存储类注解）、provisioner和volumeBindingMode。
添加如下内容
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ran-local-path annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: rancher.io/local-path volumeBindingMode: WaitForFirstConsumer - 应用配置：
kubectl apply -f storage.yaml，提示“created”即为成功。 - 验证：
kubectl get storageclass，ran-local-path需标注“default”。 - 退回base节点：
exit。
关键要点
- 注解
storageclass.kubernetes.io/is-default-class: "true"是设置默认存储类的关键。 - 卷绑定模式不可错写，否则会扣分。
- 参考链接
https://kubernetes.io/docs/concepts/storage/storage-classes/
5、Service
核心任务
重新配置 spline-reticulator namespace 中现有的 front-end Deployment，以公开现有容器 nginx 的端口 80/tcp
创建一个名为 front-end-svc 的新 Service ，以公开容器端口 80/tcp
配置新的 Service ，以通过 NodePort 公开各个 Pod
操作步骤
- 切换节点：
ssh cka000000。 - 编辑Deployment：
kubectl -n spline-reticulator edit deployment front-end，在容器配置中添加ports字段（containerPort:80）。 - 创建NodePort服务：
kubectl -n spline-reticulator expose deployment front-end --type=NodePort --port=80 --target-port=80 --name=front-end-svc。
- 验证：
kubectl -n spline-reticulator get svc front-end-svc -o wide。 - 退回base节点：
exit。
关键要点
- 在线编辑Deployment时需注意缩进，错误修改可能导致配置回滚。
- 无需手动指定NodePort端口，集群会自动分配。
6、Pod 优先级 PriorityClass
核心任务
请执行以下任务：
为用户工作负载创建一个名为 high-priority 的新PriorityClass ，其值比用户定义的现有最高优先级类值小一。
修改在priority namespace 中运行的现有busybox-logger Deployment ，以使用 high-priority 优先级类。
确保busybox-logger Deployment 在设置了新优先级类后成功部署。
请勿修改在priority namespace 中运行的其他Deployment，否则可能导致分数降低。
操作步骤
- 切换节点：
ssh cka000000。 - 查询现有PriorityClass：
kubectl get priorityclass，排除系统默认类，确定用户自定义最高优先级值。 - 创建priority.yaml文件，配置value（最高值减1）、globalDefault:false。
vim priority.yaml
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 999999999 globalDefault: false description: "test" - 应用配置：
kubectl apply -f priority.yaml。 - 编辑Deployment：
kubectl -n priority edit deployment busybox-logger，添加priorityClassName: high-priority。 - 验证：
kubectl -n priority get deployment busybox-logger，确保Pod正常运行。 - 退回base节点：
exit。
关键要点
- 系统默认类（system-cluster-critical等）无需计入用户自定义优先级计算。
- Pod可能需要2分钟左右从Pending转为Running，可先进行下一题。
- 参考链接
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
7、Argo CD
核心任务
通过执行以下任务在集群中安装Argo CD：
添加名为argo 的官方Argo CD Helm 存储库。注意：Argo CD CRD 已在集群中预安装。
为argocd namespace 生成Argo CD Helm 图表版本 7.7.3 的模板，并将其保存到~/argo-helm.yaml ，
将图表配置为不安装 CRDs 。使用 Helm 安装Argo CD ，并设置发布名称为argocd ，使用与模板中相同的配置和版本（ 7.7.3），
将其安装在argocd namespace 中，并配置为不安装CRDs 。
注意：您不需要配置对 Argo CD 服务器 UI 的访问权限。
操作步骤
- 切换节点：
ssh cka000000。 - 添加Helm仓库：
helm repo add argo https://argoproj.github.io/argo-helm，更新仓库：helm repo update。 - 生成模板：
helm template argocd argo/argo-cd --namespace argocd --version 7.7.3 --set crds.install=false > ~/argo-helm.yaml。 - 安装Argo CD：
helm install argocd argo/argo-cd --namespace argocd --version 7.7.3 --set crds.install=false。 - 验证：
kubectl -n argocd get pods，存在相关Pod即可。 - 退回base节点：
exit。
关键要点
- 必须指定--set crds.install=false，因CRD已预安装。
- 模板生成与安装命令需严格匹配版本和配置。
8、PVC
核心任务
mariadb namespace 中的MariaDB Deployment 被误删除。请恢复该Deployment 并确保数据持久性。请按照以下步骤：
如下规格在mariadb namespace 中创建名为mariadb 的PersistentVolumeClaim (PVC)：访问模式为 ReadWriteOnce
存储为250Mi
集群中现有一个PersistentVolume。
您必须使用现有的PersistentVolume (PV)。
编辑位于~/mariadb-deployment.yaml 的MariaDB Deployment 文件，以使用上一步中创建的PVC。将更新的Deployment 文件应用到集群。
确保MariaDB Deployment 正在运行且稳定。
操作步骤
- 切换节点：
ssh cka000000。 - 查询PV的StorageClass：
kubectl get pv（通常为local-path）。 - 创建pvc.yaml文件，配置命名空间、storageClassName、访问模式和存储请求。
vim pvc.yaml
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mariadb namespace: mariadb spec: storageClassName: local-path accessModes: - ReadWriteOnce resources: requests: storage: 250Mi - 应用PVC：
kubectl apply -f pvc.yaml。 - 编辑Deployment文件：
vim ~/mariadb-deployment.yamlvolumes:
- name: mariadb-data
persistentVolumeClaim:
claimName: "mariadb" - 应用Deployment：
kubectl apply -f ~/mariadb-deployment.yaml。 - 验证：
kubectl -n mariadb get pod。 - 退回base节点：
exit。
关键要点
- PVC需与现有PV的StorageClass匹配，否则无法绑定。
- 只有创建Pod后，PVC才会显示绑定状态。
- 参考链接
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
9、Gateway
核心任务
将现有Web 应用程序从Ingress 迁移到Gateway API。您必须维护 HTTPS 访问权限。注意：集群中安装了一个名为nginx 的GatewayClass 。
首先，创建一个名为web-gateway 的Gateway ，主机名为gateway.web.k8s.local ，并保持现有名为web 的Ingress 资源的现有 TLS 和侦听器配置。
接下来，创建一个名为web-route 的HTTPRoute ，主机名为gateway.web.k8s.local ，并保持现有名为 web 的Ingress 资源的现有路由规则。
最后，删除名为web 的现有Ingress 资源。
操作步骤
- 切换节点：
ssh cka000000。 - 查询现有Ingress信息：
kubectl get ingress web -o yaml，记录TLS的secretName、路由路径和服务信息。 - 创建gateway.yaml，配置gatewayClassName（nginx）、HTTPS监听器和TLS证书引用。
vim gateway.yaml
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: web-gateway spec: gatewayClassName: nginx listeners: - name: https hostname: gateway.web.k8s.local port: 443 protocol: HTTPS tls: mode: Terminate certificateRefs: - name: web-cert kind: Secret group: "" - 应用Gateway：
kubectl apply -f gateway.yaml。 - 创建httproute.yaml，配置parentRefs（关联web-gateway）、主机名和后端服务路由。
- 应用HTTPRoute：
kubectl apply -f httproute.yaml。vim httproute.yaml
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: web-route spec: parentRefs: - name: web-gateway # 上面创建的 Gateway 名字 hostnames: - "gateway.web.k8s.local" # 题目要求的主机名 rules: - matches: - path: type: PathPrefix value: / # ingress 里的 paths path backendRefs: - name: web # ingress 里的 service name port: 80 # ingress 里的 service port number - 删除原Ingress：
kubectl delete ingress web。 - 退回base节点：
exit。
关键要点
- TLS模式设为Terminate，证书引用需准确匹配原Ingress的secretName。
- HTTPRoute的pathType和后端服务端口需与原Ingress一致。
- 参考链接
https://kubernetes.io/docs/concepts/services-networking/gateway/
10、NetworkPolicy
核心任务
从提供的YAML 样本中查看并应用适当的NetworkPolicy。
确保选择的 NetworkPolicy 不过于宽松，同时允许运行在 frontend 和backend namespaces 中的frontend 和backend Deployment 之间的通信。
首先，分析frontend 和 backend Deployment，以确定需要应用的NetworkPolicy 的具体要求。
接下来，检查位于 ~/netpol 文件夹中的NetworkPolicy YAML 示例。
注意：请勿删除或修改提供的示例。仅应用其中一个。否则可能会导致分数降低。
最后，应用启用frontend 和backend Deployment 之间的通信的NetworkPolicy，但不要过于宽容。
注意：请勿删除或修改现有的默认拒绝所有入站流量或出口流量NetworkPolicy。否则可能导致零分。
操作步骤
- 切换节点：
ssh cka000000。 - 查询命名空间标签：
kubectl get ns frontend backend --show-labels。 - 查询Pod标签：
kubectl -n frontend get pod --show-labels和kubectl -n backend get pod --show-labels。 - 查看默认拒绝策略：
kubectl -n backend get networkpolicies。 - 选择合适的NetworkPolicy：优先选择仅允许app=frontendPod访问app=backendPod的配置（如netpol2.yaml）。
- 应用配置：
kubectl apply -f ~/netpol/netpol2.yaml。 - 验证：
kubectl -n backend get networkpolicies。 - 退回base节点：
exit。
关键要点
- 避免选择过于宽松的策略（如允许整个命名空间通信）。
- 不可修改或删除默认拒绝策略，否则会零分。
11、定制资源定义 CRD
核心任务
验证已部署到集群的cert-manager 应用程序。
使用kubectl ，将cert-manager 所有定制资源定义（CRD）的列表，保存到~/resources.yaml 。
注意：您必须使用kubectl 的默认输出格式。请勿设置输出格式。否则将导致分数降低。
使用kubectl ，提取定制资源Certificate 的subject 规范字段的文档，并将其保存到 ~/subject.yaml 。
注意：您可以使用kubectl 支持的任何输出格式。如果不确定，请使用默认输出格式。
操作步骤
- 切换节点：
ssh cka000000。 - 检查cert-manager状态：
kubectl -n cert-manager get pods。 - 保存CRD列表：
kubectl get crds | grep cert-manager > ~/resources.yaml。 - 提取subject字段文档：
kubectl explain certificate.spec.subject > ~/subject.yaml。 - 验证文件内容：
cat resources.yaml和cat subject.yaml。 - 退回base节点：
exit。
关键要点
- 必须使用kubectl默认输出格式，不可自定义格式。
- explain命令可准确提取字段文档，无需手动编写。
12、ConfigMap
核心任务
名为nginx-static 的 NGINX Deployment 正在nginx-static namespace 中运行。它通过名为nginx-config 的ConfigMap 进行配置。
更新nginx-config ConfigMap 以仅允许TLSv1.2 TLSv1.3 连接。注意：您可以根据需要重新创建、重新启动或扩展资源。
操作步骤
- 切换节点：
ssh cka000000。 - 导出ConfigMap：
kubectl -n nginx-static get configmap nginx-config -o yaml > nginx-config.yaml。 - 编辑yaml：修改ssl_protocols为
TLSv1.2 TLSv1.3;，添加immutable: true。 - 删除原有ConfigMap：
kubectl -n nginx-static delete configmaps nginx-config。 - 重新创建：
kubectl apply -f nginx-config.yaml。 - 重启Deployment：
kubectl rollout restart deployment nginx-static -n nginx-static。 - 验证：
curl -k --tls-max 1.2 https://web.k8snginx.local。 - 退回base节点：
exit。
关键要点
- 不可变配置（immutable: true）需正确添加，修改前需先删除原有ConfigMap。
- MAC用户可能需要配置hosts文件映射Pod IP。
13、Calico
核心任务
文档地址
Flannel Manifest
https://github.com/flannel-io/flannel/releases/download/v0.26.1/kube-flannel.yml
Calico Manifest
https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml
Context
集群的 CNI 未通过安全审核，已被移除。您必须安装一个可以实施网络策略的新 CNI。
安装并设置满足以下要求的容器网络接口（CNI）：
选择并安装以下 CNI 选项之一：
Flannel 版本 0.26.1
Calico 版本 3.27.0
选择的 CNI 必须：让 Pod 相互通信、支持 Network Policy、 实施从清单文件安装（请勿使用 Helm）
操作步骤
- 切换节点：
ssh cka000000。 - 下载tigera-operator.yaml：
wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml。 - 部署operator：
kubectl create -f tigera-operator.yaml（使用create而非apply）。 - 查询Pod CIDR：
kubectl cluster-info dump | grep -i cluster-cidr（通常为192.168.0.0/16）。 - 下载custom-resources.yaml：
wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/custom-resources.yaml。 - 编辑yaml：修改cidr为查询到的Pod CIDR。
- 部署自定义资源：
kubectl create -f custom-resources.yaml。 - 验证：
kubectl -n calico-system get pod，等待Pod Running。 - 退回base节点：
exit。
关键要点
- Flannel不支持Network Policy，必须选择Calico。
- 两个yaml文件的下载地址需牢记（替换文件名即可）。
14、resources cpu 和 memory
核心任务
您管理一个WordPress 应用程序。由于资源请求过高，某些Pod 无法启动。
relative-fawn namespace 中的WordPress 应用程序包含：
具有 3 个副本的 WordPress Deployment
按如下方式调整所有 Pod 资源请求：
将节点资源平均分配给这 3 个 Pod
为每个 Pod 分配公平的 CPU 和内存份额
添加足够的开销以保持节点稳定
请确保，对容器和初始化容器使用完全相同的请求。您无需更改任何资源限制。
在更新资源请求时，暂时将WordPress Deployment 缩放为 0 个副本可能会有所帮助。
更新后，请确认：
WordPress 保持 3 个副本
所有 Pod 都在运行并准备就绪
操作步骤
- 切换节点：
ssh cka000000。 - 缩放副本为0：
kubectl -n relative-fawn scale deployment wordpress --replicas=0。 - 查询节点资源：
kubectl describe node k8s-master1，计算可用资源。 - 编辑Deployment：
kubectl -n relative-fawn edit deployment wordpress，调整containers和initContainers的requests（如CPU 80m、内存200Mi）。 - 恢复副本数：
kubectl -n relative-fawn scale deployment wordpress --replicas=3。 - 验证：
kubectl -n relative-fawn get pod，确保3个副本均Running。 - 退回base节点：
exit。
关键要点
- 必须先缩放为0再修改资源，否则新Pod可能无法启动。
- 无需修改limits，资源请求需留有余量以保持节点稳定。
15、etcd 修复
核心任务
kubeadm 配置的集群已迁移到新机器。它需要更改配置才能成功运行。
修复在机器迁移过程中损坏的单节点集群。
首先，确定损坏的集群组件，并调查导致其损坏的原因。注意：已停用的集群使用外部 etcd 服务器。
接下来，修复所有损坏的集群组件的配置。
注意：确保重新启动所有必要的服务和组件，以使更改生效。否则可能导致分数降低。
最后，确保集群运行正常。确保：
每个节点和所有 Pod 都处于 Ready 状态。
操作步骤
- 切换节点并提权：
ssh cka000000，sudo -i。 - 模拟故障（仅模拟环境）：
sh etcd-set.sh。 - 修复kube-apiserver：
vim /etc/kubernetes/manifests/kube-apiserver.yaml，确保--etcd-servers=https://127.0.0.1:2379。 - 重启kubelet：
systemctl daemon-reload，systemctl restart kubelet。 - 修复kube-scheduler：
vim /etc/kubernetes/manifests/kube-scheduler.yaml，调整requests.cpu为100m。 - 验证：
kubectl get nodes和kubectl -n kube-system get pod，异常Pod可删除后等待重启。 - 退回base节点：
exit（退root），exit（退节点）。
关键要点
- 需在root用户下操作，etcd服务器地址必须正确。
- 重启kubelet是配置生效的关键步骤。
16、cri-dockerd
核心任务
您的任务是为 Kubernetes 准备一个 Linux 系统。 Docker 已被安装，但您需要为 kubeadm 配置它。
完成以下任务，为 Kubernetes 准备系统：
设置 cri-dockerd ：
安装 Debian 软件包 ~/cri-dockerd_0.3.6.3-0.ubuntu-jammy_amd64.deb Debian 软件包使用 dpkg 安装。
启用并启动 cri-docker 服务
配置以下系统参数:
net.bridge.bridge-nf-call-iptables 设置为 1
net.ipv6.conf.all.forwarding 设置为 1
net.ipv4.ip_forward 设置为 1
net.netfilter.nf_conntrack_max 设置为 131072
确保这些系统参数在系统重启后仍然存在，并应用于正在运行的系统。
操作步骤
- 切换节点：
ssh cka000000。 - 安装cri-dockerd：
sudo dpkg -i ~/cri-dockerd_0.3.6.3-0.ubuntu-jammy_amd64.deb。 - 启用并启动服务：
sudo systemctl enable cri-docker，sudo systemctl start cri-docker，sudo systemctl status cri-docker。 - 配置系统参数：
sudo vim /etc/sysctl.conf，添加4个参数配置。在文件最末尾,添加,按G自动跳转到文件最后
net.bridge.bridge-nf-call-iptables = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.netfilter.nf_conntrack_max = 131072 - 生效参数：
sudo sysctl -p。 - 退回base节点：
exit。
关键要点
- 系统参数需添加到sysctl.conf以确保重启后生效。
- 服务状态需为active（running）。
通用考试注意事项
- 所有题目均需先切换到指定节点（ssh cka000000），完成后退回base节点（exit），否则可能零分。
- 多用tab键自动补全，考试支持该功能。
- 编辑yaml时注意缩进，错误缩进可能导致配置失效。
更多推荐
60
0- 0
已为社区贡献2条内容
所有评论(0)