這篇文章主要講解了“Kubernetes 1.14.1快速升級的方法是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Kubernetes 1.14.1快速升級的方法是什么”吧！
10余年的本溪網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。全網(wǎng)整合營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整本溪建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)公司從事“本溪網(wǎng)站設(shè)計(jì)”,“本溪網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
sudo apt install kubeadm=1.14.1-00 kubectl=1.14.1-00 kubelet=1.14.1-00
查看該版本的容器鏡像版本：
kubeadm config images list
輸出如下：
~# kubeadm config images list k8s.gcr.io/kube-apiserver:v1.14.1 k8s.gcr.io/kube-controller-manager:v1.14.1 k8s.gcr.io/kube-scheduler:v1.14.1 k8s.gcr.io/kube-proxy:v1.14.1 k8s.gcr.io/pause:3.1k8s.gcr.io/etcd:3.3.10 k8s.gcr.io/coreDNS:1.3.1
原始的kubernetes鏡像文件在gcr上，不能直接下載。我給鏡像到了阿里云的杭州機(jī)房的容器倉庫里，拉取還是比較快的。
重慶分公司
重慶分公司
echo ""
echo "=========================================================="
echo "Pull Kubernetes v1.14.1 Images from aliyuncs.com ......"
echo "=========================================================="
echo ""
MY_REGISTRY=registry.cn-hangzhou.aliyuncs.com/openthings
## 拉取鏡像
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-apiserver:v1.14.1
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.14.1
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.14.1
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.14.1
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.14.1 k8s.gcr.io/kube-apiserver:v1.14.1
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.14.1 k8s.gcr.io/kube-scheduler:v1.14.1
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.14.1 k8s.gcr.io/kube-controller-manager:v1.14.1
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.14.1 k8s.gcr.io/kube-proxy:v1.14.1
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.14.1 Images FINISHED."
echo "into registry.cn-hangzhou.aliyuncs.com/openthings, "
echo " by openthings@https://my.oschina.net/u/2306127."
echo "=========================================================="
echo ""保存為shell腳本，然后執(zhí)行。
或者，下載腳本：https://github.com/openthings/kubernetes-tools/blob/master/kubeadm/2-images/
全新安裝：
#指定IP地址，1.14.1版本： sudo kubeadm init --kubernetes-version=v1.14.1 --apiserver-advertise-address=10.1.1.199 --pod-network-cidr=10.244.0.0/16 #注意，CoreDNS已經(jīng)內(nèi)置，不再需要參數(shù)--feature-gates CoreDNS=true
先查看一下需要升級的各個(gè)組件的版本。
使用kubeadm upgrade plan，輸出的版本升級信息如下：
COMPONENT CURRENT AVAILABLE API Server v1.14.0 v1.14.1 Controller Manager v1.14.0 v1.14.1 Scheduler v1.14.0 v1.14.1 Kube Proxy v1.14.0 v1.14.1 CoreDNS 1.3.1 1.3.1 Etcd 3.3.10 3.3.10
確保上面的容器鏡像已經(jīng)下載（如果沒有提前下載，可能被網(wǎng)絡(luò)阻隔導(dǎo)致掛起），然后執(zhí)行升級：
kubeadm upgrade -y apply v1.14.1
看到下面信息，就OK了。
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.14.1". Enjoy!
然后，配置當(dāng)前用戶環(huán)境：
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 來查看狀態(tài)和 kubectl cluster-info 查看服務(wù)地址。
每個(gè)工作節(jié)點(diǎn)需要拉取上面對應(yīng)版本的鏡像，以及安裝kubelet的對應(yīng)版本。
檢查版本：
~$ kubectl version
查看Pod信息：
kubectl get pod --all-namespaces
完成。
從1.13.x之前的版本升級上了的話，因?yàn)閍pi改變（kubelet升為1.14后無法啟動(dòng)apiserver），導(dǎo)致新的kubeadm訪問以前的apiserver出錯(cuò)，從而升級失敗?？梢岳＄R像下來后，手工切換鏡像的版本（所有節(jié)點(diǎn)的/etc/kubernetes/manifests下的文件都需要修改）。
對每一個(gè)節(jié)點(diǎn)，執(zhí)行下面的步驟：
cd /etc/kubernetes/manifests/。
改變所有的 *.yaml , 指定 images 版本為 1.14.1。
在1.14.0版本升級完后，出現(xiàn)問題(1.14.1仍存在)：
工作節(jié)點(diǎn) join 到 cluster失敗，參見 [kubeadm] #76013, https://github.com/kubernetes/kubernetes/issues/76013
據(jù)有的社區(qū)成員測試，全新安裝的1.14集群可以正常運(yùn)行。
我的集群是從1.13.4上升級而來，經(jīng)測試1.14.1版本，該問題仍然存在。
kube-proxy的版本需要進(jìn)管理工具去修改DaemonSet的images版本號為1.14.1。
coredns的版本需要進(jìn)管理工具去修改復(fù)制集的images版本號為1.3.1。
可以參考《Kubernetes中強(qiáng)制刪除已銷毀的頑固pod》。
再次運(yùn)行flannel的安裝，不管用。
但是，修改完重啟集群就起不來了。進(jìn)去看pod狀態(tài)為Crash。
強(qiáng)制刪除CoreDNS的Pod運(yùn)行實(shí)例。Kubernetes會(huì)自動(dòng)啟動(dòng)新的實(shí)例。
原來安裝的jupyterhub起不來了，進(jìn)去看hub pod狀態(tài)為Crash。
hub-db-dir目錄下的jupyterhub.sqllite寫入臨時(shí)文件存在，導(dǎo)致鎖死，不是glusterfs寫入權(quán)限問題。
設(shè)置gluster volume heal vol01 enable，讓其數(shù)據(jù)同步。
重啟volume或者glusterd服務(wù)。
或者，刪除所有g(shù)luster存儲(chǔ)節(jié)點(diǎn)下的hub-db-dir目錄下的jupyterhub.sqllite文件，再刪除hub pod，使其自動(dòng)重建文件。
一般上面幾步后，能夠恢復(fù)。
參考：GlusterFS: 訪問權(quán)限設(shè)置
查看hub的日志，顯示SQLlite訪問出錯(cuò)，將其從宿主存儲(chǔ)目錄下移除，訪問hub service失敗。
刪除hub pod后，service的proxy-public也無法連接。
強(qiáng)制刪除JupyterHub的hub和Proxy的Pod運(yùn)行實(shí)例。
強(qiáng)制刪除CoreDNS的Pod運(yùn)行實(shí)例，Kubernetes自動(dòng)啟動(dòng)新實(shí)例后，運(yùn)行恢復(fù)。
有時(shí)候是glusterfs設(shè)置權(quán)限問題，setfacl/getfacl進(jìn)行設(shè)置。
進(jìn)一步檢查，發(fā)現(xiàn)可能是GlusterFS的volume寫入問題，不同步引起的。
其它：
出現(xiàn)整個(gè)集群無法訪問，kubectl get node失敗，kubectl version時(shí)apiserver訪問失敗。
查看其中一個(gè)節(jié)點(diǎn)route，再次出現(xiàn)神秘的podsxx 255.255.255.255路由記錄，route del刪除記錄失敗。
運(yùn)行sudo netplan apply后，路由記錄消失，節(jié)點(diǎn)恢復(fù)可訪問。
感謝各位的閱讀，以上就是“Kubernetes 1.14.1快速升級的方法是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Kubernetes 1.14.1快速升級的方法是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！
