筆者今天講的升級方式為官方推薦的方法：使用 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；