satellite:在生产过程中监控 Kubernetes

2016-03-25

卫星:在生产过程中监控Kubernetes

在这篇博客帖子中,我们分享一些真实场景下在底层(包括AWS 和裸机上)部署Kubernetes集群的时候遇到的问题。我们也会分享我们开发的用来解决其中的一些问题的解决方案,这部分我们会公开源代码。


监测Kubernetes组件

监测Kubernetes集群不是一个简单的事情,同样的,也需要不简单的方法。为了阐述可能会发生的错误的类型,这里是我们在AWS配置上的一个例子。


我们集群中的一个例子完美展示了用Sky DNS运行以及所有pods启动的健康状态,然而,在几分钟之后,Sky DNS就进入“CrashLoopBackoff”状态了。应用程序容器已经是启动的,但是还在功能失调阶段,因为他们在第一次重新启动的时候无法到达数据库。


结果原来是集群宕机,但是我们只能盯着事件和pods状态,对于发生了什么无法得出一个清晰的理解。





在联系到主节点,看了Sky DNS pod的日志之后,他们用etcd揭露了一个问题。Sky DNS就无法连接,或者连接在它建立之后立刻变得不稳定了。etcd它本身就是在运行的,那么问题是出在哪里呢?


在做了相当一部分的调查之后,我们找到了答案。高延迟网络连接磁盘导致读写错误,这就导致了etcd无法写到文件系统。虽然它是正确配置而且也在运行工作,但是它并不是一直可为Kubernetes服务所用。


吸取教训——即使你已经成功地建立起集群,但是你也不能保证它就可以像预期的那样继续工作。


那么在配置期间哪些问题比较容易出错呢?出错规律十分符合“墨菲定律”。

  • 主机之间没有联系
  • etcd宕机或者不稳定/错误配置导致滞后
  • 主机间的覆盖网络层损坏
  • 单个节点中的任意一个都会宕机
  • Kubernetes API服务器或者控制器管理者宕机
  • Docker无法启动容器
  • 网络分割会影响节点子集


我们和第一个KubeCon的参加者互相交换了一些意见,头脑风暴出一下可能的解决办法:

“你怎样估量Kubernetes集群的健康?@klizhenas建议创建一个能够给pods安排时间以及未事先安排的app;有没有人创建一下这个?

——Brandon Philips(@Brandon Philips)2015年11月11日


我们在评估一些选择来检测Kubernetes的文本:

典型监测

其他方法的冒烟测试:比如

典型监测解决办法

传统的监控监测方法还没有出现短缺。这个种类之中最好的选择之一就是monit。


这是一个贫乏的,极小的(单个执行文件),而且久经战场的后台程序运行在成千上万台机器上面——为小的起步但是是限制到监测单个系统。这是它最大的缺点。


使用monit过程中发现的问题之一就是一组测试执行有限和拓展性的缺乏。虽然可配置,但是我们还是不得不通过写脚本来拓展它的功能,或者通过微弱的界面来使特殊目的的程序得到控制。


更加重要的是,我们发现,连接几个monit实例到互相耦合时非常难的。高可用系统和弹性网络代理收集自己分享的信息,然后协同工作来另这些信息保持更新。


冒烟类型测试

“猫眼测试”这个术语的定义:

“一系列初步的测试来揭示一些简单的故障的严重性,以此来拒绝预期中软件的发布。它通常包含一个子集的测试,测试覆盖了大多数重要的作用来确定重要作用在按照预期运行。冒烟测试最频繁的特点就是它运行的很快,通常是秒级的。”

以我们已有的Kubernetes知识,我们坚信我们可以使用冒烟测试用以下特点来创建一个监视系统:

  • 轻量级定期测试
  • 高可用性和弹性网络分区
  • 零故障操作环境
  • 时间序列作为健康数据的历史


不管故障容易发生的抽象层次,就算是应用程序故障,或者是低层次网络错误,这个系统都能够追踪他们以查到实际的原因。

Serf启动的监测代理


我们的高层次解决方案是一系列程序代理,一个集群中的一个节点驻留在另一个节点上。 他们互相之间通过一个Serf提供的gossip协议来交流:




Kubernetes关键组件的代理监控状态——etcd,scheduler,API服务器和另外一些东西,还有一些执行冒烟程序——创建可以互相交流的轻量级容器。





代理定期同步数据,这样每个节点都是随时更新关于集群作为一个整体的信息。由于Serf提供的一致性保证比较弱,导致更新信息也不是很严格。定期测试结果保存到后端——这可以很简单,就如同一个SQLite数据库或者InfluxDB等一系列实时数据库。


拥有一个对等系统对侦测故障和监测信息十分有帮助,即使系统中的关键部分部分宕机也没有关系。在下面的例子中,主要节点以及大部分的节点都已经宕机,这就导致etcd也出了故障。然而,我们仍然可以得到关于集群连接到以下任意一个节点的诊断信息:



这里是在部分损坏的系统截图:



限制

由于它的简易,目前的模型就有了一定的限制。如果是为更小一些的集群(比如8个节点)就可以运行,然而,在一个再大一点的集群,你就不想每个节点都可以互相交流了。这个的解决方式就是我们计划采取的方案是创建一个特殊的聚合器,从Skype的超级节点那里或者是从Consul的“anti-entropy catelogs上面借鉴一些想法。


结论

监测Kubernetes集群的状态不是直接使用传统监测工具就可以了的。手动故障排除有一定的复杂性,在集群里有一个自动反馈循环的话,就可以消除很大部分的复杂性。


“satellite”项目已经证明当操作集群的时候对我们是有用的,所以我们决定对它进行开源。我们希望它可以成为一个帮助提升kubernetes发现错误系统。欢迎点击我们的github代码库——PRs!

点击体验,开启谷歌级数字化之旅
立即体验
立即咨询