处理一次k8s、calico无法分配podIP的心路历程
又一次偷偷化解了可能发生的重大事故。不想看过程的可以直接跳到末尾看处理方案。
一个网络错误
某天,上kplcloud构建一个测试应用,构建完成之后发现新pod一直启动失败,并且抛出了以下错误信息:
Failed create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up pod "xxxxxx-fc4cb949f-gpkm2_xxxxxxx" network: netplugin failed but error parsing its diagnostic message "": unexpected end of JSON input
会k8s的运维同学早已不在,突然出问题了怎么办?
试着开始解决问题。
一、有没有可能是镜像拉取失败,开始找问题:
- 登录集群所有服务器查看空间是否占满(然而并没有占满)
- 查询集群所有服务器网络情况(也没有问题)
- 再启一个pod试试?(起不来)
这就尴尬了......,有没有可能是calico的问题?
二、查看服务器报错信息
尝试以下命令看服务器的报错信息:
$ journalctl -exf
确实有一些错误信息:
这个错误太广泛了,继续尝试从其他地方找找问题。
此时已经开始在思考如何跑路的问题了...
要不尝试从重启能否解决?
风险太大,不能冒险。虽然很多时候重启能解决大部分问题,但重启docker、k8s在这种情况下不是最佳选择。
继续搜刮日志,猜测是无法分配IP的问题,那目标转向calico
从calico-node上面找问题
查询ip池是否用完。
使用calicoamd命令查询calico是否正常正常运行
$ calicoctl get ippools -o wide CIDR NAT IPIP 172.20.0.0/16 true false $ calicoctl node status
似乎是没啥问题。
开始场外求助......
无果
既然calico-node都运行正常,应该不会是calico-etcd的问题吧。
试试calico-etcd
本着有疑问就查证试试的态度,下面开始对calico-etcd进行一顿骚操作。
为了减少代码量方便阅读,以下etcdctl所需要加的证书及endpoints,就不一一添加了,大家参考一下就好:
ETCDCTL_API=3 etcdctl --cacert=/etc/etcd/ssl/ca.pem \ --cert=/etc/etcd/ssl/etcd.pem \ --key=/etc/etcd/ssl/etcd-key.pem \ --endpoints=http://10.xx.xx.1:2379,http://10.xx.xx.2:2379,http://10.xx.xx.3:2379
calico并没有问题,试试calico 所使用的 ETCD是否正常,进入calico-etcd集群:
$ ETCDCTL_API=3 etcdctl member list bde98346d77cfa1: name=node-1 peerURLs=http://10.xx.xx.1:2380 clientURLs=http://10.xx.xx.1:2379 isLeader=true 299fcfbf514069ed: name=node-2 peerURLs=http://10.xx.xx.2:2380 clientURLs=http://10.xx.xx.2:2379 isLeader=false 954e5cdb2d25c491: name=node-3 peerURLs=http://10.xx.xx.3:2380 clientURLs=http://10.xx.xx.3:2379 isLeader=false
似乎集群也运行正常,get数据也正常。
一切看起来都感觉是多么的正常,似乎没有什么毛病。
算了,算了,还是先写会简历吧,换换脑子。
那尝试向ETCD写入一条数据试试?
$ ETCDCTL_API=3 etcdctl put /hello world Error: etcdserver: mvcc: database space exceeded
报了一个错Error: etcdserver: mvcc: database space exceeded???
似乎是找到原因了,既然定位到问题所在,那接下来就好办了。(不用跑路了(⁎⁍̴̛ᴗ⁍̴̛⁎))把简历先放一放。
感谢伟大的google,我从etcd官网找到了一些线索及解决方案,后面我贴上官网介绍,先解决问题:
使用etcdctl endpoint status
查询etcd各个节点的使用状态:
$ ETCDCTL_API=3 etcdctl endpoint status http://10.xx.xx.1:2379, 299fcfbf514069ed, 3.2.18, 2.1 GB, false, 7, 8701663 http://10.xx.xx.2:2379, bde98346d77cfa1, 3.2.18, 2.1 GB, true, 7, 8701683 http://10.xx.xx.3:2379, 954e5cdb2d25c491, 3.2.18, 2.1 GB, false, 7, 8701687
上面可以看到集群空间已经使用了2.1GB了,这个值需要留意一下。
查询etcd是否有告警信息使用命令etcdctl alarm list
:
$ ETCDCTL_API=3 etcdctl alarm list memberID:2999344297460918765 alarm:NOSPACE
显示了一个alerm:NOSPACE
,这个表示没空间了,那是没什么空间呢?磁盘还是内存?先查询一下。
似乎磁盘、内存空间都足够的。从官网的信息了解到应该是etcd配额的问题,Etcd v3 的默认的 backend quota 2GB,也就是说etcd默认最大的配额是2GB,如果超过了则无法再写入数据,要么把旧数据删除,要么把数据压缩了。
参考官方的解决方案
ETCD官网参考:https://etcd.io/docs/v3.2.17/op-guide/maintenance/
-
获取etcd的旧版本号
$ ETCDCTL_API=3 etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*' 5395771 5395771 5395771
-
压缩旧版本
$ ETCDCTL_API=3 etcdctl compact 5395771 compacted revision 5395771
-
整理碎片
$ ETCDCTL_API=3 etcdctl defrag Finished defragmenting etcd member[http://10.xx.xx.1:2379] Finished defragmenting etcd member[http://10.xx.xx.2:2379] Finished defragmenting etcd member[http://10.xx.xx.3:2379]
-
关闭告警
$ ETCDCTL_API=3 etcdctl alarm disarm memberID:2999344297460918765 alarm:NOSPACE $ ETCDCTL_API=3 etcdctl alarm list
-
测试数据是否可写入
$ ETCDCTL_API=3 etcdctl put /hello world OK $ ETCDCTL_API=3 etcdctl get /hello OK
回到k8s这边,删除那个失败的pod,并查看是否可正常分配ip。
一切正确,完美。
为了避免后续再出现类似问题,需要设置自动压缩,启动自动压缩功能需要在etcd启动参考上加上xxxxx=1
https://skyao.gitbooks.io/learning-etcd3/content/documentation/op-guide/maintenance.html
etcd 默认不会自动 compact,需要设置启动参数,或者通过命令进行compact,如果变更频繁建议设置,否则会导致空间和内存的浪费以及错误。Etcd v3 的默认的 backend quota 2GB,如果不 compact,boltdb 文件大小超过这个限制后,就会报错:
”Error: etcdserver: mvcc: database space exceeded”
,导致数据无法写入。
产生这么多垃圾数据的原因就是因为频繁的调度,我们集群有大量CronJob在执行,并且执行的非常活跃,每次产生新的Pod都会被分配到ip。有可能是因为pod时间太短或没有及时注销而导致calico-etcd产生了大量垃圾数据。
尾巴
因calico-etcd集群的的使用配额满了,在创建pod时calico所分配的IP无法写入到etcd里,从而导致pod创建失败也就无法注册到CoreDNS了。
为了不采坑,监控是非常重要的,我们有etcd集群的监控,却忽略了etcd配额的监控,幸运的是当时并没有应用重启动或升级,没有造成损失。
最后的建议就是,没事上去点点,说不定会有您意想不到的惊喜(惊吓)。
作者:宜信技术学院 王聪
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
记一次mongodb核心集群雪崩故障分析
记一次mongodb核心集群雪崩故障分析 关于作者前滴滴出行技术专家,现任OPPO文档数据库mongodb负责人,负责oppo千万级峰值TPS/十万亿级数据量文档数据库mongodb内核研发及运维工作,一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。Github账号地址:https://github.com/y123456yz 1. 问题背景某核心JAVA长连接服务使用mongodb作为主要存储,客户端数百台机器连接同一mongodb集群,短期内出现多次性能抖动问题,此外,还出现一次“雪崩”故障,同时流量瞬间跌零,无法自动恢复。本文分析这两次故障的根本原因,包括客户端配置使用不合理、mongodb内核链接认证不合理、代理配置不全等一系列问题,最终经过多方努力确定问题根源。该集群有十来个业务接口访问,每个接口部署在数十台业务服务器上面,访问该mongodb机器的客户端总数超过数百台,部分请求一次拉取数十行甚至百余行数据。该集群为2机房同城多活集群(选举节不消耗太多资源,异地的第三机房来部署选举节点),架构图如下:从上图可以看出,为了实现多活,在每个机房都部署有对应代理,对应...
- 下一篇
如何看待超级大小周?
老大上班时突然说起 PDD 居然实行了超级大小周(一周上 6 天班 一周上 7 天班),看来我们还是太轻松了。。。 一个月只休 2天,这也太刺激了吧!有没有 PDD 的朋友说说这是真的吗…… 补充说明: 这个问题出来以后,除了有人抱怨这种大小周做法惨无人道以外,也有人表示这样的公司还会提供相应的高薪,愿意用加班时间在职业生涯早期积累一定的财富,见仁见智。 那么大家如何看待这种超级大小周?
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS关闭SELinux安全模块
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7设置SWAP分区,小内存服务器的救世主