Kubernetes救援 - 教你如何从新技术的坑里爬出来(上) | TW洞见

今日洞见

文章作者/配图来自ThoughtWorks：佟达。

本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。

当下新技术层出不穷，为了降低开发者的学习成本，很多新技术都会提供“Quick Start”，初学者只需要非常简单的几步，就可以把这个新技术用起来。“Quick Start”的初衷是好的，隐藏复杂性，让用户第一时间体验产品。但是，正因为复杂性被隐藏了，很多初学者在跟着“Quick Start”成功操作一遍后，会产生“我已经会了”的假象。而在引入到具体项目后，遇到问题，束手无策，只能求助于StackOverflow一知半解的答案，或者陷入到茫茫多的官方文档之中。

为什么我的眼里常含泪水？因为这坑真是又深又沉。每当被坑，我的心里就会浮现出这张图：

最近摆弄Kubernetes，不免又被摆了一道。

一不小心掉进坑里

作为一个发布不过两三年的新技术，Kubernetes的文档可谓做的不错。对于如何创建试用集群，Kubernetes提供了非常丰富的说明，包括基于三大云平台（AWS，GCE，Azure），Mesos集群，CoreOS集群，vagrant虚拟机，以及裸机等等。一开始，我选择vagrant多机部署，一切都是自动化的，等了大概半个多小时，显示配置成功，然后按照文档说的，执行了几个kubectl命令，看起来挺简单的。

“Quick Start”基本上都是提供一个傻瓜式命令，想变魔术一样，“嘭”，什么都有了。

因为vagrant集群是基于fedora的，而且用SaltStack做部署，每次启动都要重新下载一大堆东西，慢的要死，不适合快速创建演示环境。所以我决定稍微改变一下，用vagrant创建几个Ubuntu的虚拟机，用基于Ubuntu的多机部署方案来做演示集群。

1. 用vagrant创建Ubuntu集群环境，done；
2. 配置一下几台虚拟机之间的ssh key，done；
3. 参照文档，运行几条命令，done；

这次就快多了，运行kubectl命令，没问题。一切都那么美好，我感到自己已经掌握了Kubernetes了，要不怎么说我是DevOps专家呢！看到文档里说，安装kube-ui可以看到图形界面，只需要运行./deployAddons.sh就够了。敲完命令，不断用kubectl get pods --namespace=kube-system看到对应的pod状态，变成running表示已经启动成功。我迫不及待的就去浏览器里看结果，结果就是这样：

看到这，我就傻眼了，说好的美图呢？不得不说，此时我的内心是崩溃的。

急救

当然，作为DevOps专家，内心的崩溃是不能让外人看出来的。所以我淡定的开始修复工作：

1. 复制网页上的报错信息；
2. 打开Google（是的，你没看错，是Google）；
3. 按下回车

不愧是Google，瞬间就返回了结果，有几个遇到的错误信息和我一样，但是要么是没解决，要么是重启就解决了，等于没说。恩，干得漂亮。

清点处境

既然知道没有人能帮我，我也就放心了。基于我的经历，我发现了一个定律：

Quick Start如果出了问题，是没有Quick Fix的。

深吸一口气，现在只能靠自己了。首先，清点一下我的处境。

1. 我自己配置了三台Ubuntu虚拟机；
2. 根据官方文档里的配置，把config-default.sh中的目标IP修改成真实的虚拟机IP，然后运行kube-up.sh，然后根据按照文档，安装了kube-ui；
3. 网页上报错信息是：Kubernetes healthz sidecar container。

既然只有三条线索，就一个一个排查好了。首先，检查vagrant虚拟机是不是出错了：

1. 三台虚拟机互相ping可以通，宿主机分别ping三台机器也可以通，看来虚拟机网络没问题；
2. 通过网页控制台信息可以看到，没有任何错误，说明8080端口是工作的，而且响应正常；
3. 用service --status-all命令列出所有服务，所有看起来跟Kubernetes有关的服务状态都是running，说明服务都运行良好。

因此暂时可以排除是基础设施的问题，再来看第二个线索，看看是不是漏掉了文档中的关键配置。于是我对着文档，一字一句的看，文档写的比较简洁，因为大部分工作都自动化了，需要配置的也不多，逐字逐句的对比也没发现什么问题。不过倒是在文档里找到一节之前没注意到文字：

照文档的说法，出问题，看etcd，大喜，赶紧打开日志查看。不出所料，没什么异常。不过根据这个提示，找到了Kubernetes日志输出路径和配置信息路径，也算不小的收获。按照原计划，进行第三步问题排查，看看这条出错信息能帮我找到什么。先Google下kubernetes healthz，发现在Kubernetes 201里提到，这是用来做节点健康检查的。再细想一下，本来应该显示kube-ui的页面，结果却显示了健康检查相关的内容，这说明了什么呢？暂时还不太清楚，但是这个疑问先记下。好了，再清点一下第一轮排查的收获：

1. 找到了Kubernetes的日志，在/var/log/upstart/下面；
2. 找到了Kubernetes的配置，在/etc/default/下面；
3. 找到一个疑点：本该显示kube-ui的页面，却显示了健康检查相关的内容。

缩小排查范围

看起来问题还是没什么头绪，但至少又给自己找了些事情可做。在/var/log/upstart/下面，有很多日志，我可以一个一个看下去。除此之外，别无他法。有时候，没有选择也是一种幸福。先列一下都有哪些日志要查：

用iterm做分屏非常容易，于是把所有的log都用tail -f /var/log/upstart/<file-name>.log命令打印出来：

看起来不错！当然这只是其中一个节点，另外两个没有展示。现在，我只要再次访问那个让我抓狂的页面，然后从这些漂亮的黑底白字中，找出任何蛛丝马迹，就可以直捣黄龙，解救我于水火之中了。

休息一下

总结一下目前的进展：

1. Kubernetes集群看似跑起来了，但是却并不能正常工作，比如kube-ui就打不开；
2. 通过排查，基础设施的问题已经排除，将注意力集中在查找Kubernetes配置是否有问题；
3. 监控所有日志，期待出现解决问题的线索。

休息一下，欲知后事，且听下回分解。