SAS Viya 4: Loading External Path-Based Data, Part 2

In my last article, I introduced some ideas around persistent storage in SAS Viya 4 / Kubernetes. However, I only briefly touched on the actual mechanisms you'd use to find where your CASLibs and libnames actually point outside of the SAS Viya 4 containers. I'm currently tracking down some CASLibs on a test SAS Viya 4 env with Kubectl. Let's take a look at the commands and results I use to see where the physical files actually sit.

. . .

Get the Relevant Namespace and Pod Name

I'm flying blind here. The first thing I need to do is understand what my Kubernetes environment looks like so I can figure out exactly where to look for the storage information. The first command I'll issue is below. This will tell me every single pod in the environment.

.

kubectl get pods --all-namespaces

The output contains numerous pods. I narrow down what I'm looking for to the CAS pods until finally I locate the CAS Controller pod.

..

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

This not only gives me the CAS Controller pod name, sas-cas-server-default-controller, but also the namespace, gelenv-stable.

Describe the Pod

Now that I know the relevant pod and namespace names, I can use them to look at how the pod is structured.

kubectl describe pod sas-cas-server-default-controller -n gelenv-stable

.

The pod contains numerous containers but I want the CAS container and, in particular, its mounts... .

Inspect any Ephemeral Volumes

There are two mounts that draw my interest, /cas/data and /gelcontent. Respectively they are bound to the identifiers, cas-default-data-volume and gelcontent-volume. I search for these lower in the output. The identifiers appear in the Volumes section.

..

Inspecting the volumes section, I can see that gelcontent-volume is an ephemeral volume and maps to /data/gel/content on the 10.96.13.223 machine.

Therefore, any CASLib or libname that uses the /gelcontent path within the SAS Viya 4 CAS environment maps to the /data/gel/content location on the 10.96.13.223 host. I can drop files there from external applications to use in SAS Viya. I can grab files from there that SAS Viya creates for use in other applications. .

Inspect any Persistent Volumes

The cas-default-data-volume identifier points to a persistent volume claim (PVC), named cas-default-data. .

With the claim name, I execute the following command. .

kubectl get pvc cas-default-data -n gelenv-stable

.

The command tells me the Kubernetes Persistent Volume (PV) that the PVC claimed.

..

Now, I need to issue one more command to see where the PV maps.

kubectl get pv pvc-7c5f34af-1c64-4332-b8d9-bd03c113048e -o json

.

The mapping information appears under the "spec" element.

..

From this, I can see that the /cas/data path inside SAS Viya environment maps to the /srv/nfs/kubedata/gelenv-stable-cas-default-data-pvc-7c5f34af-1c64-4332-b8d9-bd03c113048e path on the intnode01 machine. So again, external applications can drop data here for SAS Viya to use in the various CASLibs and libnames that use the /cas/data path, and external applications can grab SAS Viya outputs from here.

.

Applying This to Your Env

Hopefully this exercise and these command examples will help you to analyze your SAS Viya 4 Kubernetes environment to see where your persistent data lives. .

Find more articles from SAS Global Enablement and Learning here.