CKA 模拟考 A

在 LabHub 中继续学习

这是模拟考试

实际的CKA是在120分钟内完成15~20个课题，超过66%就可以通过。这个套餐也

作业17个·120分钟·合格线是66%，所以需要全部正确。因为是部分分数制，所以需要全部正确。

没有。通过17个中的12个视为完成处理。

**不要看提示，先试着解到最后。**实际考试没有提示。

遇到困难的作业可以跳过，如果还有时间的话，回来的话对分数更有优势。

提示和正确答案请在考试结束后用作复习。

在实际考试现场第一次知道的话会浪费时间的东西

考试是远程桌面，每道作业都通过指定的主机ssh进行工作。

**不支持叠加ssh。**工作结束后，请务必用exit回到原来的位置。

k别名和bash自动完成**已经设置好了。**一开始就从alias开始

现在建议制作不符合环境。这个练习板也一样调整了。

yq·curl·wget·man也已经安装好了。
终端复制是Ctrl+Shift+C,粘贴是Ctrl+Shift+V。
Ctrl+W 关闭浏览器标签页。 删除单词时请使用Ctrl+Alt+W。
INSERT键被堵住，vim必须以i进入输入模式。
每个题目的分值不同，允许多种途径到达正确答案。

域名分配

| 域名 | 实际分数 | 这套任务 |

|---|---:|---:|

| Cluster Architecture, Installation and Configuration | 25% | 1~4次 |

| Workloads and Scheduling | 15% | 5~7次 |

| Services and Networking | 20% | 8~10次 |

| Storage | 10% | 11~12号 |

| Troubleshooting | 30% | 13~17号 |

从13号到17号

在实际考试中，故障资源是事先准备好的。在这个环境中没有那个设备，所以

在各课题的指示书中放入了问题宣言。首先照样应用后

请诊断并纠正症状。即使不适用，从头正确制作也通过评分，

那样就不能进行诊断练习了。

##在这个环境中的其他点

Pad内的群集是kwokctl发布的1人用群集。因为控制平面是真实的

Manifest、RBAC、排程、季度、CRD、PV绑定、排水全部实际运行。

但是工作负载容器不会运行，所以kubectl exec·logs·port-forward是

不能用。作业也不要求那个。

开始前，请用kubectl get nodes确认3个节点是否已准备就绪。如果还没有准备就绪的话

正在显示聚类中（大约需要2分钟）。

##评分

按下各课题的确认按钮，评分器将在活着的群集中重新计算值

进行对比。不是看文件上写了什么，而是看群集处于什么状态。

通往正确答案的道路允许多种途径。

ops名称空间的部署权限

创建名称空间ops，并设置服务账户deployer。

Role deployer允许在apps组中的deployments上进行get·list·watch·create·update，在core组中的pods上进行get·list。没有其他权限。将RoleBinding deployer绑定到该服务帐户。

core组用空字符串写在apiGroups上。权限扩大时，不只确认允许的错误才会显现出来，所以请一起询问不能用kubectl auth can-i ... --as=system:serviceaccount:ops:deployer的动词。

汇总ClusterRole

请创建ClusterRole monitoring-view。不要直接写规则，而是写aggregationRule，让ClusterRole附有标签rbac.example.com/aggregate-to-monitoring: "true"。

带有该标签的ClusterRole monitoring-metrics允许core组中的pods和nodes进行get·list·watch。

统计由控制器进行。如果将monitoring-view的rules清空后创建，一会儿规则就会填充。如果填充不了，则选择器的标签和实际标签即使只有一字也不同。

Backup CRD和自定义资源

请创建CRD backups.ops.example.com。组为ops.example.com,版本为v1(served·storage),范围为Namespaced,kind为Backup,复数为backups,简称为bk。在模式中spec.schedule是必填字符串,spec.retention是整数。

然后在命名空间ops中创建Backup nightly,并将schedule设置为0 2 * * *, retention设置为7。

CRD注册后不久，仍未被服务。请使用kubectl wait --for=condition=Established crd/<이름>等待后，创建自定义资源。如果在模式中不写类型，任何值都可以。

team-a 季度和基本资源值

