企业官网建设流程全解析

1. 这套CKA真题到底考什么：整体观感与备考策略

Kubernetes CKA考试这几年题型一直挺稳定的，2020年4月2日这批真题属于典型的"基本功全覆盖"型试卷，没有偏题怪题，但有个显著特点——时长达3小时，题目量约17道左右，每道题分值不太均匀，越想拿高分越得注意时间分配。

我当时做这套题的整体感觉是：考得一点都不花哨，etcd备份，Pod创建，Service暴露，RBAC授权，Ingress配置，网络策略，持久化存储，节点维护，升级回滚，调度约束，基本把日常运维里最常用的场景都铺了一遍。难点不在某个知识点本身，而是多个知识点串在同一个场景里，比如给你一个Deployment，要求它通过某一个Service对外暴露，同时配上NetworkPolicy限制来源，这就把一个简单的"创建资源"升级成了"理解和掌控资源间关系"。

备考这套真题，我的建议是：别一上来就盯着YAML填空题去背，先把每个知识点的"为什么"弄明白。CKA不是考你背多熟，而是考你在终端环境里能不能快速、准确、不出错地完成运维动作。尤其是kubectl命令和YAML字段的对应关系，这个不熟练，考场上心态很容易崩。

需要说明一下，下面我写的题目描述和解答思路是基于常见CKA题型做的解构分析，重点在于把背后的原理和实操细节讲透，而不是逐字复述原题。

2. 考点拆解与核心原理：这些题到底在验证什么

2.1 集群备份与恢复：etcd是K8s的"命根子"

这套题里必有一道etcd备份恢复，通常是给你一个独立的etcd POD，要求你先用etcdctl打快照，然后模拟灾难场景，把快照恢复回去。很多人在这一步栽跟头，主要是因为对etcd工作方式不熟。

etcd存的是整个集群的"真相"，所有API对象、调度状态、集群配置全在里面。K8s控制平面的大脑是kube-apiserver，但它自己不记事儿，所有状态都交给etcd。所以备份集群，本质上就是备份etcd数据，这句话是CKA备考最重要的认知，没有之一。

实际操作时，有三个细节特别容易踩坑：

• etcdctl版本必须和etcd服务端匹配。V3 API和V2 API的命令格式完全不一样，如果你用的etcdctl是V2版本，执行etcdctl snapshot save会直接报错或不生效。考试环境里经常需要手动设置ETCDCTL_API=3环境变量，我看到很多人漏了这一步。
• 证书参数缺一不可。etcd走的是TLS双向认证，--cacert、--cert、--key三个参数少一个都连不上。更隐蔽的问题是证书路径，不同环境路径不一样，最好先通过ps -ef | grep etcd看看实际启动参数，照着参数拿路径。
• 恢复操作必须停掉API Server。恢复etcd不是简单地把快照文件复制回去，正确流程是：先停止所有控制平面组件的调度与写入，再把快照恢复到etcd数据目录，然后启动etcd，最后把控制平面组件拉起来。如果你不停组件直接覆盖数据目录，kube-apiserver缓存里还有旧数据，恢复完你会发现集群状态还是脏的。

2.2 RBAC权限控制：最小权限原则的实战化

RBAC几乎是CKA必考项，2020年这批题考的角色绑定场景很典型：创建一个ServiceAccount，创建一个Role或者ClusterRole，再创建一个RoleBinding或者ClusterRoleBinding，最后验证权限是否生效。它的核心知识点就是四个对象的搭配关系。

很多人对"什么情况用Role、什么情况用ClusterRole"分不清楚。我的理解是这样的：Role是命名空间级别的，它只能管某个namespace里的资源；ClusterRole是集群级别的，它能管所有namespace的资源，也能管节点、PersistentVolume这类非命名空间资源。如果你要授权的对象是跨namespace的，或者要管PV、StorageClass、Node这类全局资源，就必须用ClusterRole。

