乐趣区

关于k8s:处理一次k8scalico无法分配podIP的心路历程

jiezi

又一次偷偷化解了可能产生的重大事故。不想看过程的能够间接跳到开端看解决计划。

一个网络谬误

某天，上 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 的运维同学早已不在，忽然出问题了怎么办？

试着开始解决问题。

一、有没有可能是镜像拉取失败，开始找问题:

  1. 登录集群所有服务器查看空间是否占满（然而并没有占满）
  2. 查问集群所有服务器网络状况（也没有问题）
  3. 再启一个 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/

  1. 获取 etcd 的旧版本号

    $ ETCDCTL_API=3 etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*'| egrep -o'[0-9].*'
5395771
5395771
5395771

  2. 压缩旧版本

    $ ETCDCTL_API=3 etcdctl compact 5395771
compacted revision 5395771

  3. 整顿碎片

    $ 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]

  4. 敞开告警

    $ ETCDCTL_API=3 etcdctl alarm disarm
memberID:2999344297460918765 alarm:NOSPACE

$ ETCDCTL_API=3 etcdctl alarm list

  5. 测试数据是否可写入

    $ 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/lea…

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 配额的监控，侥幸的是过后并没有利用重启动或降级，没有造成损失。

最初的倡议就是，没事下来点点，说不定会有您意想不到的惊喜(惊吓)。

 作者：宜信技术学院 王聪

退出移动版