当前位置：首页 > news >正文

【CKA】Kubernetes(k8s)认证之CKA考题讲解

news 文章来源：https://blog.csdn.net/weixin_74814027/article/details/144298430 2025/4/29 12:11:29

CKA考题讲解

0.考试101

0.1 kubectl命令⾃动补全

在 bash 中设置当前 shell 的⾃动补全，要先安装 bash-completion 包。

echo "source <(kubectl completion bash)" >> ~/.bashrc

还可以在补全时为 kubectl 使⽤⼀个速记别名：

alias k=kubectl
complete -o default -F __start_kubectl k

0.2 切换cluster环境

kubectl config use-context hk8skubectl config use-context CONTEXT_NAME [options]

0.3 关于–all-namespace

使⽤ -A 参数来简写完整参数内容 --all-namespaces

0.4 查看资源作⽤域

## 列出所⽀持的全部资源类型和它们的简称、API组, 是否是名字空间作⽤域 和 Kind。
kubectl api-resources
kubectl api-resources --namespaced=true # 所有命名空间作⽤域的资源
kubectl api-resources --namespaced=false # 所有⾮命名空间作⽤域的资源
kubectl api-resources -o name # ⽤简单格式列举所有资源（仅显示资源名称）
kubectl api-resources -o wide # ⽤扩展格式列举所有资源（⼜称 "wide" 格式）
kubectl api-resources --verbs=list,get # ⽀持 "list" 和 "get" 请求动词的所有资源
kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源

0.5 关于–dry-run

kubectl create deploy nginx --image=nginx --dry-run=client -o yaml > deploynginx.yml

1.权限控制RBAC

Context：为流⽔线创建⼀个新的 ClusterRole 并为其绑定到范围为指定 namespace 的特定ServiceAccount 。
Task：创建⼀个名为 deployment-clusterrole 且仅允许创建以下资源类型的新 ClusterRole
Deployment
StatefulSet

DaemonSet
在现有的 namespace app-team1 创建⼀个名为 cicd-token 的新 ServiceAccount 。
限于 namespace app-team1 中，将新的 ClusterRole deployment-clusterrole 绑定到新的 ServiceAccount
cicd-token 。

在这里插入图片描述

#在现有的 namespace **app-team1** 创建⼀个名为 cicd-token 的新 ServiceAccount 。
kubectl create sa cicd-token -n app-team1#创建⼀个名为 deployment-clusterrole 且 仅允许创建 以下资源类型的新 ClusterRole
Deployment
StatefulSet	
DaemonSetkubectl create clusterrole deployment-clusterrole --verb=create --resource=deployment,daemonsets,statefulsets#限于 namespace app-team1 中，将新的 ClusterRole deployment-clusterrole 绑定到新的 ServiceAccount cicd-token 
kubectl create rolebinding cicd --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token -n app-team1

2.查看pod的CPU

Task
通过 pod label name=cpu-loader ，并找到运⾏时占⽤⼤量CPU的pod。
并将占⽤CPU最⾼的 pod名称写⼊⽂件 /opt/KUTR000401/KUTR00401.txt(已存在)。

#环境如果异常，kubectl top 命令⽆法执⾏，那么⾸先 kubectl describe pod/metrics-server-pod -n kube-system 并尝试删除 kubectl delete pod/metrics-server-pod -n kube-system，等待pod重建后 READY状态恢复为1/1。#如果执行 kubectl top pod -A  
error: Metrics API not available  #要在 Kubernetes 集群中安装 Metrics Serverkubectl top pods -A -l name=cpu-loader --sort-by='cpu'
echo pod-name >> /opt/KUTR00401/KUTR00401.txt

3.配置⽹络策略NetworkPolicy

Task
在现有的 namespace corp-net 中创建⼀个名为 allow-port-from-namespace 的新 NetworkPolicy。
确保新的 NetworkPolicy 允许 namespace echo 中的 Pods 连接到 namespace corp-net 中的 Pods 的 80 端
⼝
进⼀步确保新的 NetworkPolicy：
不允许对没有在监听端⼝ 80 的Pods的访问

不允许⾮来⾃ namespace echo 中的 Pods的访问

https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-port-from-namespacenamespace: corp-net
spec:podSelector: {}policyTypes:- Ingressingress:- from:- namespaceSelector:matchLabels:name: echoports:- protocol: TCPport: 80####################################################################################apiVersion: networking.k8s.io/v1  # 指定使用的 Kubernetes 网络策略 API 版本
kind: NetworkPolicy  # 定义这是一个网络策略资源
metadata:name: allow-port-from-namespace  # 网络策略的名称namespace: corp-net  # 指定网络策略应用的命名空间
spec:podSelector: {}  # 选择当前命名空间内的所有 Pod（因为没有指定任何标签选择器）policyTypes:- Ingress  # 指定策略类型为 Ingress，即控制进入 Pod 的流量ingress:  # 定义 Ingress 规则- from:  # 指定允许的流量来源- namespaceSelector:  # 使用命名空间选择器来选择允许的命名空间matchLabels:  # 定义要匹配的标签name: echo  # 只有标签为 name=echo 的命名空间中的 Pod 可以访问ports:  # 指定允许访问的端口- protocol: TCP  # 使用 TCP 协议port: 80  # 目标端口为 80

