1. Documentation
×

Optimizing ephemeral storage

Overview

This topic applies only if you enabled the ephemeral storage technology preview in OKD 3.10. This feature is disabled by default. To enable this feature, see configuring for ephemeral storage.

Technology Preview releases are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information see Red Hat Technology Preview Features Support Scope.

Pods use ephemeral storage for their internal operation such as saving temporary files. The lifetime of this ephemeral storage does not extend beyond the life of the individual pod, and this ephemeral storage cannot be shared across pods.

Prior to OKD 3.10, ephemeral local storage was exposed to pods through the container’s writable layer, logs directory, and EmptyDir volumes. Issues related to the lack of local storage accounting and isolation include the following:

  • Pods do not know how much local storage is available to them.

  • Pods cannot request guaranteed local storage.

  • Local storage is a best effort resource.

  • Pods can get evicted due to other pods filling the local storage, after which, new pods are not admitted until sufficient storage has been reclaimed.

Ephemeral storage is still exposed to pods in the same way, but there are new methods for implementing requests and limits on pods' consumption of ephemeral storage.

Management of container logs applies only if using CRI-O as the container runtime and file-based logging for logging.

It is important to understand that ephemeral storage is shared among all pods in the system, and that OKD does not provide any mechanism for guaranteeing any level of service beyond the requests and limits established by the administrator and users. For example, ephemeral storage does not provide any guarantees of throughput, I/O operations per second, or any other measure of storage performance.

General storage guidelines

A node’s local storage can be broken into primary and secondary partitions. Primary partitions are the only ones you can use for ephemeral local storage. There are two supported primary partitions, root and runtime.

  • Root

    Root partitions hold the kubelet’s root directory, /var/lib/kubelet/ by default, and /var/log/ directory. You can share this partition among pods, the operating system, and OKD system daemons. Pods can access this partition by using EmptyDir volumes, container logs, image layers, and container writable layers. OKD manages shared access and isolation of this partition.

  • Runtime

    Runtime partitions are optional partitions you can use for overlay file systems. OKD attempts to identify and provide shared access along with isolation to this partition. This partition contains container image layers and writable layers. If the runtime partition exists, the root partition does not hold any image layer or writable layers.