备战CKA：权限控制RBAC|查看pod的CPU|网络策略 NetworkPolicy以下是 CKA 认证考试升级后两个

cka的考试券早早就买了，一直拖着没考试。结果新题就要出了

以下是 CKA 认证考试升级后两个变化的示例参考：

1.移除“为部署 Kubernetes 集群提供底层基础设施”的能力，因为自上次更新以来，Kubernetes 的使用现实已经转变为管理平台。

2.引入与 Gateway API 相关的能力：“使用 Gateway API 管理入口流量”。

更新的 CKA 考试领域如下： 存储：10%

实现存储类和动态卷配置
配置卷模式、访问模式和卷回收策略
管理持久卷和持久卷声明

故障排除：30%

对集群和节点进行故障排除
对集群组件故障进行故障排除
监控集群和应用程序资源的使用情况
管理和评估容器输出流
对服务和网络进行故障排除 工作负载和调度：15%
了解部署以及如何执行滚动更新和回滚
使用 ConfigMaps** 和 Secrets 配置应用程序
配置工作负载自动扩展
了解用于创建健壮的、自修复的应用程序部署的原语
配置 Pod** 准入控制和调度（限制、节点亲和性等）

集群架构，安装和配置：25%

管理基于角色的访问控制（RBAC）
准备安装 Kubernetes 集群的基础架构
使用 kubeadm 创建和管理 Kubernetes 集群
管理 Kubernetes 集群的生命周期
实现和配置高可用控制平面
使用 Helm 和 Kustomize 安装集群组件
了解扩展接口（CNI、CSI、CRI等）
了解 CRD，安装和配置运算符

服务和网络：20%

理解 Pods 之间的连通性
定义和执行网络策略
了解 ClusterIP、NodePort**、LoadBalancer 服务类型和端点
使用 Gateway API 管理 Ingress 流量
了解如何使用 Ingress 控制器和 Ingress 资源
了解如何配置和使用 CoreDNS

那下面就看看这新版本之前的18道题，分为几个章节讲一下

1. 权限控制RBAC

设置配置环境：

[candidate@node-1] $ kubectl config use-context k8s

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

参考:

kubectl create clusterrole -h kubectl create rolebinding -h kubernetes.io/zh-cn/docs/…

解答:

要完成这个任务，你需要创建一个ClusterRole，它只允许对Deployment、StatefulSet和DaemonSet这三种资源类型进行管理，并且还需要在一个特定的命名空间中创建一个新的ServiceAccount，然后将这个ClusterRole绑定到这个ServiceAccount上。以下是完成这些步骤所需的Kubernetes YAML配置。

创建 ClusterRole

首先，定义一个名为deployment-clusterrole的ClusterRole，它只允许对Deployment、StatefulSet和DaemonSet进行操作：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-clusterrole
rules:
- apiGroups: ["", "apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

创建 ServiceAccount

接着，在app-team1命名空间内创建一个名为cicd-token的ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cicd-token
  namespace: app-team1

绑定 ClusterRole 到 ServiceAccount

最后，创建一个ClusterRoleBinding来将deployment-clusterrole绑定到cicd-token上，但请注意，尽管ClusterRole本身具有集群范围的权限，我们通过限制ServiceAccount的命名空间来确保其权限仅限于app-team1命名空间：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cicd-token-binding
subjects:
- kind: ServiceAccount
  name: cicd-token
  namespace: app-team1
roleRef:
  kind: ClusterRole
  name: deployment-clusterrole
  apiGroup: rbac.authorization.k8s.io

应用配置

将上述三个YAML配置保存为单独的文件或合并为一个文件，然后使用kubectl apply -f <filename>.yaml命令应用这些配置到Kubernetes集群中。

这样就完成了创建限定于特定资源类型的ClusterRole以及将其绑定到指定命名空间中的ServiceAccount的过程。这有助于实现细粒度的访问控制，确保ServiceAccount只能在其所属的命名空间内对指定资源执行操作。

考试的时候务必记住切换集群, 注意集群名称 kubectl config use-context k8s

# 创建clusterrole 
kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets 
# 创建 sc cicd-token 
kubectl -n app-team1 create serviceaccount cicd-token 
# 创建 rolebinding # 题目中写了“限于namespace app-team1中”，则创建rolebinding。没有写的话，则创建clusterrolebinding 
kubectl -n app-team1 create rolebinding cicd-token-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token 
# rolebinding后面的名字cicd-token-rolebinding随便起的，因为题目中没有要求，如果题目中有要求，就不能随便起了

检查（考试时，可以不检查的）:

kubectl -n app-team1 describe rolebinding cicd-token-rolebinding 
kubectl auth can-i create deployment --as system:serviceaccount:app-team1:cicd-token 
kubectl auth can-i create deployment -n app-team1 --as system:serviceaccount:app-team1:cicd-token

2. 查看pod的CPU

模拟题目:

设置配置环境： [candidate@node-1] $ kubectl config use-context k8s

Task

通过 pod label name=cpu-loader，找到运行时占用大量 CPU 的 pod，并将占用 CPU 最高的 pod 名称写入文件 /opt/KUTR000401/KUTR00401.txt（已存在)

参考:

kubectl top -h kubectl top pod -h kubernetes.io/docs/refere…

解答:

考试的时候务必记住切换集群, 注意集群名称 kubectl config use-context k8s

kubectl top pod -l name=cpu-loader -A --sort-by cpu echo "查出来的Pod Name" > /opt/KUTR000401/KUTR00401.txt

检查:

cat /opt/KUTR000401/KUTR00401.txt

3. 网络策略 NetworkPolicy

模拟题目:

设置配置环境： [candidate@node-1] $ kubectl config use-context hk8s

Task

在现有的namespace my-app中创建一个名为allow-port-from-namespace的新NetworkPolicy。确保新的NetworkPolicy允许namespace echo中的Pods连接到namespace my-app中的Pods的9000端口。进一步确保新的NetworkPolicy：不允许对没有在监听端口9000的Pods的访问不允许非来自 namespace echo中的Pods的访问

双重否定就是肯定，所以最后两句话的意思就是：仅允许端口为9000的pod方法。仅允许echo命名空间中的pod访问。

参考:

kubernetes.io/zh-cn/docs/… 概念 --> 服务负载均衡和联网 --> 网络策略

解答:

# 查看 命名空间的 标签 
kubectl get ns --show-labels 
# 如果访问者的namespace没有标签label，则需要手动打一个。如果有一个独特的标签label，则也可以直接使用 kubectl label ns echo project=echo

vim networkpolicy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
   name: allow-port-from-namespace # 题目指定的名字
   namespace: my-app  # 被访问者命名空间

spec:
  podSelector:
    matchLabels: {}  # 这两行必须写,也可写成   podSelector: {}

  policyTypes:
  - Ingress   # 策略影响入栈流量
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: echo #访问者的命名空间标签 
      ports:
        - protocol: TCP
          port: 9000 # 被访问者的 端口

kubectl apply -f networkpolicy.yaml

说明

PodSelector：
- podSelector 部分指定了匹配条件，只有带有标签 port-9000: "true" 的 Pods 才会被允许接收流量。这意味着只有那些明确声明监听端口 9000 的 Pods 才能接受流量。
Ingress 规则：
- ingress 部分定义了允许的流量来源。
  - from 部分指定了允许来自 namespace echo 的流量。
  - ports 部分指定了允许的端口为 TCP 9000。
PolicyTypes：
- policyTypes 设置为 Ingress，表示该策略仅控制入站流量。

检查:

kubectl describe networkpolicy -n my-app