Community Blog Sealer – A Kubernetes-based Distributed Application Package & Delivery Tool

Sealer – A Kubernetes-based Distributed Application Package & Delivery Tool

In this blog, we discuss the origin of Sealer, its value, and how to apply it in real-life production environments that use containers.

By Zhongyi, Alibaba Cloud technical expert, Sealos author, and Sealer project sponsor.

In this blog, we discuss the origin of Sealer, its value, and how to apply it in real-life production environments that use containers.

The Origin of Sealer

1. Trend and Development of Cloud


From the perspective of applications, the motivation for developing cloud technology is shield the underlying details of the architecture, allowing developers and businesses to pay more attention to the business logic itself.

When Openstack was launched in 2010, developers no longer needed to care about the complex management issues of physical machines. However, there was no improvement in the management of the application itself. Application developers still needed to deal with the operating system.

The emergence of Docker in 2013 set off a transformation in cloud architecture, breaking through the traditional IaaS and PaaS, blurring the hierarchy. It has helped applications implement some packaging and isolation work, making applications easier to manage.

Not long later in 2014, the emergence of Kubernetes changed the hierarchical architecture to the "cloud core" architecture. The cloud operating system has emerged, realizing the abstraction of computing network storage of these resources, and implementing the orchestration and management of applications. As such, application configuration management, service discovery, and resource configuration became simpler, and publishing distributed applications became as smooth as publishing stand-alone applications.

More recently, the emergence of Serverless FaaS has made applications focus on the business logic itself, but there has not been any practical standards like Kubernetes, and the topic is still controversial.

As an interesting place in the field of blockchain smart contracts, the first generation contracts of EVM are born serverless, running on Ethereum, the world computer. The second-generation contract represented by Polkadot solana near ICP supports WASM breaks the limitations of EVM scenarios and makes the contract suitable with more general scenarios. Therefore, I hope that cloud and chain technology can be unified in one place to realize the real "world computer", and all applications run on this "supercomputer".

2. Pain Points and Rigid Needs in the Delivery Field

We hope to make Kubernetes simple and conform to the trend to make the delivery clean.


At present, three major difficulties faced by Apsara Stack delivery are Docker, Kubernetes, and Helm. These technologies have solved some of the pain points, but not complete:

  • Docker only solves the mirroring problem of a single application. The whole software contains a lot of distributed components. Docker is unable to solve it;
  • Kubernetes solves the problems of distributed application management and resource abstraction, and how to arrange complex applications between applications. However, it does not solve the problem of managing these arrangements.
  • Helm only packages arranged files and extracts parameters, but it does not manage all dependencies.

Therefore, even if you use the preceding technology, once you get to the real scene, you will be in trouble.

For many users, the installation of Kubernetes itself may be more complicated than the installation of business. How to manage so many container images and what to do if no one is in the customer environment? The probability of problems caused by manual misoperation of component installation is increased.

Therefore, it is urgent for building technology of packaging the cluster as a mirror to ensure consistency in the cluster dimension.

3. An Excellent Design Concept

I believe that only when a great idea is born will you be excited, full of enthusiasm, and do everything possible to make it a reality. When designing Sealer, we tried every means to make it simple and clean, but it still needs to meet various requirements. Just like integrating many complicated technologies into a mobile phone, subtraction is a test for design ability.

Sealer's concept expounds simplicity and high abstraction to the extreme. It solves the pain points elegantly, conforms to the general trend of the industry, and creates great ecological value.

The Value of Sealer

1. Helping Enterprises Achieve Scale Delivery


For private cloud delivery companies, what Sealer can help is to achieve large-scale delivery, expand revenue, reduce costs, and increase profits. Companies that adopt Sealer technology can win in the large-scale competition. They reduce the delivery price of a single product and create a core price advantage.

Judging from the current situation of existing delivery projects, almost all of them start with hundreds of thousands of millions, which almost limits the customer base to the head customers. However, the demand for small and medium-sized enterprises is real. Due to the high delivery cost, there is no market for demand. If the price can be reduced to thousands or tens of thousands, the new market will be opened.

