Kubernetes-CKA-exam考试答案及解析

Q1:权限控制RBAC

创建名称deployment-clusterrole的ClusterRole

该角色具备创建Deployment、Statefulset、Daemonset的权限

在命名空间app-team1中创建名称为cicd-token的ServiceAccount

绑定ClusterRole到ServiceAccount，且限定命名空间为app-team1

原题英文说明如下

解析&参考答案解析：需要熟悉创建serviceaccount、clusterrole和rolebinding的方法需要限定在ns级别，因此最好使用rolebinding

切换context

kubectlcreatensapp-team1kubectlcreateserviceaccountcicd-token-napp-team1kubectlcreateclusterroledeployment-clusterrole--verb=create--resource=deployment,statefulset,daemonsetkubectl-napp-team1createrolebindingcicd-clusterrole--clusterrole=deployment-clusterrole--serviceaccount=app-team1:cicd-token

当然也可从官文拷贝yaml并修改，然后apply即可注：经群友和读者提示，创建rolebinding的时候需要限制到指定ns即-napp-team1，不加的话会在defaultns中

说明当前考试版本为1.19.0考点链接

docs/reference/access-authn-authz/rbac

======

Q2:设置节点不可用设置ek8s-node-1节点为不可用重新调度该节点上的所有pod

原题英文说明如下：

解析&参考答案

cordon节点drain节点，需要忽略daemonsets并清除local-data，否则可能无法驱逐pod参考答案：切换context

kubectlcordonek8s-node-1kubectldrainek8s-node-1--ignore-daemonsets--delete-local-data--force

完成后一定要通过getnodes加以确认

说明当前考试版本为1.19.0考点链接

docs/tasks/administer-cluster/safely-drain-node

=====

Q3:升级kubeadm

升级master节点为1.20.1升级前确保drainmaster节点不要升级workernode、容器manager、etcd、CNI插件、DNS等内容

解析&参考答案解析：首先cordon、drainmaster节点其次升级kubeadm并apply到1.20.1版本升级kubelet和kubectl

参考答案：

切换context

kubectlgetnodessshmk8s-master-0kubectlcordonmk8s-master-0kubectldrainmk8s-master-0--ignore-daemonsetsapt-markunholdkubeadmkubectlkubeletapt-getupdate&&apt-getinstall-ykubeadm=1.20.1-00kubelet=1.20.1-00kubectl=1.20.1-00apt-markholdkubeadmkubectlkubeletkubeadmupgradeplankubeadmupgradeapplyv1.20.1--etcd-upgrade=false//kubectlrolloutundodeploymentcoredns-nkube-system,有些大佬建议rolloutcoredns，笔者考试的时候没有rolloverkubectluncordonmk8s-master-0

说明当前考试版本为1.19.0考点链接

tasks/administer-cluster/kubeadm/kubeadm-upgrade

=========Q4:备份还原etcd

题目概述备份:2379上的etcd数据到/var/lib/backup/etcd-snapshot.db

使用之前的文件/data/backup/etcd-snapshot-previous.db还原etcd

使用指定的ca.crt、etcd-client.crt、etcd-client.key

原题英文说明如下：

解析&参考答案解析：备份etcd到指定目录从指定备份文件还原etcd参考答案：备份：ETCDCTL_API=3etcdctl--endpoints:2379--cacert=/opt/xxx/ca.crt--cert=/opt/xxx/etcd-client.crt--key=/opt/xxx/etcd-client.keysnapshotsave/var/lib/backup/etcd-snapshot.db还原：ETCDCTL_API=3etcdctl--endpoints:2379--cacert=/opt/xxx/ca.crt--cert=/opt/xxx/etcd-client.crt--key=/opt/xxx/etcd-client.keysnapshotrestore/var/lib/backup/etcd-snapshot-previous.db

还原成功后，最好通过getnodes确定集群状态是正常的注意1：还原这里使用snapshotrestore，之前手误写成restoresave，经读者提醒已经更新注意2：笔者和一位考98分的群友沟通，他反馈还原这里存在一点问题(虽然笔者还原的时候没有报错),以下是他的思路(笔者后续会抽空测试下，然后重新整理下还原的参考答案)，建议最新读者自己学习时候尝试下这个思路1.restore的时候会在执行目录生成一个default.etcd的文件夹，里面是etcd的数据文件。2.然后切换到root，systemctlcatetcd看一下启动的时候的参数，etcd的数据目录在哪里。3.然后stopetcd，将之前的数据备份然后mvdefault.etcd,到配置文件指定的目录，给上属组和主都是etcd。然后启动etcd就行了

说明当前考试版本为1.19.0考点链接

tasks/administer-cluster/configure-upgrade-etcd

=======

