分类: 技术雷达

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

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

 

how-to-draw-a-horse

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

一不小心掉进坑里

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

“Quick Start”基本上都是提供一个傻瓜式命令,想变魔术一样,“嘭”,什么都有了。 因为vagrant集群是基于fedora的,而且用SaltStack做部署,每次启动都要重新下载一大堆东西,慢的要死,不适合快速创建演示环境。所以我决定稍微改变一下,用vagrant创建几个Ubuntu的虚拟机,用基于Ubuntu的多机部署方案来做演示集群。

用vagrant创建Ubuntu集群环境,done; 配置一下几台虚拟机之间的ssh key,done; 参照文档,运行几条命令,done; 这次就快多了,运行kubectl命令,没问题。一切都那么美好,我感到自己已经掌握了Kubernetes了,要不怎么说我是DevOps专家呢!看到文档里说,安装kube-ui可以看到图形界面,只需要运行./deployAddons.sh就够了。敲完命令,不断用kubectl get pods –namespace=kube-system看到对应的pod状态,变成running表示已经启动成功。我迫不及待的就去浏览器里看结果,结果就是这样:

fail-to-visit-kube-ui

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

急救

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

复制网页上的报错信息; 打开Google(是的,你没看错,是Google); 按下回车 不愧是Google,瞬间就返回了结果,有几个遇到的错误信息和我一样,但是要么是没解决,要么是重启就解决了,等于没说。恩,干得漂亮。

清点处境

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

Quick Start如果出了问题,是没有Quick Fix的。 深吸一口气,现在只能靠自己了。首先,清点一下我的处境。

我自己配置了三台Ubuntu虚拟机; 根据官方文档里的配置,把config-default.sh中的目标IP修改成真实的虚拟机IP,然后运行kube-up.sh,然后根据按照文档,安装了kube-ui; 网页上报错信息是:Kubernetes healthz sidecar container。 既然只有三条线索,就一个一个排查好了。首先,检查vagrant虚拟机是不是出错了:

三台虚拟机互相ping可以通,宿主机分别ping三台机器也可以通,看来虚拟机网络没问题; 通过网页控制台信息可以看到,没有任何错误,说明8080端口是工作的,而且响应正常; 用service –status-all命令列出所有服务,所有看起来跟Kubernetes有关的服务状态都是running,说明服务都运行良好。 因此暂时可以排除是基础设施的问题,再来看第二个线索,看看是不是漏掉了文档中的关键配置。于是我对着文档,一字一句的看,文档写的比较简洁,因为大部分工作都自动化了,需要配置的也不多,逐字逐句的对比也没发现什么问题。不过倒是在文档里找到一节之前没注意到文字:

kubernetes-ubuntu-doc-troubleshooting

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

找到了Kubernetes的日志,在/var/log/upstart/下面; 找到了Kubernetes的配置,在/etc/default/下面; 找到一个疑点:本该显示kube-ui的页面,却显示了健康检查相关的内容。 缩小排查范围

看起来问题还是没什么头绪,但至少又给自己找了些事情可做。在/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/.log命令打印出来:

kubernetes-log

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

休息一下

总结一下目前的进展:

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

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

Share

发表评论

评论