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.
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".
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:
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.
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.
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.
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:
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.
We will make many basic mirrors for your use:
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.
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.
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.yamlHow to start the Clusterfile of a cluster, similar to Docker-compose:
apiVersion: sealer.cloud/v2
kind: Cluster
metadata:
name: default-kubernetes-cluster
spec:
image: kubernetes:v1.19.8
ssh:
passwd: xxx
hosts:
- ips: [192.168.0.2,192.168.0.3,192.168.0.4]
roles: [master]
- ips: [192.168.0.3]
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.
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.
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.
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.
How to Build Flexible Abstraction for any Kubernetes Resources with CUE and KubeVela
Decrypting the Three Major Components of Dubbo for High-Availability Deployment
482 posts | 48 followers
FollowAlibaba Developer - December 14, 2021
Alibaba Cloud Native Community - July 6, 2022
Alibaba Cloud Native Community - May 31, 2022
Alibaba Cloud Native - May 23, 2022
Alibaba Cloud Native Community - September 7, 2022
Alibaba Cloud Native Community - May 18, 2022
482 posts | 48 followers
Follow
Elastic High Performance Computing Solution
High Performance Computing (HPC) and AI technology helps scientific research institutions to perform viral gene sequencing, conduct new drug research and development, and shorten the research and development cycle.
Learn More
Super Computing Cluster
Super Computing Service provides ultimate computing performance and parallel computing cluster services for high-performance computing through high-speed RDMA network and heterogeneous accelerators such as GPU.
Learn More
Elastic High Performance Computing
A HPCaaS cloud platform providing an all-in-one high-performance public computing service
Learn More
Remote Rendering Solution
Connect your on-premises render farm to the cloud with Alibaba Cloud Elastic High Performance Computing (E-HPC) power and continue business success in a post-pandemic world
Learn MoreMore Posts by Alibaba Cloud Native Community