绑定也是同样的逻辑：RoleBinding可以把Role绑定到某个namespace里的用户，但它跨不了namespace；想全局生效就得用ClusterRoleBinding。这里有个容易忽略的点——RoleBinding可以绑定ClusterRole，这个设计非常常用，因为ClusterRole里定义了一组通用权限，你可以在不同的namespace里用RoleBinding去绑定同一个ClusterRole，这样既复用了权限定义，又只暴露给指定namespace，是很典型的最小权限做法。

验证权限是否生效的命令是kubectl auth can-i，比如kubectl auth can-i list pods --as=system:serviceaccount:default:my-sa，这个命令能模拟某个身份去测试一个操作是否被允许。注意--as后面传的是system:serviceaccount:<namespace>:<name>格式，这个格式很多人第一次写不对。

2.3 Ingress网络入口：流量路由的核心逻辑

CKA考Ingress通常不会让你从头搭一个Ingress Controller，而是给你一个已有的集群环境，要求创建一个Ingress资源，把某个Service的HTTP流量暴露出去，可能还要求指定路径和主机名。这道题暴露出来最多的问题是YAML里Ingress的apiVersion写错。

这里我必须特别强调一个版本坑：2020年那会儿，K8s 1.19之前Ingress的apiVersion是networking.k8s.io/v1beta1，1.19之后才稳定到networking.k8s.io/v1。考试环境用的K8s版本不同，GKV写法就不同，直接抄网上的老YAML必挂。稳妥做法是先kubectl explain ingress看当前环境的API版本，再动手写。

Ingress的路由逻辑说穿了就是"主机名+路径"到"Service+端口"的转发规则。一个Ingress可以配置多条规则，每条规则可以匹配多个路径。路径类型有Prefix和Exact两种，大部分场景用Prefix。很多人对路径的匹配逻辑理解有偏差，/foo作为Prefix会匹配/foo、/foo/bar，但不会匹配/foobar，这个边界一定要清楚。

2.4 NetworkPolicy网络策略：默认拒绝的安全网

NetworkPolicy这道题在2020年这套真题里分量不轻，因为它把所有流量模型都考了一遍。通常的要求是：创建一个NetworkPolicy，允许特定来源的Pod访问目标Pod的特定端口。

NetworkPolicy的底层机制是：它通过Linux内核的iptables或者更现代的网络插件规则实现，K8s本身只负责定义声明式的网络策略，真正执行靠CNI插件。这就意味着，如果你的集群网络插件是Flannel，那NetworkPolicy可能根本不生效，因为Flannel默认不支持这个特性；支持NetworkPolicy的常用插件是Calico。创建NetworkPolicy之前，先确认集群CNI是什么，这决定了你的策略会不会默默被忽略。

写NetworkPolicy时最容易漏的是podSelector不为空。如果你只定义了ingress规则但没写podSelector，那这个策略匹配不到目标Pod，等于白建。还有一个认知误区：Ingress规则里的from为空，表示允许所有来源访问；但如果整个NetworkPolicy里只写了ingress规则，没写egress规则，那么egress流量不受影响。理解"策略只影响它定义的流量方向"这个点，答题时逻辑才能清晰。

2.5 节点维护与Pod迁移：drain和cordon的正确姿势

节点维护题考得也很实在，通常场景是：某个Worker节点要下线维护，要求把上面的Pod全部安全迁移走，并且确保这个节点不会被调度新的Pod。完成这个任务只需要两个命令：kubectl cordon和kubectl drain，但这两个命令后面的含义值得说道说道。

kubectl cordon的作用是把节点标记为不可调度，已有的Pod不受影响，新Pod不会调度上去。kubectl drain更狠一点，它在cordon的基础上，会把节点上的Pod全部驱逐掉。但drain有个前提——你得加--ignore-daemonsets=true，因为DaemonSet控制的Pod（比如网络插件Pod、kube-proxy）是每个节点必须存在的，驱逐了也会立刻重建，不忽略的话drain命令会一直卡住不执行。

