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

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

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

    1.  開發的應用程式與 Kubernetes 息息相關，譬如該應用程式會用到 Kubernetes API，這類型應用程式需要部署到 Kubernetes 內才可以發揮其功用。

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

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

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

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

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

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

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

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

Kubeadm

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

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

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

Kubeadm 本身也支持架設多節點的集群，只是在使用上沒有這么方便，需要先創建 Master 節點，并且產生相對應的 token/key，接下來其他節點使用 kubeadm 的指令加入到已經創建的集群中。

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

Minikube

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

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

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

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

KIND

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

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

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

K3D

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

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

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

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