Application of ContainerOS in cloud native

The development of cloud computing can be divided into three stages.

The first stage: stand-alone deployment, with equipment as the center. For example, when deploying Java website applications, only one device is usually used. Install the OS system on this device, and then deploy Java JDK, Tomcat, etc. on the OS system.

The second stage: with the development of equipment and hardware, the original device-centric development has become resource-centric, and the concept of cloud has emerged. Generally, the public cloud or private cloud will be deployed first, and virtual machine resources will be deployed on the private cloud/public cloud, and then traditional businesses such as Java applications will be deployed.

The third stage: with the development of information, it gradually evolved to be application-oriented. For example, Java applications no longer use traditional services, but implement applications in the way of containerization or DevOps workflow. Cloud generation is the main development trend at present.

What will happen to OS in the development trend of cloud native?

First of all, traditional OS may have installed sshd or Apache software package during deployment. In the cloud native scenario, all applications are based on containers. For example, Python applications are more likely to use Python container images. There is no need for the underlying sshd or Apache packages. You can cut them off and the system will become thinner.

Secondly, in the cloud native environment, there may be thousands or hundreds of OS nodes in the K8s cluster. Operation and maintenance are very troublesome, and upgrading and other operations need to be carried out by each machine in turn.

In addition, the traditional Linux environment is a file environment, and you can change the critical path or data at will. In the cloud native environment, the system needs to be solidified as much as possible, and the stability or security will become higher.

Traditional OS software is delivered in the form of RPM and upgraded in the form of update. The application of containerOS is used in the way of container image. The upgrade of the OS no longer provides a single update, but changes the OS cluster into a whole. A cve upgrade only needs to be pushed to the warehouse once, and the system will automatically upgrade according to the packages in the warehouse.

The original K8s deployment is implemented through the deployment script or deployment tool provided by the K8s official. After the K8s cluster is deployed, NGINX or Java and other applications are deployed on the K8s. Now, applications can be packaged and deployed as a whole through Sealer technology, which means that after the deployment of K8s, the delivery is not a pure K8s cluster, but K8s+NGINX applications.

The containerOS at the bottom of the framework is lightweight tailored based on the OS of Dragon monitor or Unison, which solidified the system into an immutable OS. The upper layer provides component packages related to container runtime, and the upper layer inherits K8s cluster components by default.

If you want to change the traditional OS into ContainerOS, you only need three steps: migrate the existing POD, replace the existing OS with ContainerOS, and migrate the data mirrored by the existing container application to the same data on ContainerOS to achieve a smooth transition of business.

The above figure shows the architecture comparison before and after the migration. After migration, the original container image can be pushed through the K8s cluster, or the image provided by the community or Unitrust can be used to provide services.

ContainerOS has the following advantages under cloud origin:

First, more efficient resources. By tailoring unnecessary component packages, resources can be released more reasonably.

Second, more convenient application. Applications are no longer provided in the form of traditional RPM packages, but are delivered in the form of container images, which solves the problem of dependency. For example, if you want to use Python 2 and Python 3, the traditional OS is difficult to solve; Under ContainerOS, only two container images are needed, one Python 2 and one Python 3.

Third, more convenient operation and maintenance services. We advocate zero operation and maintenance. All OS versions, software packages, components, and kernels in the cluster are consistent without additional configuration. Each upgrade is a new system, which avoids the production of snowflake server or separate configuration. It is equivalent to installing a new OS and becomes simpler.

In the cloud native scenario, ContainerOS has more application scenarios.

① You can migrate and replace the original environment, such as the one deployed in the traditional OS or K8s cluster, directly to the ContainerOS+K8s scenario. The container image of the privatized warehouse is provided. When making the container image, the cve repair and security detection can be performed to improve the security of the container.

② Transformation of cloud base. In the cloud native scenario, the development is more based on K8s. In the container cloud scenario, K8s can be made into a component of the container cloud, providing API interfaces. Upgrade, system POD monitoring, K8s monitoring, etc. can be connected to the container cloud platform through the provided API interfaces, providing more integrated delivery.

③ Privatization customization. You can use ContainerOS to customize your own PaaS platform. For example, OA software can be provided directly through the overall PaaS platform of container cloud+OA software.

The above figure shows the performance test results of the operating system under the cloud. Concurrency and latency were significantly improved. This is mainly due to the tailoring of the system and kernel, which frees up more resources.

The overall idea of ContainerOS in the cloud native era is to make operation and maintenance easier.

Taking animal keepers as an example, if there are different types of animals in the zoo, the keepers need to understand the habits of each animal, which is difficult to manage; If there is only one animal in the zoo, the work of the keeper will become very simple. The same is true for the operating system. If all the underlying OS is unified and turned into an animal, the operation, maintenance and upgrade will become easier.

To sum up, ContainerOS focuses on liberating operation and maintenance and making management easier in cloud native scenarios.