Kubernetes have many options to let the pod store determined data, but Kubernetes itself was originally designed to support only network storage. It is good for most cases used in cloud infrastructure and network speed while getting significantly faster over time, there is still the risk factors and the additional latency due to network traffic congestion.
High-performance applications need a data storage solution that is faster, and use local disks node is the best alternate. You can compare top storage solutions for Kubernetes from various online sources.
Before the local volume types are introduced, the only way to Pod to access local storage is to:
- Using hostPath to mount a local directory to Pod
- Using temporary, empty volume with emptyDir
This option is good has limited functionality for our needs, or they required us to configure the host first. In both cases, our ability to automate the deployment is limited. Type a local volume aims to resolve some of these issues, but it is still in beta.
The first challenge we determine how storage conditions to Pods. Each Pod needs a specific amount of disk space to complete tasks. At the same time, we do not want a single Pod to consume a disproportionate amount of disk space to produce excessive amounts of data.
Since Pods are directly related to the host resources, we cannot easily migrate workloads across nodes. After Pod scheduled on the node, it's there forever. However, this does not mean we do not have any reproduction.
Instead of relying on Kubernetes or networked storage solutions to replicate our data, we handle replication within the application itself.
This leads to our final challenge, which tracks changes associated with Pods and partitions. More specifically, the handling Pod or node failure. Because of the partition associated with certain Pod cases, we can not easily reuse a partition in the event of failure Pod.