---
title: Understanding Containers
---

# Understanding Containers {#nodes-containers-using}

Containers are the basic units of OpenShift Container Platform applications that isolate processes to provide portable micro-services. To maintain cluster stability, you must understand how container runtimes manage workloads and how kernel memory allocation impacts resource limits on your nodes.

[Linux container technologies](https://www.redhat.com/en/topics/containers#overview) are lightweight mechanisms for isolating running processes so that they are limited to interacting with only their designated resources.

Many application instances can be running in containers on a single host without visibility into each others' processes, files, network, and so on. Typically, each container provides a single service (often called a "micro-service"), such as a web server or a database, though containers can be used for arbitrary workloads.

The Linux kernel has been incorporating capabilities for container technologies for years. OpenShift Container Platform and Kubernetes add the ability to orchestrate containers across multi-host installations.

## About containers and RHEL kernel memory {#nodes-containers-memory}

Due to Red Hat Enterprise Linux (RHEL) behavior, a container on a node with high CPU usage might seem to consume more memory than expected. The higher memory consumption could be caused by the `kmem_cache` in the RHEL kernel. The RHEL kernel creates a `kmem_cache` for each cgroup. For added performance, the `kmem_cache` contains a `cpu_cache`, and a node cache for any NUMA nodes. These caches all consume kernel memory.

The amount of memory stored in those caches is proportional to the number of CPUs that the system uses. As a result, a higher number of CPUs results in a greater amount of kernel memory being held in these caches. Higher amounts of kernel memory in these caches can cause OpenShift Container Platform containers to exceed the configured memory limits, resulting in the container being killed.

To avoid losing containers due to kernel memory issues, ensure that the containers request sufficient memory. You can use the following formula to estimate the amount of memory consumed by the `kmem_cache`, where `nproc` is the number of processing units available that are reported by the `nproc` command. The lower limit of container requests should be this value plus the container memory requirements:

```terminal
$(nproc) X 1/2 MiB
```

## About the container engine and container runtime {#nodes-containers-runtimes}

A *container engine* is a piece of software that processes user requests, including command-line options and image pulls. The container engine uses a *container runtime*, also called a *lower-level container runtime*, to run and manage the components required to deploy and operate containers. You likely will not need to interact with the container engine or container runtime.

> [!NOTE]
> The OpenShift Container Platform documentation uses the term *container runtime* to refer to the lower-level container runtime. Other documentation can refer to the container engine as the container runtime.

OpenShift Container Platform uses CRI-O as the container engine and runC or crun as the container runtime. The default container runtime is crun. Both container runtimes adhere to the [Open Container Initiative (OCI)](https://www.opencontainers.org/) runtime specifications.

> [!WARNING]
> Starting in OpenShift Container Platform 4.22, the runC container runtime is deprecated.

CRI-O is a Kubernetes-native container engine implementation that integrates closely with the operating system to deliver an efficient and optimized Kubernetes experience. The CRI-O container engine runs as a systemd service on each OpenShift Container Platform cluster node.

crun, developed by Red Hat, is a fast and low-memory container runtime fully written in C. runC, developed by Docker and maintained by the Open Container Project, is a lightweight, portable container runtime written in Go.

crun has several improvements over runC, including:

- Smaller binary
- Quicker processing
- Lower memory footprint

runC has some benefits over crun, including:

- Most popular OCI container runtime.
- Longer tenure in production.
- Default container runtime of CRI-O.

You can move between the two container runtimes as needed.

**Additional resources**
{._additional-resources}

- [Creating a `ContainerRuntimeConfig` CR to edit CRI-O parameters](/openshift-docs-markdown/machine_configuration/machine-configs-custom#create-a-containerruntimeconfig_machine-configs-custom)