kubectl get pod -n corp-net -o wide
kubectl exec -it pod/echo-pod -n echo --sh
curl pod-ip #容器内验证策略是否⽣效
telnet pod-ip 6379

4.暴露服务service

Task
请重新配置现有的deployment front-end 以及添加名为 http 的端⼝规范来公开现有容器 nginx 的端⼝
80/tcp 。
创建⼀个名为 front-end-svc 的 service，以暴露容器端⼝ http。
配置此 service，以通过各个pod所在节点上的 NodePort 来公开他们。

https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#type-nodeport

kubectl explain deployment.spec.template.spec.containers.ports #查看语法
kubectl edit deploy/front-end -n default #编辑deployment

编辑 front-end-svc.yml

apiVersion: v1
kind: Service
metadata:name: front-end-svcnamespace: default
spec:type: NodePortselector:app: front-endports:
# 默认情况下，为了⽅便起⻅，`targetPort` 被设置为与 `port` 字段相同的值。- port: 80targetPort: http
# 可选字段
# 默认情况下，为了⽅便起⻅，Kubernetes 控制平⾯会从某个范围内分配⼀个端⼝号（默认：30000-32767）nodePort: 30007

应⽤yaml⽂件，并验证

kubectl apply -f front-end-svc.yml
kubectl get svc
curl localhost:30007

6.扩容deployment副本

Task:
将 deployment guestbook 扩展⾄ 4 个 pods

kubectl get deploy/guestbook -o wide
kubectl scale deploy/guestbook --replicas 4
kubectl get deploy/guestbook -o wide

7.调度pod到指定节点

Task:
按如下要求调度⼀个 Pod
名称： nginx-kusc00401
Image：nginx
Node selector： disk=ssd

空间名称 default

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/

apiVersion: v1
kind: Pod
metadata:name: nginx-kusc00401
spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentnodeSelector:disk: ssd

8.查看可⽤节点数量

Task:
检查有多少 nodes 已经就绪 (不包括被打上 Taint: NoSchedule 的节点)，并将数量写⼊
/opt/KUSC00402/kusc00402.txt chown magedu: /opt/KUSC00402/kusc00402.txt

kubectl describe nodes | grep -i Taint | grep -vci NoSchedule
echo node-num >> /opt/KUSC00402/kusc00402.txt

9.创建多容器的pod

Task：
按如下要求调度⼀个Pod：名称 kucc8
app containers：2
container名称/image

nginx
consul

空间名称 default

apiVersion: v1
kind: Pod
metadata:name: kucc8
spec:containers:- name: nginximage: nginx- name: consulimage: consul

10.创建PV

Task
创建名为 app-data 的 persistent volume ，容量为 1Gi ，访问模式为 ReadWriteOnce 。
volume 类型为 hostPath ，位于 /srv/app-data

apiVersion: v1
kind: PersistentVolume
metadata:name: app-data
spec:capacity:storage: 1GiaccessModes:- ReadWriteOncehostPath:path: "/srv/app-data"

11.创建PVC

Task
创建⼀个新的 PersistentVolumeClaim :

名称 pv-volume
Class csi-hostpath-sc managed-nfs-storage
容量 10Mi

创建⼀个新的 Pod，将 PersistentVolumeClaim 作为 volume 进⾏挂载：

名称 web-server
image nginx
挂载路径 /usr/share/nginx/html

配置新的Pod，使得对上述 volume 具有 ReadWriteOnce 权限。

最后，使⽤ kubectl edit 或 kubectl patch 将 PersistentVolumeClaim 的容量扩展为 70Mi，并记录此更改。

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim

pvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pv-volume
spec:storageClassName: csi-hostpath-scaccessModes:- ReadWriteOnceresources:requests:storage: 10Mi

pvc-pod.yml

apiVersion: v1
kind: Pod
metadata:name: web-server
spec:volumes:- name: task-pv-storagepersistentVolumeClaim:claimName: pv-volumecontainers:- name: web-serverimage: nginxports:- containerPort: 80name: "http"volumeMounts:- mountPath: "/usr/share/nginx/html"name: task-pv-storage

kubectl apply -f pvc.yml
kubectl apply -f pvc-pod.yml
kubectl get pvc
kubectl edit pvc/pv-volume --record #调整PVC的容量⼤⼩

12.查看pod⽇志

Task
监控 pod foo 的⽇志并提取与错误 file-not-found 相对应的⽇志⾏
将这些⽇志⾏写⼊ /opt/KUTR00101/foo

kubectl get pods -A
kubectl logs pod/foo | grep 'file-not-found' > /opt/KUTR00101/foo
cat !!:$

13.使⽤sidecar代理容器⽇志

Context
将⼀个现有的 Pod 集成到 Kubernetes 的内置⽇志记录体系结构中（例如 kubectl logs）。
添加 streaming sidecar 容器是实现此要求的⼀种好⽅法。
Task
使⽤ busybox Image 来将名为 sidecar 的 sidecar 容器添加到现有的 Pod big-corp-app 中。
新的 sidecar 容器必须运⾏以下命令：

