前言

笔者在 2020 年年初加入了星环的云开发部，在此之前接触过最复杂的容器平台就是 docker swarm，并且也是一知半解，所以在工作的初期，对 K8s 的熟悉是一个必不可少的工作。然而 K8s 是一个具有一定复杂性的容器平台，所以开发/学习环境的搭建也会比较复杂。在尝试搭建完整版集群失败后又尝试 minikube，但是又发现 minikube 的诸多缺点，如功能的局限，可配置性的低下。于是，在工作大半年，掌握一定基本知识后，着手开发本文所要介绍的 MediumKube。初衷可能是为了帮助刚加入星环的小伙伴们熟悉 K8s，不过感觉需求不高，就不了了之了。对于我自己来说，这倒是成为了快速搭建开发环境的一个实用工具。

这些年容器云的技术已经渗入到我们日常开发的方方面面，不管是做一些企业应用的开发，还是个人网站的搭建。应用程序是否能在容器平台上运行，并且利用容器平台的特性去进行性能调优/成本管理确实是很难忽略的一个部分。而如今，有很多的应用完全基于云平台去开发，它们充分运用了云平台的能力，来做到诸如微服务化，服务网格化，弹性化等特点。然而一个完全基于云平台开发的应用也自然而然需要一个复杂的云开发环境，不论是对应用本身的部署，还是对云平台 API 的利用，甚至是对云平台本身能力的扩展，都是有很大帮助的。

作为开发环境，我们关注的点可能不同于生产环境。我在这里列举一些我个人对开发环境的期望

• 是否可以快速部署，删除

• 功能性是否完整

• 对于高级用户是否提供丰富的配置项

• 开发者对环境底层组件的可见性

• 作为中国的开发者，是否能轻松地使用开源的软件生态

现在市面上也有很多的免费软件可以作为容器云的开发环境，比如傻瓜式的 k8s 发行版 minikube，可应用于边缘计算和资源受限环境的 k8s，或者对于非 k8s 的使用者来说，docker swarm 也是易于部署的容器云环境之一。

本文介绍的 MediumKube 不同于以上这些产品化程度比较高的软件，它基于 libvirt 和 cloud-init 提供了一个高度可定制化的方案。相比于纯粹的 kubernetes 轻量化发行版，它更像是一个虚拟机管理工具，而它提供的一些能力使得它成为部署 kubernetes 开发环境的一个实用的软件。

使用 Cloud-Init 快速初始化虚拟机实例

Cloud-init 是 IaaS 云服务通用的一个标准，它的推行者就是大名鼎鼎的 Canonical，也就是开发 Ubuntu 的那家公司。Cloud-init 是 Infrastructure as Code 的一个例子。通过声明式地编写配置文件，我们就可以实现对云实例的初始化。它是如此通用的一个标准，以至于我们可以将它集成到数百行代码的微型项目中，来实现一个最简化的 IaaS 服务。MediumKube 使用了这个工具，使得它本身就是一个可定制化极高的虚拟机管理工具。当然，由于它的定位是快速部署 Kubernetes，所以它也内置了一个默认 Cloud-Init 模板，和它的源代码本身一起发行。

上图就是 MediumKube 内置模板的一部分。这个模板做了包括对用户，软件源，系统配置脚本，docker/kubernetes 的安装的相关工作，使得实例一旦部署完，就带有相应的软件环境，无需再做额外的配置

配置和模板引擎

MediumKube 支持模板引擎。通过编写全局的配置项，并且将它们使用在 Cloud-Init 模板中，用户可以部署出高度自定义的虚拟机集群。

上图列出了 MediumKube 所支持的一些配置项。有些会影响虚拟机的属性，而另一些，可以渲染到模板中。比如非常有用的 HTTPProxy，对于中国用户来说时非常实用的，因为模板引擎的支持，用户不再需要在多个零散的地方一遍遍地设置代理的配置，而是通过统一的配置文件去全局地设置。虽然配置项繁多，但是 MediumKube 对每一个都有推荐的默认值，这也在灵活性和易用性之间取得了一个平衡点。相信大家都有使用 minikube 时不知道去哪里配置虚拟机的高级参数的困扰，所以兼顾入门用户和高级用户也是 MediumKube 的一个优点。

使用 mediumkubed 维持稳定的网络环境

一个稳定的网络环境对于开发环境来说也比较重要。MediumKube 开发的前期就出现过由于网络环境的变动，某些配置变得不再可用，比如监听在宿主机上的代理。由于 DHCP 或者切换 wifi，宿主机的 IP 经常变动，为了解决这个问题，mediumkube 会为用户维护一个虚拟网络，并且这个虚拟网络时非常易于配置的。用户只需要声明简单的接口信息，mediumkube 会自动进行配置 iptables，dnsmasq 等像信息。

下图为 mediumkubed 开发初期的拓扑结构，类似于 Docker 的 Bridge 网络，非常简洁，但同时也很实用。随着开发，会有越来越多的功能被添加。

Mediumkubed 会被注册为 systemd 中的一个模块，所以管理器来非常简单。

简单易用的命令行工具

在 UI 方面，mediumkube 提供了简单易用的命令行界面。比如用户可以展示已部署的虚拟机，并管理它们的生命周期，如停止/启动/删除/部署

同时，mediumkube 也有快速的组建集群，加入集群，重置节点等命令，使得集群的管理变得简单。比如，如果用户需要部署一个两节点的集群，只需要如下简单的命令

$ mediumkube deploynode1 node2

$ mediumkube initnode1

$ mediumkube joinnode2 node1

当然，如果用户不满足于这些简单的命令，他们也可以通过 shell 命令来登入到虚拟机中进行操作。

如上图所示，用户无需记忆任何 IP 地址，而且如果配置得当，也无需手动管理任何密钥，直接可以对节点进行管理。

MediumKube 的未来

MediumKube 是个很年轻也很小众的项目。它解决了一部分人的痛点的同时，也有相当大的局限性。比如在单机环境下的集群部署会使得系统资源捉襟见肘，以及项目比较低的产品化程度，都会使的它只是在“理论上”比较实用。作为 MediumKube 的开发者，自然也希望 MediumKube 越来越好用，下面谈谈我对它的规划。

集群化

上面也提到了，MediumKube 在单机的环境下带来了不小的局限性，所以集群化一定是一个未来的规划。当然，引入复杂的元素，势必会对系统的简洁性带来打击，比如 MediumKube 会变得难以部署，甚至还不亚于部署一个 K8S 集群，或者分布式元素的加入可能会带来更多的 bug。很多问题说大也不大，不过确实是需要花时间去思考的。集群化的 mediumkube 采用何种架构？虚拟机的部署如何进行调度？Overlay 网络用哪种技术做（上面的截图好像暴露了我准备用 flannel 这个事实）？如何进行简单却灵活的分布式部署？如果简单地进行节点的规划？是否需要图形化的支持？要考虑的东西确实比较繁杂。

稳定性和代码质量

作为开发环境，稳定性的要求可能没那么强，不过在 mediumkubed 在早期确实也出现过占用巨量内存的情况。而且作为一个玩具项目和 golang 学习用例，mediumkube 在代码质量上也比较堪忧。比如文件传输模块的代码就非常糟糕，以至于上行和下行的速度有明显的差距。希望在未来可以有所改善。

说在最后

最后希望技术可以真真正正地提升我们生活的便利性，并感谢 CNCF，Canonical，libvirt，Google 等组织和所有开源社区的开发者们给我们带来这些好玩，易用，免费的优质软件，也期待未来可以看到更多有意思的技术。

作者：闻云路