重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要讲解了“Kubernetes 1.14.1快速升级的方法是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Kubernetes 1.14.1快速升级的方法是什么”吧!
10余年的本溪网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。全网整合营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整本溪建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联公司从事“本溪网站设计”,“本溪网站推广”以来,每个客户项目都认真落实执行。
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上,不能直接下载。我给镜像到了阿里云的杭州机房的容器仓库里,拉取还是比较快的。
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/
全新安装:
#指定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 查看服务地址。
每个工作节点需要拉取上面对应版本的镜像,以及安装kubelet的对应版本。
检查版本:
~$ kubectl version
查看Pod信息:
kubectl get pod --all-namespaces
完成。
从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快速升级的方法是什么这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!