Q5:配置网络策略NetworkPolicy题目概述在命名空间fubar中创建网络策略allow-port-from-namespace

只允许nsmy-app中的pod连上fubar中pod的80端口

注意:这里有2个ns，一个为fubar(目标pod的ns)，另外一个为my-app(访问源pod的ns)

原题英文说明如下：

解析&参考答案解析：

拷贝services-networking/network-policies中的案例，删掉不必要的部分设置网络策略所属的ns为fubar，端口为80设置namespaceSelector为源nsmy-app的labels参考答案：————————————————版权声明：本文为CSDN博主「昕光xg」的原创文章，遵循CC4.0BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：/u011127242/article/details/113962519

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-port-from-namespacenamespace:fubarspec:podSelector:matchLabels:{}policyTypes:-Ingressingress:-from:-namespaceSelector:matchLabels:my-app-key:my-app-valuepodSelector:#此处podSelector前不要加-，加了则表示furbar中的pod都可以访问furbar的80端口matchLabels:{}ports:-protocol:TCPport:80

注意：2月份之前的真题网络策略和来源的pod都是同一个ns，这次调整来源为my-app，而不是所有ns的pod都能访问fubar下pod的80端口；因此需要查看my-app的labels，然后在namespaceSelector中添加对应的labels；很多考过的小伙伴反应实际考试的时候没有label，因此建议实际考试的时候加一个label；由于之前刷题都是同一个ns，笔者考试的时候也忽略了这里有2个ns，这应该是笔者踩的一个坑。

网络策略测试本题有一些疑点，那就是题目希望my-app访问fubar下的80，而在实际中又没有给出ns的label，一般答题者估计也没有考虑到调整nslabel属性。笔者针对网络策略做了个测试，分别测试无label、有label、podSelector位置不同等3种情况下的效果，以验证笔者给的参考答案。

创建3个ns和对应的nginx、ubuntu

kubectlcreatensns-targetkubectlcreatensns-app1kubectlcreatensns-app2

kubectl-nns-targetcreatedeploymentnginx-target--image=nginx:1.19.4kubectl-nns-app1createdeploymentnginx-app1--image=nginx:1.19.4kubectl-nns-app2createdeploymentnginx-app2--image=nginx:1.19.4target:echo"hi,nginx-target!">/usr/share/nginx/html/index.htmlapp1:echo"hi,nginx-app1!">/usr/share/nginx/html/index.htmlapp2:echo"hi,nginx-app2!">/usr/share/nginx/html/index.html

kubectl-nns-targetcreatedeploymentubuntu-target--image=ubuntu:20.04--sleepinfinitykubectl-nns-app1createdeploymentubuntu-app1--image=ubuntu:20.04--sleepinfinitykubectl-nns-app2createdeploymentubuntu-app2--image=ubuntu:20.04--sleepinfinity在3个ubuntu中分别起81端口，python3-mhttp.server81&

kubectl-nns-targetexposedeploymentnginx-target--name=svc-nginx-target--port=80kubectl-nns-app1exposedeploymentnginx-app1--name=svc-nginx-app1--port=80kubectl-nns-app2exposedeploymentnginx-app2--name=svc-nginx-app2--port=80

测试连通性

获取svc，ep信息ns-app1service/svc-nginx-app1ClusterIP80<none>80/TCP17mns-app2service/svc-nginx-app2ClusterIP53<none>80/TCP17mns-targetservice/svc-nginx-targetClusterIP68<none>80/TCP17mns-app1endpoints/svc-nginx-app199:8017mns-app2endpoints/svc-nginx-app20:8017mns-targetendpoints/svc-nginx-target97:8017m测试访问(从ns-targe可以访问任意3个pod，当前集群内部全部互通，此处暂不挨个截图)：root@ubuntu-target-55887fbb7-f7rdm:/#curl99hi,nginx-app1!root@ubuntu-target-55887fbb7-f7rdm:/#curl0hi,nginx-app2!root@ubuntu-target-55887fbb7-f7rdm:/#curl97hi,nginx-target!

创建网络策略测试1，限制80端口，ingress的from不加任何限制:

在3个ubuntu实例中分别起一个81的服务python3-mhttp.server81&

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-port-from-namespacenamespace:ns-targetspec:podSelector:matchLabels:{}policyTypes:-Ingressingress:-from:-namespaceSelector:matchLabels:{}-podSelector:matchLabels:{}ports:-protocol:TCPport:80

此时app1和app2中都可以curltarget中的podip:80；由于网络策略的原因，app1和app2无法正常curltarget中的podip:81,删除网络策略后可以正常curlpodip:81

测试2，限制80端口，ingress的from限制namespaceSelector:

