Satellite是硅谷初创公司Gravitational公司旗下一个用Go写的开源项目，可用来收集Kubernetes集群的健康信息，它既是一个library，也是一个应用。作为library，可以用做监控方案。在这篇文章里，Satellite项目成员为我们分享了在一些场景下在底层（包括AWS 和裸机上）部署Kubernetes集群时遇到的问题和他们在开发过程中用来解决其中一些问题的解决方案。

监测Kubernetes组件

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

我们集群中的一个例子完美展示了用SkyDNS运行以及所有pods启动的健康状态，然而，在几分钟之后，SkyDNS就进入“CrashLoopBackoff”状态了。应用程序容器已经是启动的，但是还在功能失调阶段，因为他们在第一次重新启动的时候无法到达数据库。结果原来是集群宕机，但是我们只能盯着事件和pods状态，对于发生了什么无法得到一个清晰的理解。

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

在做了相当一部分的调查之后，我们找到了答案。高延迟网络连接磁盘导致读写错误，这就导致了etcd无法写到文件系统。虽然它是正确配置而且也在运行工作，但是它并不是一直可为Kubernetes服务所用。吸取教训——即使你已经成功地建立起集群，但也不能保证它就可以像预期的那样继续工作。那么在配置期间哪些问题比较容易出错呢？问题主要有以下这些：

• 主机之间没有联系

• etcd宕机或者不稳定／错误配置导致滞后

• 主机间的覆盖网络层损坏

• 单个节点中的任意一个都会宕机

• Kubernetes API服务器或者控制器管理者宕机

• Docker无法启动容器

• 网络分割会影响节点子集

我们在跟第一届KubeCon的参加者交流了一些意见，头脑风暴出以下可能的解决办法：

你怎样评估Kubernetes集群的健康？@klizhenas建议创建一个能够给pods进行调度以及取消调度的app；有没有人创建一下这个？

——Brandon Philips（ Philips）2015年11月11日

我们评估一下来监控Kubernetes的方法：

典型监测；面向应用的冒烟测试

典型监测解决办法

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

这是一个极其轻便精简（单个执行文件），而且久经战场的后台程序运行在成千上万台机器上面——为小的起步但是是限制到监测单个系统。这是它最大的缺点。使用monit过程中发现的问题之一就是一组测试执行有限和拓展性的缺乏。虽然可配置，但是我们还是不得不通过写脚本来拓展它的功能，或者通过微弱的界面来使特殊目的程序得到控制。更加重要的是，我们发现，连接几个monit实例到一个高可用系统和弹性网络是非常难的，而且系统和网络还要代理收集自己分享的信息，然后协同工作来另这些信息保持更新。

冒烟类型测试

“冒烟测试”这个术语的定义：

“一系列初步的测试来揭示一些简单的故障的严重性，以此来拒绝预期中软件的发布。它通常包含一个子集的测试，测试覆盖了大多数重要的作用来确定重要作用在按照预期运行。冒烟测试最频繁的特点就是它运行的很快，通常是秒级的。”以我们已有的Kubernetes知识，我们坚信我们可以使用冒烟测试用以下特点来创建一个监视系统：

• 轻量级定期测试

• 高可用性和弹性网络分区

• 零故障操作环境

• 时间序列作为健康数据的历史

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

Serf启动的监测Agents

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

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

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

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

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

限制

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

结语

监测Kubernetes集群的状态不是直接使用传统监测工具就可以了的。手动故障排除有一定的复杂性，在集群里有一个自动反馈循环的话，就可以消除很大部分的复杂性。Satellite项目已经证明当操作集群的时候对我们是有用的，所以我们决定对它进行开源，希望它可以成为一个帮助提升kubernetes发现错误系统。

（如果需要转载，请联系我们哦，尊重知识产权人人有责）