共計 4451 個字符，預計需要花費 12 分鐘才能閱讀完成。
這篇文章主要介紹 Kubernetes 1.15.2 如何快速升級，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
1、升級 kubeadm/kubectl/kubelet 版本
sudo apt install kubeadm=1.15.2-00 kubectl=1.15.2-00 kubelet=1.15.2-00kubernetes for china
查看該版本的容器鏡像版本：
kubeadm config images list輸出如下：
~# kubeadm config images list
k8s.gcr.io/kube-apiserver:v1.15.2
k8s.gcr.io/kube-controller-manager:v1.15.2
k8s.gcr.io/kube-scheduler:v1.15.2
k8s.gcr.io/kube-proxy:v1.15.2
k8s.gcr.io/pause:3.1k8s.gcr.io/etcd:3.3.10
k8s.gcr.io/coredns:1.3.1
2、拉取容器鏡像
原始的 kubernetes 鏡像文件在 gcr 上，不能直接下載。我給鏡像到了阿里云的杭州機房的容器倉庫里，拉取還是比較快的。
echo
echo ==========================================================
echo Pull Kubernetes v1.15.2 Images from aliyuncs.com ......
echo ==========================================================
echo
MY_REGISTRY=registry.cn-hangzhou.aliyuncs.com/openthings
## 拉取鏡像
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-apiserver:v1.15.2
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.15.2
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.15.2
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.15.2
docker pull ${MY_REGISTRY}/k8s-gcr-io-etcd:3.3.10
docker pull ${MY_REGISTRY}/k8s-gcr-io-pause:3.1
docker pull ${MY_REGISTRY}/k8s-gcr-io-coredns:1.3.1
## 添加 Tag
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-apiserver:v1.15.2 k8s.gcr.io/kube-apiserver:v1.15.2
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.15.2 k8s.gcr.io/kube-scheduler:v1.15.2
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.15.2 k8s.gcr.io/kube-controller-manager:v1.15.2
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.15.2 k8s.gcr.io/kube-proxy:v1.15.2
docker tag ${MY_REGISTRY}/k8s-gcr-io-etcd:3.3.10 k8s.gcr.io/etcd:3.3.10
docker tag ${MY_REGISTRY}/k8s-gcr-io-pause:3.1 k8s.gcr.io/pause:3.1
docker tag ${MY_REGISTRY}/k8s-gcr-io-coredns:1.3.1 k8s.gcr.io/coredns:1.3.1
echo
echo ==========================================================
echo Pull Kubernetes v1.15.2 Images FINISHED.
echo into registry.cn-hangzhou.aliyuncs.com/openthings,
echo by openthings@https://my.oschina.net/u/2306127.
echo ==========================================================
echo 保存為 shell 腳本，然后執行。
或者，下載腳本：https://github.com/openthings/kubernetes-tools/blob/master/kubeadm/2-images/
3、升級 Kubernetes 集群
全新安裝：
# 指定 IP 地址，1.15.2 版本：sudo kubeadm init --kubernetes-version=v1.15.2 --apiserver-advertise-address=10.1.1.199 --pod-network-cidr=10.244.0.0/16
#注意，CoreDNS 已經內置，不再需要參數 --feature-gates CoreDNS=true先查看一下需要升級的各個組件的版本。
使用 kubeadm upgrade plan，輸出的版本升級信息如下：
COMPONENT CURRENT AVAILABLE
API Server v1.15.0 v1.15.2
Controller Manager v1.15.0 v1.15.2
Scheduler v1.15.0 v1.15.2
Kube Proxy v1.15.0 v1.15.2
CoreDNS 1.3.1 1.3.1
Etcd 3.3.10 3.3.10確保上面的容器鏡像已經下載（如果沒有提前下載，可能被網絡阻隔導致掛起），然后執行升級：
kubeadm upgrade -y apply v1.15.2看到下面信息，就 OK 了。
[upgrade/successful] SUCCESS! Your cluster was upgraded to v1.15.2 . Enjoy!然后，配置當前用戶環境：
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config就可以使用 kubectl version 來查看狀態和 kubectl cluster-info 查看服務地址。
4、工作節點的升級
每個工作節點需要拉取上面對應版本的鏡像，以及安裝 kubelet 的對應版本。
檢查版本：
~$ kubectl version查看 Pod 信息：
kubectl get pod --all-namespaces完成。
5、HA cluster 的升級
從 1.13.x 之前的版本升級上了的話，因為 api 改變（kubelet 升為 1.14 后無法啟動 apiserver），導致新的 kubeadm 訪問以前的 apiserver 出錯，從而升級失敗。可以拉取鏡像下來后，手工切換鏡像的版本（所有節點的 /etc/kubernetes/manifests 下的文件都需要修改）。
對每一個節點，執行下面的步驟：
cd /etc/kubernetes/manifests/。
改變所有的 *.yaml , 指定 images 版本為 1.15.2。
在 1.14.0 版本升級完后，出現問題 (1.14.1 仍存在)：
工作節點 join 到 cluster 失敗，參見 [kubeadm] #76013, https://github.com/kubernetes/kubernetes/issues/76013
據有的社區成員測試，全新安裝的 1.14 集群可以正常運行。
我的集群是從 1.13.4 上升級而來，經測試 1.14.1 版本，該問題仍然存在。
kube-proxy 的版本需要進管理工具去修改 DaemonSet 的 images 版本號為 1.14.1。
coredns 的版本需要進管理工具去修改復制集的 images 版本號為 1.3.1。
可以參考《Kubernetes 中強制刪除已銷毀的頑固 pod》。
再次運行 flannel 的安裝，不管用。
但是，修改完重啟集群就起不來了。進去看 pod 狀態為 Crash。
強制刪除 CoreDNS 的 Pod 運行實例。Kubernetes 會自動啟動新的實例。
原來安裝的 jupyterhub 起不來了，進去看 hub pod 狀態為 Crash。
hub-db-dir 目錄下的 jupyterhub.sqllite 寫入臨時文件存在，導致鎖死，不是 glusterfs 寫入權限問題。
設置 gluster volume heal vol01 enable，讓其數據同步。
重啟 volume 或者 glusterd 服務。
或者，刪除所有 gluster 存儲節點下的 hub-db-dir 目錄下的 jupyterhub.sqllite 文件，再刪除 hub pod，使其自動重建文件。
一般上面幾步后，能夠恢復。
參考：GlusterFS: 訪問權限設置
查看 hub 的日志，顯示 SQLlite 訪問出錯，將其從宿主存儲目錄下移除，訪問 hub service 失敗。
刪除 hub pod 后，service 的 proxy-public 也無法連接。
強制刪除 JupyterHub 的 hub 和 Proxy 的 Pod 運行實例。
強制刪除 CoreDNS 的 Pod 運行實例，Kubernetes 自動啟動新實例后，運行恢復。
有時候是 glusterfs 設置權限問題，setfacl/getfacl 進行設置。
進一步檢查，發現可能是 GlusterFS 的 volume 寫入問題，不同步引起的。
其它：
出現整個集群無法訪問，kubectl get node 失敗，kubectl version 時 apiserver 訪問失敗。
查看其中一個節點 route，再次出現神秘的 podsxx 255.255.255.255 路由記錄，route del 刪除記錄失敗。
運行 sudo netplan apply 后，路由記錄消失，節點恢復可訪問。
以上是“Kubernetes 1.15.2 如何快速升級”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！
