Storage
Mobility
Protection
Analysis and control
TOPICShare
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.
Namespace restrictions
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).
Not-so-effective solutions
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.
Volume creation
To specify the namespace that a volume can be shared with, Trident uses annotations (provided in the PVC definition). Here’s an example:
Kind: PersistentVolumeClaim
apiVersion: v1
metadata:
annotations :
trident.netapp.io/shareToNamespace: secondary
name: primary-pvc
namespace: primary
spec:
accessModes:
- ReadWriteMany
storageClassName: trident
resources:
requests:
storage: 100Gi
Primary PVC
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
annotations:
trident.netapp.io/shareFromPVC: primary/primary-pvc
name: secondary-pvc
namespace: secondary
spec:
accessModes:
- ReadWriteMany
storageClassName: trident
resources:
requests:
storage: 100Gi
Secondary PVC
TridentVolumeReference
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:
apiVersion: trident.netapp.io/v1
kind: TridentVolumeReference
metadata:
name: tvr-secondary-to-primary
namespace: secondary
spec:
pvcName: primary
pvcNamespace: primary
TridentVolumeReference
Give it a try today with the manifests provided here!
Volume deletion
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).
See for yourself
Check out the new features of Trident for yourself. Download Astra Trident and see what it can do. You can also view a demo of the feature here.