Kubernetes 1.14.1快速升级的方法是什么

70次阅读
没有评论

共计 4554 个字符,预计需要花费 12 分钟才能阅读完成。

这篇文章主要讲解了“Kubernetes 1.14.1 快速升级的方法是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着丸趣 TV 小编的思路慢慢深入,一起来研究和学习“Kubernetes 1.14.1 快速升级的方法是什么”吧!

1、升级 kubeadm/kubectl/kubelet 版本

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

2、拉取容器镜像

原始的 kubernetes 镜像文件在 gcr 上,不能直接下载。我给镜像到了阿里云的杭州机房的容器仓库里,拉取还是比较快的。

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 脚本,然后执行。

或者,下载脚本:https://github.com/openthings/kubernetes-tools/blob/master/kubeadm/2-images/

3、升级 Kubernetes 集群

全新安装:

# 指定 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 已经内置,不再需要参数 --feature-gates CoreDNS=true

先查看一下需要升级的各个组件的版本。

使用 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

确保上面的容器镜像已经下载(如果没有提前下载,可能被网络阻隔导致挂起),然后执行升级:

kubeadm upgrade -y apply v1.14.1

看到下面信息,就 OK 了。

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

在 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.14.1 快速升级的方法是什么”的内容了,经过本文的学习后,相信大家对 Kubernetes 1.14.1 快速升级的方法是什么这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是丸趣 TV,丸趣 TV 小编将为大家推送更多相关知识点的文章,欢迎关注!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计4554字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)