中午睡觉, 梦到一群母蜘蛛围攻我, 我却不能动, 苦苦挣扎在音乐声中惊醒
醒来后, 继续工作, 突然发现服务器磁盘占用100%, 操作巨卡, 一脸问号
是不是之前部署的istio的镜像无法下载, 导致的, 我忘记了删除部署
然后将istio全部删除, 集群还是卡, 节点丢失
最后重启了各个节点的kubelet, 集群正常了
但是呢, 很多挂载pv的POD一直create状态, 然后describe一下, 发现pvc无法挂载
这种情况一般是pvc被其他哥们强占, 所以按照经验是这种路子, 然后分析了, 发现没有活着的哥们强占他
想起之前的情况:
不知什么原因, 和ROOK挂载后出现POD迷失的情况, 也就是无法删除并且留在了node上, 重启kubelet, 查看allkube可以看到没了 但是呢, 目标node一直报错 Jul 5 00:17:28 localhost kubelet: E0705 00:17:28.138366 938 kubelet_volumes.go:128] Orphaned pod "94d9dcc1-7ee6-11e8-95bf-000c29ab3f28" found, but volume paths are still present on disk : There were a total of 1 errors similar to this. Turn up verbosity to see them.
解决方式: cd /var/lib/kubelet/pods 删除报错对应的文件夹, 删除不了只能先重启机器
那么是什么原因造成POD迷失的呢, 是由于kubelet不正常被kill了 POD迷失后, k8s会自动部署该POD新的实例, 而迷失的POD还持有原PVC的挂载, 因此如果PVC的策略是RWO, 那么新的实例无法挂载 这个时候得寻找这个迷失POD的节点 需要查看kubelet的日志, 找到出现上述错误的节点kubelet, 按照上述操作干死 干死后新的实例也是无法起来的, 使用k8s将新实例干死, 这时候又是坑中坑, 一直是Terminating状态, 无法干死 这个时候, 查看这个新实例的node, 到node上重启kublet即可干死它, 最好确认下该node的kubelet日志 重新部署该POD, 还是起不来, 报错无法挂载pvc 一看ceph监控吓一跳
查看osd的日志
这里osd保证集群健康的方式是osd之间互相的heat, 按照这个ip找到了集群中的osd实例, 发现真的无法ping通 直接ping该ods实例所在node的docker0端口, 发现仍然无法ping通, 排除了osd容器的问题, 是node的网络问题 最后搞笑的发现是ping其他节点的这台主机网络有问题, 最后发现是3台master的网络出了问题, 有点麻烦!!! 分析后, 类似网络覆盖分裂, master之间可以通, 而node之间也可以通, 但master和node之间无法通行 查看master的ip a flanneld的overlay有2个网段!!! 蛋疼蛋疼 (这里后面在细细记录了~)
首先想到是重启master的flanneld和docker, 一台一台来, 否则导致docker, flanneld, etcd互相依赖起不来, 集群GG 无效 重启node的flaneld和docker 无效 重启node的kubelet 无效 崩溃~~
重启master的flanneld, docker, kubelet, kube-proxy 无效 万般无奈, 不如直接重启master, 干你妈的
重启后flanneld的overlay只有1个子网段了 ping之后发现OK了~ 随之按此方法依次重启另外两台master, 最后发现还有几台node, 也重启下解决 最后ceph集群全部正常
重新尝试部署新实例 部署成功, 并且成功加载pvc, 数据没丢, 只是丢了一段刚刚宕机时间的监控数据
一脸惊叹~