前言

筆者在2020年年初加入了星環的雲開發部，在此之前接觸過最複雜的容器平臺就是docker swarm，並且也是一知半解，所以在工作的初期，對K8s的熟悉是一個必不可少的工作。然而K8s是一個具有一定複雜性的容器平臺，所以開發/學習環境的搭建也會比較複雜。在嘗試搭建完整版叢集失敗後又嘗試minikube，但是又發現minikube的諸多缺點，如功能的侷限，可配置性的低下。於是，在工作大半年，掌握一定基本知識後，著手開發本文所要介紹的MediumKube。初衷可能是為了幫助剛加入星環的小夥伴們熟悉K8s，不過感覺需求不高，就不了了之了。對於我自己來說，這倒是成為了快速搭建開發環境的一個實用工具。

這些年容器雲的技術已經滲入到我們日常開發的方方面面，不管是做一些企業應用的開發，還是個人網站的搭建。應用程式是否能在容器平臺上執行，並且利用容器平臺的特性去進行效能調優/成本管理確實是很難忽略的一個部分。而如今，有很多的應用完全基於雲平臺去開發，它們充分運用了雲平臺的能力，來做到諸如微服務化，服務網格化，彈性化等特點。然而一個完全基於雲平臺開發的應用也自然而然需要一個複雜的雲開發環境，不論是對應用本身的部署，還是對雲平臺API的利用，甚至是對雲平臺本身能力的擴充套件，都是有很大幫助的。

作為開發環境，我們關注的點可能不同於生產環境。我在這裡列舉一些我個人對開發環境的期望。

• 是否可以快速部署，刪除

• 功能性是否完整

• 對於高階使用者是否提供豐富的配置項

• 開發者對環境底層元件的可見性

• 作為中國的開發者，是否能輕鬆地使用開源的軟體生態

現在市面上也有很多的免費軟體可以作為容器雲的開發環境，比如傻瓜式的k8s發行版minikube，可應用於邊緣計算和資源受限環境的k3s，或者對於非k8s的使用者來說，docker swarm也是易於部署的容器雲環境之一。

本文介紹的MediumKube不同於以上這些產品化程度比較高的軟體，它基於libvirt和cloud-init提供了一個高度可定製化的方案。相比於純粹的kubernetes輕量化發行版，它更像是一個虛擬機器管理工具，而它提供的一些能力使得它成為部署kubernetes開發環境的一個實用的軟體。

----------

使用Cloud-Init快速初始化虛擬機器例項

Cloud-init是IaaS雲服務通用的一個標準，它的推行者就是大名鼎鼎的Canonical，也就是開發Ubuntu的那家公司。Cloud-init是Infrastructure as Code的一個例子。透過宣告式地編寫配置檔案，我們就可以實現對雲例項的初始化。它是如此通用的一個標準，以至於我們可以將它整合到數百行程式碼的微型專案中，來實現一個最簡化的IaaS服務。MediumKube使用了這個工具，使得它本身就是一個可定製化極高的虛擬機器管理工具。當然，由於它的定位是快速部署Kubernetes，所以它也內建了一個預設Cloud-Init模板，和它的原始碼本身一起發行。

上圖就是MediumKube內建模板的一部分。這個模板做了包括對使用者，軟體源，系統配置指令碼，docker/kubernetes的安裝的相關工作，使得例項一旦部署完，就帶有相應的軟體環境，無需再做額外的配置

配置和模板引擎

MediumKube支援模板引擎。透過編寫全域性的配置項，並且將它們使用在Cloud-Init模板中，使用者可以部署出高度自定義的虛擬機器叢集。

