kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Tidy install guide for container runtimes (#12704) 

* Use feature-state note for CRI

* Note applicability to Linux hosts

* Explain cgroup ("control group")

* De-emphasize cgroup details

The individual runtime install steps already take account of this
advice.
This commit is contained in:
Tim Bannister 2019-02-25 16:37:39 +00:00 committed by Kubernetes Prow Robot
parent 99dccca00a
commit e176143ab1
1 changed files with 19 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
content/en/docs/setup/cri.md
View File

@ -7,15 +7,14 @@ content_template: templates/concept
weight: 100
---
{{% capture overview %}}
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
This page contains installation instruction for various runtimes.
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
To run containers in Pods, Kubernetes uses a container runtime. Here are
the installation instruction for various runtimes.
{{% /capture %}}
{{% capture body %}}
Please proceed with executing the following commands based on your OS as root.
You may become the root user by executing `sudo -i` after SSH-ing to each host.
{{< caution >}}
A flaw was found in the way runc handled system file descriptors when running containers.
@ -26,15 +25,25 @@ Please refer to this link for more information about this issue
[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
{{< /caution >}}
## Cgroup drivers
### Applicability
{{< note >}}
This document is written for users installing CRI onto Linux. For other operating
systems, look for documentation specific to your platform.
{{< /note >}}
You should execute all the commands in this guide as `root`. For example, prefix commands
with `sudo `, or become `root` and run the commands as that user.
### Cgroup drivers
When systemd is chosen as the init system for a Linux distribution, the init process generates
and consumes a root cgroup and acts as a cgroup manager. Systemd has a tight integration with
cgroups and will allocate cgroups per process. It's possible to configure your container
runtime and the kubelet to use `cgroupfs`. This means that there will then be two different
cgroup managers.
and consumes a root control group (`cgroup`) and acts as a cgroup manager. Systemd has a tight
integration with cgroups and will allocate cgroups per process. It's possible to configure your
container runtime and the kubelet to use `cgroupfs`. Using `cgroupfs` alongside systemd means
that there will then be two different cgroup managers.
Cgroups are used to constrain resources that are allocated to processes.
Control groups are used to constrain resources that are allocated to processes.
A single cgroup manager will simplify the view of what resources are being allocated
and will by default have a more consistent view of the available and in-use resources. When we have
two managers we end up with two views of those resources. We have seen cases in the field