在名称空间team-a中放置ResourceQuotateam-a-quota。限制为pods 10, requests.cpu 2, requests.memory 4Gi, limits.cpu 4, limits.memory 8Gi。

在同一个命名空间中放置LimitRange team-a-limits,让资源填充到不少的容器中，limits cpu 500m·memory 512Mi 和 requests cpu 100m·memory 128Mi。

LimitRange的default填充limits，defaultRequest填充requests。要查看实际填充情况，可以向服务器询问kubectl run ... --dry-run=server -o yaml。

frontend部署和滚动战略

请在名称空间web中创建Deploymentfrontend。图像是nginx:1.27,副本有4个,分区标签是app=frontend和tier=web。

策略是RollingUpdate，maxSurge 1·maxUnavailable 0，只剩下3个版本历史。

maxUnavailable 0的意思是“即使在更新中也不会减少准备好的板数”。可以用数字写，也可以用百分比写，评分器会期待数字1和0。

部署专用节点和容差

请重新创建节点lab-node-batch。在kwok管理的情况下，附加注释kwok.x-k8s.io/node: fake,设置标签workload=batch和涂层workload=batch:NoSchedule。

接着在命名空间batch中创建Deploymentcruncher，将busybox:1.36复制成3个副本，但请让三个进程都只显示在那个节点上。

容忍性只说“可以去”，而“去那里”是nodeSelector或required nodeAffinity说的。两者都需要才能确定配置。

出现在所有节点的代理

请在名称空间web中创建DaemonSetnode-agent。图像是busybox:1.36,必须在包括着有着色效果的节点在内的群集的所有节点上运行。

DaemonSet也会通过调度器。要显示带有颜色的节点，需要承受该颜色的容忍度。为了让任何颜色的节点都能承受，只要不写键，只让operator保持Exists就可以了。

使用带名称的端口的api服务

请在名称空间web中创建Deploymentapi。图像是nginx:1.27,复制件2个,容器端口是8080，那个端口的名称是http。

Service api 要从 ClusterIP 收到80次，但应该传递不是数字而是端口名称 http。

即使选择器错误，Service也会正常创建，只有端点是空的。请用kubectl get endpointslice -n web -l kubernetes.io/service-name=api检查是否附有地址。

shop.example.com 入口

请创建IngressClass nginx。controller是k8s.io/ingress-nginx。

在名称空间web中创建指向frontend部署的Servicefrontend（80号），将Hostshop的shop.example.com发送到Ingress/，frontend:80，/api发送到api:80。两个路径都设置为pathType为Prefix。

Ingress即使没有后端服务也能创建。服务名称至少写错了，但不会出错，请亲自确认。在v1中，后端写为service.name和service.port.number。

web名称空间网络政策

请为名称空间web的所有页面创建以阻止 incoming traffic as default的NetworkPolicy default-deny-ingress。

接着，仅在api-allow版块上使用NetworkPolicy app=api，仅允许来自相同命名空间的app=frontend版块和命名空间monitoring的TCP 8080。

全面阻止是指将podSelector设为空对象，并且不写任何ingress规则。如果将from列表中的项目分开写，就是OR，如果在一个项目中同时写podSelector和namespaceSelector，就是AND。这个问题是OR。

静态体积绑定

请创建StorageClass local-fast。provisioner是kubernetes.io/no-provisioner, reclaimPolicy是Retain, volumeBindingMode是Immediate。

PV pv-fast-1 是 2Gi·ReadWriteOnce·local-fast·hostPath /mnt/fast1。请将命名空间 storage 的 PVC data 设置为 1Gi·ReadWriteOnce·local-fast，并将其绑定到该 PV。

如果PVC在Pending中没有离开，那么其中一个类名、访问模式、容量中的一个与PV不匹配。请求容量可以比PV容量小，但访问模式必须完全包含。

将PVC和临时卷一起使用的工作负载

请在名称空间storage中创建Deploymentwriter。图像是nginx:1.27,复制件1个。

将PVC data 作为卷名data 挂载到/data，将emptyDir卷cache 挂载到/cache。

音量在pad规格的volumes中声明，然后从容器的volumeMounts中以名称写入。只有其中一个的话，pad就不会被创建，或者会丢失挂载。

端点为空的服务

请先照样应用以下宣言。

