"A rose by any other name would smell as sweet" is a famous passage from William Shakespeare's Romeo and Juliet. Juliet's point is that she'd love Romeo just the same even if he wasn't from the house of Montague, rivals to her own house Capulet. We use it now in much the same way to mean that the name of something doesn't really affect its intrinsic properties. Such is the case with the SAS Compute Server and the new pod-naming convention we have today.
Background
The SAS Programming Runtime Environment (SPRE) provides several routes to access the legacy SAS runtime to submit and run SAS program code. The SAS Compute Server is often the most familiar as it's utilized by SAS Studio and other front-end applications. But there are also the SAS/CONNECT and SAS Batch variations that are useful for a variety of other use cases. In general, however, many of the concepts that apply to one SPRE engine can often be very similarly applied to the others.
It's a multi-step process on the backend to go from a user logging into SAS Studio to the creation of a SAS Compute Server running in the Kubernetes cluster. And if you want to understand that a bit better, I recommend Edoardo's post, SAS Programming Run-Time Architecture with SAS Viya 4. In particular, this passage is key:
Clients interact with SPRE services (SAS Compute service, SAS/CONNECT spawner, SAS Batch service), which all use an intermediate SAS Launcher service to start the back-end servers, thanks to SAS Launcher integration with Kubernetes API.
The old naming approach
So the convention for a while now has been that SAS Viya names the SAS Compute Server (and other SPRE servers like CONNECT and Batch) with the prefix "sas-launcher-" because the SAS Launcher service was instantiating it. But, as you can imagine, that was a little confusing when you wanted to bring up a list of pods running in your Kubernetes cluster to find many named very similarly. For example, in SAS Viya at LTS-2022.1 environment where I've got several SAS Compute Servers actively running:
$ kubectl -n viya get pods | grep launch
sas-launcher-0514c5b7-49e3-4ef7-b34a-6915fe88a14c-13913 2/2 Running 0 83m
sas-launcher-05359b91-7588-40f5-bbeb-743f6f1cbbc9-13910 2/2 Running 0 85m
sas-launcher-0e9304e8-c3bf-4e27-9ac0-212d81b5cea3-11770 2/2 Running 0 9d
sas-launcher-13f5af67-8229-47f0-b162-104308f483b2-13908 2/2 Running 0 85m
sas-launcher-5e717369-f1af-4296-a171-fd50e2461747-13920 2/2 Running 0 61m
sas-launcher-63c258a8-9627-46b9-baac-20be9b6fd9b2-13916 2/2 Running 0 64m
sas-launcher-6577d67864-49pf6 1/1 Running 0 59d
sas-launcher-79e7ff2f-5f55-4250-a254-318817115e66-13911 2/2 Running 0 83m
sas-launcher-7ad6e1dc-786f-4819-91e2-56c9a1ed58de-13912 2/2 Running 0 83m
sas-launcher-7e3bfb13-5ff3-4611-a86c-2edd684765b7-9644 2/2 Running 0 18d
sas-launcher-ff1b2d42-db1b-4a2c-b6db-81c19323c476-13917 2/2 Running 0 64m
That's a lot of pods with the same name. And notice as well that there is one pod that's named slightly differently (shorter name) - that's the actual SAS Launcher Service - a SAS Viya microservice. And if you were to look closer at the Launcher Service's details, you'd see it's controlled by a Kubernetes ReplicaSet. The rest are all SAS Compute Servers - not microservices! After you're familiar with this, it's not too confusing once you know what you're looking at - but with recent updates to SAS Viya, we now have a better naming convention to make it easier...
Putting a new name to a familiar service
With the latest releases of SAS Viya, we have a new naming convention employed for the SAS Compute Server - and that's basically to prefix the pod with "sas-compute-server-" (or others as apropos). Here's a list of SAS Viya at Stable-2022.10 pods in the cluster, showing only the ones with "launch" or "compute" in the name:
$ kubectl -n viya get pods | egrep "launch|compute"
sas-compute-5b79c67795-n2zvv 1/1 Running 0 20h
sas-compute-server-02420a0b-e0ab-42b0-9f35-d398f5451d28-pfwpf 1/1 Running 0 5m10s
sas-compute-server-3a23f6c7-a5c6-406a-b573-98305fce3be9-v58vs 1/1 Running 0 6m10s
sas-compute-server-665f8de9-70d5-40a9-a25c-25f8490c09e6-j4d9z 1/1 Running 0 6m11s
sas-compute-server-6d04f316-bd18-4bce-825c-88f664b285e3-2kgdj 1/1 Running 0 6m11s
sas-compute-server-d6c963d0-1a47-41df-9389-3dbae308220e-58qhg 1/1 Running 0 5m5s
sas-compute-server-e74372c6-9ddf-4203-8970-e35a014e6051-npgkk 1/1 Running 0 5m10s
sas-compute-server-f00b0b88-e0af-4b20-800d-99282fe1144b-mqdc4 1/1 Running 0 6m10s
sas-compute-server-f8975f24-c684-4398-87cd-f2b084700a13-pcvds 1/1 Running 0 6m11s
sas-launcher-74c59fbb64-2plc9 1/1 Running 0 20h
The SAS Launcher Service is still there - but now the SAS Compute Servers are more easily recognizable. Notice that with the modified grep, we also see the SAS Compute Service listed as well (with the shorter name).
This same concept extends to the SAS/CONNECT services of the SPRE as well. As an example, using the Grid Signon capabilities available in SAS Viya (see the gridsvc_enable statement), we can submit SAS/CONNECT code to fire up a new instance of SAS to run a parallel job. The resulting pod has a descriptive name in Kubernetes:
$ kubectl -n viya get pods | grep grid
sas-grid-enabled-server-552f2693-cc67-4ecd-8263-b37fe7ee61cgwz4 1/1 Running 0 10s
Sidebar: You might be wondering why "grid" is mentioned in the pod's name. At this point, it's not a reference to SAS 9.4 Grid Manager, nor is it a reference to the Viya equivalent SAS Workload Orchestrator. You no longer need a dedicated grid provider to use the gridsvc_enable statement for parallel job activity in SAS Viya. So "grid" here is really just a nod to the general idea of grid computing as SAS/CONNECT demonstrates it.
We can see the naming approach applies to SAS Batch services of the SPRE, too. After using the sas-viya CLI to submit a batch job and checking on the pods:
$ kubectl -n viya get pods | grep batch
sas-batch-69d78f7c7-pkjnm 1/1 Running 0 42h
sas-batch-server-1bba3ffe-2d4a-4c3e-bf45-8e833df747b9-w6m7s 1/1 Running 0 12s
In particular, the "sas-batch-server" is our SAS program running in batch. The other pod named "sas-batch" is the SAS Batch micro service that's picked up by the grep parameter.
Wrapping up
A small, non-HA deployment of SAS Viya at idle will have around 150 pods running. Hundreds more could be running for large, active, highly available deployments of SAS Viya. Finding the pods that are doing the jobs you're looking out for is now quite a bit easier with SAS Compute Servers getting a new naming convention based on their invocation task.
Find more articles from SAS Global Enablement and Learning here.
