高分通过kubernetes CKA秘籍

Kubernetes：CKA通过秘籍。

1、自己平时按照题多练，考试的环境比较卡，所以尽量在平时多练练，更加熟悉操作，练就有效。

2、在考试的时候，尽量减少手动输入，可以在上面复制，减少失误！

3、题型就那么多，自己多看看官方文档就可以做出了，平时练习的时候看好时间！

4、考前还有很多注意事项，有需要尽管联系！

1、RBAC 4`

 为部署管道创建一个新的clusterRole并将其绑定到范围为特定的namespace的特定ServiceAccount
 
 Task
 创建一个名为deployment-clusterrole且仅创建以下资源类型的新clusterRole；
 deployment
 statefulset
 daemonset
 
 kubectl create clusterrole --verb=create --resource=deployments,statefulsets,daemonsets
 
 在现有的namespace app-team1环境一个名为cicd-token的新serviceaccount
 
 kubectl -n app-team1 create serviceaccount cicd-token
 
 限于namespace app-team1 ，将新的clusterRole。 deployment-clusterroler绑定到新的serviceaccount cicd-token
 
 kubectl -n app-team1 create rolebinding cicd-token-binding  --clusterrole=deployment-clusterroler --serviceaccount=
 app-team1:cicd-token

#记住补全命令
source < (kubectl completion bash)

帮助命令
kubectl create clusterrole -h
kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename]
[--dry-run=server|client|none] [options]

--verb=create (权限)
--resource=deployments,statefulsets,daemonsets  #(记住要加s，要不然会报错)

#一定要先指命名空间 
-n app-team1  先指命令空间
kubectl -n app-team1 create serviceaccount -h  #可以加-h 查看命令帮助

例子：
Usage:
  kubectl create serviceaccount NAME [--dry-run=server|client|none] [options]

# 在现有的namespace app-team1环境一个名为cicd-token的新serviceaccount
kubectl -n app-team1 create serviceaccount cicd-token

#限于namespace app-team1 ，将新的clusterRole。

kubectl -n app-team1 create rolebinding -h  #已经指明rolebinding  如果没有就classrole

Usage:
  kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname]
[--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] [options]

kubectl -n app-team1 create rolebinding cicd-token-binding --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token


#创建rolebinding NAME

#指定clusterrole
--cluster=deployment-clusterrole 

--serviceaccount=app-team1:cicd-token


kubectl describe -n app-team1 rolebindings.rbac.authorization.k8s.io cicd-token-binding



#注意点 
命名空间一定要跟上

解答：

#考试务必要切换集群，

kubectl config use-context k8s

#创建一个名为deployment-clusterrole且仅允许创建下资源类型的新clusterrole

kubectl create cluster deployment-clusterole --verb=create --resource=deployments,statefulsets,daemonsets

#在现有namespace app-team1 创建一个名为cicd-token 的次年serviceaccount

kubectl -n app-team1 create serviceaccount cicd-token

#限于namespace app-team1 中，将新的clusterRole deployment-clusterrole绑定到新的Service account cicd-token

#题目中写了“限于 namespace app-team1 中”，则创建 rolebinding。没有写的话，则创建 clusterrolebinding。

kubectl -n app-team1 create rolebinding cicd-token-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token

#第二次操作；
kubectl config use-context k8s

为部署流水线创建一个新的clusterrole并将其绑定到范围为特定的namespace的特定serviceaccount

task
创建 一个名为deployment-clusterrole且仅允许创建以下资源类型的新clusterrole

kubectl create clusterrole -verb=create --resource=deployments,statefulsets,daemonsets

kubectl create clusterrole deployment-clusterrole  -verb=create --resource=deployments,statefulsets,daemonsets

在现有的namespace app-team1	中创建一个名为cicd-token的新serviceaccount

kubectl -n app-team1 create --serviceaccount=cicd-token

kubectl -n app-team1 create serviceaccount cicd-token


限于namesapce app-team1中,将新的clusterrole deployment-cluster绑定到新的serviceaccount cicd-token

kubectl -n app-team1 create rolebinding cicd-token-rolebinding --clusterole=deployment-cluster --serviceaccount=app-team1:cicd-token


#检查

kubectl -n app-team1 describe rolebinding cicd-token

2、查看pod的CPU 5`

考题：

设置配置环境

kubeclt config use-context k8s

TASK

通过pod label name=-loader ,找到运行时占用大量cpu的pod，

