Ephemeral Volumes
1. Ephemeral Volumes
Kubernetes offers a variety of Volume types, both ephemeral and durable. Let’s start by looking at ephemeral Volumes, including emptyDir, DownwardAPI, ConfigMap, and Secret. emptyDir is the most basic type of ephemeral Volume. It creates an empty directory within the Pod's filesystem to read and write from, and will exist as long as that Pod is running on that node. emptyDir is commonly used for storing temporary files or data that doesn't need to persist beyond the Pod's lifetime. Examples might include scratch space, such as for a disk-based merge sort, checkpointing a long computation for recovery from crashes, or holding files that a content-manager container fetches while a web server container serves the data. When a Pod is removed from a node for any reason, the data in the emptyDir is permanently deleted. However, if a container crashes, that event will not cause a Pod to be removed from a node. This means the data in the emptyDir volume will remain safe. Next is the DownwardAPI Volume type, which can be used to make data from the Downward API available to applications. This data can include Pod labels, annotations, secrets, and node information, which makes it useful for configuring applications based on their deployment context. It’s a way for containers to learn about their Pod environment. Then there are ConfigMap Volumes. Similar to DownwardAPI, ConfigMap Volumes can be used to inject configuration data into the Pod's environment. However, ConfigMap data is more structured, is stored as key-value pairs, and can be shared across multiple Pods. The data stored in a ConfigMap object can be referenced in a volume, as if it were a tree of files and directories. Applications can then consume the data. Finally, there is the Secret Volume type, which is specifically designed for storing sensitive data, such as passwords, tokens, or API keys. Secrets are unencrypted, but Google encrypts the data at rest and ensures secure access within the Pod. Secret Volumes are backed by underlying data store (etcd), so the Secrets are never written to non-volatile storage. Secrets aren’t secret just because of the way they are configured. Differentiating between ConfigMaps and Secrets provide a way to manage non-sensitive and sensitive Pod configuration data differently. Some Volume types, like Secrets and ConfigMaps, are coupled to the life of the Pod and are deleted when the Pod ceases to exist. But it’s important to note that although the Secret and ConfigMap Volumes that attach to individual Pods are ephemeral, the objects are not. At a fundamental level, ConfigMap, Secret, and DownwardAPI allow for different kinds of Kubernetes data into a Pod.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.