drain执行完，节点上的Pod会被重新调度到其他可用节点。这里要留个心眼：如果被驱逐的Pod由StatefulSet控制，或者有严格的PodDisruptionBudget（PDB）限制，drain过程可能会被PDB挡住，导致驱逐失败。遇到这种情况，要么临时调整PDB，要么确认业务可容忍后再操作。

维护完成后，恢复节点用kubectl uncordon，这个命令把节点重新标记为可调度。三个命令一套下来，节点维护的完整生命周期就闭环了。这个考点分值不高，但几乎是送分题，前提是你得像条件反射一样熟悉这三个命令。

3. 实操与逐题拆解：一套完整可落地的答题路径

3.1 第一类场景题：搭建一个"对外暴露的受控应用"

CKA很喜欢出这种组合题：创建Deployment，创建Service，再创建NetworkPolicy限制访问。如果要拿满分，三者的配合必须天衣无缝。我习惯的答题顺序是：先Deployment后Service再Policy，这个顺序符合逻辑依赖关系。

假设题目要求是：命名空间app下创建名为web的Deployment，镜像用nginx，副本数2，容器端口80，然后创建一个ClusterIP类型的Service，名字叫web-svc，端口80指向80，最后创建一个NetworkPolicy，只允许来自命名空间monitoring的Pod访问这个Service。

第一步，创建命名空间并确认它存在：

kubectl create ns app kubectl create ns monitoring

第二步，写Deployment的YAML。注意CKA考试环境通常不允许你用kubectl run直接生成YAML，有些版本会提示你用其他方式，所以自己写YAML更稳妥：

apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: app labels: app: web spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx ports: - containerPort: 80

kubectl apply -f deploy-web.yaml

第三步，创建Service。这里有个小技巧：直接用kubectl expose命令可以快速生成Service，但生成的YAML字段可能不够精细，比如targetPort没指定对。我的做法是先用kubectl create service clusterip web-svc --tcp=80:80 -n app --dry-run=client -o yaml > svc.yaml生成基础YAML，再手动确认字段准确后apply。

生成的YAML大致长这样：

apiVersion: v1 kind: Service metadata: name: web-svc namespace: app spec: ports: - port: 80 targetPort: 80 selector: app: web

Service的selector必须和Deployment的Pod模板labels完全匹配，这个匹配关系是Service流量路由到Pod的核心，核对一眼往往能省后面排查的半小时。

第四步，写NetworkPolicy。命名空间monitoring要能访问app命名空间里app=web的Pod，策略定义在目标Pod所在的命名空间：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring-to-web namespace: app spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: monitoring ports: - protocol: TCP port: 80

上面这个YAML里最关键的是namespaceSelector怎么选中目标命名空间。很多人以为直接写name: monitoring就行，但现在K8s版本里命名空间自动带labels，其中kubernetes.io/metadata.name是控制平面自动打上的。所以namespaceSelector.matchLabels用这个key即可精准匹配，如果省略这个label而是用name字段，反而容易漏。

第五步，验证整体链路。先看Pod状态：

kubectl get pods -n app -o wide

然后看Service的Endpoints是否就绪：

kubectl get endpoints web-svc -n app

如果Endpoints列表里有Pod IP，说明Service正常；如果没有，大概率是selector没匹配上，排查方向就是这个。NetworkPolicy的效果验证稍微麻烦一点，如果你有权限能够在monitoring命名空间跑一个临时Pod去curl目标Service，那最直接。没有条件的话，把YAML写对就等于答对了，考场上时间有限，不建议过度验证。

3.2 第二类场景题：RBAC权限精确实战

这类题的标准描述是：创建一个ServiceAccount名字叫deployer，创建一个ClusterRole叫deployer-role，它只允许对Deployment、StatefulSet、DaemonSet做create、delete、get、list、watch操作，然后把它们绑定到deployer上。

解题路径清晰，但每一步都有细节。

第一步，创建ServiceAccount：

kubectl create sa deployer -n default

