手動升級kubernetes集群
在我最開始寫作本書的時候，kubernetes剛發布1.6.0版本，而kubernetes基本按照每三個月發布一個大版本的速度迭代，為了使用新特性和只支持新版本kubernetes的配套軟件，升級kubernetes就迫在眉睫，在此我們使用替換kubernets的舊的二進制文件這種暴力的方式來升級測試集群，若升級生產集群還望三思。
另外，自kubernetes1.6版本之后發布的1.7和1.8版本又增加了一些新特性，參考：
目前kubernetes的官方文檔上並沒有詳細的手動安裝的集群如何升級的參考資料，只有兩篇關於kubernetes集群升級的文檔。
- 在ubuntu上如何使用juju升級：https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/
手動升級的還沒有詳細的方案，大多是基於管理工具部署和升級，比如juju、kubeadm、kops、kubespray等。
manual upgrade/downgrade testing for Kubernetes 1.6 - google group，在這個Google group中討論了kubernetes手動升級的問題，並給出了參考建議。
升級步驟
注意：該升級步驟是實驗性的，建議在測試集群上使用，無法保證線上服務不中斷，實際升級完成后無需對線上服務做任何操作。
大體上的升級步驟是，先升級master節點，然后再一次升級每台node節點。
升級建議
下圖來自@ahmetb的Twitter，這是他對於0宕機時間的kubernetes集群升級建議。
圖片 - Kubernetes零宕機時間升級建議
主要包括以下建議：
- 應用使用高級對象定義，如支持滾動更新的
Deployment對象 - 應用要部署成多個實例
- 使用pod的preStop hook，加強pod的生命周期管理
- 使用就緒和健康檢查探針來確保應用存活和及時阻攔應用流量的分發
准備
- 備份kubernetes原先的二進制文件和配置文件。
- 下載最新版本的kubernetes二進制包，如1.8.5版本，查看changelog，下載二進制包，我們使用的是kubernetes-server-linux-amd64.tar.gz，分發到集群的每個節點上。
升級master節點
停止master節點的進程
systemctl stop kube-apiserver
systemctl stop kube-scheduler
systemctl stop kube-controller-manager
systemctl stop kube-proxy
systemctl stop kubelet
使用新版本的kubernetes二進制文件替換原來老版本的文件，然后啟動master節點上的進程：
systemctl start kube-apiserver
systemctl start kube-scheduler
systemctl start kube-controller-manager
因為我們的master節點同時也作為node節點，所有還要執行下面的”升級node節點“中的步驟。
升級node節點
關閉swap
# 臨時關閉 swapoff -a # 永久關閉，注釋掉swap分區即可 vim /etc/fstab #UUID=65c9f92d-4828-4d46-bf19-fb78a38d2fd1 swap swap defaults 0 0 修改kubelet的配置文件
將kubelet的配置文件/etc/kubernetes/kublet配置文件中的KUBELET_API_SERVER="--api-servers=http://172.20.0.113:8080"行注釋掉。
注意：：kubernetes1.7及以上版本已經沒有該配置了，API server的地址寫在了kubeconfig文件中。
停止node節點上的kubernetes進程：
systemctl stop kubelet
systemctl stop kube-proxy
使用新版本的kubernetes二進制文件替換原來老版本的文件，然后啟動node節點上的進程：
systemctl start kubelet
systemctl start kube-proxy
啟動新版本的kube-proxy報錯找不到conntrack命令，使用yum install -y conntrack-tools命令安裝后重啟kube-proxy即可。
檢查
到此升級完成，在master節點上檢查節點狀態：
NAME STATUS ROLES AGE VERSION
172.20.0.113 Ready <none> 244d v1.8.5 172.20.0.114 Ready <none> 244d v1.8.5 172.20.0.115 Ready <none> 244d v1.8.5 所有節點的狀態都正常，再檢查下原先的運行在kubernetes之上的服務是否正常，如果服務正常的話說明這次升級無誤。
API版本變更適配
對於不同版本的Kubernetes，許多資源對象的API的版本可能會變更，下表列出了kubernetes1.5至1.9的API資源對象的版本演進：
圖片 - Kuberentes API對象的版本演進
當我們升級過后，可能出現資源對象的API變更后，原先的YAML文件無法使用的情況，因此需要對新版本的Kubernetes進行適配。對應的API版本轉換工具：https://github.com/fleeto/kube-version-converter，可以將Kuberntes API對象轉換到指定版本。