使用 KubeKey 搭建 Kubernetes/KubeSphere 環境的"心路(累)歷程"

今天要幹嘛？

今天我要給 KubeKey 挑個刺！

身為一個 KubeSphere Community Member，至今為止我居然沒有用過 KubeKey，是不是很過分？說出來都覺得沒臉在 KubeSphere 社群立足啊！

想當年開始玩 KubeSphere 時，每走一步我都覺得「不和諧」。雖說 KubeSphere 早已經有了足夠的知名度和大量的企業使用者，但是我總能挑出「刺」，天天給 KubeSphere 社群提意見建議……

沒錯，最終他們「受不了」了，決定邀請我加入 KubeSphere 社群，成為一名光榮的 Member！

現在我自己也搞開源社群了。自從開始管理 DevStream 開源社群后，我基本就沒有精力參與 KubeSphere 社群了。哎，一顆躁動的心，一雙不安分的手！我得做點啥，但是開發我是沒精力參與了，要不，發揮一下我的「臭毛病」 - 晚期的強迫症和極致的細節洞察力，去挑挑刺吧！

沒錯！

我決定試用一下 KubeKey！一方面把這些「刺」反饋給 KubeSphere 社群，幫助他們進一步完善 KubeKey 的使用體驗！另外一方面在這個過程中熟悉 KubeKey 的用法，看下能不能找到 DevStream 和 KubeSphere 共同作業的點，比如用 DevStream 簡化 KubeSphere 的安裝部署和設定過程。

在哪裡幹？

KubeSphere 社群給了我一個開發機，一臺 Linux vm，酷！我就在這個 Linux vm 上「幹」它吧！

從哪裡開始幹？

這還不簡單，README 檔案呀！

快速開幹！

我們在檔案裡找 Quick Start，沒錯，有，大致長這樣：

開炮！

看到這個紀錄檔，是不是看著特別像「no errors, no warnings」，一派祥和，歌舞昇平，馬上可以用 kubectl 命令看下嶄新的 Kubernetes 叢集了！（不要和我槓單節點 k8s 環境是不是叢集，官方稱之為「單節點叢集」）

我就不演示 kubectl get xxx 了，結果慘不忍睹！我們仔細看這個輸出紀錄檔，對，細品，有沒有發現這裡用了幾行非 error 級別的紀錄檔告訴我們需要先安裝：

• conntrack
• socat

給 KubeKey 的建議1：這裡是不是用 error level logs 更合理一些？

給 KubeKey 的建議2：能不能紀錄檔裡直接告訴使用者需要先安裝 conntrack 和 socat，並且同時列印出安裝命令？（我知道 centos 和 ubuntu 安裝方式不一樣，不過可選的命令集合其實很有限，kk 獲取系統型別也很容易，給使用者更友好的提示其實很容易做到）

給 KubeKey 的建議3：表格裡那麼多項沒有 y 的，到底哪些是必須有的哪些是不必須的？這個結果讓使用者看得心慌：我需要先安裝那麼多東西才能開始用 kk？望而卻步啊！

解決依賴問題再繼續幹！

回到檔案，其實仔細看可以在這裡發現前置依賴，就是這段文字太長了，讓人有點沒耐心仔細看完。

還是 Google 大法好用！我們照著這個思路執行下面命令：

yum -y install conntrack-tools
yum -y install socat

不出意外的話這一步很難失敗。對，如果你失敗了，那就是意外。真的失敗了，那就是 yum 設定問題了，明白怎麼處理吧？

然後繼續執行 ./kk create cluster，看下能不能得到和諧的輸出。（記得如果環境不夠「科學」，要先執行export KKZONE=cn，否則你會在某一步卡半天，卡到懷疑人生，無法判斷是網路太慢還是網路不通）

給 KubeKey 的建議4：當命令卡住的時候，比如映象下載太慢時，有沒有超時邏輯？或者能不能定時輸出一個紀錄檔告訴使用者「沒有卡死」？或者顯示一下下載的進度條？總之不要長時間沒有紀錄檔，使用者會忍不住去 Ctrl+c，然後一臉迷茫，下一步幹啥？

