preface

The author joined the cloud development department of Starring in early 2020. Before that, the most complex container platform I had come into contact with was Docker Swarm, and I had only a little knowledge of it. Therefore, it was essential to get familiar with K8s at the beginning of my work. However, K8s is a container platform with some complexity, so the development/learning environment can be complicated to set up. After the failure of trying to build a complete version of the cluster, I tried Minikube, but found many disadvantages of Minikube, such as limited functions and low configurability. Therefore, after working for more than half a year and mastering some basic knowledge, I began to develop MediumKube introduced in this paper. The original intention may be to help those who just joined Starring to get familiar with K8s, but felt that the demand was not high, so it was abandoned. For me, this turned out to be a useful tool for setting up a development environment quickly.

Over the years, container cloud technology has permeated every aspect of our daily development, from enterprise applications to personal websites. Whether the application can run on the container platform and take advantage of the features of the container platform for performance tuning/cost management is really a hard part to ignore. Nowadays, many applications are completely developed based on cloud platform. They make full use of the capabilities of cloud platform to achieve features such as microservitization, service grid, flexibility and so on. However, an application developed entirely based on the cloud platform also naturally needs a complex cloud development environment, which is of great help to the deployment of the application itself, the utilization of the CLOUD platform API, and even the expansion of the cloud platform itself.

As a development environment, our concerns may differ from those of a production environment. Here are some of my personal expectations for a development environment

  • Deleted whether rapid deployment is enabled

  • Functional integrity

  • Whether to provide rich configuration items for advanced users

  • Visibility of the developer to the underlying components of the environment

  • As a Chinese developer, is it easy to use the open source software ecosystem

There are also a number of free software that can be used as container cloud development environments, such as the dumb-ass K8S distribution Minikube, K8S for edge computing and resource-constrained environments, or docker Swarm is one of the container cloud environments that are easy to deploy for non-K8S users.

The MediumKube presented in this article is different from these more productized software in that it provides a highly customizable solution based on libvirt and Cloud-init. It is more of a virtual machine management tool than a pure Kubernetes lightweight distribution, and it provides some capabilities that make it a useful tool for deploying a Kubernetes development environment.

Use cloud-init to quickly initialize a VIRTUAL machine instance

Cloud-init is a common standard for IaaS Cloud services, and it is being promoted by the well-known Canonical, the company behind Ubuntu. Cloud-init is an example of Infrastructure as Code. By writing the configuration file declaratively, we can initialize the cloud instance. It is such a common standard that we can integrate it into hundreds of lines of code in miniature projects to implement a minimal IaaS service. MediumKube uses this tool, making it itself a highly customizable virtual machine management tool. Of course, since it is positioned for rapid deployment of Kubernetes, it also comes with a default cloud-init template, which is distributed with its source code itself.

The image above is part of MediumKube’s built-in template. This template includes the installation of users, software sources, system configuration scripts, and Docker/Kubernetes, so that once the instance is deployed, it has the corresponding software environment, and no additional configuration is required

Configure and template engines

MediumKube supports template engines. By writing global configuration items and using them in cloud-init templates, users can deploy highly customized clusters of virtual machines.

The figure above lists some of the configuration items supported by MediumKube. Some affect the attributes of the virtual machine, while others can be rendered into templates. For example, very useful HTTPProxy, very practical for Chinese users, because of the template engine support, users no longer need to set the proxy configuration in a number of scattered places over and over again, but through a unified configuration file to global Settings. Although there are many configuration options, MediumKube has recommended defaults for each one, striking a balance between flexibility and ease of use. We all have the trouble of not knowing where to configure advanced virtual machine parameters when using Minikube, so it is also an advantage of MediumKube for both beginners and advanced users.

Use Mediumkubed to maintain a stable network environment

A stable network environment is also important for a development environment. Early in MediumKube’s development, some configurations became unavailable due to changes in the network environment, such as listening on agents on the host. To solve this problem, Mediumkube maintains a virtual network for the user, which is very easy to configure. Users only need to declare simple interface information, mediumkube automatically configure iptables, DNSMasq and other information.

The following diagram shows mediumkubed’s early development topology, which is similar to Docker’s Bridge network. It is very simple, but also very practical. As we develop, more and more features will be added.

Mediumkubed is registered as a module in Systemd, so the manager is very simple.

Easy to use command line tools

In terms of UI, Mediumkube provides an easy-to-use command line interface. For example, users can display deployed virtual machines and manage their life cycles, such as stop/start/delete/deploy

Mediumkube also has quick commands to form, join, and reset a cluster, making cluster management easy. For example, if the user needs to deploy a two-node cluster, the following simple command is required

$ mediumkube deploynode1 node2

$ mediumkube initnode1

$ mediumkube joinnode2 node1

Of course, if users are not satisfied with these simple commands, they can also log in to the VIRTUAL machine through shell commands.

As shown in the figure above, the user does not need to remember any IP addresses and, if configured properly, does not need to manually manage any keys.

The future of MediumKube

MediumKube is a very young and niche project. While it solves some people’s pain points, it also has considerable limitations. For example, cluster deployment in a single machine environment will make the system resources limited, and the project is relatively low level of transition, will make it only “theoretically” more practical. As a developer of MediumKube, I want MediumKube to be more and more useful. Here are my plans for it.

clustering

As mentioned above, MediumKube has significant limitations in a standalone environment, so clustering is definitely a future plan. Of course, the simplicity of the system can be hurt by the introduction of complex elements, such as MediumKube, which can become as difficult to deploy as deploying a K8S cluster, or the addition of distributed elements can be more buggy. Many questions are big or small, but they do take time to think about. What is the architecture of clustered Mediumkube? How do I schedule VM deployment? What technology is used for the Overlay network (the screenshot above seems to give away the fact that I was going to use Flannel)? How to make simple yet flexible distributed deployment? What if you simply plan the nodes? Do you need graphical support? There are a lot of things to consider.

Stability and code quality

As a development environment, the stability requirements may not be as strong, but Mediumkubed did have some problems in its early days using a lot of memory. Also as a toy project and golang learning case, Mediumkube has a poor code quality. The file transfer module, for example, is so poorly coded that there is a noticeable difference in upstream and downstream speeds. Hopefully it can be improved in the future.

Said in the last

Finally, I want to thank CNCF, Canonical, Libvirt, Google and all the developers in the open source community for bringing us great software that is fun, easy to use, and free to use. I look forward to seeing more interesting technologies in the future.

Author: Wen Yun Lu