并将占用CPU最高的pod名称写入文件/opt/KUTR000401/KUTR00401.(已存在)

考点：kubectl top --l 命令的使用

解析：

kubectl top pod

kubectl top pod -A -l name=cpu-loader --sort-by=‘cpu’

-A #所有的命名空间

-l 标签

–sort-by 排序

kubectl top pod -h

#考试务必切换集群，
kubectl config use-contest k8s

#查看pod名称 -A是所有namespace

kubectl top pod -l name=cpu-loader --sort-by=cpu -A

#将cpu占有最多的pod的name写入/opt/test1.txt
echo "POD-name" > /opt/kutr000401/kutr00401.txt

#检查
cat /opt/kutr000401.kutr00401.txt    #翻译的问题，其实是两个零

3、配置网络策略networkpolicy 4`

#主要考点： 创建 networkpolicy

Task

在现有namespace my-app 中创建一个名为allow-port-from-namespace 的新networkpolicy

确保新的networkpolicy 允许namespace ehco 中的pods 连接到namespace my-app 中的pods的9000端口

确保：新的networkpolicy

不允许对没有在监听 端口9000的pods的访问

不允许非来自namespace ehco 中的pods的访问

解答：
#注意echo出现的位置不同，一个作为访问者，一个作为被访问者；

#查看所有ns的标签label
kubectl get ns --show-labels

如果访问者的namespace没有标签label，则需要手动打一个。如果有一个独特的标签label，则也可以直接使用。
kubectl label ns echo project=echo

#查看这个标签
kubectl get ns echo --show-labels


编写一个yaml文件
vim networkpolicy.yaml
#注意：set paste ，防止yaml文件空格错序

apiVersion: networking.k8s.io/v1
kind: Networkpolicy
metadata:
  name: allow-port-form-namespace
  namespace: my-app
spec: 
  podSelector:        #这两行必须要写，或者也可以写成一行为 podSelector: {}
    matchLabels: {}     # 注意 matchLabels:与{}之间有一个空格
  policyTypes:
    - Ingress     #策略影响入栈流量
  ingress:
  - from:         #允许流量的来源
      - namespaceSelector:
          matchLabels:
            project: echo
    prots:
    - protocol: TCP
      port: 9000
      
      
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-port-from-namespace
  namespace: my-app
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
    - Ingress
  ingress:
    - from:

        - namespaceSelector:
            matchLabels:
              project: echo        
      ports:
        - protocol: TCP
          port: 9000

#创建
kubectl apply -f networkpolicy.yaml


#检查
kubectl describe networkpolicy -n my-app


#
题2；在同个命名空间下访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-port-from-namespace
  namespace: fooar
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
  - from:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 9000
      

4、暴露服务service 4`

请重新配置现有的deployment front-end 以及添加名为http 的端口规范来公开现有容器nginx的端口 80/tcp

创建一个名为front-end-svc的新service ，以公开容器端口http

配置此service ，以通过各个pod所在的节点上的nodeport来公开他们

考试时务必执行，切换集群。
kubectl config use-context k8s

#检查deployment信息，并记录selector 的label标签，这里时app=front-end
kubectl get deployment front-end -o wide           # -o wide 显示详细信息   注意的时标签也是

参考官方文档，按照需要 edit deployment ,添加端口信息

kubectl edit deploymnet front-end

# 注意 :set paste ,防止yaml 文件空格错序


    spec:
      containers:
      - image: vicuu/nginx:hello
        imagePullPolicy: IfNotPresent
        name: nginx     #找到此位置，添加下面4行
        ports:
        - name: http
          containerPort: 80
          protocol: TCP


#暴露对应端口
kubectl expose deploymnet front-end --type=Nodeport --port=80 --target-port=80 --name=front-end-svc

#注意考试中需要创建的时NodePOrt，还是ClusterIP。如果时ClusterIP，则樱花为--type=ClusterIP
#--port是service的端口号， --target-port 是deployment里pod的容器的端口号



暴露服务后，减产一下service的selector标签是都正确，这个要与deployment的selector标签一致的

kubectl get svc front-end-svc -o wide

kubectl get deployment front-end -o wide


#如果你kubectl expose 暴露符文u后，发现service的selector标签是空的 <none> ,或者不是deployment的

