Container Run Environments (container runtimes) Part 1: Introduction to Container Run Environments
From the translator :
This is a translation of the article Container runtimes Part 1: An Introduction to Container runtimes .
The author of the original publication: Ian Lewis .
One of the terms that you often hear when dealing with containers is “container runtime” ( hereinafter referred to as “ runtime” means “ launch environment” - translator's comment ). “Container launch environment” can have different meanings for different people, so it comes as no surprise that this is such a confusing and dimly understandable term, even within the Docker user and developer community itself.
This post is the first in a series that consists of 4 parts:
')
This post will explain what container launch environments are and where there are so many misunderstandings. After that, I will delve into the different types of container launch environments, what they do and how they differ from each other.
(In the picture, a play on words: Not sure if this refers to the Kubernetes launch environments of the container, the low-level launch environment of the container or the duration of the movie - translator's note)
Traditionally, a programmer can understand “runtime” either as a phase in the life cycle of a program during which it runs, or as an environment of a language that supports this execution. An example of this is the Java HotSpot runtime. The last value is the closest to the runtime of the container. The container launch environment is responsible for all container launch phases that are not directly involved in launching the program itself. As we will see later in this series, launch environments provide various levels of functions, but the “launch container” function for the tool is essentially all that is needed to call it a container launch environment .
If you are not very familiar with containers, first familiarize yourself with these materials and return:
Docker was released in 2013 and solved many developer problems by running containers in an unbroken chain. It included:
All this time, Docker has been a monolithic system. However, none of these functions truly depended on each other. Each of them could be implemented in smaller and specialized tools that could be used together. Each of the tools could work together with the others, using a common format, a container standard.
Because of this, Docker, Google, CoreOS, and other vendors have created the Open Container Initiative (OCI) . After that, they separated their code to launch containers as a tool and library, called runc , and passed it to OCI, as a reference implementation of the OCI launch environment specification .
At first, the question of what exactly Docker passed on to OCI was confusing. What they conveyed was the standard way to launch containers and nothing else. They did not include the image format or protocols for receiving / unloading the container image from / into the image register (image storage). When you run the Docker Container, these are the actions that Docker actually performs:
What Docker standardized was only step # 3. While this has not been clarified, everyone perceived the container launch environment as a system that supports all the functions that Docker supports. Over time, the Docker guys explained that the original specification states that only the “launch container” part forms the “launch environment”. This disconnection, which continues even now, makes “container launch environments” such a confusing topic. I hope to show that both sides are right to some extent, and I will use this term quite widely in this post.
When developers think about container launch environments, here is a list of some examples that might come to mind: runc, lxc, lmctfy, Docker (containerd), rkt, cri-o. Each of them is designed for different situations and performs different functions. Some, such as containerd and cri-o, actually use runc to launch the container, but manage images and have an API on top of that. You can think of these functions — which include transferring images, managing images, unpacking images and APIs — as high-level functions compared to a low-level runc implementation.
With this in mind, you can see that the area of ​​the container launch environment is quite complex. Each launch environment covers a different part of this spectrum from low level to high level. Here is a very subjective diagram:
In practice, container launch environments that focus simply on launching containers are commonly referred to as “low-level container launch environments.” Other launch environments that support higher-level features, such as image management and various gRPC / Web APIs, are commonly referred to as “high-level container tools”, “high-level container launching environments”, or usually simply “container-launching environments”. I will refer to them as “high-level container launch environments”. It is important to note that low-level and high-level launch environments are fundamentally different things that solve various problems.
Containers are implemented using namespaces and cgroups Linux. Namespaces give you the ability to virtualize system resources, such as the file system or networking, for each container. Cgroups provides a way to limit the amount of resources, such as CPU and memory, that each container can use. At the lowest level, the launch environments of containers are responsible for configuring these namespaces and cgroups. Support for low-level launch environments uses these features of the operating system.
Typically, developers who want to run applications in containers need more features than low-level launch environments provide. They need APIs and functions around image formats, image management and the ability to share images. These features provide high-level launch environments. Low-level launch environments simply do not have enough capacity for such daily needs. For these reasons, the only ones who will use low-level launch environments will be the developers of high-level launch environments and tools for containers.
The developers of low-level launch environments will say that high-level launch environments, such as containerd and cri-o, are not really container launch environments, since from their point of view they delegate the launch of the runc container. But from the user's point of view, they are full-fledged tools that provide the ability to run containers. One implementation may change to another, so it makes sense to call them the launch environment from this point of view. Despite the fact that containerd and cri-o both use runc, these are two very different projects with support for very different functions.
I hope that helped me understand what container environments are and why they are so difficult to understand. Feel free to leave me comments on the article (on the author’s website - comment of the translator) or on Twitter and let me know that in the launch environments of the containers it was the most difficult to understand.
In the next post, I'll go headlong into low-level container launch environments. In it, I will talk about what exactly low-level container launch environments do. I will talk about both popular low-level launch environments (such as runc and rkt), and unpopular, but important ones (such as lmctfy). I'll even go over how to run a simple low-level launch environment. Be sure to subscribe to my RSS feed or Twitter to get an alert when the next post comes out.
Until then, you can join the Kubernetes community through these channels:
Thanks to Sandeep Dinesh , Mark Mandel , Craig Box , Maya Kaczorowski and Joe Burnett for checking out the drafts of this post.
From the translator : I, in turn, express my gratitude for checking the draft translation of the user GDApsy .
This is a translation of the article Container runtimes Part 1: An Introduction to Container runtimes .
The author of the original publication: Ian Lewis .
One of the terms that you often hear when dealing with containers is “container runtime” ( hereinafter referred to as “ runtime” means “ launch environment” - translator's comment ). “Container launch environment” can have different meanings for different people, so it comes as no surprise that this is such a confusing and dimly understandable term, even within the Docker user and developer community itself.
This post is the first in a series that consists of 4 parts:
')
- Part 1: Introduction to container launch environments: why are they so confusing?
- Part 2: Deep immersion in low-level launch environments (eng)
- Part 3: Deep immersion in high-level launch environments
- Part 4: Launch environments in Kubernetes and CRI
This post will explain what container launch environments are and where there are so many misunderstandings. After that, I will delve into the different types of container launch environments, what they do and how they differ from each other.
(In the picture, a play on words: Not sure if this refers to the Kubernetes launch environments of the container, the low-level launch environment of the container or the duration of the movie - translator's note)
Traditionally, a programmer can understand “runtime” either as a phase in the life cycle of a program during which it runs, or as an environment of a language that supports this execution. An example of this is the Java HotSpot runtime. The last value is the closest to the runtime of the container. The container launch environment is responsible for all container launch phases that are not directly involved in launching the program itself. As we will see later in this series, launch environments provide various levels of functions, but the “launch container” function for the tool is essentially all that is needed to call it a container launch environment .
If you are not very familiar with containers, first familiarize yourself with these materials and return:
- What exactly is a container: namespaces and cgroups
- Cgroups, namespaces and beyond: what are the containers made of?
Why are container runtimes so confusing?
Docker was released in 2013 and solved many developer problems by running containers in an unbroken chain. It included:
- Container image format
- Method for building container images (Dockerfile / docker build)
- Ability to manage container images (docker images, docker rm, etc.)
- Ability to manage container instances (docker ps, docker rm, etc.)
- The ability to share images of containers (docker push / pull)
- Ability to run containers (docker run)
All this time, Docker has been a monolithic system. However, none of these functions truly depended on each other. Each of them could be implemented in smaller and specialized tools that could be used together. Each of the tools could work together with the others, using a common format, a container standard.
Because of this, Docker, Google, CoreOS, and other vendors have created the Open Container Initiative (OCI) . After that, they separated their code to launch containers as a tool and library, called runc , and passed it to OCI, as a reference implementation of the OCI launch environment specification .
At first, the question of what exactly Docker passed on to OCI was confusing. What they conveyed was the standard way to launch containers and nothing else. They did not include the image format or protocols for receiving / unloading the container image from / into the image register (image storage). When you run the Docker Container, these are the actions that Docker actually performs:
- Download image.
- Unpacking the image in a "package" (bundle). This action aligns the layers into a single file system.
- Starting the container from the package.
What Docker standardized was only step # 3. While this has not been clarified, everyone perceived the container launch environment as a system that supports all the functions that Docker supports. Over time, the Docker guys explained that the original specification states that only the “launch container” part forms the “launch environment”. This disconnection, which continues even now, makes “container launch environments” such a confusing topic. I hope to show that both sides are right to some extent, and I will use this term quite widely in this post.
Low level and high level container launch environments.
When developers think about container launch environments, here is a list of some examples that might come to mind: runc, lxc, lmctfy, Docker (containerd), rkt, cri-o. Each of them is designed for different situations and performs different functions. Some, such as containerd and cri-o, actually use runc to launch the container, but manage images and have an API on top of that. You can think of these functions — which include transferring images, managing images, unpacking images and APIs — as high-level functions compared to a low-level runc implementation.
With this in mind, you can see that the area of ​​the container launch environment is quite complex. Each launch environment covers a different part of this spectrum from low level to high level. Here is a very subjective diagram:
In practice, container launch environments that focus simply on launching containers are commonly referred to as “low-level container launch environments.” Other launch environments that support higher-level features, such as image management and various gRPC / Web APIs, are commonly referred to as “high-level container tools”, “high-level container launching environments”, or usually simply “container-launching environments”. I will refer to them as “high-level container launch environments”. It is important to note that low-level and high-level launch environments are fundamentally different things that solve various problems.
Containers are implemented using namespaces and cgroups Linux. Namespaces give you the ability to virtualize system resources, such as the file system or networking, for each container. Cgroups provides a way to limit the amount of resources, such as CPU and memory, that each container can use. At the lowest level, the launch environments of containers are responsible for configuring these namespaces and cgroups. Support for low-level launch environments uses these features of the operating system.
Typically, developers who want to run applications in containers need more features than low-level launch environments provide. They need APIs and functions around image formats, image management and the ability to share images. These features provide high-level launch environments. Low-level launch environments simply do not have enough capacity for such daily needs. For these reasons, the only ones who will use low-level launch environments will be the developers of high-level launch environments and tools for containers.
The developers of low-level launch environments will say that high-level launch environments, such as containerd and cri-o, are not really container launch environments, since from their point of view they delegate the launch of the runc container. But from the user's point of view, they are full-fledged tools that provide the ability to run containers. One implementation may change to another, so it makes sense to call them the launch environment from this point of view. Despite the fact that containerd and cri-o both use runc, these are two very different projects with support for very different functions.
Next...
I hope that helped me understand what container environments are and why they are so difficult to understand. Feel free to leave me comments on the article (on the author’s website - comment of the translator) or on Twitter and let me know that in the launch environments of the containers it was the most difficult to understand.
In the next post, I'll go headlong into low-level container launch environments. In it, I will talk about what exactly low-level container launch environments do. I will talk about both popular low-level launch environments (such as runc and rkt), and unpopular, but important ones (such as lmctfy). I'll even go over how to run a simple low-level launch environment. Be sure to subscribe to my RSS feed or Twitter to get an alert when the next post comes out.
Until then, you can join the Kubernetes community through these channels:
- By posting and answering questions on stack overflow
- Subscribing to Twitter @Kubernetesio
- Joining Kubernetes Slack and chatting with us. (I am ianlewis so say "Hello"!)
- Contributing to Kubernetes on GitHub
Thanks to Sandeep Dinesh , Mark Mandel , Craig Box , Maya Kaczorowski and Joe Burnett for checking out the drafts of this post.
From the translator : I, in turn, express my gratitude for checking the draft translation of the user GDApsy .
Source: https://habr.com/ru/post/350446/
All Articles