共计 4501 个字符，预计需要花费 12 分钟才能阅读完成。
丸趣 TV 小编给大家分享一下 Kubernetes 1.15.0 如何快速升级，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
1、升级 kubeadm/kubectl/kubelet 版本
sudo apt install kubeadm=1.15.0-00 kubectl=1.15.0-00 kubelet=1.15.0-00kubernetes 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.1k8s.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。
可以参考《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.0 如何快速升级”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