则需要编辑此service,手动添加标签
kubectl edit svc front-end-svc
在ports这一小段下面添加selector标签
 selector:
   app: front-end
 
 确保service的selector标签与deployment的selector 标签一致
 
 
 最后curl检查
 kubectl get pod,svc -o wide
 curl
 所在的node的ip 或主机名：30938
 curl svc 的IP地址：80
 （注意，只能curl同svc 的80 端口，但是无法ping通的）

5、创建ingress 7`

Task

创建一个新的nginx Ingress资源：

名称：ping

namespace：ing-internal

使用服务端口5678 在路径/hello 上公开服务 hello

可以使用命令检查服务hello的可用性，改命令返回hello：

curl -kL <internal_IP> /hello

#考试时务必切换集群。
kubectl config use-context k8s

#拷贝官方的yaml案例，修改相关参数即可；


vim ingress.yaml


apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: nginx-example  ##考试时，默认是没有 ingressClassName 的，所以我们要先手动建一个 ingressClassName，命名就为 nginx-example 吧
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx
  
---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ping
  namespace: ing-internal
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example    #这里调用上面新建的 ingressClassName 为 nginx-example
  rules:
  - http:
      paths:
      - path: /hello
        pathType: Prefix
        backend:
          service:
            name: http
            port:
              number: 5678


kubectl apply -f ingress.yaml

最后 curl 检查
# 通过 get ingress 查看 ingress 的内外 IP，然后通过提供的 curl 测试 ingress 是否正确。
# 做完题后，略等 3 分钟，再检查，否则可能还没获取 IP 地址。或者可以先去做别的题，等都做完了，再回来检查这道题，一下，记得回来检查时，先使用 kubectl config use-context k8s 切换到此集群。
kubectl get ingress -n ing-internal

curl ingress 的 ip 地址/hello

6、扩容 deployment副本数量 4`

Task

将deployment presentation扩展至4个pods

参考：

kubectl scale deployment -h

#考试的时候记得切换集群
kubectl config use-context k8s


#先检查一下现有的pod数量
kubectl get deployment presentation -o wide
kubectl get  pod -l app=presentation 


#扩展成4个
kubectl scale deployment presentation --replicas=4


#检查
kubectl get deployments presentation -o wide
kubectl get pod -l app=presentation

7、调度pod到指定节点 4`

task:

要求调度一个pod：

名称：nginx-kusc00401

image：nginx

node selector：disk=ssd

#切换考试环境
kuebctl config use-context k8s


#先检查是否有这个pod，应该时没有创建的，所有需要创建
kubectl get pod -A | grep nginx-kusc00401



#确保node 有这个labels ，考试时，检查一下就行，应该已经提取设置好了labels
kubectl get nodes --show-labels| grep 'disk=ssd'

如果没有设置，则使用kubectl label nodes node01 disk=ssd 命令来手动自己设置

拷贝官文案例，修改下 pod 名称和镜像，删除多余的部分即可
vim pod-disk-ssd.yaml

#注意：set paste ，防止yaml 文件空格错序

apiVersion: v1
kind: Pod
metadata:
  name: nginx-kusc00401

spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: disk-ssd


kubectl apply -f pod-disk-ssd.yaml


#检查
kubectl get pod nginx-kusc00401 -o wide

8、查看可用节点数量 4`

Task

检查有多少nodes已准备就绪 （不包括被打上 Taint： NoSchedule 的节点）

并将数量写入 /opt/KUSC00402/kusc00402.txt

考点： 检查节点角色标签，状态属性，污点属性的使用

kubectl -h

#考试时务必切换集群
kubectl config use-context k8s

# grep  的 -i 是忽略大小写， grep -v 是排除在外， grep -c 是统计查出来的条数
kubectl describe nodes | grep -i Taint | grep -vc NoSchedule
echo "查出来的数字" > /opt/KUSC00402/kusc00402.txt

其实你直接使用命令，也能一眼看出来，几个没有的；
kubectl describe nodes | grep -i Taints


#检查

cat /opt/KUSC00402/kusc00402.txt

9、创建多容器的pod 4`

task:

按如下要求调度一个pod：

名称： kucc8

app containers: 2

container 名称/images：

• nginx

• consul

考点： pod概念

#考试是务必先切换集群

kubectl config use-context k8s

参考"调度pod 到指定节点的 yaml配置文件"

vim pod-kucc.yaml
# 注意：set paste ,防止yaml 文件空格错序

apiVersion: v1
kind: Pod
metadata:
  name: kucc8
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  - name: consul
    image: consul
    imagePullPolicy: IfNotPresent
    
    
 kubectl apply -f pod-kucc.yaml
 
 #检查
 kubectl get pod kucc8
 

10、创建PV4`

