Este conteúdo não está disponível no idioma selecionado.
Chapter 2. Understanding ephemeral storage
To manage temporary data that exists only for the duration of a workload, review the properties of ephemeral storage.
2.1. Overview of ephemeral storage Copiar o linkLink copiado para a área de transferência!
To manage local storage for stateless applications, use ephemeral storage. Ephemeral storage is designed for the transient nature of pods and containers. You can use this feature to handle operations that require storage only for the duration of the lifecycle for the workload. Both developers and administrators can use the feature.
In addition to persistent storage, pods and containers can require ephemeral or transient local storage for their operation. 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.
Pods use ephemeral local storage for scratch space, caching, and logs. Issues related to the lack of local storage accounting and isolation include the following:
- Pods cannot detect how much local storage is available to them.
- Pods cannot request guaranteed local storage.
- Local storage is a best-effort resource.
- Pods can be evicted due to other pods filling the local storage, after which new pods are not admitted until sufficient storage is reclaimed.
Unlike persistent volumes, ephemeral storage is unstructured and the space is shared between all pods running on a node, in addition to other uses by the system, the container runtime, and OpenShift Container Platform. The ephemeral storage framework allows pods to specify their transient local storage needs. It also allows OpenShift Container Platform to schedule pods where appropriate, and to protect the node against excessive use of local storage.
While the ephemeral storage framework allows administrators and developers to better manage local storage, I/O throughput and latency are not directly affected.
2.2. Types of ephemeral storage Copiar o linkLink copiado para a área de transferência!
To provision ephemeral local storage, you can create the primary partition by using either root or runtime methods. This storage is always made available in the primary partition, providing temporary space for your workloads.
2.2.1. Root Copiar o linkLink copiado para a área de transferência!
This partition holds the kubelet root directory, /var/lib/kubelet/ by default, and /var/log/ directory. This partition can be shared between user pods, the OS, and Kubernetes system daemons. This partition can be consumed by pods through EmptyDir volumes, container logs, image layers, and container-writable layers. Kubelet manages shared access and isolation of this partition. This partition is ephemeral, and applications cannot expect any performance SLAs, such as disk IOPS, from this partition.
2.2.2. Runtime Copiar o linkLink copiado para a área de transferência!
This is an optional partition that runtimes can use for overlay file systems. OpenShift Container Platform attempts to identify and provide shared access along with isolation to this partition. Container image layers and writable layers are stored here. If the runtime partition exists, the root partition does not hold any image layer or other writable storage.
2.3. Ephemeral storage management Copiar o linkLink copiado para a área de transferência!
Cluster administrators can manage ephemeral storage within a project by setting quotas that define the limit ranges and number of requests for ephemeral storage across all pods in a non-terminal state. Developers can also set requests and limits on this compute resource at the pod and container level.
You can manage local ephemeral storage by specifying requests and limits. Each container in a pod can specify the following:
-
spec.containers[].resources.limits.ephemeral-storage -
spec.containers[].resources.requests.ephemeral-storage
2.3.1. Ephemeral storage limits and requests units Copiar o linkLink copiado para a área de transferência!
Limits and requests for ephemeral storage are measured in byte quantities. You can express storage as a plain integer or as a fixed-point number using one of these suffixes: E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki.
For example, the following quantities all represent approximately the same value: 128974848, 129e6, 129M, and 123Mi.
The suffixes for each byte quantity are case-sensitive. Be sure to use the correct case. Use the case-sensitive "M", such as used in "400M", to set the request at 400 megabytes. Use the case-sensitive "400Mi" to request 400 mebibytes. If you specify "400m" of ephemeral storage, the storage request is only 0.4 bytes.
2.3.2. Ephemeral storage requests and limits example Copiar o linkLink copiado para a área de transferência!
The following example configuration file shows a pod with two containers:
- Each container requests 2GiB of local ephemeral storage.
- Each container has a limit of 4GiB of local ephemeral storage.
At the pod level, kubelet works out an overall pod storage limit by adding up the limits of all the containers in that pod.
-
In this case, the total storage usage at the pod level is the sum of the disk usage from all containers plus the pod’s
emptyDirvolumes. - Therefore, the pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of local ephemeral storage.
-
In this case, the total storage usage at the pod level is the sum of the disk usage from all containers plus the pod’s
Example ephemeral storage configuration with quotas and limits
2.3.3. Ephemeral storage configuration effects pod scheduling and eviction Copiar o linkLink copiado para a área de transferência!
The settings in the pod spec affect both how the scheduler makes a decision about scheduling pods and when kubelet evicts pods.
- First, the scheduler ensures that the sum of the resource requests of the scheduled containers is less than the capacity of the node. In this case, the pod can be assigned to a node only if the node’s available ephemeral storage (allocatable resource) is more than 4GiB.
- Second, at the container level, because the first container sets a resource limit, kubelet eviction manager measures the disk usage of this container and evicts the pod if the storage usage of the container exceeds its limit (4GiB). The kubelet eviction manager also marks the pod for eviction if the total usage exceeds the overall pod storage limit (8GiB).
2.4. Additional resources Copiar o linkLink copiado para a área de transferência!
2.5. Monitoring ephemeral storage Copiar o linkLink copiado para a área de transferência!
To monitor ephemeral storage usage, use the /bin/df utility. By using this tool, you can track disk space consumption on the volumes where ephemeral container data resides, specifically /var/lib/kubelet and /var/lib/containers.
When you use the df command, the available space for only /var/lib/kubelet is shown if /var/lib/containers is placed on a separate disk by the cluster administrator.
Procedure
To show the human-readable values of used and available space in
/var/lib, enter the following command:df -h /var/lib
$ df -h /var/libCopy to Clipboard Copied! Toggle word wrap Toggle overflow The output shows the ephemeral storage usage in
/var/lib:Example output
Filesystem Size Used Avail Use% Mounted on /dev/disk/by-partuuid/4cd1448a-01 69G 32G 34G 49% /
Filesystem Size Used Avail Use% Mounted on /dev/disk/by-partuuid/4cd1448a-01 69G 32G 34G 49% /Copy to Clipboard Copied! Toggle word wrap Toggle overflow