The same is true for Party A. It takes several months to purchase a set of software to the ground, and the whole link is long with sales communication, POC, delivery, etc. Since Party B's delivery costs become lower, Party A's procurement costs will be reduced.

Before Sealer, it was almost impossible for most enterprises to deliver 10,000 sets of complex software offline a year, and hourly delivery was even fantastic. However, Sealer can realize self-service, the delivery scale is no longer limited by the technical level, and it can also realize one-click delivery.

2. Breaking Down Collaboration Barriers

There were many container-related technologies before Docker. Why neither made an impact as successful as Docker? It is because the emergence of standards makes collaboration between ecosystems possible. The emergence of the Docker image allows perfect collaboration between the producer and the deliverer of the software. Anything needed can be found in the warehouse, and the users no longer need to care about the implementation details inside.

Many people try to establish standards, but most of them fail, and Docker succeeds. Why? Because the rapid popularization of a standard needs to meet some basic principles:

  • First: Hit the pain point
  • Second: Simple
  • Third: Powerful

By meeting these three criteria, the possibility of becoming a recognized standard will be increased.

The Docker image-standard packages all the dependencies of the process to ensure its consistency. This is the pain point in delivery.

It is difficult to meet both 2 and 3. Although the instructions in Dockerfiles are simple, it can pack almost anything. This is easy to be widely accepted. If a standard is hundreds of pages of documents, users will be scared away at a glance, let alone followed...

Sealer's design follows the preceding three points.


In terms of pain points, Sealer takes the essence of Docker's design idea, which can achieve what Docker fails. That is because modern software is almost all distributed applications. Docker does not care how distributed applications are mirrored. Sealer especially uses Kubernetes as the cluster operating system, derives Docker's idea to the cluster dimension, and realizes the construction, packaging, delivery, operation of distributed software.

Simple. The Sealer uses Occam's razor to the extreme, cuts the command to less than the Docker file command, and follows Docker's command design to make it easier for users to accept. If you don't understand Sealer's Kubefile in three minutes, it is a failure of Sealer's design.

Powerful. The Sealer is simple but not crude. You can find that a few simple instructions can help users build almost any complex customized Kubernetes clusters and customized distributed application images and then run it with one click.

Therefore, Sealer needs to establish a cluster image delivery standard. With the standard, people can cooperate better.

Before Sealer, there were always grievances between research personnel and delivery personnel of complex application design. The front-line delivery people do not understand the relationship between dozens of businesses. The research personnel did not know how complicated the front-line delivery environment is. Once something goes wrong, they will have an online meeting of a dozen people. Finally, the boss will find that many are responsible but no one is accountable.

With Sealer, the research personnel will make the cluster mirror image, and the delivery personnel can run Sealer casually; if it fails, it is that the research personnel will not make the mirror image proper, and blame the research personnel, with a clear division of labor. In addition, the requirements for delivery personnel will also become low. Interns can start work in half a day of training.

3. Flexible Customization, Free Combination, Reusability, Consistency, and Compatibility

We will make many basic mirrors for your use:

  • Various Kubernetes versions, various architectures ARM, AMD…
  • Images including various CNI and CSI implementations, calico, flannel, openlocal, openebs...
  • Various ecosystem software images, highly available MySQL, Redis, Prometheus...

These images are not docker images, but cluster images and a cluster can run after pull down.

The more amazing ability is that we support the free combination of these images. For example, if you need the combination of calico + redis + mysql, you can merge the three images for your business. Cluster mirroring is like playing mud. A few lumps of mud are still a lump of mud. The high degree of abstraction is breathtaking.

What's more, even if these fail to satisfy you, you only need to customize what is contained in your cluster as simple as writing a Dockerfile. For example, put the front and back-end services of your software into the cluster image. You can use the existing basic image of FROM to reuse the capabilities provided by others.

Moreover, the Sealer low-level technology ensures that these images have good compatibility and can run smoothly on any platform.

Applying Sealer to the Real World


The Sealer has only been developed since mid-2020, attracting more than 40 developers and more than 30 trial customers in the community, and landing in two production environments.

At first, we spent more than half a year designing and writing design documents. During this period, many versions of the design were rejected, and the design was optimized. Each instruction was designed carefully. We added entities if necessary.