第二步，写ClusterRole的YAML。这里要理解Role里resources、apiGroups、verbs三个字段的含义：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: deployer-role rules: - apiGroups: ["apps"] resources: ["deployments", "statefulsets", "daemonsets"] verbs: ["create", "delete", "get", "list", "watch"]

注意：Deployment、StatefulSet、DaemonSet都在apps组里，不在核心组""里。有人把apiGroups写成[""]，那就完全无效。核心组资源是Pod、Service、ConfigMap、Secret等，这三个控制器都不属于。

第三步，创建ClusterRoleBinding：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: deployer-binding subjects: - kind: ServiceAccount name: deployer namespace: default roleRef: kind: ClusterRole name: deployer-role apiGroup: rbac.authorization.k8s.io

这里有个必须遵守的规则：roleRef创建之后不可更改，所以绑定名称、角色名称写错了只能删掉重建，不能修。Subject里ServiceAccount的namespace也容易写漏，不写默认是空，绑定不会生效。

第四步，验证权限：

kubectl auth can-i create deployments --as=system:serviceaccount:default:deployer kubectl auth can-i delete pods --as=system:serviceaccount:default:deployer

第一条应该返回yes，第二条应该返回no。使用--as模拟身份验证是确认RBAC配置正确的最可靠手段，比靠猜强多了。考场上很多人做完不验证，结果漏配了某个verb，丢分很冤枉。

3.3 第三类场景题：etcd备份与恢复全流程

这道题是所有CKA题型里"容错率最低"的，因为恢复步骤环环相扣，一步错就全错。我给你的建议是把备份命令背成肌肉记忆。

题目一般给一个etcd Pod，名字类似etcd-master，在kube-system命名空间，etcd数据目录是/var/lib/etcd。备份命令如下：

export ETCDCTL_API=3 etcdctl --endpoints=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-snapshot.db

执行完检查快照状态：

etcdctl --write-out=table snapshot status /tmp/etcd-snapshot.db

注意：如果你用的是v3版本的etcdctl，--write-out要写在子命令后面，不是etcdctl --write-out=table snapshot status ...，有些版本对参数位置很敏感。另外，快照文件路径必须可写，/tmp目录一般没问题，但最好确认一下。

恢复流程是重头戏，我先给出一份可用的操作序列：

1. 找到etcd Pod：

kubectl get pods -n kube-system | grep etcd

2. 备份当前数据目录（出于安全习惯），然后停止kube-apiserver和etcd：

sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/ sudo mv /etc/kubernetes/manifests/etcd.yaml /tmp/

在静态Pod环境下，移动YAML文件会让kubelet停止对应容器。这个操作让控制平面暂时不再写数据。

3. 恢复快照：

sudo etcdctl --endpoints=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 restore /tmp/etcd-snapshot.db \ --data-dir=/var/lib/etcd-from-backup

4. 把恢复出来的数据目录挪到正确位置，并清理旧数据。

sudo mv /var/lib/etcd /var/lib/etcd.bak sudo mv /var/lib/etcd-from-backup /var/lib/etcd

5. 把之前挪走的YAML文件放回去，让kubelet重新拉起控制平面组件：

sudo mv /tmp/etcd.yaml /etc/kubernetes/manifests/ sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/

6. 等待集群恢复，验证Pod：

kubectl get pods -n kube-system kubectl get nodes

这套流程里我特别要提醒权限问题。etcd数据目录的所有者通常是etcd用户，你用root恢复数据后，目录owner可能变成root，etcd进程启动时可能因为权限拒绝而起不来。恢复完成后如果遇到权限问题，执行chown -R etcd:etcd /var/lib/etcd再重启，这个坑非常隐蔽。

还有一个容易被忽略的细节是，不同K8s版本的etcd数据目录结构有差异。K8s 1.20之后etcd数据目录可能带有member/子目录结构，restore工具会自动处理；但如果你手动复制，就必须保证目录结构完整。稳妥起见，restore命令的--data-dir参数指向一个全新的空目录，再整体挪过去，不要直接在原目录上恢复。