上圖列出了MediumKube所支援的一些配置項。有些會影響虛擬機器的屬性，而另一些，可以渲染到模板中。比如非常有用的HTTPProxy，對於中國使用者來說時非常實用的，因為模板引擎的支援，使用者不再需要在多個零散的地方一遍遍地設定代理的配置，而是透過統一的配置檔案去全域性地設定。雖然配置項繁多，但是MediumKube對每一個都有推薦的預設值，這也在靈活性和易用性之間取得了一個平衡點。相信大家都有使用minikube時不知道去哪裡配置虛擬機器的高階引數的困擾，所以兼顧入門使用者和高階使用者也是MediumKube的一個優點。

使用mediumkubed維持穩定的網路環境

一個穩定的網路環境對於開發環境來說也比較重要。MediumKube開發的前期就出現過由於網路環境的變動，某些配置變得不再可用，比如監聽在宿主機上的代理。由於DHCP或者切換wifi，宿主機的IP經常變動，為了解決這個問題，mediumkube會為使用者維護一個虛擬網路，並且這個虛擬網路時非常易於配置的。使用者只需要宣告簡單的介面資訊，mediumkube會自動進行配置iptables，dnsmasq等像資訊。

下圖為mediumkubed開發初期的拓撲結構，類似於Docker的Bridge網路，非常簡潔，但同時也很實用。隨著開發，會有越來越多的功能被新增。

Mediumkubed會被註冊為systemd中的一個模組，所以管理器來非常簡單。

簡單易用的命令列工具

在UI方面，mediumkube提供了簡單易用的命令列介面。比如使用者可以展示已部署的虛擬機器，並管理它們的生命週期，如停止/啟動/刪除/部署

同時，mediumkube也有快速的組建叢集，加入叢集，重置節點等命令，使得叢集的管理變得簡單。比如，如果使用者需要部署一個兩節點的叢集，只需要如下簡單的命令

$ mediumkube deploy node1 node2

$ mediumkube init node1

$ mediumkube join node2 node1 

當然，如果使用者不滿足於這些簡單的命令，他們也可以透過shell命令來登入到虛擬機器中進行操作。

如上圖所示，使用者無需記憶任何IP地址，而且如果配置得當，也無需手動管理任何金鑰，直接可以對節點進行管理。

MediumKube的未來

MediumKube是個很年輕也很小眾的專案。它解決了一部分人的痛點的同時，也有相當大的侷限性。比如在單機環境下的叢集部署會使得系統資源捉襟見肘，以及專案比較低的產品化程度，都會使的它只是在“理論上”比較實用。作為MediumKube的開發者，自然也希望MediumKube越來越好用，下面談談我對它的規劃。

叢集化

上面也提到了，MediumKube在單機的環境下帶來了不小的侷限性，所以叢集化一定是一個未來的規劃。當然，引入複雜的元素，勢必會對系統的簡潔性帶來打擊，比如MediumKube會變得難以部署，甚至還不亞於部署一個K8S叢集，或者分散式元素的加入可能會帶來更多的bug。很多問題說大也不大，不過確實是需要花時間去思考的。叢集化的mediumkube採用何種架構？虛擬機器的部署如何進行排程？Overlay網路用哪種技術做（上面的截圖好像暴露了我準備用flannel這個事實）？如何進行簡單卻靈活的分散式部署？如果簡單地進行節點的規劃？是否需要圖形化的支援？要考慮的東西確實比較繁雜。

穩定性和程式碼質量

作為開發環境，穩定性的要求可能沒那麼強，不過在mediumkubed在早期確實也出現過佔用巨量記憶體的情況。而且作為一個玩具專案和golang學習用例，mediumkube在程式碼質量上也比較堪憂。比如檔案傳輸模組的程式碼就非常糟糕，以至於上行和下行的速度有明顯的差距。希望在未來可以有所改善。

說在最後

最後希望技術可以真真正正地提升我們生活的便利性，並感謝CNCF，Canonical，libvirt，Google等組織和所有開源社群的開發者們給我們帶來這些好玩，易用，免費的優質軟體，也期待未來可以看到更多有意思的技術。

作者：聞雲路