背景：

线上 kubernetes 环境应用 kubeadm 搭建. 过后应该是 1.15 的 kubeadm 搭建的。稳固运行了近两年的工夫。其中降级了一次大版本从 1.15 降级到 1.16。进行过屡次小版本升级。当初的版本为 1.16.15。两头也曾想降级过版本到更高的版本，然而降级 master 的时候出现异常了，还好是三节点的 master 集群，就复原到了 1.16 的版本。始终没有进行更高版本的降级。昨天总算是对集群下手降级了 ……

集群配置

Kubernetes 降级过程

1. 参考官网文档

参照：https://kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

https://v1-17.docs.kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
kubeadm 创立的 Kubernetes 集群从 1.16.x 版本升级到 1.17.x 版本，以及从版本 1.17.x 降级到 1.17.y，其中 y > x

2. 确认可降级版本与降级计划

yum list --showduplicates kubeadm --disableexcludes=kubernetes

因为我的 kubeadm 版本是 1.16.15 那我只能先降级到 1.17.15 而后从 1.17.15 降级到 1.17.17（先不思考降级更高版本）。master 节点有 k8s-master-01 k8s-master-02 k8s-master-03 三个节点，集体习惯个别不喜爱先动第一个，就间接从第三个节（sh-master-03）点动手了 ……

3. 降级 k8s-master-03 节点管制立体

yum install  kubeadm-1.17.15-0 --disableexcludes=kubernetes

sudo kubeadm upgrade plan

嗯 能够降级到 1.17.17？试一下

kubeadm upgrade apply v1.17.17

不能降级到 1.17.17 然而能够到 1.17.16？然而要先降级 kubeadm。怎么会是这样呢？如下是能够 1.y 到 1.y+ 1 版本的。

kubeadm upgrade apply v1.17.15

yum install -y kubelet-1.17.15-0 kubectl-1.17.15-0 --disableexcludes=kubernetes

systemctl daemon-reload
sudo systemctl restart kubelet

嗯还是没有搞明确怎么就还是到 1.17.16 版本了，无伤大雅了。就先这样了！

注：当然了为了防止出现问题，应该是先把 /etc/kubernetes 文件门路下配置文件备份一下！

4. 降级其余管制立体（k8s-master-02 k8s-master-03）

其余两个 master 节点都执行一下命令：

yum install -y kubeadm-1.17.15-0 --disableexcludes=kubernetes
kubeadm upgrade node
yum install -y kubelet-1.17.15-0 kubectl-1.17.15-0 --disableexcludes=kubernetes
systemctl daemon-reload
sudo systemctl restart kubelet

登陆任意一台 master 节点：

[root@k8s-master-03 ~]# kubectl get nodes
NAME             STATUS                     ROLES    AGE    VERSION
k8s-master-01    Ready                      master   297d   v1.17.15
k8s-master-02    Ready                      master   297d   v1.17.15
k8s-master-03    Ready                      master   297d   v1.17.16-rc.0
k8s-node-01      Ready                      node     549d   v1.16.15
k8s-node-02      Ready                      node     2d5h   v1.16.15
k8s-node-03      Ready                      node     549d   v1.16.15
k8s-node-04      Ready                      node     547d   v1.16.15
k8s-node-05      Ready                      node     547d   v1.16.15
k8s-node-06      Ready                      node     192d   v1.16.15
test-ubuntu-01   Ready,SchedulingDisabled   <none>   47h    v1.16.15
tm-node-002      Ready                      node     154d   v1.16.15
tm-node-003      Ready                      <none>   99d    v1.16.15

5. 持续降级小版本到 1.17.17

同理，反复以上的步骤，小版本升级到 1.17.17

kubectl get nodes -o  wide

留神：以上 master-02 master-03 管制立体节点降级疏忽了凌空节点步骤

6. work 节点的降级

所有 work 节点执行：
注：演示在 k8s-node-03 节点执行

 yum install  kubeadm-1.17.17 kubectl-1.17.17 kubelet-1.17.17 --disableexcludes=kubernetes

将节点设置为不可调度，并凌空节点：

 kubectl drain k8s-node-03 --ignore-daemonsets

kubeadm upgrade node
sudo systemctl daemon-reload
sudo systemctl restart kubelet

kubectl uncordon k8s-node-03
kubectl get nodes -o wide

注：后截的图 already 疏忽，就看后果 ……，就先降级几个节点了。其余几点节点有工夫再进行降级，预计也差不多，如有什么异样再进行整顿剖析！

7. 降级与应用中呈现的一些小问题

1. clusterrole

还是有些小异样，比方：我的 controller-manager 的 clusterrole system:kube-controller-manager 的权限怎么就有问题了？

不晓得过后是不是因为只降级了两个节点 k8s-master-01 节点造成的。在呈现这个问题的时候我是降级了 k8s-master-01 节点，而后删除了 clusterrole system:kube-controller-manager，而后把我 kubernetes1.21 的 clusterrole 搞过来 apply 了

 kubectl get  clusterrole system:kube-controller-manager -o yaml > 1.yaml

 kubectl get  clusterrole system:kube-controller-manager -o yaml >clusterrole.yaml
 kubectl apply -f 1.yaml

反正貌似就是解决了 ….clusterrole 这货色看看认真整一下。最近反正是有点懵了 ……

2. flannel 的异样

还有一个问题是 flannel 的：
我的集群是 1.15 降级上来的。始终是没有问题的，然而新减少 work 节点后，调配到新节点的带探针的就会有各种诡异的问题.，要么探测不通过，要么重启反正各种问题 ….. 怎么回事呢？

狐疑了一下 flannel. 登陆 github flannel 仓库看了一下：

看了一下我的集群的 flannel 版本还都是 v0.11。不论他了先降级一下 flannel 吧 ……

kubectl delete -f XXX.yaml(老的 flannel 插件配置文件)

官网下载 kube-flannel.yaml 文件
​

批改 network

注：当然了如果还是 1.16 也要批改一下 rbac 的 apiversion.

kubectl apply -f kube-flannel.yaml

批改后是根本没有呈现以往探针失败重启的景象了。

3. Prometheus 的报错

kubernetes 版本对应 Prometheus 的版本:

嗯我的是晚期的 0.4 分支，kubernetes1.17 还能够用。不过 control-manager scheduler 的报警都出现异常问题了 …… 参照 https://duiniwukenaihe.github.io/2021/05/14/Kubernetes-1.20.5-upgrade1.21.0%E5%90%8E%E9%81%97%E7%97%87/ 批改 kube-controller-manage kube-scheduler 配置文件。当然了。我如果降级到 1.18 或者更高的版本就刺激了 ….. 的切换分支进行重新配置还是什么呢？

后记：

1. 尽量去参考官网文档
2. 记得降级网络组件
3. api 如有变动，记得批改相干组件 version 或者配置文件

​