editns-app1,并添加labelmetadata:labels:ns:ns-app1

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:ns-namespace-selectornamespace:ns-targetspec:podSelector:matchLabels:{}policyTypes:-Ingressingress:-from:-namespaceSelector:matchLabels:ns:ns-app1-podSelector:matchLabels:{}ports:-protocol:TCPport:80

此时只有app1可以curltarget中的podip:80；由于网络策略的原因，app1和app2都无法正常curltarget中的podip:81,删除网络策略后可以正常curlpodip:81

如下图，ns-app1可以正常访问ns-target中的80端口，但是不能访问81端口；

ns-app2不可以访问ns-target中的80和81端口；

综合上述测试可以发现，如果需要限定某个nsA访问另外一个nsB，那么最好设置nsA的label，然后通过namespaceSelector加以限制即可。测试3，限制80端口，from中的namespaceSelector和podSelector的范围不同第一种情况，namespaceSelector和podSelector是2个对等的项，可以通过json形式表示from:[{namespaceSelector:{此处匹配label范围为namespaceSelector所在的ns}},{podSelector:{此处匹配对象范围为spec.podSelector所在ns，即NetworkPolicy所在的ns中的pod}}]-from:-namespaceSelector:matchLabels:ns:ns-app1-podSelector:matchLabels:{}

第二种情况，属于一个对象的2个子对象，可以通过json形式表示from:[{namespaceSelector:{限定ns},

podSelector:{限定namespaceSelector所在ns中指定的pod}}]-from:-namespaceSelector:matchLabels:ns:ns-app1podSelector:matchLabels:{}

测试结果如下图所示，第一种情况下ns-app1和ns-target中的pod都可以访问target中的80，第二种情况下只有ns-app1中的pod可以访问target中的80(target中的pod不能访问target中80端口)。

说明当前考试版本为1.19.0考点链接

docs/concepts/services-networking/network-policies

======

Q6:创建service

重新配置已有的deploymentfront-end，添加一个名称为http的端口，暴露80/TCP创建名称为front-end-svc的service，暴露容器的http端口配置service的类别为NodePort

原题英文说明如下：

解析&参考答案解析：按照需要editdeploy，添加端口信息通过expose命令使用NodePort的方式暴露端口参考答案：1）editfront-end，在containers中添加如下内容kubectleditdeploymentfront-endports:-name:httpprotocol:TCPcontainerPort:80

2）expose对应端口kubectlexposedeploymentfront-end--type=NodePort--port=80--target-port=80--name=front-end-svc

说明当前考试版本为1.19.0考点链接

docs/concepts/services-networking/service

======

Q7:按要求创建Ingress资源

Name:pingNamespace:ing-internalAddress:Defaultbackend:default-http-backend:80(<error:endpoints"default-http-backend"notfound>)Rules:HostPathBackends----------------*/hellohello:5678(:80,:80,:80)Annotations:nginx.ingress.kubernetes.io/rewrite-target:/Events:<none>

题目概述创建一个新的Ingress资源，名称ping，命名空间ing-internal使用/hello路径暴露服务hello的5678端口

原题英文说明如下：

解析&参考答案解析：拷贝官文的yaml案例，修改相关参数即可设置成功后需要通过curl-kl<INTERNAL_IP>/hello来测试参考答案：apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:pingnamespace:ing-internalannotations:nginx.ingress.kubernetes.io/rewrite-target:/spec:rules:-http:paths:-path:/hellopathType:Prefixbackend:service:name:helloport:number:5678创建成功后，通过getingress查看ingress的内外IP，然后通过提供的curl测试ingress是否正确，正常情况下是会输出hello的

说明当前考试版本为1.19.0考点链接

docs/concepts/services-networking/ingress

=====Q8:扩容deployment

扩容deploymentguestbook为6个pods

解析&参考答案解析：调整replicas为6即可，送分题

参考答案：

切换context

kubectlscaledeployment--replicas=6guestbook

说明当前考试版本为1.19.0考点链接

docs/tutorials/kubernetes-basics/scale/scale-intro

=====Q9:调度pod到指定节点

题目概述创建pod名称nginx-kusc0041，镜像nginx调度该pod到disk=ssd的节点上

原题英文说明如下：

解析&参考答案解析：拷贝官文案例，修改下pod名称和镜像，删除多余的部分即可，又是个送分题参考答案：

切换context

apiVersion:v1kind:Podmetadata:name:nginx-kusc0041spec:containers:-name:nginximage:nginxnodeSelector:disk:ssd

说明当前考试版本为1.19.0考点链接

docs/concepts/scheduling-eviction/assign-pod-node

=====

Q10:统计ready状态节点数量

题目概述统计ready状态节点要求不包括NoSchedule的节点

原题英文说明如下：

解析&参考答案解析：getnodes查看节点数量，grepNoSchedule查看节点NoSchedule节点数量计算两者之差，echo数据到指定文档即可，还是个送分题参考答案：