比剛才和諧了，不過第一行紀錄檔很不和諧。

如果 Failed 影響大，比如會讓某個功能不可用，那麼應該用 error 級別，這樣我會嘗試去修復；反之 WARN 級別的意思就是「你可以忽略，忽略也能用」。OK，我選擇忽略。（我不一定真的忽略，但是很多使用者肯定會這樣想。）

給 KubeKey 的建議5：儘量避免 WARN 紀錄檔，尤其是 WARN 配合 Failed 一起用，讓使用者又覺得這個錯誤很嚴重，又覺得可以忽略。

接著就看網路環境了。

順利的話，最後可以看到這樣的紀錄檔：

Installation is complete.

Please check the result using the command:

	kubectl get pod -A

讓我們執行 kubectl get pod -A，看下「豌豆莢」們是不是正常：

$ kubectl get pod -A
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-75ddb95444-6dg9b   1/1     Running   0          30m
kube-system   calico-node-rqqrk                          1/1     Running   0          30m
kube-system   coredns-5495dd7c88-9hlrp                   1/1     Running   0          30m
kube-system   coredns-5495dd7c88-nlp5d                   1/1     Running   0          30m
kube-system   kube-apiserver-i-hmqwjh0m                  1/1     Running   0          30m
kube-system   kube-controller-manager-i-hmqwjh0m         1/1     Running   0          30m
kube-system   kube-proxy-x69p9                           1/1     Running   0          30m
kube-system   kube-scheduler-i-hmqwjh0m                  1/1     Running   0          30m
kube-system   nodelocaldns-vd77n                         1/1     Running   0          30m

我勒個乖乖，Amazing 啊！清一色的 Running、1/1 且 0 restarts，堪稱完美！

如何幹翻重來？

裝好了，然後呢？

幹翻重來吧，因為直接執行 ./kk create cluster 並不帶 KubeSphere。我們體驗過 k8s 的安裝過程了，整體還是挺簡單易用的。下面試下帶 KubeSphere 的玩法吧。

幹翻操作：

./kk delete cluster

執行完這個命令後，k8s 叢集會被刪掉。當然，對應的 kubectl 和 docker images 我不希望被刪掉，事實證明 KubeKey 也不會把它們刪掉。對，我驗證了：

連著 KubeSphere 一起幹！

命令是如此的簡單，只需要加一個 flag 就夠了：

./kk create config --with-kubesphere

幹不過，輸了。

結果不美麗啊：

