Development teams deploying complex applications require sophisticated automation to deploy and manage the infrastructure. This can be expensive and time-consuming for small development teams.
Kubernetes solves this problem by providing an extensible clustered data storage management framework. Its storage lifecycle moves from provisioning to binding and can then shift to using or reclaiming.
Scalability
Kubernetes provides an efficient and scalable way to manage storage. The architecture separates the details of how storage is provisioned from how it is consumed. This uses two primary API resources, Persistent Volumes (PVs) and PersistentVolumeClaim (PVC).
The Kubernetes persistent volume allows applications to access PVs without knowing the underlying infrastructure. Developers create a PVC that specifies the size and other storage specifications they need. Kubernetes will dynamically provision a PV that matches the PVC. The PVC can then be bound to a pod so the applications can use it.
This allows for storage efficiency, preventing developers from overestimating their storage needs. It also helps to avoid storage sprawl, which can increase the cost of running a containerized application.
With the help of a StorageClass, Kubernetes can dynamically provision persistent volumes. The StorageClass defines the type of storage that should be used, such as fast SSDs slower HDDs, or even remote cloud storage services. The storage class can be specified in a PVC so Kubernetes can dynamically provision PVs matching the request.
Another benefit of Kubernetes PVs is that they are reusable, which makes them ideal for stateful applications. This means that the data will be preserved after a container is destroyed and can be reclaimed for another application. This scalability is critical for demanding applications that need to be available at all times.
Reliability
Kubernetes volumes are a plugin mechanism that connects ephemeral containers with persistent data storage. They can be backed by different types of storage hardware, including local SSDs, HDDs, NVMe SSDs, and cloud-based services like Amazon EBS. The underlying storage system can be changed by adding or removing storage policies and access modes.
By decoupling storage from individual pods, volume plugins enable a more scalable and reliable way of managing applications in container orchestration. On-disk files in a container are temporary, so all on-disk files are lost if the container crashes or stops. This can make sharing files between multiple containers or across a multi-container application challenging. In addition, a single failure can cause the entire cluster to crash. With Kubernetes, the infrastructure automatically restarts failed components to ensure that all connections are properly relinked and that applications continue functioning as expected.
Another feature that makes the Kubernetes platform more reliable is the ability to use higher-order services that continuously evaluate configurations, monitor the state of all running application components and underlying infrastructure, and actively “converge” them to match configured requirements.
These services can retry to connect to a failed container, restart the failed container on a different node, provide it with additional resources, and relink all of its connections so that applications continue to function as expected.
Flexibility
Kubernetes is designed for containerized applications to be immutable, but for some applications, the ephemeral storage used by containers cannot be the sole location to persist data. For these stateful applications, the volume abstraction is crucial for keeping data that outlives the lifespan of a Pod.
With persistent volumes, developers can easily provision the required application storage resources and scale up or down according to workload requirements. However, the flexibility of persistent volumes comes at a cost in terms of storage space and costs. This is where using a built-in storage efficiency feature such as Trident on ONTAP can make a huge difference.
Storage efficiency is important because developers will often need to pay more attention to their storage needs, which can result in unnecessary costs. In addition, how persistent volumes are provisioned is a big factor in ensuring storage efficiency. There are two ways that persistent volumes can be provisioned: statically or dynamically. In static provisioning, the cluster administrator must manually make existing storage devices available to the cluster users. In dynamic provisioning, the cluster checks for an available PV that meets a PersistentVolumeClaim’s storage requirements and binds it to the claim.
Trident provides an excellent solution to these challenges with basic annotations that enable highly space-efficient, instantaneous, persistent volume claims. Using a combination of built-in storage efficiency features on ONTAP, such as deduplication, compression, and compaction, plus automated tiering to less-expensive object storage (such as Amazon S3 or Azure Blob) until it is needed, Trident can reduce the number of persistent volumes required by as much as 50 percent.
Security
Kubernetes volumes allow stateful applications like databases to survive pod restarts. They are a permanent form of data storage separate from the container. At its core, a volume is a directory that the pod’s containers can access, possibly with some data. Kubernetes uses volume abstraction to solve two problems: loss of files when a pod restarts and the inability to share files between containers.
The Kubernetes cluster has two API resources to manage persistent volumes: PersistentVolume and PersistentVolumeClaim. A PersistentVolume consists of an ID, a fs mount point, and a status set (Pending, Mounted, or Unmounted). A Pod can use multiple PersistentVolumes. The PersistentVolumeClaim specifies a set of access modes and a storage size requested by the Pod.
Conclusion
The control loop in the master watches for new PersistentVolumeClaims and matches them to existing PVs. If the Pod’s PersistentVolumeClaim matches the PVC’s storage requirements, the control loop binds the PV and the PersistentVolumeClaim together. The bind is done regardless of other volume-matching criteria, including node affinity.
Administrators can offer different kinds of storage through StorageClass objects, which are used to create a persistent volume. For example, a StorageClass can represent different types of disks or even cloud storage providers. Administrators can also configure a hostPath PersistentVolume, which uses a file or directory on the node to emulate network-attached storage.
