一次kibana服务失败的排查过程

公司在kubernetes集群上稳定运行数月的kibana服务于昨天下午突然无法正常提供服务，访问kibana地址后提示如下信息：

排查过程：

---

看到提示后，第一反应肯定是检查elasticsearch集群，碰巧昨天下午公司VPN奇慢，频繁连接不上亦庄机房，因此问题排查一度集中在elasticsearch服务上，另一方面也是因为kibana服务由docker镜像提供，只读服务本身是没有状态变化的，在kubernetes集群中查看pod状态，也没有崩溃重启的记录，因此只能怀疑是连接的elasticsearch数据源无法访问。

在公司VPN逐渐正常后，确认目标elasticsearch集群状态也一直正常，问题排查稍微有些停顿。kibana服务本身及数据源elasticsearch集群都正常，那么问题只能出在kibana服务的运行环境，即docker或kubernetes集群之上，由于提示信息是请求超时，因此问题进一步定位到kubernetes及docker的网络状态。

进入容器内部访问elasticsearch集群，不出意外，无法ping通，看来确实是由于网络问题引起的kibana服务无法正常访问elasticsearch集群。

进一步测试得知，所有容器内部都无法访问外部地址，但是docker寄宿的虚拟机是可以访问外部地址的，因此最终定位问题在docker的虚拟网桥docker0工作不正常导致。

问题解决：

---

问题定位后，仍然不确定为何会产生这个问题，kubernetes集群的docker节点采用docker 1.12.1版本：

问题原因未知，仅定位了问题，解决问题只有采用笨办法：重新启动kubernetes集群节点机上的docker服务及kubelet服务。

在重启后，kubernetes自动重新调度kibana服务至节点机，进入pod内部后，访问外部网络恢复正常，在浏览器访问kubernetes提供的kibana服务，恢复正常，问题解决。但问题产生的原因依然未知：docker0网桥中止包转发，导致docker0挂接的所有容器网络异常。如有高人知道请不吝指出，谢谢。