29.kubernetes升级

一、升级思路

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

二、版本偏差策略
列比排apiserverkubelet
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版本
在这里插入图片描述

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