We had no working members after the design was completed, and the team was assembled within one month. Most of them were members of community groups and developers of ecological companies. For example, when we communicated with Harmony Cloud, our ideas were recognized and we decided to invest resources. Finally, a seven-person virtual organization was born. After three months of intensive development, the first version was born and open source was completed.

After making Sealer open source, we developed more rapidly. We gathered the strength of the open-source community, attracted many external developers to make the project converge and stabilize, and soon attracted a group of users to try. This showed the strong demand and users' recognition of the Sealer concept.

1. Simple Interface Design

Following the design philosophy of simpleness, we learned from Docker's design philosophy to make and run cluster images simple.

Build Kubefile for a cluster image is similar to Dockerfile, but simpler. For example, create a cluster image that contains calico:

FROM kubernetes:v1.19.8-alpine
COPY etc .    
RUN wget https://docs.projectcalico.org/manifests/tigera-operator.yaml    
CMD kubectl apply -f etc/tigera-operator.yaml    
CMD kubectl apply -f etc/custom-resources.yaml

How to start the Clusterfile of a cluster, similar to Docker-compose:

apiVersion: sealer.cloud/v2
kind: Cluster
  name: default-kubernetes-cluster
  image: kubernetes:v1.19.8
    passwd: xxx
  - ips: [,,]
    roles: [master]
  - ips: []
    roles: [node]

Configuring cluster image name and ssh information in server IP can build a cluster. Each line here reflects the elaborate design, such as why IP uses lists, how roles are grouped. Of course, some other fields have not been displayed. In principle, users who do not need to pay attention to other functions are not burdened. The users need to care about the parameters of what kind of capability they use.

2. Excellent Plug-in Mechanism

Some of us may encounter some exotic needs, which are not universal, but they are just needed by customers. If you support them, your architecture will be disrupted, making the whole product "not elegant" and affecting the experience of other users.

At this time, these functions must be stripped away through powerful design capabilities, so that people who do not need to use it are unable to perceive its existence.

Therefore, Sealer designed a powerful plug-in mechanism to let you do what you want but don't affect others.


For example, some people have to use Sealer to modify the hostname, which is not what Sealer cares about, so we can develop a plug-in, and the user can activate this function by configuring this plug-in:


Some users said that they want to develop a dedicated plug-in, but do not want to contribute the code to the Sealer community, because it is not versatile and the contribution is meaningless. In this scenario, we support the golang plugin mechanism and load the .so file to realize the dynamic loading of the plug-in.

3. Ultimate Performance and Ultimate Pursuit

Although we have developed fast in the process of cluster construction. Six nodes in a few minutes are almost the limit. However, whether the user experience is smooth has a great impact, so we have not stopped the pursuit of performance.

For example, it takes 2-3 minutes for Terraform to connect with the public cloud. We think this is unacceptable. Therefore, we wrote the driver again and shortened the time to less than 30 seconds, which is almost the limit. Further improvement is limited by the speed of the server starting the virtual machine. We have done a backoff wait and a more reasonable concurrency mechanism to achieve this performance.

For example, cluster images, like Docker, pull images hierarchically to improve layer reuse and improve performance. The process of copying files takes up a lot of time, so we provided on-demand copy functions. In the future, we will build capabilities of nydus to implement the load-on-demand mechanism and distribution of cluster images in P2P to further improve performance.

For example, the container image needs to be cached in the process of building a cluster image. The traditional method is pull and push, which does more useless work. We will use the proxy to cache and use the pull process to cache. However, it is not extreme to need a registry when building. In the future, we will integrate the core code and cache without starting the registry.

All of the above shows that we have taken great pains for the ultimate experience of users.

What's Next for Sealer?

Simple and powerful products can capture the hearts of users. Sealer not only needs to solve the core pain points but also needs to enable users to obtain excellent experiences.


Functionally, Sealer has completed the setting of "Docker in Cluster". In the future, we will invest more in ecological development, create more and better official images, establish more partnerships, and truly connect software providers with users to collaborate efficiently.

0 0 0
Share on

You may also like


Related Products