task

创建名为 app-config的persistent volume，容量为1Gi ，访问模式为 ReadWriteMany

volume 类型为hostPath ，位于/srv/app-config

考点： hostPath 类型的 pv

#考试时务必执行切换集群
kubectl config use-context k8s

复制官方合适的案例，修改参数 然后设置 hostPath 为/srv/app-config 即可

vim pv.yaml
#注意： set paste ，防止yaml 文件空格错序



apiVersion: v1
kind: PersistentVolume
metadata:
  name: tapp-config
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/srv/app-config"
 

# 创建
kubectl apply -f pv.yaml


#检查
kubectl get pv

#RWX 是ReadWriteMany ，RWO 是ReadWriteOnce

    
 

11、创建PVC7`

Task

创建一个新的 PersistentVolumeClaim：

名称: pv-volume

Class: csi-hostpath-sc

容量: 10Mi

创建一个新的 Pod，来将 PersistentVolumeClaim 作为 volume 进行挂载：

名称：web-server

Image：nginx:1.16

挂载路径：/usr/share/nginx/html

配置新的 Pod，以对 volume 具有 ReadWriteOnce 权限。

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

考点： PVC的创建class 属性的使用，–record记录变更

# 考试是务必执行，切换集群

kubectl config use-context ok8s

根据官方文档复制一个 PVC 配置，修改参数，不确定的地方就是用 kubectl 的 explain 帮助。

开始操作

vim pvc.yaml

#注意： set paste，防止 yaml 文件空格错序
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-volume      #pvc名字
spec:
  storageClassName: csi-hostpath-sc
  accessModes:
    - ReadWriteOnce          # 注意，考试时的访问模式可能有 ReadWriteMany 和 ReadOnlyMany 和 ReadWriteOnce，根据题目要求写。
  resources:
    requests:
      storage: 10Mi
      
 #创建PVC
 kubectl apply -f pvc.yaml
 
 #检查
 kubectl get pvc
 
 
 
 
 vim pvc-pod.yaml
 #注意： set paste ,防止 yaml 文件空格错序
apiVersion: v1
kind: Pod
metadata:
  name: web-server                 
spec:
  volumes: 
    - name: task-pv-storage          #绿色的两个 name 要一样。
      persistentVolumeClaim:
        claimName: pv-volume         #这个要使用上面创建的 pvc 名字
  containers:
    - name: nginx
      image: nginx:1.16
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage		#绿色的两个 name 要一样。

#创建
kubectl apply -f pvc-pod.yaml

#检查
kubectl get pod web-server



#更改大小，并记录过程
将 storage: 10Mi 改为 storage: 70Mi 
注意是修改上面的 spec:里面的 storage:
kubectl edit pvc pv-volume --record 

12、查看pod日志 5`

Task

监控 pod foo 的日志并提取与错误 RLIMIT_NOFILE相对应的日志行

将这些日志行写入 /opt/KUTR00101/foo

考点： kubectl logs命令

#考试时务必切换集群。
kubectl config use-context k8s

#帮助
kubectl -h

kubectl logs foo | grep "RLIMIT_NOFILE" > opt/KUTR00101/foo



#检查
cat /opt/KUTR00101/foo

