Kubernetes救援 – 教你如何從新技術的坑里爬出來(上)

當下新技術層出不窮，為了降低開發者的學習成本，很多新技術都會提供“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的多機部署方案來做演示集群。

用vagrant創建Ubuntu集群環境，done； 配置一下幾臺虛擬機之間的ssh key，done； 參照文檔，運行幾條命令，done； 這次就快多了，運行kubectl命令，沒問題。一切都那么美好，我感到自己已經掌握了Kubernetes了，要不怎么說我是DevOps專家呢！看到文檔里說，安裝kube-ui可以看到圖形界面，只需要運行./deployAddons.sh就夠了。敲完命令，不斷用kubectl get pods –namespace=kube-system看到對應的pod狀態，變成running表示已經啟動成功。我迫不及待的就去瀏覽器里看結果，結果就是這樣：

看到這，我就傻眼了，說好的美圖呢？不得不說，此時我的內心是崩潰的。

急救

當然，作為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，說明服務都運行良好。 因此暫時可以排除是基礎設施的問題，再來看第二個線索，看看是不是漏掉了文檔中的關鍵配置。于是我對著文檔，一字一句的看，文檔寫的比較簡潔，因為大部分工作都自動化了，需要配置的也不多，逐字逐句的對比也沒發現什么問題。不過倒是在文檔里找到一節之前沒注意到文字：

照文檔的說法，出問題，看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集群看似跑起來了，但是卻并不能正常工作，比如kube-ui就打不開； 通過排查，基礎設施的問題已經排除，將注意力集中在查找Kubernetes配置是否有問題； 監控所有日志，期待出現解決問題的線索。

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