/bin/sh -c tail -n+1 -f /var/log/big-corp-app.log

使⽤挂载在 /var/log 的 Volume，使⽇志⽂件 big-corp-app.log 可⽤于 sidecar 容器。
除了添加所需要的 volume mount 以外，请勿更改现有容器的规格。

kubectl get pod/big-corp-app -n default -o yaml > big-corp-app-origin.yml
cp big-corp-app-origin.yml big-corp-app.yml

https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/logging/#sidecar-container-with-logging-agent

编辑 big-corp-app.yml

apiVersion: v1
kind: Pod
metadata:name: big-corp-appnamespace: default
spec:containers:- name: countimage: busyboxargs:- /bin/sh- -c- >i=0;while true;doecho "$(date) INFO $i" >> /var/log/big-corp-app.log;i=$((i+1));sleep 1;donevolumeMounts:- name: varlogmountPath: /var/log- name: sidecarimage: busyboxargs:- /bin/sh- -c- >tail -n+1 -F /var/log/big-corp-app.logvolumeMounts:- name: varlogmountPath: /var/logvolumes:- name: varlogemptyDir: {}

14.升级集群

Task
现有的 Kubernetes 集群正在运⾏版本 1.24.2。仅将 master 节点上的所有 Kubernetes 控制平⾯和节点组件升级
到版本 1.24.3。
确保在升级之前 drain master 节点，并在升级后 uncordon master 节点。
可以使⽤以下命令，通过 ssh 连接到 master 节点：
ssh master01
可以使⽤以下命令，在该 master 节点上获取更⾼权限：
sudo -i
另外，在主节点上升级 kubelet 和 kubectl。
请不要升级⼯作节点，etcd，container 管理器，CNI 插件， DNS 服务或任何其他插件。

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#upgrading-control-plane-nodes

#考试节点上去保护并排空升级节点的pod
kubectl cordon master01
kubectl drain master01 --ignore-daemonsets=true --delete-emptydir-data=true
ssh master01
sudo -i
###升级管理⼯具
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.24.3-00 && \
apt-mark hold kubeadm
#验证版本
kubeadm version
#验证集群升级计划
kubeadm upgrade plan
#升级集群版本,包含 kube-apiserver、kube-controller-manager、kube-scheduler、kubeproxy，排除etcd
kubeadm upgrade apply v1.24.3 --etcd-upgrade=false
#多个master节点，使⽤kubeadm upgrade node升级其他控制平⾯节点
###升级master节点的 kubelet 和 kubectl
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.24.3-00 kubectl=1.24.3-00 && \
apt-mark hold kubelet kubectl
#解除节点保护
exit
exit
kubectl uncordon master01

15.备份还原etcd

Task
⾸先，为运⾏在 https://127.0.0.1:2379 上的现有 etcd 实例创建快照并将快照保存到 /var/lib/backup/etcdsnapshot.db
为给定实例创建快照预计能在⼏秒钟内完成。如果该操作似乎挂起，则命令可能有问题。⽤ CTRL + C 来取消操
作，然后重试。
然后还原位于/data/backup/etcd-snapshot-previous.db 的现有先前快照。
提供了以下 TLS 证书和密钥，以通过 etcdctl 连接到服务器。
CA 证书: /opt/KUIN00601/ca.crt
客户端证书: /opt/KUIN00601/etcd-client.crt
客户端密钥: /opt/KUIN00601/etcd-client.key

https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

##1.25的考试中，etcd的备份还原是在操作机上进⾏操作
export ETCDCTL_API=3
#备份
etcdctl --endpoints=https://10.100.0.100: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 snapshot status /var/lib/backup/etcd-snapshot -w table
#查看
ll /data/backup/etcd-snapshot-previous.db
#还原
etcdctl --endpoints=https://10.100.0.100:2379 --cacert="/opt/KUIN00601/ca.crt" --
cert="/opt/KUIN00601/etcd-client.crt" --key="/opt/KUIN00601/etcd-client.key"
snapshot restore /data/backup/etcd-snapshot-previous.db --data-dir=/var/lib/etcd

16.排查集群中故障节点

Task
名为 node02 的 Kubernetes worker node 处于 NotReady 状态。
调查发⽣这种情况的原因，并采取相应的措施将 node 恢复为 Ready 状态，确保所做的任何更改永久⽣效。
可以使⽤以下命令，通过 ssh 连接到 node02 节点：
ssh node02
可以使⽤以下命令，在该节点上获取更⾼权限：
sudo -i

ssh node02
sudo -i
systemctl status kubelet.service
systemctl enable --now kubelet.service
systemctl status kubelet.service
exit
exit
kubectl get nodes

17.节点维护

Task：
将名为 node02 的node 设置为不可⽤，并重新调度该 node上所有运⾏的 pods。

kubectl cordon node02
kubectl drain node02 --ignore-daemonsets --delete-emptydir-data --force