13、 sidecar 代理容器日志13`

context

将一个现有的Pod 集成到 Kubernetes 的内置日志记录体系结构中 （例如：kubectl logs）

添加 streaming sidecar 容器是实现此要求的一种好方法。

Task：

使用busybox image 来将名为 sidecar 的sidecar 容器添加到现有的Pod 11-factor-app中。

新的 sidecar 容器必须运行以下命令：

/bin/sh -c tail -n+1 -f /var/log/11-factor-app.log

使用挂载在/var/log 的volume，使用日志文件 11-factor-app.log 可用于 sidecar 容器。

除了添加所需的volume mount 以外，请勿更改现有容器的规格。

考点： pod 两个容器共享存储卷

# 务必切换集群环境
kubectl config use-context 2k8s



#导出这个pod 的yaml文件
kubectl get pod 11-factor-app -o yaml > varlog.yaml

#备份 yanl 文件，防止改错了，回退。
cp varlog.yaml varlog-bak.yaml

#修改 varlog.yaml文件
vim varlog.yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/containerID: e05930e0a31c02407e369bfe1aad638dfaa977f46007a4aaabd9569db54d3092
    cni.projectcalico.org/podIP: 10.244.196.175/32
    cni.projectcalico.org/podIPs: 10.244.196.175/32
  creationTimestamp: "2022-11-01T14:10:51Z"
  name: 11-factor-app
  namespace: default
  resourceVersion: "351901"
  uid: a8d8b84f-4742-4bde-ae10-2b4d2c4aa465
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - |
      i=0; while true; do
        echo "$(date) INFO $i" >> /var/log/11-factor-app.log;
        i=$((i+1));
        sleep 1;
      done
    image: busybox
    imagePullPolicy: IfNotPresent
    name: count
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xhzsg
      readOnly: true   #在原配置文件，灰色的这段后面添加
    - name: varlog 					#新加内容
      mountPath: /var/log			#新加内容
  - name: sidecar					#新加内容，注意 name 别写错了
    image: busybox					#新加内容
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/11-factor-app.log']   #新加内容，注意 文件名 别写错了。另外是用逗号分隔的，而题目里是空格
    volumeMounts:                    #新加内容
    - name: varlog					#新加内容
      mountPath: /var/log			#新加内容

  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: node01
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:										#在原配置文件，灰色的这段后面添加。
  - name: kube-api-access-xhzsg
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
  - name: varlog								#新加内容，注意找好位置。
    emptyDir: {}								#新加内容
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-11-01T14:10:51Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2023-01-29T07:25:56Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2023-01-29T07:25:56Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2022-11-01T14:10:51Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://ec95ab181959af25c40ee294135b57b52b622b4e3984b1be8d9fbdb9916f2995
    image: docker.io/library/busybox:latest
    imageID: sha256:bc01a3326866eedd68525a4d2d91d2cf86f9893db054601d6be524d5c9d03981
    lastState:
      terminated:
        containerID: containerd://5f53d729e1211861be4254d2d9dc6717b7d1352d6d858b4e1af7fc5d53b5d945
        exitCode: 255
        finishedAt: "2023-01-29T07:25:05Z"
        reason: Unknown
        startedAt: "2023-01-28T09:47:20Z"
    name: count
    ready: true
    restartCount: 10
    started: true
    state:
      running:
        startedAt: "2023-01-29T07:25:56Z"
  hostIP: 11.0.1.112
  phase: Running
  podIP: 10.244.196.175
  podIPs:
  - ip: 10.244.196.175
  qosClass: BestEffort
  startTime: "2022-11-01T14:10:51Z"



# 删除原先的 pod
kubectl delete pod 11-factor-app
kubectl get pod 11-factor-app
# 新建这个 pod
kubectl apply -f varlog.yaml


检查
# 考试时，仅使用第一条检查一下结果即可
kubectl logs 11-factor-app sidecar
# kubectl exec 11-factor-app -c sidecar -- tail -f /var/log/11-factor-app.log

14、升级集群 7`

现有的kubernetes集群正在运行版本1.25.1 仅将master节点上的所有 kubernetes 控制平面和节点组件升级到版本1.25.2

确保在升级之前drain master 节点, 并在升级后 uncordon master 节点.

通过ssh 连接到master节点,ssh master01

在master节点上获取更高权限,sudo -i

另外,在主节点上升级kubelet 和 kubectl

请不要升级工作节点,etcd ,container 管理器, CNI插件, DNS服务或其他插件

注意: 要求升级的集体版本!!!

考点: 如何离线主机, 并升级控制面板和升级节点

背命令
#kubectl -h

#切换集群
kubectl config use-context mk8s

开始操作
kubectl get nodes

#cordon 停止调度,将node 调为SchedulingDisabled 新pod 不会被调度到该node,但该node的旧node 不受影响

# drain 驱逐节点, 首先, 驱逐该node 上的pod ,并在其他节点重新创建,接着,将节点调为SchedulingDisabled.

# 所以 Kubectl cordon master01 这条可写可不写


#可以不写
kubectl cordon master01

#驱逐节点
kubectl drain master01 --ignore-daemonsets


#ssh到master节点 ,并切换root
ssh master01
sudo -i

#升级kubeadm

Ubuntu系统先更新
apt update

apt-cache show kubeadm| grep 1.25.2

