由 dawei 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 的安装也需要自己处理，但是作为一个单节点的测试环境也算是容易上手。