笔者今天讲的升级方式为官方推荐的方法：使用 kubeadm 升级集群；

为什么要写？

笔者最近发现kubernetes的从版本12.1开始，加入了证书轮换的功能；这意味着使用kubeadm安装也能不用顾忌证书过期的问题；

之前的策略是需要至少每半年升级一次，在升级的过程中，如果证书小于180天，会自动替换新的证书；

但是实际生产环境中，大多不会保持这个频率升级生产环境，所以证书过期的隐患；

这也是很多人选择手动安装的原因之一；

 

据笔者自己体验，从1.8开始，kubeadm的部署过程已经比其他方式的安装过程要更有效率的多；

且笔者更偏向于将kubernetes组件以容器的方式跑在kubernetes内部（etcd除外，笔者更偏向于跑在集群外部，实际生产环境也是这样运行的）；

kubeadm部署的环境刚好能满足笔者的需求（支持自定义配置文件部署，很好的满足了个性化的需求），所以在这里推荐大家也使用这种方式部署集群，且日后的升级也十分的方便（kubeadm安装高可用集群的文章点击这里---哈哈哈，暂时没写，没空）；

 

升级过程

现有集群的版本如下图所示，为10.5的版本；

先从master开始升级；

执行

kubectl cordon master其中一台的节点名

可再次通过get nodes 的命令看到该节点已被标记不可调度；

 

然后执行

kubectl drain master节点名 --ignore-daemonsets

如下图所示，可以看到提示：忽略了所有的daemonset的pod，并且将剩余的pod驱逐；

 

接下来需要升级kubeadm到1.11.X版本（kubeadm升级不能跳版本，比如10.x不能直接升级至12.X，需要先升级到11.X版本）

准备好11.3的镜像

gcr.io/google_containers/kube-apiserver-amd64:v1.11.3

gcr.io/google_containers/kube-proxy-amd64:v1.11.3

gcr.io/google_containers/kube-scheduler-amd64:v1.11.3

gcr.io/google_containers/kube-controller-manager-amd64:v1.11.3

coredns/coredns:v1.1.3

quay.io/coreos/flannel:v0.10.0-amd64

k8s.gcr.io/pause-amd64:3.1

 

导出集群的master配置后，使用该配置文件进行升级；

执行

kubeadm upgrade apply v1.11.3 --config kubeadm-config.yaml

如下图所示，开始升级；

结果如下图所示：

 

此时，该master节点的api等组件已升级至11.3；

将kubelet与kubectl也升级至11.3（笔者使用的是yum安装升级）；

注意kubelet此时的配置文件为初始默认的配置文件，所以可将其他master节点上的kubelet配置文件复制过来；

文件路径：/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

重启kubelet，执行

systemctl daemon-reload

systemctl restart kubelet

最后恢复master的调度，执行

kubectl uncordon master节点名称

至此，该台master的升级已经全部完成

同样方式，操作其余master与node即可完成集群的全部11.X的升级；

再同样的操作可继续升级至12.X；