{{<

我。。。

你。。。

你給我一個 WARN 後就直接掛了？

給 KubeKey 的建議6：WARN 紀錄檔前面提到了，這裡再次印證我的觀點，紀錄檔級別要嚴謹，WARN 要少用。

這個錯誤，，，看起來是要 Google 一會了。但是我懶啊！這不就是和 docker 安裝方式有關嘛（我猜可能和版本也有關係），我卸掉 docker，讓 KubeKey 來安裝總行了吧！

給 KubeKey 的建議7：如果你們知道這個錯誤的解決方案，請把方法（或者參考資料連結）貼到紀錄檔裡，不要期待使用者可以輕鬆 Google 一下解決。當然，我不能接受你說我解決不了，哈哈，不過現在是晚上10:30分，我想快點打完收工了，不查了。

其實這個機子本來沒有 docker，為什麼我會提前安裝呢？因為我勤勞？不存在的。我是被這段內容誤導的：

看這個縮排級別，你瞟一眼，是不是最顯眼的是下面的 Note？Note 裡說先安裝 docker，然後假如你很熟悉 docker，是不是就順手先裝了 docker 在繼續看檔案？

對，我就跪在了這裡。裝了 docker 才發現，這個 Note 是針對 Build Binary from Source Code 的 Note。。。

給 KubeKey 的建議8：這裡的檔案也優化下吧，讓 Note 看起來不那麼像全域性 Note。

重整旗鼓，繼續幹！

上來就是一套組合拳：

yum remove docker
./kk create cluster --with-kubesphere

不出我所料，錯誤繞過去了！

對，我就是這麼心安理得，可以忍住不去查前面這個錯誤是怎麼回事，我選擇繞過後晚上還是可以睡得香噴噴！我相信 KubeSphere 社群過幾天會告訴我答案的。

截圖看不到效果，大家腦補一下上面這個箭頭會左右移動，對，動態的！太可愛了吧！明天我要去問下誰寫的這個程式碼，真是個可愛的程式設計師！

在等這個箭頭停下來的時間裡，再給 KubeKey 加一個建議吧：

給 KubeKey 的建議9：這裡的檔案也優化下吧，風格一致更優雅，要麼都寫一個「範例」版本，要麼都用[version]佔位。

給 KubeKey 的建議10：y 和 yes 在使用者意圖裡絕對是一模一樣，要不要相容下？包括大小寫（我沒有測試大小寫是不是相容）

給 KubeKey 的建議11：如果一次安裝長時間卡住，可能是網路問題。這時候如果 Ctrl+c 然後重新執行安裝，會出現這種情況，沒錯，兩個 ks-installer。當然，我知道需要先 delete 一下就能繞過去，但是或許 kk 能夠識別到使用者沒有 delete 並且給出提示，那就更「優雅」了。

再次重整旗鼓，繼續幹！

由於我用的雲主機，前面安裝過程太久，我去洗了個澡，回來後終端斷開連線了。沒錯，再次進去的時候我忘記執行 export KKZONE=cn 了，所以失敗了一次。再次執行的時候忘記 delete 了，所以再失敗了一次。

於是，我要 delete 了：

慘不忍睹，慘絕人寰啊！！！

你給我裝的 docker 呀，怎麼還能有這個錯誤？

同樣，你告訴我 WARN，我是不會上心的。

無視

and

繼續！

好玩的事情是，這次看著錯誤資訊似乎，，，和前面沒啥區別呀。。。但是沒有直接退出程式，而是繼續往下走了！好吧，我是不會去研究這個錯誤的！

又到了這個「可愛到爆」的箭頭了，繼續漫長的等待吧～

不對勁啊，為什麼那麼久，是不是掛了？

好吧，喚醒一下我沉睡多年（準確說是大半年）的 k8s 排錯技能！

我看到了 ks-installer pod 的錯誤 events 資訊：

有意思，這是個大 bug 了吧，映象不存在？我得去問一下內部人員：

給 KubeKey 的建議11：對著檔案走不通安裝過程，這算大 bug 了，不用我細說怎麼 fix 了吧。

一鼓作氣，再而衰，三而竭，竭前最後掙扎著幹一次

沒力氣打「組合拳」了，一條簡單的命令，然後小拳拳敲個回車：

./kk create cluster --with-kubesphere v3.2.1

好傢伙，一把給我整到了晚上11點。。。我不要面子的啊，我在家辦公還要加班啊，我是朝十晚四午休三小時的男人啊……

不過說實話，看到這個熟悉的紀錄檔，還是很親切的！畢竟去年不知道看了多少遍這個紀錄檔！（別不信，我是深度玩過的，有視訊為證）

繼續看下 pod

很和諧！Amazing 啊！

（其實沒有特別和諧，restarts 不是全0。不過沒關係，我知道這不影響功能，只是安裝過程還有優化的空間而已。）

你想看最後的 Dashboard ？我也想！

不過我沒有 ELB，焦急等待中……（委託大佬給我設定 ELB 去了）

半小時後……

登入頁面來了！

進去後，熟悉的感覺，熟悉的味道！

後面我一定要再寫幾篇文章介紹下 KubeSphere 怎麼玩！當年那一堆筆記，那些付在 KubeSphere 上的青春，不寫點啥可惜了！

最後的總結

1. 官方檔案比 GitHub 的 README 更適合「普通使用者」；
2. 好睏啊！！！我要睡覺了，總結啥嘛，沒啥好總結的。

最後的最後

轉載請註明出處！

更多我的文章，請移步我的個人網站：https://www.danielhu.cn

更多 DevStream 團隊的文章，請移步 DevStream 部落格網站：https://blog.devstream.io

想要及時收到我的最新文章，請關注我的個人公眾號：胡說雲原生