preface

Last time I took you on SealerEarly experienceI think everyone is so relieved. I’m going to talk about sealer’s overall architecture. Get in the car, guys. Let’s go.

The core concept

First sealer introduced three concepts CloudImage, Kubefile and Clusterfile.

CloudImage: equivalent to DockerImage, where rootfs is Kubernetes, which contains all the dependencies your application needs (eg. docker Image, YAML File, or Helm Image…) .

Kubefile: describes how to build CloudImage.

Clusterfile: Defines the configuration to run cluster images.

Docker builds a docker image using Dockerfile, and uses compose to run the container. Sealer builds a CloudImage using Kubefile and starts the entire cluster using Clusterfile.

Of course docker is to mirror the container, Sealer is to mirror the entire K8S cluster in a higher dimension, making distributed software delivery more easy, just like build Run share!!

Module parse

Watching module parsing is boring and requires you to calm your restless heart.

sealer

There are currently files for Calico, Helm

–apply for the RUN cluster

–build for creating the image

— Check Do pre check: Check a few things before installing the cluster image to make sure the cluster image works. Post check: Checks whether the POD and server can pass.

— All k8S-related clients are put here, such as calling the K8S API to get node information, etc

The Cloud acts as an interface that allows sealer to be executed without shell scripts

–command A proxy for commands that do not exist in the system, such as ipvs-related control commands

–common some common things, constants, etc

–config is the configuration management, the business layer configuration parameters, such as helm related configuration has password, etc., through this injection

— Docs Document information

How does filesystem mount images together and then send them to machines for file cleaning

— Guest handles some upper-level instructions

A hack is something script-related

How to store images on this machine, how to deal with docker Hub, related to docker-related things

— How can IFRA connect to various public clouds, such as Ali Cloud, and get virtual machine up

Ipvs Configures some IPVS rules

Logger configures some log information

– analytical Kubefile parser

Runtime manages the entire K8S lifecycle

— Sealer concrete binary, sealer’s main entry man function is placed here, Sealer is standard cabRA engineering.

Seautil Concrete binary, also standard cabra engineering, is the command agent, to help us to the machine to execute some commands that are not on the system

— Test is for integration testing, E2E

–type defines the structure

Utils common tool methods, SSH, overlay2

— Vender maintains dependency packages, go mod Vender

Architecture diagram

Implementation layer

The implementation layer is an implementation extension based on the common capability layer reuse library, this layer does not care about where the image comes from, and does not care about the role of individual modules.

Common capability layer

This layer is mainly to implement and extend the capabilities of cluster mirroring, eg. Parse Kubefile, Clusterfile structure definition and so on.

Standard definition layer

Responsible for defining standards under which implementation layers must strictly follow the definition of eg.Kubefile. If you want to implement build, you must follow the criteria defined in Kubefile. The cluster must be run in strict accordance with the cluster parameters defined in Clusterfile. Of course, the files contained in the base image must follow the standard defined in cloud RootFS and must follow its standard capability extension.

conclusion

Once you know sealer’s core, modules and architecture, you have a pretty good idea of how it works. Ok, here comes the station, brothers get off, move your little hands point a concern, point a praise, your support is my motivation.

References:

“1”. Official Sealer documentation