29.kubernetes升级

一、升级思路

正在运行的业务容器不中断，进行灰度升级。一般的是先更新master上的k8s服务版本，再滚动更新node上的k8s服务。node上的服务升级要先隔离目标node的业务流量，待在途任务全部执行完成后停掉业务pod，再更新目标node上的kubelet和kube-proxy版本，升级完成后启动业务pod释放业务流量。再同理逐步升级其他node节点。
升级时考虑高版本Master对低版本Node的兼容性，高版本的Master一般可以管理低版本的Node，但版本不可以差异过大，例如某些功能或API被高版本弃用后，低版本的Node将无法运行，具体的查看官方文档kubernetes版本及版本偏差支持策略

二、版本偏差策略

列比排	apiserver	kubelet
apiserver	±1
con\sche	-1
kubelet	-2
kube-proxy	-2	同节点必须相同
kubectl	±1

• 集群内apiserver小版本最多差1
• kubelet版本号不能高于apiserver，最多比apiserver低两个小版本
• kube-controller-manager、kube-scheduler 版本号最好与 kube-apiserver 保持一致，但允许比 kube-apiserver 低一个小版本（为了支持在线升级）
• kubectl可以比apiserver高一个小版本，亦可以低一个小版本
• kube-proxy必须和节点上的kubelet的小版本保持一致

三、升级Master服务

1. 升级kube-apiserver

所有master逐个先升级

2. 升级kube-con\sche

待所有kube-apiserver全部升级完成后，再逐个升级kube-controller-manager和kube-scheduler

3. 升级kubectl

四、升级Node服务

待所有Master服务升级完成后，再逐个或批量滚动升级Node服务

1. 隔离目标node

kubectl cordon node1

2. 驱逐node上的pod

kubectl drain node1 --delete-local-data --ignore-daemonsets --force
–delete-local-data: 即使pod使用了emptyDir也删除
–ignore-daemonsets: 忽略deamonset控制器的pod，如果不忽略，deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,会成为死循环；
–force: 不加force参数只会删除该NODE上由ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job创建的Pod，加了后还会删除’裸奔的pod’(没有绑定到任何replication controller)

3. 升级kubelet和kube-proxy

4. 解除隔离

kubectl uncordon node1

临时图
下图升级apiserver后，又升级了master节点上的kubelet和kube-proxy

同理升级到1.19版本