我们本地开发者，真的需要一个 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。
对我个人来说，我希望这套解决方案能够有下列特性：
- 容易设定与搭建，最好几个按钮就好
- 能够用指令完成，不需要有任何 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 真的可以轻松地建立起多节点的模拟环境。