3.4 第四类场景题：节点升级与版本回退

这题在2020年的真题里出现过，而且分值不低。它模拟的是一个生产集群的Kubernetes版本升级场景，通常只要求你升级某一个Worker节点，从v1.19.x升到v1.20.y。这个场景下默认是kubeadm搭建的集群，所以升级路径很标准化。

有几点需要提前说清楚：

• 升级节点不等于升级集群证书，不要混淆两个概念。
• 升级的版本跳跃要受控，kubeadm官方支持小版本升级，你不能从v1.19直接跳到v1.21，CKA题目也不会这么出。
• 节点隔离先行，升级前先kubectl drain掉该节点，确保升级过程中业务Pod不受影响。

标准流程是这样：

1. 先排空目标节点：

kubectl drain <node-name> --ignore-daemonsets=true --delete-emptydir-data

2. SSH登录到目标节点，升级kubeadm：

apt-get update && apt-get install -y kubeadm=1.20.x-00

3. 执行升级规划检查：

kubeadm upgrade plan

4. 升级该节点的kubelet和kubectl：

apt-get install -y kubelet=1.20.x-00 kubectl=1.20.x-00

5. 重启kubelet：

sudo systemctl daemon-reload && sudo systemctl restart kubelet

6. 回到控制节点，解除隔离：

kubectl uncordon <node-name> kubectl get nodes

这个流程看着简单，但有个经常翻车的点：kubeadm upgrade plan在控制节点上执行，它告诉你的是集群内各节点的可升级版本，以及升级顺序是否符合要求。如果目标节点上有本地修改过的静态Pod清单或者非标准配置，升级过程可能失败。遇到失败直接看kubelet日志：

journalctl -u kubelet -f

日志会告诉你卡在哪里。大多数情况下是kubelet版本和kubeadm版本不一致，或者CGroup驱动配置有偏差。

3.5 第五类场景题：持久化存储的挂载与静态供给

CKA常见的存储题是：创建一个PersistentVolume，创建一个PersistentVolumeClaim，然后在Pod里把PVC挂载到指定路径。这道题的知识点其实是在考察你是否理解PV和PVC的生命周期绑定逻辑。

写PV的YAML时，有几个字段必须对齐，否则PVC永远绑定不上：

• storageClassName：如果集群里默认的StorageClass存在，你得显式把PV的storageClassName设为""，否则PVC会试图动态供给，导致绑定失败。
• accessModes：PV和PVC的访问模式必须一致，ReadWriteOnce（RWO）和ReadOnlyMany（ROX）混用直接绑定失败。
• capacity.storage：PVC请求的容量不能超过PV容量，这是绑定条件之一。

一个完整的静态PV长这样：

apiVersion: v1 kind: PersistentVolume metadata: name: pv-data spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv-data

PVC：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: ""

Pod挂载：

apiVersion: v1 kind: Pod metadata: name: pod-pvc spec: containers: - name: app image: nginx volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: pvc-data

做完之后验证：

kubectl get pv pvc -o wide

PV的状态从Available变成Bound，PVC的状态从Pending变成Bound，才算闭环。如果PVC一直Pending，先kubectl describe pvc看Events，里面会明确写"no persistent volumes available for this claim"或者"storageclass not found"这类错误。

这个题型的核心考点是"为什么不直接用hostPath挂在Pod上"，而是要用PV/PVC：因为PVC是命名空间隔离的，PV是集群级别的，这种分离使得存储资源可以被可靠地抽象和调度。理解了这一层，你写YAML时才会有意识地把字段对齐，而不是死记硬背。

4. 真题里的隐藏知识：版本差异与命令细节

4.1 版本差异是CKA最大的隐形杀手

2020年4月这批真题，K8s版本应该是1.17或1.18，具体版本我在实际练习时用的环境不完全一致。但CKA考试有一个特点：它不考最新功能，只考基础功能，但基础功能如果你不看版本，也会因为字段演进而踩坑。

