Kubernetes Hub

In recent years, software developers and DevOps engineers have benefited from encapsulating applications into lightweight, independent units called containers. Kubernetes takes container deployment to a whole new level by providing a robust solution for managing and scaling containers and containerized applications and workloads across a cluster of machines.

Kubernetes is changing the way that software is being deployed, though it has a lot of moving parts to be aware of. If you’re just getting started with Kubernetes or want to know what it can do with NetApp’s Trident and Cloud Volumes ONTAP, our Kubernetes Introduction blog post will introduce you to the history, background, important use cases, and basic terminology that relates to Kubernetes.

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.

Docker volumes behave as a layer that abstracts storage provisioning and container usage. Using commands within Docker, volumes can be created, managed, and used to keep Docker admin operations consistently interfaced.

The storage that Docker volumes are based on can be provisioned from file services such as NFS, or local, block-level storage types. Whichever storage type is preferred, the Docker host machine will need to have access to it ahead of when provisioning takes place (an Amazon EC2 instance hosting a Docker container needs an Amazon EBS volume assigned to it). All of the additional data management tasks associated with the volume from scaling and capacity to monitoring and backup creation are manual operations for the user to carry out.

A solution for handling those operations are NetApp’s Trident and Cloud Volumes ONTAP. With the help of Trident, all of the data management features of NetApp storage are available for Docker volumes. These features are available by using native Docker commands, making provisioning storage for containers a vastly improved experience. This also makes moving to Kubernetes possible, as all the benefits can be carried over through Trident for Kubernetes.

NetApp Trident is a fully supported, open-source storage provisioner for Kubernetes, which enables Kubernetes persistent volumes to be dynamically provisioned with Cloud Volumes ONTAP. This allows you to retain the use of native Kubernetes manifests and constructs to interact with your persistent storage, while at the same time gaining the benefits of using NetApp’s enterprise-grade data management platform.

Cloud Volumes ONTAP provides a whole host of features that are crucial for the reliable storage of persistent data. Protecting data with instant snapshots and high availability, as well as supporting data mobility between your on-premises systems and your Kubernetes deployments with highly efficient block-level data replication, are just some of the advantages users gain from using NetApp storage technologies.

Cloud Manager simplifies the process of deploying NetApp Trident into your Kubernetes deployment, irrespective of its underlying implementation, and then configuring the cluster to use a specific deployment of Cloud Volumes ONTAP. All of this can be achieved within minutes from the Cloud Manager web-based UI, and with just a few clicks you’ll be ready to start provisioning persistent storage for your cluster using Cloud Volumes ONTAP.

One of the most popular file protocols in use today is NFS (Network File System). With NFS, users can share files in enterprise-scale deployments with thousands of users around the world concurrently for use cases as diverse as big data analytics, data lake creation, archiving, database, and more. With Kubernetes deployments, NFS can be used with pods to provide Kubernetes persistent volumes that can share data across containers.

There are a number of advantages to using NFS with Kubernetes. One of these advantages is that it offers more flexibility than block-level persistent volume allocations. NFS makes it possible for a single file system to be mounted by multiple hosts who all have concurrent file access. As such, the storage volume can be mounted and used right away, without being formatted using an OS. This makes it easier to attach pods and storage and lowers administrative overhead. Of course, you’ll still need a Kubernetes persistent volumes provisioner, and NetApp Trident can do that, as it fully supports NFS.

The benefits of using Trident as a Kubernetes NFS provisioner, include the abilities to dynamically resize NFS persistent volumes, mount persistent volumes as Read/Write Many, and create separate storage classes for different mount parameters and other requirements. Plus, it comes along with all the data management benefits of Cloud Volumes ONTAP.

This post gives you an in-depth look at NFS file services with Kubernetes and how to use Trident as your Kubernetes NFS provisioner for Kubernetes persistent volumes. You’ll be able to see specific code examples for provisioning, creating separate storage class, and more.