• ChangeLog, https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md
• Kubernetes 1.15 釋出，可擴充套件性與持續性改進, https://www.oschina.net/news/107618/kubernetes-1-15-released
• kubeadm升級kubernetes到1.15.0版本, https://www.codercto.com/a/88502.html
• Kubernetes v1.15.0 環境搭建 - CentOS, https://www.jianshu.com/p/832bcd89bc07

1、升級kubeadm/kubectl/kubelet版本

sudo apt install kubeadm=1.15.0-00 kubectl=1.15.0-00 kubelet=1.15.0-00

• kubernetes for china

檢視該版本的容器映象版本：

kubeadm config images list

輸出如下：

~# kubeadm config images list

k8s.gcr.io/kube-apiserver:v1.15.0
k8s.gcr.io/kube-controller-manager:v1.15.0
k8s.gcr.io/kube-scheduler:v1.15.0
k8s.gcr.io/kube-proxy:v1.15.0
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.3.10
k8s.gcr.io/coredns:1.3.1
 

2、拉取容器映象

原始的kubernetes映象檔案在gcr上，不能直接下載。我給映象到了阿里雲的杭州機房的容器倉庫裡，拉取還是比較快的。

echo ""
echo "=========================================================="
echo "Pull Kubernetes v1.15.0 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.0
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.15.0
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.15.0
docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.15.0
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.0 k8s.gcr.io/kube-apiserver:v1.15.0
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.15.0 k8s.gcr.io/kube-scheduler:v1.15.0
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.15.0 k8s.gcr.io/kube-controller-manager:v1.15.0
docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.15.0 k8s.gcr.io/kube-proxy:v1.15.0
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.0 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.0版本：
sudo kubeadm init --kubernetes-version=v1.15.0 --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.14.1   v1.15.0
Controller Manager   v1.14.1   v1.15.0
Scheduler            v1.14.1   v1.15.0
Kube Proxy           v1.14.1   v1.15.0
CoreDNS              1.3.1     1.3.1
Etcd                 3.3.10    3.3.10

確保上面的容器映象已經下載（如果沒有提前下載，可能被網路阻隔導致掛起），然後執行升級：

kubeadm upgrade -y apply v1.15.0

看到下面資訊，就OK了。

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.15.0". 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.0。

在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。
  • 再次執行flannel的安裝，不管用。
  • 但是，修改完重啟叢集就起不來了。進去看pod狀態為Crash。
  • 強制刪除CoreDNS的Pod執行例項。Kubernetes會自動啟動新的例項。
    • 可以參考《Kubernetes中強制刪除已銷燬的頑固pod》。
• 原來安裝的jupyterhub起不來了，進去看hub pod狀態為Crash。
  • 檢視hub的日誌，顯示SQLlite訪問出錯，將其從宿主儲存目錄下移除，訪問hub service失敗。
  • 刪除hub pod後，service的proxy-public也無法連線。
  • 強制刪除JupyterHub的hub和Proxy的Pod執行例項。
  • 強制刪除CoreDNS的Pod執行例項，Kubernetes自動啟動新例項後，執行恢復。
  • 有時候是glusterfs設定許可權問題，setfacl/getfacl進行設定。
    • 參考：GlusterFS: 訪問許可權設定
  • 進一步檢查，發現可能是GlusterFS的volume寫入問題，不同步引起的。
    • hub-db-dir目錄下的jupyterhub.sqllite寫入臨時檔案存在，導致鎖死，不是glusterfs寫入許可權問題。
    • 設定gluster volume heal vol01 enable，讓其資料同步。
    • 重啟volume或者glusterd服務。
    • 或者，刪除所有gluster儲存節點下的hub-db-dir目錄下的jupyterhub.sqllite檔案，再刪除hub pod，使其自動重建檔案。
    • 一般上面幾步後，能夠恢復。

其它：

• 出現整個叢集無法訪問，kubectl get node失敗，kubectl version時apiserver訪問失敗。
• 檢視其中一個節點route，再次出現神祕的podsxx 255.255.255.255路由記錄，route del刪除記錄失敗。
• 執行sudo netplan apply後，路由記錄消失，節點恢復可訪