Kubernetes v1.22, what is the impact for SAS Viya ?

2 Likes

You might have heard or read that: "Kubernetes is the new OS."

You may agree or not, but while it is not technically true (Kubernetes still rely on Hosts running Operating Systems such as Linux), the underlying Host OS has become a secondary consideration for SAS Viya.

It is because anyone who deploys or maintain it, instead of working at the OS level, now only interacts with Kubernetes in 99% of the cases.

The same way, modern IT is evolving from a BareOS to a Cloud native model, SAS has historically evolved from a Multi-Vendor Architecture (MVA) platform - with a long list of supported Linux, UNIX and Windows Operating systems - to a Kubernetes-only platform with SAS Viya.

One of the big differences between Kubernetes (compared to traditional Operating systems) is the speed at which it is evolving.

Kubernetes has 3 minor releases a year with only 1 year of patch support provided.

As the Kubernetes API evolves, APIs are periodically reorganized or upgraded. When APIs evolve, the old APIs are deprecated and eventually removed. So it is possible that something that was running on Kubernetes 1.18 will not run anymore on 1.22...

In addition, 3^rd party tools required by SAS Viya (cert-manager, ingress NGINX, etc…) also need to be considered as their version might be deprecated with newer Kubernetes versions.

The key point here is that the range of supported Kubernetes versions depends on the Viya version and keeps changing.

Last month, a new version of Viya : stable 2021.2.4 has been released. It was the first version to support Kubernetes v1.22 and NGINX Ingress Controller v1.x.x.

This Kubernetes version comes with significant changes that impact our Viya platform, that’s what we will discuss in this blog.

Most of the content presented here comes from Holden O'Neal and Heather Hewlett and I’d like to thank them for their hard work.

Kubernetes v1.22 API Deprecation

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

The Kubernetes 1.22 brings two specific challenges:

The removal of several API group versions that impact SAS Viya's deployment on Kubernetes. The full list of API group versions removed in Kubernetes 1.22 can be found here
Due to the level of change surrounding the Kubernetes v1.22 release, a more recent release of cert-manager and NGINX Ingress Controller are required.

A major concern was flagged for customers who use SAS provided Postgres instance (aka "SAS Crunchy") as the underlying database for the SAS Infrastructure Data Server.

It was because before Viya 2021.2.2, the Crunchy Postgres CustomResourceDefinition (CRD) used the v1beta1 Kubernetes API. But a revised Crunchy Postgres CRD using Kubernetes API v1 is has been introduced since.

The changes to use a Crunchy version with the V1 API by default were completed for this new Viya version 2021.2.4.

Dependencies

Something important to understand is that you DO NOT HAVE to run specifically Kubernetes v1.22 to support the new stable version of Viya 2021.2.4.

However, Viya 2021.2.4 is not be supported on Kubernetes 1.19…., so let’s have a look at some support tables/matrix to clarify things.

Heather Hewlett (from SAS) put together the two tables below which nicely show the dependencies.

The "Viya Support matrix" shows that to move to 2021.2.4, we need to run at least Kubernetes 1.20. Also, we can see that 2021.2.3 & earlier, Viya versions (Stable and LTS) cannot work with K8s v1.22 or Ingress Nginx 1.x.x.

Now the Kubernetes Support Matrix is also very interesting: it shows that if the customer is running Viya in his cluster and is planning to move to Kubernetes 1.22, then he will also have to upgrade his NGINX version (and potentially the Cert-manager version as well).

Talking about customer scenario we can see that, depending on the kind of update that the customer is planning (Viya version, Kubernetes version, 3rd party tool version), the constraints can be different...not only the constraints but also the steps and their sequence...

Customer scenarios

The diagram below shows the sequence of steps that were tested by SAS with success in three customer scenarios :

SCENARIO 1: I'm a customer who has Viya and my company wants to run on K8s 1.22.
SCENARIO 2: I'm a customer who has Viya and my company wants to run on ingress-nginx v1.x.x
SCENARIO 3: I'm a customer who has Viya and my company wants to run a new release of Viya

As you can see, depending on the source environment situation, different actions are required before being able to update the Viya and Kubernetes versions. Remember that upgrading the Ingress and Kubernetes cluster versions is the customer responsibility.

If a Cloud Managed Kubernetes service (such as AKS, GKE or EKS) is used, it is usually quite easy. Note that some Cloud providers (such as GCP) will by default be automatically upgraded to supported Kubernetes versions.

Now we have the two other scenarios, but the steps are almost the same.

Multiple versions of Viya in the same K8s cluster

Finally, there is another "special" case where this change in the crunchy API introduce an important requirement : it is when you run different versions of Viya in different namespaces within the same Kubernetes cluster.

As described in the previous diagrams, there is a specific question and an additional step to perform in case you are running multiple versions of Viya with the SAS crunchy postgres : You need to make sure they are all updated to 2021.2.3 before starting to move to 2021.2.4. If you don’t do that, then you will break the older Viya environments.

The reason for this requirement is that the sas-crunchy CRD (Custom Resource Description) is shared by all deployments in the same k8s cluster. So, updating one of the Viya deployments to use the new v1 CRD, would lead the rest of the Viya deployments to stop functioning because of the changed CRD.

So, for example having both the current LTS (2021.2 as of February 2022) and stable coexisting on the same cluster won’t work anymore. However when LTS 2022.1 is released, it will be able to be deployed in the same cluster as a recent stable version - since the new LTS it will be based on 2021.2.5 (which will also uses the crunchy v1 API).

As a summary:

Deploying separate instances of SAS Viya in different namespaces the cluster is possible if they have the same cadence version. If not, then it might not be possible.

Note that this caveat was added in the official documentation FAQ

Conclusion

The large scope of changes in K8s v1.22 has had a cascading effect on the Viya code base and 3rd party tools it is dependent on. This serves to highlight the level of dependence and imbrication of Viya 4 with its eco-system.

When you are in one of the scenario described above (update to Viya stable 2021.2.4, update the Kubernetes cluster to 1.22 or update the ingress NGINX version), keep an eye on potential issue related to 3rd party tools versions.

It is not only the deployment process itself that is impacted by a customer move to Kubernetes v1.22, but the whole ecosystem of SAS Viya (Viya ARK, IaC/DaC projects, Viya monitoring and logging, orchestration-cli etc...).

The integration of SAS Viya with Kubernetes and the related 3rd party software (NGINX, cert-manager, crunchy, Opendistro, Redis, etc...) is a key consideration and challenge, not only for the setup, but also for the long-term maintenance.

Thanks for reading ! and special thanks to Holden O'Neal and Heather Hewlett for their review and contribution to this blog post.

Find more articles from SAS Global Enablement and Learning here.