Container Runtimes [page]deterministic

setup

You need to install a [container runtime](#gloss:container-runtime) into each node in the cluster so that Pods can run there. This page outlines what is involved and describes related tasks for setting up nodes.

Kubernetes requires that you use a runtime that conforms with the [Container Runtime Interface](#gloss:cri) (CRI).

See [CRI version support](#cri-versions) for more information.

This page provides an outline of how to use several common container runtimes with Kubernetes.

[containerd](#containerd)
[CRI-O](#cri-o)
[Docker Engine](#docker)
[Mirantis Container Runtime](#mcr)

> Note: Kubernetes releases before v1.24 included a direct integration with Docker Engine, using a component named _dockershim_. That special direct integration is no longer part of Kubernetes (this removal was [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) as part of the v1.20 release). You can read [Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) to understand how this removal might affect you. To learn about migrating from using dockershim, see [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).

If you are running a version of Kubernetes other than v, check the documentation for that version.

## Install and configure prerequisites

### Network configuration

By default, the Linux kernel does not allow IPv4 packets to be routed between interfaces. Most Kubernetes cluster networking implementations will change this setting (if needed), but some might expect the administrator to do it for them. (Some might also expect other sysctl parameters to be set, kernel modules to be loaded, etc; consult the documentation for your specific network implementation.)

### Enable IPv4 packet forwarding {#prerequisite-ipv4-forwarding-optional}

To manually enable IPv4 packet forwarding:

```bash # sysctl params required by setup, params persist across reboots cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.ipv4.ip_forward = 1 EOF

# Apply sysctl params without reboot sudo sysctl --system ```

Verify that `net.ipv4.ip_forward` is set to 1 with:

```bash sysctl net.ipv4.ip_forward ```

## cgroup drivers

On Linux, [control groups](#gloss:cgroup) are used to constrain resources that are allocated to processes.

Both the [kubelet](#gloss:kubelet) and the underlying container runtime need to interface with control groups to enforce [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control groups, the kubelet and the container runtime need to use a *cgroup driver*. It's critical that the kubelet and the container runtime use the same cgroup driver and are configured the same.

There are two cgroup drivers available:

* [`cgroupfs`](#cgroupfs-cgroup-driver) * [`systemd`](#systemd-cgroup-driver)

### cgroupfs driver {#cgroupfs-cgroup-driver}

The `cgroupfs` driver is the [default cgroup driver in the kubelet](/docs/reference/config-api/kubelet-config.v1beta1). When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups.

The `cgroupfs` driver is not recommended when [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is the init system because systemd expects a single cgroup manager on the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups), use the `systemd` cgroup driver instead of `cgroupfs`.

### systemd cgroup driver {#systemd-cgroup-driver}

When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (`cgroup`) and acts as a cgroup manager.

systemd has a tight integration with cgroups and alloc …(trimmed)