相对9月之前的题最大的差别就是题量和考试时间都缩水了,每个题目的分值提高了,最高一个题13分(不过还算容易),时间2个小时,题量17个题目。话不多说看看庐山真面目吧(我选的是中文考试,感觉有些中翻译过的题干反倒看得有点别扭)。
考试环境中一共有一下的context,考试做题的时候务必别忘了切换每个题目的context
1、Context k8s
为部署管道创建一个新的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
考点:RABC授权模型的理解。
kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets
kubectl create serviceaccount cicd-token --namespace=default
kubectl create rolebinding deployment-clusterrole --clusterrole=deployment-clusterrole --serviceaccount=default:cicd-token --namespace=default
2、将名为 ek8s-node-1 的 node 设置为不可用,并重新调度该 node 上所有运行的 pods
考点:cordon和drain 命令的使用
$ kubectl cordon ek8s-node-1
$ kubectl drain ek8s-node-1 --force
3、现有的Kubernetes 集群正在运行版本1.18.8。仅将主节点上的所有 Kubernetes控制平面和节点组件升级到版本1.19.0。
另外,在主节点上升级kubelet和kubectl。
确保在升级之前 drain 主节点,并在升级后 uncordon 主节点。 请不要升级工作节点,etcd,container 管理器,CNI插件, DNS服务或任何其他插件。
考点:如何离线主机,并升级控制面板和升级节点
kubectl drain <cp-node-name> --ignore-daemonsets
sudo kubeadm upgrade apply v1.19.0
yum install -y kubelet-1.19.0 kubectl-1.19.0 --disableexcludes=kubernetes
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl uncordon <cp-node-name>
--升级节点
sudo kubeadm upgrade node
yum install -y kubelet-1.19.0 kubectl-1.19.0 --disableexcludes=kubernetes
sudo systemctl daemon-reload
sudo systemctl restart kubelet
4、此项目无需更改配置环境。问题权重: 7%
Task
首先,为运行在https://127.0.0.1:2379上的现有 etcd 实例创建快照并将快照保存到 /srv/data/etcd-snapshot.db。
为给定实例创建快照预计能在几秒钟内完成。 如果该操作似乎挂起,则命令可能有问题。用 + 来取消操作,然后重试。
然后还原位于/data/backup/etcd-snapshot-previous.db的现有先前快照。
提供了以下TLS证书和密钥,以通过etcdctl连接到服务器。
CA 证书: /opt/KUIN00601/ca.crt
客户端证书: /opt/KUIN00601/etcd-client.crt
客户端密钥: /opt/KUIN00601/etcd-client.key
考点:etcd的备份和还原命令
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save/restore snapshotdb --cert=/opt/KUIN00601/etcd-client.crt --key=/opt/KUIN00601/etcd-client.key --cacert=/opt/KUIN00601/ca.crt
5、设置配置环境:问题权重: 7%
kubectl config use-context hk8s
Task
创建一个名为allow-port-from-namespace的新NetworkPolicy,以允许现有 namespace corp-net中的 Pods 连接到同一 namespace 中其他 Pods 的端口 9200。
确保新的NetworkPolicy:
不允许对没有在监听端口9200的Pods的访问
不允许不来自 namespacecorp-net的Pods的访问
考点:NetworkPolicy 的创建
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: all-port-from-namespace
namespace: internal
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: namespacecorp-net
- podSelector: {}
ports:
- port: 9000
6、设置配置环境:问题权重: 7%
kubectl config use-context k8s
Task请重新配置现有的部署front-end以及添加名为http的端口规范来公开现有容器 nginx 的端口80/tcp。
创建一个名为front-end-svc的新服务,以公开容器端口http。
配置此服务,以 通过在排定的节点上的 NodePort 来公开各个 Pods
考点:将现有的deploy暴露成nodeport的service。
$ kubectl expose deployment front-end --name=front-end-svc --port=80 --tarport=80 --type=NodePort
7、问题权重: 7%设置配置环境:
kubectl config use-context k8s
Task
如下创建一个新的nginx Ingress资源:
名称: ping
Namespace: ing-internal
使用服务端口 5678在路径 /hello 上公开服务 hello
可以使用以下命令检查服务 hello的可用性,该命令应返回 hello:
curl -kL <INTERNAL_IP>/hello
考点:Ingress的创建
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ping
namespace: ing-internal
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /hello
pathType: Prefix
backend:
service:
name: hello
port:
number: 5678
8、设置配置环境:问题权重: 4%
kubectl config use-context k8s
Task
将 deployment 从 presentation 扩展至 6 pods
考点:kubectl scale 命令
$ kubectl scale --replicas=6 deployment/loadbalancer
9、设置配置环境:问题权重: 4%
kubectl config use-context k8s
Task
按如下要求调度一个 pod:
名称:nginx-kusc00401
Image:nginx
Node selector:disk=spinnin
考点:nodeSelect属性的使用
apiVersion: v1
kind: Pod
metadata:
name: nginx-kusc00401
labels:
role: nginx-kusc00401
spec:
nodeSelector:
disk: spinnin
containers:
- name: nginx
image: nginx
10、设置配置环境:问题权重: 4%
kubectl config use-context k8s
Task
检查有多少 worker nodes 已准备就绪(不包括被打上 Taint:NoSchedule 的节点), 并将数量写入 /opt/KUSC00402/kusc00402.txt
考点:检查节点角色标签,状态属性,污点属性的使用
$ kubectl describe nodes <nodeName> | grep -i taints | grep -i noSchedule
11、设置配置环境:问题权重: 4%
kubectl config use-context k8s
Task
创建一个名为 kucc8 的 pod,在 pod 里面分别为以下每个 images 单独运行一个 app container(可能会有 1-4 个 images):nginx + redis + memcached + consul
考点:pod概念
apiVersion: v1
kind: Pod
metadata:
name: kucc1
spec:
containers:
- image: nginx
name: nginx
- image: redis
name: redis
- image: memchached
name: memcached
- image: consul
name: consul
12、设置配置环境:问题权重: 4%
kubectl config use-context hk8s
Task
创建名为 app-config 的 persistent volume,容量为 1Gi,访问模式为 ReadWriteMany。 volume 类型为 hostPath,位于 /srv/app-config
考点:hostPath类型的pv
apiVersion: v1
kind: PersistentVolume
metadata:
name: app-config
labels:
type: local
spec:
capacity:
storage: 2Gi
accessModes:
- ReadWriteMany
hostPath:
path: "/src/app-config"
13、设置配置环境:问题权重: 7%
kubectl config use-context ok8s
Task
创建一个新的PersistentVolumeClaim:
名称: pv-volume
Class: csi-hostpath-sc
容量: 10Mi
创建一个新的Pod,此Pod将作为volume挂载到 PersistentVolumeClaim:
最后,使用kubectl edit或kubectl patch将 PersistentVolumeClaim的容量扩展为70Mi,并记录此更改。
考点:pvc的创建class属性的使用,--save-config记录变更
#创建PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pv-volume
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 10Mi
storageClassName: csi-hostpath-sc
#创建pod
apiVersion: v1
kind: Pod
metadata:
name: web-server
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: pv-volume
volumes:
- name: pv-volume
persistentVolumeClaim:
claimName: myclaim
kubectl edit pvc pv-volume --save-config
14、 问题权重: 7%
名称:web-server
Image:nginx
挂载路径:/usr/share/nginx/html
配置新的Pod,以对volume具有ReadWriteOnce权限。
考点:pod中对pv和pvc的使用
15、设置配置环境:问题权重: 5%
kubectl config use-context k8s
Task
监控 pod bar 的日志并:
提取与错误 file-not-found 相对应的日志行
将这些日志行写入 /opt/KUTR00101/bar
考点:kubectl logs命令
kubectl logs foobar | grep unable-access-website > /opt/KUTR00101/foobar
16、 设置配置环境:问题权重: 7%
kubectl config use-context k8s
在不更改其现有容器的情况下,需要将一个现有的 Pod 集成到 Kubernetes 的内置日志记录体系结构中(例如 kubectl logs)。添加 streaming sidecar 容器是实现此要求的一种好方法。
Task
将一个 busybox sidecar 容器添加到现有的Pod legacy-app。新的 sidecar 容器必须运行以下命令:
/bin/sh -c tail -n+1 -f /var/log/legacy-app.log
使用名为logs的 volume mount 来让文件 /var/log/legacy-app.log可用于sidecar 容器。
不要更改现有容器。 不要修改日志文件的路径,两个容器都必须通过/var/log/legacy-app.log来访问该文件。
考点:pod两个容器共享存储卷
apiVersion: v1
kind: Pod
metadata:
name: podname
spec:
containers:
- name: count
image: busybox
args:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$(date) INFO $i" >> /var/log/legacy-ap.log;
i=$((i+1));
sleep 1;
done
volumeMounts:
- name: logs
mountPath: /var/log
- name: count-log-1
image: busybox
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/legacy-ap.log']
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: logs
emptyDir: {}
#验证:
$ kubectl logs <pod_name> -c <container_name>
17、设置配置环境,问题权重: 5%
kubectl config use-context k8s
Task
通过 pod label name=cpu-loader,找到运行时占用大量 CPU 的 pod, 并将占用 CPU 最高的 pod 名称写入文件 /opt/KUTR000401/KUTR00401.txt(已存在)。
考点:kubectl top --l 命令的使用
kubectl top pod -l name=cpu-user -A
转载至https://blog.csdn.net/zz27563582/article/details/109691454