以常见的Deployment为例，apiVersion: apps/v1是1.9之后稳定的，1.16开始extensions/v1beta1的Deployment完全废弃。截至2020年这个时间点，如果你写extensions/v1beta1去创建Deployment，在新版本里会直接报错。

Ingress的apiVersion也因为在1.19经历了一次演进，在2020年时写networking.k8s.io/v1beta1还合法。但考试环境如果已经是1.19+，这么写也能过，因为v1beta1依然能识别。不过到了1.22之后，v1beta1被移除，所以现在备考，我建议统一用networking.k8s.io/v1，这是最不会出错的写法。

还有kubectl drain的行为变化。早些年drain命令会自动忽略DaemonSet，现在则需要显式加--ignore-daemonsets=true，不加就报错或者卡住。如果你平时背的是老命令，考试时敲下去发现不执行，别慌，看一眼错误提示，补上参数就行。

4.2 kubectl技巧：在效率和安全之间平衡

CKA考试是允许查文档的，但考试界面的资源有限，快速查看字段定义的能力很关键。我总结了一套实用组合：

• kubectl explain pod.spec.containers：查字段结构，比翻文档快得多。
• kubectl api-resources：查某个资源属于哪个apiGroup，比如想看NetworkPolicy的apiVersion，这个命令最直接。
• kubectl create ... --dry-run=client -o yaml：生成YAML草稿，然后在此基础上改，比自己手写快一倍。

平日练习时，我还习惯做一个小动作——kubectl get events，这个命令在CKA考试时未必经常用，但排查问题时更直观。不过这里要注意，CKA的终端环境是受限的，很多操作需要sudo权限，而且严格控制输入范围。所以考试时不要想着用花哨的插件或者自写脚本，基础的kubectl命令就是全部。

一个高频踩坑点是kubectl edit和kubectl apply之间的选择。考试时很多人习惯先kubectl run生成一个Pod，然后kubectl edit去改YAML。这个方法可行，但edit是直接修改集群里的对象，如果你要改的是Deployment的镜像版本或副本数，没问题；如果你要改的是Pod的某个不可变字段（比如nodeName），edit会直接报错，因为你改了一个创建时不可变的字段。CKA常见操作里，kubectl rollout restart、kubectl scale这些命令比edit更安全高效，能用命令解决的，别用edit硬改。

5. 考场时间管理与实操节奏：真实作答顺序建议

CKA考场上最常见的失败原因不是不会做，而是时间不够。3小时17道题，平均每题10分钟多一点，碰到组合题往往要花20分钟以上。按我的经验，合理的作答顺序应该是：

首先做etcd备份恢复这类独立性强的题，因为它们分值高、步骤固定、做完就不回头。先把最容易拿的分拿到手，心态就稳了。

然后做RBAC、NetworkPolicy、Ingress这类配置题，它们需要的集群状态很简单，不存在跨题依赖。

最后做节点维护、升级这类需要命令交互多、耗时的题，因为这类题一般只占一个节点，做完就结束。

我整理了一个简略的时间分配参考：

这个表的意思不是严格照着分配，而是告诉你哪些题别恋战。遇到一道题卡住超过15分钟，我的建议是先把当前进度能保存的保存好，跳到下一题，回头有时间再补。CKA的评判是按题目点数给分的，你在难题上死磕20分钟，可能只拿几分，同样的时间做三道简单题，可能拿20分，这个账要算清楚。

还要提醒一个考场细节：每道题做完后要自己主动验证，不要等提交之后才意识到有问题。比如做完RBAC，立刻kubectl auth can-i验证；做完Ingress，立刻curl测试路由；做完etcd恢复，立刻kubectl get nodes看集群状态。考试界面上有所有节点的终端访问权限，不需要额外授权，这个动作的成本很低，收益却很大。

6. 模拟练习与自我检测：一道接近真题的组合演练

光看解析不练手，等于白学。我在这里给你设计一道高度接近真题风格的模拟练习题，你可以在这个基础上自己再扩展。

