前言：
CKA是一个线上的技术认证考试，具体是个什么样的认证网上的资料非常多，在此不重复了。
大家比较关心的问题大体集中在这几点：
1，CKA认证的含金量到底如何？
CKA 证书是云原生计算基金会CNCF组织的,它考察的是你是否具备足够管理 Kubernetes 集群的必备知识。考试形式是上机直接在集群上操作,非常考验个人知识的扎实程度和 Kubernetes 实践经验。它本身是非常细致、严谨的官方技术考试。目前来看关于这块技术的认证,不论是发证机构还是考核方式及难度,CKA看来都是很权威的
2，CKA认证的难易程度？
CKA认证考试的题目全部是实操题（多说一句和rhce这些线下考试基本一样，都是上机实操，区别仅仅是CKA是线上而已），没有任何一个选择题或者填空题之类的，而且经常听学员反馈考点设备的网络较卡，设备反应慢等问题，考试环境中需要你自己动手把所有的实操题全部完成才行，所以对于没有基础的学员来说还是有难度的，也就是说，会者不难，难者不会。
3，是否需要CKA认证？
我看过了比较多的各种各样的CKA题库，从实际的生产中来说，CKA认证里的很多部分是用不到的或者说很少会用到的，比如，集群的升级，etcd数据库的备份（通常etcd的备份都是脚本自动化完成），节点的维护等等这些。但，大部分的内容还是有实际的应用价值的。
综上，可以负责任的说，CKA认证还是有实际意义的，确实能够证明一个人对kubernetes集群的管理能力。
有官网有模拟考试两次的机会，两次正式考试的机会。
其实任何的考试都是一个窍门：勤学苦练 ，没有什么特别的技巧（天赋异禀的另说喽）。
本文计划以2022CKA考试题库为蓝本，每天详细记录5道题目的解题思路，解题方法。题库总计17道题目。
一，
RBAC
题目要求：
创建名称 deployment-clusterrole 的 ClusterRole，该⻆色具备创建 Deployment、Statefulset、 Daemonset 的权限，在命名空间 app-team1 中创建名称为 cicd-token 的 ServiceAccount，绑定 ClusterRole 到 ServiceAccount，且限定命名空间为 app-team1。
解题思路：
此题涉及四种资源：serviceAccount，clusterrole，rolebinding，namespace，本文的资源都使用缩写。
这里主要是考察三点，一个是给sa赋权，一个是sa和clusterrole的绑定，一个是限定命名空间，而绑定只有rolebinding是和命名空间有关，clusterrolebinding是无关命名空间的，因此，绑定需要使用rolebinding。
这里说明一下如何知道某个资源是和namespace有关联的：
例如，我们查询角色绑定 rolebinding 输出会有namespace
很明显，角色绑定rolebinding和namespace是绑定的
root@k8s-master:~# kubectl get rolebindings.rbac.authorization.k8s.io -A
NAMESPACE NAME ROLE AGE
default cicd-deployment ClusterRole/deployment-clusterrole 54m
default leader-locking-nfs-client-provisioner Role/leader-locking-nfs-client-provisioner 354d
ingress-nginx ingress-nginx Role/ingress-nginx 354d
ingress-nginx ingress-nginx-admission Role/ingress-nginx-admission 354d
kube-public kubeadm:bootstrap-signer-clusterinfo Role/kubeadm:bootstrap-signer-clusterinfo 369d
kube-public system:controller:bootstrap-signer Role/system:controller:bootstrap-signer 369d查看角色 role呢？输出会有namespace
很明显，role是和namespace绑定的
root@k8s-master:~# kubectl get roles.rbac.authorization.k8s.io -A
NAMESPACE NAME CREATED AT
default leader-locking-nfs-client-provisioner 2021-12-23T09:57:07Z
ingress-nginx ingress-nginx 2021-12-23T10:10:47Z
ingress-nginx ingress-nginx-admission 2021-12-23T10:10:49Z
kube-public kubeadm:bootstrap-signer-clusterinfo 2021-12-08T06:32:46Z查询集群角色 clusterrole呢？ 输出没有namespace
很明显，clusterrole是不和namespace绑定的
root@k8s-master:~# kubectl get clusterroles.rbac.authorization.k8s.io -A
NAME CREATED AT
admin 2021-12-08T06:32:43Z
calico-kube-controllers 2021-12-08T06:43:37Z
calico-node 2021-12-08T06:43:37Z
cluster-admin 2021-12-08T06:32:43Z查询集群角色绑定 clusterrolebinding呢？输出没有namespace
很明显，clusterrolebinding是不和namespace绑定的
root@k8s-master:~# kubectl get clusterrolebindings.rbac.authorization.k8s.io -A
NAME ROLE AGE
calico-kube-controllers ClusterRole/calico-kube-controllers 369d
calico-node ClusterRole/calico-node 369d
cluster-admin ClusterRole/cluster-admin 369d
ingress-nginx ClusterRole/ingress-nginx 354d
ingress-nginx-admission ClusterRole/ingress-nginx-admission 354d
kubeadm:get-nodes ClusterRole/kubeadm:get-nodes 369d
kubeadm:kubelet-bootstrap ClusterRole/system:node-bootstrapper 369d查询服务账号sa，输出是有namespace的，
很明显，serviceaccount是和namespace绑定的
root@k8s-master:~# kubectl get sa -A
NAMESPACE NAME SECRETS AGE
app-team1 cicd-token 1 85m
app-team1 default 1 354d
default default 1 369d
default nfs-client-provisioner 1 354d解题代码：
根据题目要求，得出应该有如下代码：
需要非常注意的是，rolebinding 一定要加namespace，否则此题不算通过。
root@k8s-master:~# kubectl create ns app-team1
Error from server (AlreadyExists): namespaces "app-team1" already exists
root@k8s-master:~# kubectl create sa cicd-token -n app-team1
error: failed to create serviceaccount: serviceaccounts "cicd-token" already exists
root@k8s-master:~# kubectl create clusterrole deployment-clusterrole --verb=create --resource=Deployment,StatefulSet,DaemonSet -n app-team1
Error from server (AlreadyExists): clusterroles.rbac.authorization.k8s.io "deployment-clusterrole" already exists
root@k8s-master:~# kubectl create rolebinding cicd-deployment --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token -n app-team1
error: failed to create rolebinding: rolebindings.rbac.authorization.k8s.io "cicd-deployment" already exists验证解题结果：
查看创建的资源
root@k8s-master:~# kubectl get sa cicd-token -n app-team1
NAME SECRETS AGE
cicd-token 1 96m
root@k8s-master:~# kubectl get clusterrole deployment-clusterrole
NAME CREATED AT
deployment-clusterrole 2022-12-13T02:52:51Z
root@k8s-master:~# kubectl get rolebindings.rbac.authorization.k8s.io cicd-deployment -n app-team1
NAME ROLE AGE
cicd-deployment ClusterRole/deployment-clusterrole 46s查看权限：
root@k8s-master:~# kubectl describe clusterroles.rbac.authorization.k8s.io deployment-clusterrole
Name: deployment-clusterrole
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [] [create]
deployments.apps [] [] [create]
statefulsets.apps [] [] [create]官网参考链接：使用 RBAC 鉴权 | Kubernetes （中文）
二，
节点调度
题目要求：
设置 ek8s-node-1 节点为不可用，重新调度该节点上的所有 pod
解题思路：
整个的节点维护的流程：
1）首先查看当前集群所有节点状态，例如共有四个节点都处于ready状态；
2）查看当前nginx两个副本分别运行在d-node1和k-node2两个节点上；
3）使用cordon命令将d-node1标记为不可调度；
4）再使用kubectl get nodes查看节点状态，发现d-node1虽然还处于Ready状态，但是同时还能被禁调度，代表新的pod将不会被调度到d-node1上。
5）再查看nginx状态，没有任何变化，两个副本仍运行在d-node1和k-node2上；
6）执行drain命令，将运行在d-node1上运行的pod平滑的赶到其他节点上；
7）再查看nginx的状态发现，d-node1上的副本已经被迁移到k-node1上；此时就可以对d-node1进行一些节点维护的操作，如升级内核，升级Docker等；
8）节点维护完后，使用uncordon命令解锁d-node1，使其重新变得可调度；
9）检查节点状态，发现d-node1重新变回Ready状态。因此，需要使用到三个命令，cordon，drain，uncordon，根据题目要求不需要恢复节点调度，因此，uncordon不需要使用，但恢复使用也没什么错。
解题步骤：
1，
查询节点状态和要维护节点内运行的pod，这里以k8s-node1节点作为维护对象
root@k8s-master:~# kubectl get no k8s-node1
NAME STATUS ROLES AGE VERSION
k8s-node1 Ready <none> 13h v1.22.2
root@k8s-master:~# kubectl get po -A -owide |grep k8s-node1
default front-end-6f94965fd9-dq7t8 1/1 Running 1 (173m ago) 13h 10.244.36.74 k8s-node1 <none> <none>
default guestbook-86bb8f5bc9-mcdvg 1/1 Running 1 (173m ago) 13h 10.244.36.77 k8s-node1 <none> <none>
default guestbook-86bb8f5bc9-zh7zq 1/1 Running 1 (173m ago) 13h 10.244.36.76 k8s-node1 <none> <none>
default nfs-client-provisioner-56dd5765dc-gp6mz 1/1 Running 2 (173m ago) 13h 10.244.36.72 k8s-node1 <none> <none>
default task-2-ds-pmlqw 1/1 Running 1 (173m ago) 13h 10.244.36.75 k8s-node1 <none> <none>
ing-internal nginx-app-68b95cb66f-qkkpx 1/1 Running 1 (173m ago) 13h 10.244.36.73 k8s-node1 <none> <none>
ingress-nginx ingress-nginx-controller-gqzgg 1/1 Running 1 (173m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
kube-system calico-node-g6rwl 1/1 Running 1 (173m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
kube-system kube-proxy-6ckmt 1/1 Running 1 (173m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
kube-system metrics-server-576fc6cd56-svg7q 1/1 Running 1 (173m ago) 13h 10.244.36.78 k8s-node1 <none> <none>2，
进入维护状态，查询是否为正确的维护状态
root@k8s-master:~# kubectl cordon k8s-node1
node/k8s-node1 cordoned
root@k8s-master:~# kubectl get no k8s-node1
NAME STATUS ROLES AGE VERSION
k8s-node1 Ready,SchedulingDisabled <none> 13h v1.22.23，
平滑驱逐该节点的所有pod除daemonset类资源
root@k8s-master:~# kubectl drain k8s-node1 --
--add-dir-header --client-certificate --grace-period --log-file= --pod-selector --skip-headers --user
--alsologtostderr --client-certificate= --grace-period= --log-file-max-size --pod-selector= --skip-log-headers --user=
--as --client-key --ignore-daemonsets --log-file-max-size= --profile --skip-wait-for-delete-timeout --username
--as= --client-key= --ignore-errors --log-flush-frequency --profile= --skip-wait-for-delete-timeout= --username=
--as-group --cluster --insecure-skip-tls-verify --log-flush-frequency= --profile-output --stderrthreshold --v
--as-group= --cluster= --kubeconfig --logtostderr --profile-output= --stderrthreshold= --v=
--cache-dir --context --kubeconfig= --match-server-version --request-timeout --timeout --vmodule
--cache-dir= --context= --log-backtrace-at --namespace --request-timeout= --timeout= --vmodule=
--certificate-authority --delete-emptydir-data --log-backtrace-at= --namespace= --selector --tls-server-name --warnings-as-errors
--certificate-authority= --disable-eviction --log-dir --one-output --selector= --tls-server-name=
--chunk-size --dry-run --log-dir= --password --server --token
--chunk-size= --force --log-file --password= --server= --token=
root@k8s-master:~# kubectl drain k8s-node1 --ignore-daemonsets --delete-emptydir-data --force
node/k8s-node1 already cordoned
WARNING: ignoring DaemonSet-managed Pods: default/task-2-ds-pmlqw, ingress-nginx/ingress-nginx-controller-gqzgg, kube-system/calico-node-g6rwl, kube-system/kube-proxy-6ckmt
evicting pod kube-system/metrics-server-576fc6cd56-svg7q
evicting pod default/guestbook-86bb8f5bc9-zh7zq
evicting pod default/front-end-6f94965fd9-dq7t8
evicting pod default/guestbook-86bb8f5bc9-mcdvg
evicting pod default/nfs-client-provisioner-56dd5765dc-gp6mz
evicting pod ing-internal/nginx-app-68b95cb66f-qkkpx
pod/guestbook-86bb8f5bc9-mcdvg evicted
pod/front-end-6f94965fd9-dq7t8 evicted
pod/guestbook-86bb8f5bc9-zh7zq evicted
pod/nfs-client-provisioner-56dd5765dc-gp6mz evicted
pod/metrics-server-576fc6cd56-svg7q evicted
pod/nginx-app-68b95cb66f-qkkpx evicted
node/k8s-node1 evicted4，
查看驱逐结果
root@k8s-master:~# kubectl get po -A -owide |grep k8s-node1
default task-2-ds-pmlqw 1/1 Running 1 (179m ago) 13h 10.244.36.75 k8s-node1 <none> <none>
ingress-nginx ingress-nginx-controller-gqzgg 1/1 Running 1 (179m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
kube-system calico-node-g6rwl 1/1 Running 1 (179m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
kube-system kube-proxy-6ckmt 1/1 Running 1 (179m ago) 13h 192.168.123.151 k8s-node1 <none> <none>
root@k8s-master:~# kubectl get no k8s-node1
NAME STATUS ROLES AGE VERSION
k8s-node1 Ready,SchedulingDisabled <none> 13h v1.22.2可以看到有许多不是daemonset控制器的pod已经被驱逐到其它节点了，此时这个节点是比较干净的。
5，
恢复节点调度，退出节点维护模式（不需要做）
root@k8s-master:~# kubectl uncordon k8s-node1
node/k8s-node1 uncordoned
root@k8s-master:~# kubectl get no k8s-node1
NAME STATUS ROLES AGE VERSION
k8s-node1 Ready <none> 13h v1.22.2官网参考链接： Kubectl Reference Docs
三，
集群升级组件
题目要求：
升级 master 节点为1.22.2，升级前确保drain master 节点，不要升级worker node 、容器 manager、 etcd、 CNI插件、DNS 等内容；
解题思路:
不升级worker node，也就是操作只在master节点，上一题的节点维护工作换到master了。
排除etcd升级，因为etcd是静态pod，不是daemonset部署，因此，upgrade的时候排除即可。
解题步骤：
切换 context
kubectl get nodes
ssh k8s-master
kubectl cordon k8s-master
kubectl drain k8s-master --ignore-daemonsets --force
apt-mark unhold kubeadm kubectl kubelet
apt-get update && apt-get install -y kubeadm=1.22.2-00 kubelet=1.22.2-00
kubectl=1.22.2-00
apt-mark hold kubeadm kubectl kubelet
kubeadm upgrade plan
kubeadm upgrade apply v1.22.2 --etcd-upgrade=false
systemctl daemon-reload && systemctl restart kubelet
//kubectl -n kube-system rollout undo deployment coredns 有些朋友建议
rollout coredns，
kubectl uncordon k8s-master
检查master节点状态以及版本
kubectl get node官网参考链接：升级 kubeadm 集群 | Kubernetes
四，
etcd的备份和还原
题目要求：
备份 https://127.0.0.1:2379 上的 etcd 数据到 /var/lib/backup/etcd-snapshot.db，使用之前的备份文件 /data/backup/etcd-snapshot-previous.db 还原 etcd，使用指定的 ca.crt 、 etcd-client.crt 、 etcd-client.key
解题思路：
这个没什么好说的，网上看的很多人有什么第二种方法，第三种方法什么的，没必要，就一个最标准的方法就行了。
注意：如果执行时，提示permission denied，则是权限不够，命令最前面加sudo即可。
备份：
ETCDCTL_API=3 etcdctl --endpoints https://172.0.0.1:2379 --
cacert=/opt/KUIN00601/ca.crt --cert=/opt/KUIN00601/etcd-client.crt --
key=/opt/KUIN00601/etcd-client.key snapshot save /var/lib/backup/etcd-snapshot.db
还原：
ETCDCTL_API=3 etcdctl --endpoints https://172.0.0.1:2379 --
cacert=/opt/KUIN00601/ca.crt --cert=/opt/KUIN00601/etcd-client.crt --
key=/opt/KUIN00601/etcd-client.key snapshot restore /data/backup/etcd-snapshotprevious.db
还原成功后，最好通过 get nodes 确定集群状态是正常的解题步骤：
先查看总共有多少pod：
root@k8s-master:~# kubectl get po -A |wc -l
24按题目要求备份etcd，生成备份文件/var/lib/backup/etcd-snapshot.db：
ETCDCTL_API=3 etcdctl \
--endpoints https://192.168.123.150:2379 \
--cacert=/opt/KUIN00601/ca.crt \
--cert=/opt/KUIN00601/etcd-client.crt \
--key=/opt/KUIN00601/etcd-client.key snapshot save /var/lib/backup/etcd-snapshot.db输出如下；
{"level":"info","ts":1670922988.1987517,"caller":"snapshot/v3_snapshot.go:68","msg":"created temporary db file","path":"/var/lib/backup/etcd-snapshot.db.part"}
{"level":"info","ts":1670922988.2269363,"logger":"client","caller":"v3/maintenance.go:211","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1670922988.2272522,"caller":"snapshot/v3_snapshot.go:76","msg":"fetching snapshot","endpoint":"https://127.0.0.1:2379"}
{"level":"info","ts":1670922988.6475282,"logger":"client","caller":"v3/maintenance.go:219","msg":"completed snapshot read; closing"}
{"level":"info","ts":1670922988.6933029,"caller":"snapshot/v3_snapshot.go:91","msg":"fetched snapshot","endpoint":"https://127.0.0.1:2379","size":"9.4 MB","took":"now"}
{"level":"info","ts":1670922988.6935413,"caller":"snapshot/v3_snapshot.go:100","msg":"saved","path":"/var/lib/backup/etcd-snapshot.db"}
Snapshot saved at /var/lib/backup/etcd-snapshot.db还原etcd：
ETCDCTL_API=3 etcdctl --endpoints https://127.0.0.1:2379 --cacert=/opt/KUIN00601/ca.crt --cert=/opt/KUIN00601/server.crt --key=/opt/KUIN00601/server.key snapshot restore /data/backup/etcd-snapshot-previous.db输出如下：
2022-12-13T17:17:15+08:00 info snapshot/v3_snapshot.go:251 restoring snapshot {"path": "/data/backup/etcd-snapshot-previous.db", "wal-dir": "default.etcd/member/wal", "data-dir": "default.etcd", "snap-dir": "default.etcd/member/snap", "stack": "go.etcd.io/etcd/etcdutl/v3/snapshot.(*v3Manager).Restore\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdutl/snapshot/v3_snapshot.go:257\ngo.etcd.io/etcd/etcdutl/v3/etcdutl.SnapshotRestoreCommandFunc\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdutl/etcdutl/snapshot_command.go:147\ngo.etcd.io/etcd/etcdctl/v3/ctlv3/command.snapshotRestoreCommandFunc\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdctl/ctlv3/command/snapshot_command.go:128\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/remote/sbatsche/.gvm/pkgsets/go1.16.3/global/pkg/mod/github.com/spf13/cobra@v1.1.3/command.go:856\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/remote/sbatsche/.gvm/pkgsets/go1.16.3/global/pkg/mod/github.com/spf13/cobra@v1.1.3/command.go:960\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/remote/sbatsche/.gvm/pkgsets/go1.16.3/global/pkg/mod/github.com/spf13/cobra@v1.1.3/command.go:897\ngo.etcd.io/etcd/etcdctl/v3/ctlv3.Start\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdctl/ctlv3/ctl.go:107\ngo.etcd.io/etcd/etcdctl/v3/ctlv3.MustStart\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdctl/ctlv3/ctl.go:111\nmain.main\n\t/tmp/etcd-release-3.5.0/etcd/release/etcd/etcdctl/main.go:59\nruntime.main\n\t/home/remote/sbatsche/.gvm/gos/go1.16.3/src/runtime/proc.go:225"}
2022-12-13T17:17:15+08:00 info membership/store.go:119 Trimming membership information from the backend...
2022-12-13T17:17:16+08:00 info membership/cluster.go:393 added member {"cluster-id": "cdf818194e3a8c32", "local-member-id": "0", "added-peer-id": "8e9e05c52164694d", "added-peer-peer-urls": ["http://localhost:2380"]}
2022-12-13T17:17:16+08:00 info snapshot/v3_snapshot.go:272 restored snapshot {"path": "/data/backup/etcd-snapshot-previous.db", "wal-dir": "default.etcd/member/wal", "data-dir": "default.etcd", "snap-dir": "default.etcd/member/snap"}官网参考链接：为 Kubernetes 运行 etcd 集群 | Kubernetes
五，
配置网络策略 NetworkPolicy
题目要求：
题目解析：
本题需要根据官网资料来做一些修改，官网参考链接：网络策略 | Kubernetes ，第一个示例复制下来后，根据题目要求修改即可。修改后的文件内容如下；
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-port-from-namespace
namespace: fubar
spec:
podSelector:
matchLabels:
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
project: my-app
ports:
- protocol: TCP
port: 8080应用部署：
root@k8s-master:~# kubectl apply -f networkpolicy.yaml
networkpolicy.networking.k8s.io/allow-port-from-namespace created