apt install kubeadm=1.25.2-00



#检查kubeadm 升级后的版本
kubeadm version



#验证升级计划,会显示很多可升级的版本,我门关注题目要求升级到的那个版本
kubeadm upgrade plan

#排除etcd ,升级其他的,提示时,输入y
kubeadm upgrade apply v1.25.2 --etcd-upgrade=false





#升级kubelet
apt-get install kubelet=1.25.2-00
kubelet --version




#升级kubectl
apt-get install kubectl=1.25.2-00
kubectl version



# 退出 root ,退回到 candidate@master01
exit

#退出 master01 ,退回到 candidate@node01
exit

不要输入exit多了,否则会退出考试环境的.



#恢复master01调度
kubectl uncordon master01


#检查 master01 是否为Ready
kubectl get node

15、备份还原etcd 7`

Task
首先，为运行在 https://11.0.1.111:2379 上的现有 etcd 实例创建快照并将快照保存到 /var/lib/backup/etcd-snapshot.db
（注意，真实考试中，这里写的是 https://127.0.0.1:2379）
为给定实例创建快照预计能在几秒钟内完成。 如果该操作似乎挂起，则命令可能有问题。用 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

考点：etcd的备份和还原命令

#注意： 切换正确的集群
kubectl config use-context xxxx

开始操作

确认终端

#备份
#如果不使用 export ETCDCTL_API=3，而使用 ETCDCTL_API=3，则下面每条 etcdctl 命令前都要加 ETCDCTL_API=3。
# 如果执行时，提示 permission denied，则是权限不够，命令最前面加 sudo 即可。

一定要指定
export ETCDCTL_API=3

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1: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 --endpoints=https://127.0.0.1:2379 

#检查：（考试时，这些检查动作，都可以不做）
etcdctl snapshot status /var/lib/backup/etcd-snapshot.db -wtable





#还原
# 考试时，/data/backup/etcd-snapshot-previous.db 的权限应该是只有 root 可读，所以需要使用 sudo 命令。
# 可以 ll /data/backup/etcd-snapshot-previous.db 检查一下读写权限和属主。

# 不加 sudo 会报错 permission denied

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1: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
  
  

16、排查集群中故障节点 13`

Task

名为node02 的Kubernetes worker node 处于NotReady状态；

调查原因，采取相应的措施将node 恢复为ready状态确保所做的任何更改永久生效。

可以使用以下命令，通过 ssh 连接到 node02 节点：

ssh node02

可以使用以下命令，在该节点上获取更高权限：

sudo -i

#考试时务必切换集群
kubectl config use-context k8s


通过 get nodes 查看异常节点， 登录节点查看 kubelet 等组件的status 并判断原因。
考试时，异常节点的kubelet 服务没有启动导致的，

开始操作

#切换节点
ssh 到 node02 节点，并切换到root下

ssh node02 
sudo -i

#检查 kubelet 服务，考试时，会发现服务没有启动

systemctl status kubelet


# 启动服务， 并设置为开机启动

systemctl start kubectl

systemctl enable kubelet


#检查
systemctl status kubelet

# 退出 root，退回到 candidate@node02
exit
# 退出 node02，退回到 candidate@node01
exit
不要输入 exit 多了，否则会退出考试环境的。

再次检查节点， 确保 node02 节点恢复 Ready 状态
kubectl get nodes

17、节点维护 4`

Task：

将名为 node02 的 node 设置 为不可用，并重新调度该 node 上所有运行的pods

考点： cordon 和drain 命令的使用

# 考试时务必切换集群

kubectl config use-context ek8s


执行命令，模拟节点异常；

kubectl get node

kubectl cordon node02

kubectl get node




kubectl drain node02 --ignore-daemonsets
# 注意，还有一个参数--delete-emptydir-data --force，这个考试时不用加，就可以正常 draini node02 的。
# 但如果执行后，有跟测试环境一样的报错（如下截图），则需要加上--delete-emptydir-data --force，会强制将 pod 移除。

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


#检查

kubectl get node

kubectl get pod -A -o wide|grep node02

# 正常已经没有 pod 在 node02 上了。但测试环境里的 ingress、calico、kube-proxy 是 daemonsets 模式的，所以显示还在 node02 上，忽略即可。

容易出错点

注意：

集群升级一定要加上版本号，要对应好比如：1.26.0-00；

不要忘记升级之前和之后！

节点维护和集群升级