The NetApp® Astra™ Trident storage orchestrator has long been meeting storage demands that arise in the Kubernetes world. As applications grow in complexity and organizations adapt to emerging DevOps trends, developers are forced to think outside the box. This creative thinking is necessary to solve the challenges that modern containerized workloads bring with them. Sharing PersistentVolumeClaims (PVCs) between Kubernetes namespaces is one such hurdle; the latest release of Astra Trident easily overcomes it.
Many Kubernetes resources are restricted to the namespace that they belong to. This limitation is true for PVCs, and for apps that are built based on the concept of shared resources, it poses a challenge. PersistentVolumes (PVs) that back PVCs, on the other hand, are cluster-scoped resources.
What apps can those be, you ask? Here are some examples:
- A central data repository for artificial intelligence and machine learning (AI/ML).
- A database with multiple clients that read from the same volume.
- Multiple applications that operate on the same data source (a logging app may read and process data from another app that generated the data itself).
Many approaches exist today, of which two are worth mentioning:
- For static PVs and PVCs, create a PV in the desired namespace and bind it to a PVC that explicitly maps to the PV. This method requires connectivity information that is unique to each volume, making it hard to scale for a large number of volumes.
- An alternative approach concerns the node that the app runs on:
- Attach the volume to the node the app runs on.
- Create PVs in the desired namespace(s). This works fine when your apps don’t have to move around. With Kubernetes, however, this is rarely the case. App pods often move between nodes.
To summarize, the approaches detailed above lack some key requirements:
- They’re not dynamic. Kubernetes clusters can grow quickly as nodes are added, so maintaining the automation becomes challenging!
- Both methods introduce an additional persona (DevOps, cloud automation, or the infrastructure team) that manages the automation.
Astra Trident introduces a game changer
The latest Astra Trident release (v22.10) introduces a new feature that allows volumes to be shared across namespaces present in a Kubernetes cluster. Users can dynamically create a volume in a primary namespace and share it in one or more secondary namespaces, all through actions that are performed on Kubernetes. What is novel about the Trident approach is that it doesn’t require any additional intervention from a non-Kubernetes persona. Check out the following architectural diagram:
Read on to learn how it works.
To specify the namespace that a volume can be shared with, Trident uses annotations (provided in the PVC definition). Here’s an example:
The latest Trident release also introduces TridentVolumeReference (TVR), a Kubernetes Custom resource, for access control. A TVR must be created in the secondary namespace where a volume needs to be shared. Kubernetes administrators can restrict create privileges for the TVR resource, which enables admins to define a potentially narrow list of Kubernetes users who can create TVRs and share volumes.
The following example shows what a TVR looks like:
Give it a try today with the manifests provided here!
What happens when a parent volume is deleted and is shared across namespaces?
When secondary or subordinate volumes exist, parent volumes are “soft-deleted” (marked for deletion but not removed). The following example explains:
- Let’s assume that a PVC named “primary” (in the “primary” namespace) is shared with a PVC named “secondary” (in the “secondary” namespace).
- When “primary” PVC is deleted, the PVC and its associated volume are not deleted until “secondary” PVC is marked for deletion. Trident soft-deletes the volume and waits until the secondary PVC is removed before completely removing the parent volume.
Add annotations in-place to existing apps
Thanks to annotations, it is easy and efficient to update existing multi-namespace manifests. Sharing of volumes still requires the following personas to coordinate, however: the primary volume owner (PVC annotations), the secondary data consumer (PVC annotations), and the Kubernetes cluster admin (authorization of TVR creation).