Kubernetes Hub

While Kubernetes allows for innovative ways to scale and use containerized workloads, there is still the need for storage solutions. Kubernetes facilitates this through persistent volumes, which provide the flexibility to control how storage is provisioned without affecting the pods that make use of that storage. Using persistent volumes, the same persistent volume claim could be set up to use a different type of backend storage based on the Kubernetes cluster it is deployed into.

Kubernetes persistent volumes are created through the use of a provisioner that interfaces with backend storage through the use of a plugin. The storage type can be a range of different formats, with support extending to Google Persistent Disk, Amazon EBS, Azure Disk Storage, and others. A reclaim policy is set for the persistent volume which determines its lifetime. This same policy controls what the cluster will do whenever a persistent volume claims is released by a pod.

Provisioning volumes takes place in two different ways: static or dynamic provisioning. With static provisioning, admins provision persistent volumes for the cluster ahead of time. This requires prior knowledge of storage requirements as a whole. In dynamic provisioning, persistent volumes are deployed automatically based on the claims the cluster receives.

Kubernetes persistent volumes enable a great amount of flexibility when it comes to storage provisioning due to the separation persistent volumes create between the containerized applications and the storage the apps make use of. NetApp’s Trident provisioner works alongside the Cloud Volumes ONTAP data management platform from inside Kubernetes, extending the benefits of storage optimization and ease of use to persistent volumes in Kubernetes.

Stateful applications that run in Kubernetes need storage that is persistent and with a lifecycle that is independent of pods. Using persistent volumes can go some way towards achieving this, but another solution is to use stateful sets and dynamic provisioning, which are easier both to scale and to manage.

Kubernetes has been offering support for stateless applications since the platform’s inception, however, the storage that stateful applications rely on needs to have strong data protection guarantees, something that Kubernetes on its own does not provide. Stateful applications include some business-critical components; a database is a good example of a stateful application that is key to an enterprise and must ensure is protected. That protection takes place at the back-end storage service in use for persistent volumes. As different storage solutions can be used for this, data protection levels can vary. The service being employed needs to provide for backup and restore and availability solutions.

Using Trident and Cloud Volumes ONTAP, Kubernetes users can dynamically provision storage for their stateful sets and gain the benefits of high levels of data protection, zero-data-loss and under-60-second high availability, and flexible data management operability, all of which enterprise-level deployments require.

As explained above, there are two ways Kubernetes persistent volumes are provisioned so users can take advantage of the extensible framework for clustered data storage management: static and dynamic. Administrators who want to have all the storage they require upfront can do so with static provisioning, which pre-allocates any Kubernetes persistent volumes. Such a decision depends on an exact understanding of the storage needs of the cluster. Should the cluster’s storage demands exceed the number of volumes previously provisioned, there would be an issue.

Those issues are avoided when using the second option for Kubernetes persistent volume provisioning, dynamic provisioning. In a deployment using dynamic provisioning, users don’t have to know of the cluster’s eventual storage needs since persistent volumes are provisioned as they are needed. This more organic process gives the Kubernetes cluster more flexibility, and room to scale.

By using dynamic storage provisioning, Kubernetes users can greatly simplify how persistent volumes are deployed in clusters. Without the requirements to provision volumes manually and have foreknowledge of the storage amount needed, users can let their clusters scale without worry.

Enterprise workloads typically have a strong requirement for reliable data storage. Kubernetes persistent volumes can be provisioned using a variety of solutions. However, ensuring that the data is easy to backup and restore, always available, consistent, and durable in a Kubernetes workload DR (Disaster Recovery) situation or any other failure is the responsibility of end users and administrators.

In this article, we’ll look at how containerized applications in Kubernetes can take advantage of the enterprise data protection features of Cloud Volumes ONTAP by provisioning persistent volumes through NetApp Trident. This solution can help meet all the data protection requirements of production Kubernetes workloads transparently and with ease.

When Kubernetes users provision large amounts of storage for containerized applications, it may be the case that large allocation of storage is never used. There may also be scenarios where a persistent volume stores data that is not compressed, a storage inefficiency that leads to consuming more storage and raising the associated storage costs unnecessarily.

The issue of storage efficiency is affected by how Kubernetes users decide to provision persistent volumes: manually through static provisioning, or automatically through dynamic provisioning. In either case, the challenge is to make sure there is storage efficiency. Developers will many times estimate for too large a storage need. In the cloud, that is a big reason for storage sprawl and unnecessary costs.

These storage challenges can be addressed through the use of the built-in storage efficiency features of Cloud Volumes ONTAP, which are available to Kubernetes users through the NetApp Trident provisioner. Storage space can be conserved through data deduplication, compression, compaction, thin provisioning, and automatically tiering cold data to less-expensive object storage on Amazon S3 or Azure Blob until it needs to be used. All of these combine to give Kubernetes advantages in reducing the storage space persistent volumes required.

Developers get a huge advantage from Kubernetes’ abilities to easily scale and manage containerized workloads. But the CI/CD pipeline also requires an easy way to test new builds and changes to environments. Normally, this would require provisioning an entirely new persistent volume with all of the same data. That could be costly both in terms of the time and the costs involved for storage. Trident and Cloud Volumes ONTAP offer a better solution: FlexClone® data clone volumes.

Using Trident, Kubernetes persistent volume claims can be answered by creating highly space-efficient clones of persistent volumes instantaneously. Trident does this using a set of basic annotations on the persistent volume claim, and working in tandem with the ONTAP back-end systems to locate the original volume claim and recreating it.

The costs benefits of using FlexClone are considerable, as no storage needs to be consumed to create the clone: only the changed data needs to be stored. And once the clone is no longer needed by a pod, a simple reclaim policy of delete will delete the clone, making sure no unnecessary storage is taken up.

With persistent volumes, Kubernetes can support stateful apps, such as databases like MySQL. Kubernetes uses this permanent form of data storage to control and use MySQL databases and other services that populate their deployments via a unified platform that scales.

Stateful sets are a powerful mechanism that Kubernetes uses to scale stateful applications. Stateful sets are good for horizontal-scaling systems that would use a new node while deploying persistent storage from a template. In this way the network identity of all the pods can stay stable with the guarantee that the persistent volumes the set is connected to, will not be deleted. However, stateful applications such as MySQL databases need the highest levels of data protection, features that Kubernetes provisioning relies on the storage service to provide. Since a variety of storage can be used in Kubernetes, meeting the data protection requirements is up to the user to manage. DevOps engineers also require an easy way to clone quickly in order to speed up testing and TTM, another feature that the storage provider backing Kubernetes may lack.

By deploying Kubernetes with NetApp Trident, the storage used for persistent volumes is allocated by NetApp systems such as Cloud Volumes ONTAP, which come with multiple data protection benefits: backup and restore for databases of any size through ONTAP Snapshots, high availability for Kubernetes persistent volumes across AZs with Cloud Volumes ONTAP HA, efficient, block-level data replication with SnapMirror, and FlexClone data cloning for fast, space-efficient clones to benefit DevOps testing.