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