本文
接下來幾天我們將開始探討對於一個本地開發者來說，要怎麼搭建一個 Kubernetes 來使用
探討這個議題之前，我們要先來問一個問題是
我們本地開發者，真的需要一個 Kuberntees 嗎? 這個是必要的嗎？
我認為這個答案是非必要，並不是所有的本地開發者都需要有一個獨立的 Kubernetes 叢集來使用，但是如果有符合下列需求之一，就會需要創建一個本地的 Kubernetes 叢集
- 開發的應用程式與 Kubernetes 息息相關，譬如該應用程式會用到 Kubernetes API，這類型應用程式需要部署到 Kubernetes 內才可以發揮其功用
- 開發的應用程式需要用到一些 Kubernetes 的資源才能夠看出差異，譬如想確認 Kubernetes HPA 發生時應用程式是否能夠如預期運作。這類型的應用程式也會需要有個本地的 Kubernetes 叢集才測試
- 開發人員本身是公司的基礎設施維運人員，譬如要設計 Jenkins 與 Kubernetes 的連動測試，可能會需要在本地先進行相關測試之後才會正式上到公司環境。好處可能是可以先不用開雲端機器，可以先省錢，都用VM來測試相關功能
- 開發的應用程式有很多依賴性，譬如需要 redis, kafaka, memcached 等，這種情況下如果
也許有個本地的 Kuberentes 會比較方便
除了上述理由之外(一定還有其他情境，我沒有辦法列舉全部），我認為剩下的情境應該都可以透過 docker/docker-compose 來完成建置相關環境供開發者測試。 (4) 的條件我認為比較彈性，假如依賴的服務都可以用 docker-compose 直接建立，那其實也不需要有個 Kuberentes，但是如果這些服務本身有一些設定而且 Kubernetes Yaml/Helm 都已經準備好, 整體部署與設定所花費的時間比重新研究如何轉移到 Docker-compose 上還來得輕量與快速，那其實也可以考慮就直接上 Kubernetes。
如果你今天深思熟慮後，確認真的有需要於本地測試 Kuberntes 的需求，我們就可以來思考，對於一個開發者，我希望可以怎麼使用這個本地的 Kubernetes。
對我個人來說，我希望這套解決方案能夠有下列特性
- 容易設定與架設，最好幾個按鈕就好
- 能夠都用指令完成，不需要有任何 UI 介入
- 能夠模擬多節點最好
- 最好能夠把上述的一切都包成一個腳本，一個命令建置完畢
接下來我們來看一下四套不同的開源軟體， 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 真的可以輕鬆地建立起多節點的模擬環境。