切换context

kubectlgetnodeskubectldescribenodes|grep-itaint|grepNoSchedule

两者数据相减，echonumber>/path/file

说明当前考试版本为1.19.0考点链接

docs/concepts/scheduling-eviction/taint-and-toleration

=====

Q11:创建多容器的pod

题目概述创建名称为kucc1的podpod中运行nginx和redis两个示例

原题英文说明如下：

解析&参考答案解析：dry-run一个pod，多追加一个镜像即可，又是一送分题参考答案：apiVersion:v1kind:Podmetadata:name:kucc1spec:containers:-name:nginximage:nginx-name:redisimage:redis

说明当前考试版本为1.19.0考点链接

docs/concepts/workloads/pods

=====

Q12:按要求创建PV

题目概述创建一个名为app-config的PV，PV的容量为2Gi，访问模式为ReadWriteMany，volume的类型为hostPathpv映射的hostPath为/srv/app-config目录

解析&参考答案解析：直接从官方拷贝合适的案例，修改参数，然后设置hostPath为/srv/app-config即可参考答案：

切换context

apiVersion:v1kind:PersistentVolumemetadata:name:app-configspec:capacity:storage:2GiaccessModes:-ReadWriteManyhostPath:path:/srv/app-config

说明当前考试版本为1.19.0考点链接

docs/concepts/storage/persistent-volumes

tasks/configure-pod-container/configure-persistent-volume-storage

=====

Q13:创建和使用PVC

题目概述使用指定storageclasscsi-hostpath-sc创建一个名称为pv-volume的pvc，容量为10Mi

创建名称为web-server的pod，将nginx容器的/usr/share/nginx/html目录使用该pvc挂载

将上述pvc的大小从10Mi更新为70Mi，并记录本次变更

解析&参考答案解析：

根据官方文档拷贝一个PVC，修改参数，不确定的地方就是用kubectl的explain即可通过dry-run+-oyaml形式生成一个nginx的pod，然后添加volumeMounts和volume(不熟悉的话直接从daemonset案例中拷贝下来加以修改就行)通过edit修改pvc，别忘了--record参数参考答案：

切换context

vim13.1.yamlapiVersion:v1kind:PersistentVolumeClaimmetadata:name:pv-volumespec:accessModes:-ReadWriteOnceresources:requests:storage:10MistorageClassName:csi-hostpath-sc

vim13.2.yamlapiVersion:v1kind:Podmetadata:name:web-serverspec:containers:-name:nginximage:nginxvolumeMounts:-mountPath:"/usr/share/nginx/html"name:mypvvolumes:-name:mypvpersistentVolumeClaim:claimName:pv-volume#13.3kubectleditpvcpv-volume--record更改10Mi为70Mi

以上是笔者做题的方法，但是最好快要结束的时候检查发现是pending状态，所以导致后续pod也是pending状态，从而这个大题全部挂了；笔者事后回顾，发现思路基本没啥问题，但笔者当时忘记了确认csi-hostpath-sc是否正常，所以仅有的可能就是没有切换到正确的context中从而导致pending的；这题的大失误也算是笔者比较粗细导致的吧。

说明当前考试版本为1.19.0考点链接

docs/concepts/storage/persistent-volumes

docs/concepts/workloads/controllers/daemonset

=====

Q14:监控pod的日志

监控foobarpod中的日志获取包含unable-to-access-website的日志，并将日志写入到/opt/KUTR00101/foobar

原题英文说明如下：

解析&参考答案解析：kubectllogs获取日志，通过grep进一步获取目标日志，也是个送分题参考答案：

切换context

kubectllogsfoobar|grepunable-to-access-website>/opt/KUTR00101/foobar

说明当前考试版本为1.19.0考点链接

docs/tasks/debug-application-cluster/debug-running-pod/

=====Q15:添加sidecar容器并输出日志

题目概述添加一个sidecar容器(使用busybox镜像)到已有的pod11-factor-app中

确保sidecar容器能够输出/var/log/11-factor-app.log的信息

使用volume挂载/var/log目录，确保sidecar能访问11-factor-app.log文件

原题英文说明如下：————————————————

解析&参考答案解析：

通过kubectlgetpod-oyaml的方法备份原始pod信息，删除旧的pod11-factor-appcopy一份新yaml文件，添加一个名称为sidecar的容器新建emptyDir的卷，确保两个容器都挂载了/var/log目录新建含有sidecar的pod，并通过kubectllogs验证参考答案：

切换context

apiVersion:v1kind:Podmetadata:name:11-factor-appspec:containers:-name:11-factor-appimage:busyboxargs:-/bin/sh--c->i=0;whiletrue;doecho"$i:$(date)">>/var/log/11-factor-app.log;i=$((i+1));