前言

笔者在2020年年初退出了星环的云开发部，在此之前接触过最简单的容器平台就是docker swarm，并且也是只知其一;不知其二，所以在工作的初期，对K8s的相熟是一个必不可少的工作。然而K8s是一个具备肯定复杂性的容器平台，所以开发/学习环境的搭建也会比较复杂。在尝试搭建完整版集群失败后又尝试minikube，然而又发现minikube的诸多毛病，如性能的局限，可配置性的低下。于是，在工作大半年，把握肯定基本知识后，着手开发本文所要介绍的MediumKube。初衷可能是为了帮忙刚退出星环的小伙伴们相熟K8s，不过感觉需要不高，就不了了之了。对于我本人来说，这倒是成为了疾速搭建开发环境的一个实用工具。

这些年容器云的技术曾经渗入到咱们日常开发的方方面面，不论是做一些企业应用的开发，还是集体网站的搭建。应用程序是否能在容器平台上运行，并且利用容器平台的个性去进行性能调优/老本治理的确是很难疏忽的一个局部。而现在，有很多的利用齐全基于云平台去开发，它们充分运用了云平台的能力，来做到诸如微服务化，服务网格化，弹性化等特点。然而一个齐全基于云平台开发的利用也自然而然须要一个简单的云开发环境，不论是对利用自身的部署，还是对云平台API的利用，甚至是对云平台自身能力的扩大，都是有很大帮忙的。

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

  • 是否能够疾速部署，删除
  • 功能性是否残缺
  • 对于高级用户是否提供丰盛的配置项
  • 开发者对环境底层组件的可见性
  • 作为中国的开发者，是否能轻松地应用开源的软件生态

当初市面上也有很多的免费软件能够作为容器云的开发环境，比方傻瓜式的k8s发行版minikube，可利用于边缘计算和资源受限环境的k3s，或者对于非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 deploy node1 node2
$ mediumkube init node1
$ mediumkube join node2 node1

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

如上图所示，用户无需记忆任何IP地址，而且如果配置切当，也无需手动治理任何密钥，间接能够对节点进行治理。

MediumKube的将来

MediumKube是个很年老也很小众的我的项目。它解决了一部分人的痛点的同时，也有相当大的局限性。比方在单机环境下的集群部署会使得系统资源顾此失彼，以及我的项目比拟低的产品化水平，都会使的它只是在“实践上”比拟实用。作为MediumKube的开发者，天然也心愿MediumKube越来越好用，上面谈谈我对它的布局。

集群化

下面也提到了，MediumKube在单机的环境下带来了不小的局限性，所以集群化肯定是一个将来的布局。当然，引入简单的元素，势必会对系统的简洁性带来打击，比方MediumKube会变得难以部署，甚至还不亚于部署一个K8S集群，或者分布式元素的退出可能会带来更多的bug。很多问题说大也不大，不过的确是须要花工夫去思考的。集群化的mediumkube采纳何种架构？虚拟机的部署如何进行调度？Overlay网络用哪种技术做（下面的截图如同裸露了我筹备用flannel这个事实）？如何进行简略却灵便的分布式部署？如果简略地进行节点的布局？是否须要图形化的反对？要思考的货色的确比拟繁冗。

稳定性和代码品质

作为开发环境，稳定性的要求可能没那么强，不过在mediumkubed在晚期的确也呈现过占用巨量内存的状况。而且作为一个玩具我的项目和golang学习用例，mediumkube在代码品质上也比拟堪忧。比方文件传输模块的代码就十分蹩脚，以至于上行和上行的速度有显著的差距。心愿在将来能够有所改善。

说在最初

最初心愿技术能够真真正正地晋升咱们生存的便利性，并感激CNCF，Canonical，libvirt，Google等组织和所有开源社区的开发者们给咱们带来这些好玩，易用，收费的优质软件，也期待将来能够看到更多有意思的技术。

作者：闻云路