探討這個議題之前，我們要先來問一個問題是：

我們本地開發(fā)者，真的需要一個 Kuberntees 嗎? 這個是必要的嗎？

我認(rèn)為這個答案是非必要，并不是所有的本地開發(fā)者都需要有一個獨立的 Kubernetes 集群來使用，但是如果有符合下列需求之一，就會需要創(chuàng)建一個本地的 Kubernetes 集群：

    1.  開發(fā)的應(yīng)用程式與 Kubernetes 息息相關(guān)，譬如該應(yīng)用程式會用到 Kubernetes API，這類型應(yīng)用程式需要部署到 Kubernetes 內(nèi)才可以發(fā)揮其功用。

    2.  開發(fā)的應(yīng)用程式需要用到一些 Kubernetes 的資源才能夠看出差異，譬如想確認(rèn) Kubernetes HPA 發(fā)生時應(yīng)用程式是否能夠如預(yù)期運作。這類型的應(yīng)用程式也會需要有個本地的 Kubernetes 集群才能測試。

    3.  開發(fā)人員本身是公司的基礎(chǔ)設(shè)施維運人員，譬如要設(shè)計 Jenkins 與 Kubernetes 的連動測試，可能會需要在本地先進(jìn)行相關(guān)測試之后才會正式上到公司環(huán)境。好處可能是可以先不用開云端機器，可以先省錢，都用 VM 來測試相關(guān)功能。

    4.  開發(fā)的應(yīng)用程序有很多依賴性，譬如需要 Redis, Kafaka, Memcached 等，這種情況下也許有個本地的 Kuberentes 會更加比較方便。

除了上述理由之外(一定還有其他情境，這里就不一一列舉），我認(rèn)為剩下的情境應(yīng)該都可以透過 Docker/Docker-Compose 來完成相關(guān)環(huán)境搭建完成后供開發(fā)者測試。

如果你今天深思熟慮后，確認(rèn)真的有需要于本地測試 Kuberntes 的需求，我們就可以來思考，對于一個開發(fā)者，我希望可以怎么使用這個本地的 Kubernetes。

對我個人來說，我希望這套解決方案能夠有下列特性：

1.  容易設(shè)定與搭建，最好幾個按鈕就好
2.  能夠用指令完成，不需要有任何 UI 介入
3.  能夠模擬多節(jié)點
4.  最好能夠把上述的一切都包成一個腳本，一個命令運行完畢

接下來我們推薦四套不同的開源軟件：Kubeadm, Minikube, KIND, K3D。

Kubeadm

Kubeadm 是由官方維護(hù)的開源項目，我認(rèn)為是非常簡單的一個測試方式，其本身會透過 systemd 的方式維護(hù) Kubelet。

之后再透過 container 的方式啟動 controller/scheduler/kube-proxy 等 Kubernetes 核心組件。

使用方面 Kubeadm 本身并不困難，可以透過指令列的方式來創(chuàng)建一切所需資源，唯一要注意的是安裝完畢之后還需要人為手動安裝 CNI 的解決方案，整個 Kubernetes 才算是安裝完畢。

Kubeadm 本身也支持架設(shè)多節(jié)點的集群，只是在使用上沒有這么方便，需要先創(chuàng)建 Master 節(jié)點，并且產(chǎn)生相對應(yīng)的 token/key，接下來其他節(jié)點使用 kubeadm 的指令加入到已經(jīng)創(chuàng)建的集群中。

總體來說， Kubeadm 能夠滿足上述要求，但是實作上會稍嫌麻煩，特別是多節(jié)點的情況下還要處理 Token/key 的信息，此外 CNI 的安裝也需要自己處理，但是作為一個單節(jié)點的測試環(huán)境也算是容易上手。

Minikube

Minikube 也是由官方維護(hù)的項目，其本身的架構(gòu)一開始是依賴于 VM (虛擬機器) 來幫使用者創(chuàng)建一個全新測試的 Kubernetes 集群，任何平臺的開發(fā)者都可以輕松使用，因為背后都會幫你起一個全新的 VM 。當(dāng) VM 起來之后，其會透過 kubeadm 的方式幫助你建立與設(shè)定 Kubernetes 集群，并且?guī)湍惆?CNI 等指令都安裝完成。

除了依賴 VM 之外，其也有提供不同底層，譬如 none 就可以直接在該機器上透過 kubeadm 來建立，基本上整個架構(gòu)會變得跟 kubeadm 非常類似，比較大的差異是 CNI 也會一并幫你安裝完成。

此外 Mnikube 本身也有一些屬于自己的套件，可以把一些功能整包裝進(jìn)去，對于這個功能我的想法是不好也不壞，不壞的地方在于提供一個環(huán)境讓使用者去測試功能，確實方便，不好的地方在于可能會讓使用者以為這些功能都是 Kubernetes 本來就有的，反而會有所誤解，甚至對于其背后使用原理都不太清楚就草草學(xué)習(xí)完畢。

總體來說， Minikube 也可以滿足上述的部分要求，多節(jié)點的部分可能就會跑起來多個 VM 來建立，消耗的資源會相對多一點。

KIND

KIND 的全名是 Kubernetes In Docker，顧名思義就是把 Kubernetes 的節(jié)點都用 Docker 的方式運行起來，每一個 Docker Container 就是一個 Kubernetes 節(jié)點，可以充當(dāng) Worker 也可以充當(dāng) Master。

使用方面非常簡單，使用 KIND 的指令搭配一個設(shè)置檔案就可以輕松地建立起 Kubernetes 集群，由于全部的操作都是由 KIND 完成，所以要建立多節(jié)點的方式也非常簡單，只要設(shè)置文件中描述需要多少節(jié)點以及各自什么身份，接下來就一個指令搞定全部，連 CNI 方面都不需要處理， KIND 會自行搞定。

總體來說， KIND 可以滿足上述所有需求，多節(jié)點的部分則是用 Docker 來管理，因此在資源與啟動速度方面都有良好的效果，搭配 Vagrant 的方式就可以輕松打包一個多節(jié)點的 VM 環(huán)境供測試者開發(fā)，確實方便。

K3D

K3D 是由 Rancher 所開發(fā) K3S 的 Docker 版本， K3S 是一個輕量級的 Kubernetes 平臺，本身適合用在一些低運算資源系統(tǒng)上。

而 K3D 直接將 K3S 給移植到 Docker 之中，讓使用者可以更方便的創(chuàng)建一個 K3S 集群。

使用起來也是很簡單的，整個主要架構(gòu)都在 k3d 這個執(zhí)行文件上面，使用該指令搭配不同的參數(shù)就可以快速地建立起多節(jié)點的 Kubernetes Cluster，此外也可以透過指令動態(tài)增加節(jié)點，使用上也是非常方便。

與 KIND一樣， CNI 的部分也會一并被處理，所以使用者真的只需要一個指令就可以處理好所有的事情，總體來說， K3D 可以滿足上述所有要求，優(yōu)點基本上跟 KIND 完全類似，搭配上 Vagrant 真的可以輕松地建立起多節(jié)點的模擬環(huán)境。