题目要求：

1. 在命名空间exam中创建一个Deployment，名为app-pod，镜像使用nginx:1.19，副本数3。
2. 为该Deployment创建一个ClusterIP类型的Service，名为app-svc，端口8080，targetPort 80。
3. 创建一个Ingress资源，主机名为exam.internal，路径/web转发到app-svc的8080端口。
4. 创建一个NetworkPolicy，只允许带有access: granted标签的Pod访问app-pod的80端口。
5. 创建一个ServiceAccount命名为scanner，绑定一个Role，该Role只允许对命名空间exam内的Pod执行get和list操作。

这是一个非常典型的CKA组合题，我把答题要点的检查清单列出来，你练完后逐条对照：

• [ ] Deployment的selector与template.metadata.labels是否一致？
• [ ] Service的selector是否能精确匹配Deployment的Pod labels？
• [ ] Ingress的apiVersion是否符合当前集群版本？
• [ ] Ingress的service.port是否填的是Service暴露的端口而不是容器端口？
• [ ] NetworkPolicy的podSelector是否选中了目标Pod？
• [ ] NetworkPolicy的namespaceSelector是否用了kubernetes.io/metadata.name？
• [ ] Role的apiGroups、resources、verbs三个字段是否都写对了？
• [ ] RoleBinding的subjects里ServiceAccount的namespace是否写了？

这个清单其实也是真实考试时我用来给自己兜底的方法，每道题做完花30秒过一遍，绝大多数低级错误都能被拦住。

动手练的时候，还有两点额外建议。第一，练习时不要开kubectl自动补全，逼自己把命令和参数都打熟，考场上敲命令的速度差个两三分钟，可能就是一道题能不能完成的分水岭。第二，给自己定时，按真实考场的时间标准来练习，比如这道组合题限时25分钟。刷题的目的不是会做，而是熟到不假思索就能把正确步骤做完。

7. 从真题到能力：通过CKA考试后我学到的几件事

这个标题看起来像总结，实际上我更想说的是做题之外的体会。CKA这张证书在业界的认可度一直不错，因为它不是背题库能过的，它考查的是你实际的问题解决能力。我备考这套真题时，最大的感受倒不是某个知识点有多难，而是K8s的运维思维和软件开发思维完全是两个维度。

开发思维是你只管自己的代码逻辑，运维思维是你得时刻考虑系统里其他组件之间的协作方式。比如etcd备份恢复，开发阶段你可能根本不关心这个组件，但在生产环境，它是整个集群的基石；比如NetworkPolicy，开发环境下你根本不会碰到跨命名空间流量控制的问题，但对一个多团队共享集群来说，这直接决定了安全边界在哪。

准备CKA的过程，其实是一个把零散知识体系化的过程。你在kubectl explain里看到的每个字段，在kubectl apply时产生的每个Event，背后都是K8s对分布式系统的一致性、调度、存储、网络的抽象。把这些抽象理解透，不仅仅是为了考试拿证，更是为了以后在生产环境里遇到问题时不慌。

我个人在备考和后续工作中的一个深刻体会是：考试题目会过时，但解题思路和方法论是长期有效的。比如版本差异的问题，任何时候考一个新版本的K8s，你都得先确认API版本和字段是否兼容，这个习惯比背下某个具体版本的知识点重要得多。再比如验证的习惯，无论你用什么工具，做什么操作，操作完之后用命令验证结果是否符合预期，这个习惯能避免大量低级失误。

如果你正在备考CKA，这套2020年4月2日的真题解析应该能给你一个相对完整的复习框架。我的建议是：不要只盯着题目的答案去背，而是把每一类题背后的设计意图搞清楚，理解K8s为什么这么设计，然后你自然就知道怎么操作了。等你真正上了考场，你会有一种感觉——这道题不就是在考察某个原理的具体应用吗？那时候，你会发现自己已经不是在应付考试了，而是在用K8s的方式思考和解决问题。