今日洞见
文章作者/配图来自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的多机部署方案来做演示集群。
这次就快多了,运行kubectl
命令,没问题。一切都那么美好,我感到自己已经掌握了Kubernetes了,要不怎么说我是DevOps专家呢!看到文档里说,安装kube-ui
可以看到图形界面,只需要运行./deployAddons.sh
就够了。敲完命令,不断用kubectl get pods --namespace=kube-system
看到对应的pod状态,变成running
表示已经启动成功。我迫不及待的就去浏览器里看结果,结果就是这样:
看到这,我就傻眼了,说好的美图呢?不得不说,此时我的内心是崩溃的。
当然,作为DevOps专家,内心的崩溃是不能让外人看出来的。所以我淡定的开始修复工作:
不愧是Google,瞬间就返回了结果,有几个遇到的错误信息和我一样,但是要么是没解决,要么是重启就解决了,等于没说。恩,干得漂亮。
既然知道没有人能帮我,我也就放心了。基于我的经历,我发现了一个定律:
Quick Start如果出了问题,是没有Quick Fix的。
深吸一口气,现在只能靠自己了。首先,清点一下我的处境。
config-default.sh
中的目标IP修改成真实的虚拟机IP,然后运行kube-up.sh
,然后根据按照文档,安装了kube-ui;Kubernetes healthz sidecar container
。既然只有三条线索,就一个一个排查好了。首先,检查vagrant虚拟机是不是出错了:
8080
端口是工作的,而且响应正常;service --status-all
命令列出所有服务,所有看起来跟Kubernetes有关的服务状态都是running
,说明服务都运行良好。因此暂时可以排除是基础设施的问题,再来看第二个线索,看看是不是漏掉了文档中的关键配置。于是我对着文档,一字一句的看,文档写的比较简洁,因为大部分工作都自动化了,需要配置的也不多,逐字逐句的对比也没发现什么问题。不过倒是在文档里找到一节之前没注意到文字:
照文档的说法,出问题,看etcd,大喜,赶紧打开日志查看。不出所料,没什么异常。不过根据这个提示,找到了Kubernetes日志输出路径和配置信息路径,也算不小的收获。按照原计划,进行第三步问题排查,看看这条出错信息能帮我找到什么。先Google下kubernetes healthz,发现在Kubernetes 201里提到,这是用来做节点健康检查的。再细想一下,本来应该显示kube-ui的页面,结果却显示了健康检查相关的内容,这说明了什么呢?暂时还不太清楚,但是这个疑问先记下。好了,再清点一下第一轮排查的收获:
/var/log/upstart/
下面;/etc/default/
下面;看起来问题还是没什么头绪,但至少又给自己找了些事情可做。在/var/log/upstart/
下面,有很多日志,我可以一个一个看下去。除此之外,别无他法。有时候,没有选择也是一种幸福。先列一下都有哪些日志要查:
master | minion1 | minion2 | |
---|---|---|---|
docker | ✓ | ✓ | ✓ |
etcd | ✓ | - | - |
flanneld | ✓ | ✓ | ✓ |
kubelet | ✓ | ✓ | ✓ |
kube-proxy | ✓ | ✓ | ✓ |
kube-apiserver | ✓ | - | - |
kube-controller-manager | ✓ | - | - |
kube-proxy | ✓ | ✓ | ✓ |
kube-scheduler | ✓ | - | - |
kube-apiserver | ✓ | - | - |
用iterm做分屏非常容易,于是把所有的log都用tail -f /var/log/upstart/<file-name>.log
命令打印出来:
看起来不错!当然这只是其中一个节点,另外两个没有展示。现在,我只要再次访问那个让我抓狂的页面,然后从这些漂亮的黑底白字中,找出任何蛛丝马迹,就可以直捣黄龙,解救我于水火之中了。
总结一下目前的进展:
休息一下,欲知后事,且听下回分解。