apiVersion: apps/v1
kind: Deployment
metadata: {name: shop, namespace: broken}
spec:
  replicas: 3
  selector: {matchLabels: {app: shop}}
  template:
    metadata: {labels: {app: shop}}
    spec:
      containers:
        - name: shop
          image: nginx:1.27
          ports: [{containerPort: 8080}]
---
apiVersion: v1
kind: Service
metadata: {name: shop, namespace: broken}
spec:
  selector: {app: shop-svc}
  ports: [{port: 80, targetPort: 80, protocol: TCP}]

3个Pad都显示出来了，但Service shop上没有任何端点。不要碰部署，只修复Service，让3个Pad连接成8080。

需要修改的地方有两个。端点完全关闭的原因和端口去错地方的原因在不同的字段中。请将kubectl get svc shop -n broken -o yaml和pad的标签并排看一下。

无法从Pending中脱身的工作负载

请先照样应用以下宣言。

apiVersion: apps/v1
kind: Deployment
metadata: {name: report, namespace: broken}
spec:
  replicas: 2
  selector: {matchLabels: {app: report}}
  template:
    metadata: {labels: {app: report}}
    spec:
      containers:
        - name: report
          image: nginx:1.27
          resources:
            requests: {cpu: "16", memory: 64Mi}

PAD无法从Pending中脱离。请保持复制件数量和图像不变，消除原因，让2个PAD全部Running。

kubectl describe pod 的Events或Pads的PodScheduled条件上，Scheduler会写下理由。一个节点可以容纳的数量在kubectl describe node的Allocatable中。

减少太大的权限

请先照样应用以下宣言。

apiVersion: v1
kind: ServiceAccount
metadata: {name: ci, namespace: broken}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: {name: ci-admin}
roleRef: {apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: cluster-admin}
subjects:
  - {kind: ServiceAccount, name: ci, namespace: broken}

在感谢中指出这个绑定。不要删除服务帐户ci，只减少权限。ci必须可以在命名空间broken内获取、列表、监视pods，并获取、列表、监视、创建、更新deployments，除此之外，在任何群集中都不能做任何事情。

仅仅删除cluster-admin绑定是不够的。删除后，ci没有任何权限，所以需要根据需要将它们重新分配到命名空间范围内。确认方法是kubectl auth can-i --as=system:serviceaccount:broken:ci。

因为卡在季度而无法启动的工作负载

请先照样应用以下宣言。

apiVersion: v1
kind: ResourceQuota
metadata: {name: tight, namespace: quota-broken}
spec:
  hard:
    requests.cpu: 500m
    limits.memory: 512Mi
---
apiVersion: apps/v1
kind: Deployment
metadata: {name: worker, namespace: quota-broken}
spec:
  replicas: 3
  selector: {matchLabels: {app: worker}}
  template:
    metadata: {labels: {app: worker}}
    spec:
      containers:
        - name: worker
          image: nginx:1.27

没有一个pad弹出。请不要碰quoter，只修改工作负载，让3个副本全部Running。

ReplicaSet 的状态条件中写着拒绝允许的理由（kubectl describe rs -n quota-broken）。如果计量器中写有任何资源，那么该命名空间的所有派对都必须声明该资源。

没有结束的排水管

请先照样应用以下宣言。

apiVersion: apps/v1
kind: Deployment
metadata: {name: edge, namespace: broken}
spec:
  replicas: 2
  selector: {matchLabels: {app: edge}}
  template:
    metadata: {labels: {app: edge}}
    spec:
      nodeSelector: {kubernetes.io/hostname: lab-node-0}
      containers: [{name: edge, image: nginx:1.27}]
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: edge-pdb, namespace: broken}
spec:
  minAvailable: 2
  selector: {matchLabels: {app: edge}}

为了进行维护，需要清空节点lab-node-0。但是排水没有结束。不要删除PodDisruptionBudget，请保持2个副本，然后结束排水。结束后，lab-node-0上不应该有任何edge进程，两个进程必须在其他节点上Running。

阻止的有两个。一个是让pad无法清空，另一个是让即使清空也找不到去处。请看kubectl get pdb -n broken的ALLOWED DISRUPTIONS列和pad的nodeSelector。