March 5, 2018 at 23:59Container runtimes Part 1: Introduction to container runtimes
- Transfer
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 “runtime” is translated as “runtime” - translator's note ). A “container launch environment” can have different meanings for different people, so it’s not surprising that this is such a confusing and vaguely understandable term, even in the Docker community of users and developers.
This post is the first in a series that consists of 4 parts:
This post will explain what container launch environments are and where so much misunderstanding comes from. After that, I will delve into the various types of container launch environments, what they do and how they differ from each other.
(In the picture there is a pun: I’m not sure whether this refers to the launch environment of the Kubernetes container, the low-level launch environment of the container or the duration of the film - a translator’s note)
By tradition, a programmer can understand “runtime” or as a phase of the program’s life cycle during which it runs, or as a language environment that supports this execution. An example here is the Java HotSpot runtime. The last value is the closest to "runtime"container. The container launch environment is responsible for all phases of the container launch that are not directly involved in launching the program itself. As we will see later in this series, launchers provide different levels of functions, but the function “launches a container” for a tool is essentially all that is needed to call it a container launcher .
If you are not too familiar with containers, get acquainted with these materials first and come back:
Docker was released in 2013 and solved many developers' problems by launching containers in a continuous chain. It included:
All this time, Docker was a monolithic system. However, none of these functions really 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 rest, using a common format, the standard of the container.
Because of this, Docker, Google, CoreOS and other vendors created the Open Container Initiative (OCI) . After that, they separated their code for running containers as a tool and a library called runc , and passed it on to the OCI, as a reference implementation of the OCI specification of the launch environment .
At first, the question is what exactly Docker transmitted OCI confused. What they conveyed was the standard way to launch containers and nothing more. They did not include the image format or the protocols for receiving / unloading the container image from / into the image register (image storage). When you launch the Docker container, these are the steps Docker actually performs:
The fact that Docker standardized was only step number 3. Until this was clarified, everyone perceived the container launch environment as a system supporting all the functions that Docker supports. Over time, the Docker guys clarified that the original specification states that only the “launch container” part forms the “launch environment”. This disconnect, which continues even now, makes the "container launch environment" such a confusing topic. I hope to show that both parties are to some extent right, and I will use this term quite widely in this post.
When developers think of 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 various functions. Some, such as containerd and cri-o, actually use runc to run the container, but they do image management and have an API on top of that. You can think of these functions — which include image transfer, image management, image unpacking, and the API — as high-level functions compared to a low-level runc implementation.
With that in mind, you can see that the scope of the container launch environment is quite complex. Each launch environment covers different parts of this spectrum from low-level to high-level. Here is a very subjective chart:
In practice, container launch environments that focus simply on launching containers are commonly referred to as “low-level container launch environments”. Other launchers that support higher-level functions, such as image management and various gRPC / Web APIs, are commonly referred to as “high-level container launchers,” “high-level container launchers,” or usually simply as “container launchers.” 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 namespace mechanisms and cgroupsLinux Namespaces give you the ability to virtualize system resources, such as the file system or network, 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 container launch environments are responsible for configuring these namespaces and cgroups. Support for low-level startup environments uses exactly these features of the operating system.
Typically, developers who want to run applications in containers need more capabilities 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 capabilities for such daily needs. For these reasons, the only people who will use low-level launch environments will be developers of higher-level launch environments and tools for containers.
Developers of low-level launchers will say that higher-level launchers, such as containerd and cri-o, are not really a container launcher, because from their point of view they delegate the execution of the runc container to run. But from the point of view of the user, they are complete tools that provide the ability to run containers. One implementation can be exchanged for another, so it makes sense to call them a launch environment from this point of view. Despite the fact that containerd and cri-o both use runc, they are two very different projects supporting very different functions.
I hope I helped to understand what container launch environments are and why they are so hard to understand. Feel free to leave me comments on the article (on the author’s site - translator's note) or on Twitter and let me know what was the most difficult to understand in container launch environments.
In the next post I will go headlong into low-level container launch environments. In it, I will talk about exactly what low-level container launch environments do. I will talk about both popular low-level startup environments (such as runc and rkt) and unpopular but important ones (such as lmctfy). I will even go over how to run a simple low-level startup environment. Be sure to subscribe to my RSS feed or Twitterto 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 translations to 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 “runtime” is translated as “runtime” - translator's note ). A “container launch environment” can have different meanings for different people, so it’s not surprising that this is such a confusing and vaguely understandable term, even in the Docker community of users and developers.
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: The deep immersion into low-level start medium (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 so much misunderstanding comes from. After that, I will delve into the various types of container launch environments, what they do and how they differ from each other.
(In the picture there is a pun: I’m not sure whether this refers to the launch environment of the Kubernetes container, the low-level launch environment of the container or the duration of the film - a translator’s note)
By tradition, a programmer can understand “runtime” or as a phase of the program’s life cycle during which it runs, or as a language environment that supports this execution. An example here is the Java HotSpot runtime. The last value is the closest to "runtime"container. The container launch environment is responsible for all phases of the container launch that are not directly involved in launching the program itself. As we will see later in this series, launchers provide different levels of functions, but the function “launches a container” for a tool is essentially all that is needed to call it a container launcher .
If you are not too familiar with containers, get acquainted with these materials first and come back:
- What exactly is a container: namespaces and cgroups
- Cgroups, namespaces and beyond: what are containers made of?
Why are container runtimes so confusing?
Docker was released in 2013 and solved many developers' problems by launching containers in a continuous 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.)
- Ability to share container images (docker push / pull)
- Ability to run containers (docker run)
All this time, Docker was a monolithic system. However, none of these functions really 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 rest, using a common format, the standard of the container.
Because of this, Docker, Google, CoreOS and other vendors created the Open Container Initiative (OCI) . After that, they separated their code for running containers as a tool and a library called runc , and passed it on to the OCI, as a reference implementation of the OCI specification of the launch environment .
At first, the question is what exactly Docker transmitted OCI confused. What they conveyed was the standard way to launch containers and nothing more. They did not include the image format or the protocols for receiving / unloading the container image from / into the image register (image storage). When you launch the Docker container, these are the steps Docker actually performs:
- Download image.
- Unpacking the image into a “bundle”. This action aligns layers into a single file system.
- Running a container from a package.
The fact that Docker standardized was only step number 3. Until this was clarified, everyone perceived the container launch environment as a system supporting all the functions that Docker supports. Over time, the Docker guys clarified that the original specification states that only the “launch container” part forms the “launch environment”. This disconnect, which continues even now, makes the "container launch environment" such a confusing topic. I hope to show that both parties are to some extent right, and I will use this term quite widely in this post.
Low-level and high-level container launch environments.
When developers think of 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 various functions. Some, such as containerd and cri-o, actually use runc to run the container, but they do image management and have an API on top of that. You can think of these functions — which include image transfer, image management, image unpacking, and the API — as high-level functions compared to a low-level runc implementation.
With that in mind, you can see that the scope of the container launch environment is quite complex. Each launch environment covers different parts of this spectrum from low-level to high-level. Here is a very subjective chart:
In practice, container launch environments that focus simply on launching containers are commonly referred to as “low-level container launch environments”. Other launchers that support higher-level functions, such as image management and various gRPC / Web APIs, are commonly referred to as “high-level container launchers,” “high-level container launchers,” or usually simply as “container launchers.” 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 namespace mechanisms and cgroupsLinux Namespaces give you the ability to virtualize system resources, such as the file system or network, 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 container launch environments are responsible for configuring these namespaces and cgroups. Support for low-level startup environments uses exactly these features of the operating system.
Typically, developers who want to run applications in containers need more capabilities 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 capabilities for such daily needs. For these reasons, the only people who will use low-level launch environments will be developers of higher-level launch environments and tools for containers.
Developers of low-level launchers will say that higher-level launchers, such as containerd and cri-o, are not really a container launcher, because from their point of view they delegate the execution of the runc container to run. But from the point of view of the user, they are complete tools that provide the ability to run containers. One implementation can be exchanged for another, so it makes sense to call them a launch environment from this point of view. Despite the fact that containerd and cri-o both use runc, they are two very different projects supporting very different functions.
Next...
I hope I helped to understand what container launch environments are and why they are so hard to understand. Feel free to leave me comments on the article (on the author’s site - translator's note) or on Twitter and let me know what was the most difficult to understand in container launch environments.
In the next post I will go headlong into low-level container launch environments. In it, I will talk about exactly what low-level container launch environments do. I will talk about both popular low-level startup environments (such as runc and rkt) and unpopular but important ones (such as lmctfy). I will even go over how to run a simple low-level startup environment. Be sure to subscribe to my RSS feed or Twitterto get an alert when the next post comes out.
Until then, you can join the Kubernetes community through these channels:
- Submitting and answering questions on Stack Overflow
- By following @Kubernetesio on Twitter
- By joining Kubernetes Slack and chatting with us. (I 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 translations to the user GDApsy .