Should I update Viya first or upgrade Kubernetes first to remain supported ?
The interdependence between SAS Viya and the Kubernetes platform versions with each of them having different release lifecycles can sometimes be problematic.
To add to the fun, SAS Viya uses the term "update" to indicate moving to the next cadence version whereas Kubernetes uses the term "upgrade" to indicate moving to the next minor release version. ☹️
If you move to a Kubernetes version without paying attention to the Viya LTS version that you are running, you may find yourself out of SAS support. And conversely if you move to a new Viya version without taking care of the Kubernetes version you could end up being out of Kubernetes support…
This dashboard below should gives you an idea of the release cycle for both platforms…
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
However the fact that, at a given time Kubernetes version "A" and SAS Viya version "B" are both supported individually does not mean that this SAS Viya version "B" is supported for this specific Kubernetes version "A" (remember that each SAS Viya version is only supported for 3 Kubernetes versions).
In this post, we want to remind some important guidelines to ensure that you remain on a "supported update path" and we also explore a very "real" customer use case of "mixed versions deadlock" I have been recently facing and see how we could address it 😊
The "Kubernetes upgrade workflow" for SAS Viya
The good news is that SAS is aware of this strong dependency between the SAS Viya and Kubernetes versions and release lifecycles and, as a result, provides specific, detailed and frequently maintained documentation to help customers deal with it.
I particularly like this table (available in the Virtual Infrastructure Requirements section of the SAS documentation), where you can see the versions dependencies between SAS Viya and Kubernetes at a glance:
You can immediately understand from the table that: whether you decide to update either SAS Viya or upgrade Kubernetes to its next version, you may also have to make a change to its counterpart to remain supported.
As an example, imagine a customer running SAS Viya LTS 2024.09 on the extended support version of AWS EKS (Elastic Kubernetes Service) 1.28 and in June 2025, they decide to update to the latest SAS Viya LTS 2025.03. From the table above, we can see that they also need to move to EKS 1.29 (at least) to remain supported.
But in this case, which platform should I perform first? SAS Viya or EKS ?
The "Kubernetes upgrade workflow" section of the SAS documentation addresses this very question!
It corresponds to scenarios that are regularly tested by SAS and covers 3 different situations (that I have tried to summarize in the table below) which correspond to different assumptions and conditions.
|
Scenario: |
S1-Upgrade Kubernetes without updating the SAS Viya platform.
|
S2-Update the SAS Viya platform and upgrade Kubernetes in the same time frame.
|
S3-Update the SAS Viya platform and upgrade Kubernetes in the same time frame. |
|
|
Assumption: |
The target Kubernetes version is supported for your current SAS Viya version. |
Your current Kubernetes version IS NOT supported for the newer release of the SAS Viya platform to which you are updating |
Your current Kubernetes version IS supported by the newer SAS Viya release. |
|
|
Condition: |
Make sure that your target Kubernetes version is supported by BOTH the currently deployed version of the SAS Viya platform and the newer version to which you plan to update. |
Make sure that target Kubernetes version is supported by the newer SAS Viya version to which you plan to update |
||
|
Steps: |
1. Viya Backup 2. Stop All Viya services 3. Upgrade the Kubernetes cluster to a supported version. 4. Verify dependent components versions (ingress-nginx, etc.) 5. Restart All Viya services |
1. Viya Backup 2. Stop All Viya services 3. Upgrade the Kubernetes cluster to a supported version. 4. Verify dependent components versions (ingress-nginx, etc.) 5. Restart all SAS Viya platform services. 6. Update the SAS Viya platform software.
|
1. Viya Backup 2. Update the SAS Viya platform software 3. Stop All Viya services 4. Upgrade the Kubernetes cluster 5. Verify dependent components versions (ingress-nginx, etc.) 6. Restart all SAS Viya platform services. |
|
The game here is to determine in which scenario you are, based on the customer’s current versions of Kubernetes/SAS Viya and their upgrades/updates plans.
So back to our example : "a customer running SAS Viya LTS 2024.09 on the extended support version of AWS EKS 1.28 and they want to upgrade to the latest SAS Viya LTS 2025.03."
So, if you look at the version and scenario tables above (or simply at the 3 bullet points in the official documentation), in which scenario would they be ?
Take your time to see if you could find the answer and solve this puzzle 😊
It is not always immediate and requires a bit of logical thought.
OK...I’m sure you have found the answer : Yes, they could be in scenario S1 or S2. Because they meet the assumptions and conditions for both scenarios.
So they can either decide to separate the 2 operations : first upgrade to EKS 1.29 or 1.30, then update SAS Viya (S1) OR they can decide to upgrade Kubernetes and update the SAS Viya platform in the same time frame (S2).
The Kubernetes upgrade workflow really helps to follow the upgrade and update steps in the right order, ensuring that the customer remains in the "Standard Support" situation the whole time.
However, there can be some special situations where your customer’s use case does not fit in any of the described scenarios ☹️…we’ll talk about that in the last section of the post.
The need to find the common k8s version between Viya LTS N and Viya LTS N+1
There is one key condition to remain on the "supported update path" that is not clearly spelled out in the documentation but is very important to understand :
When you upgrade Kubernetes to a new version, it is imperative that the target Kubernetes version is supported with your current and future Viya version.
In other words, when looking at the version table (above) you must identify a target Kubernetes version that is supported across your current and future Viya versions…the target Kubernetes version must be in common for the Viya N and Viya N+1 versions.
For example, if you were on Viya LTS 2024.03 with Kubernetes 1.27, you could not move to Kubernetes 1.28 then 1.29 without updating SAS Viya. You would need to go first to Kubernetes 1.28, then update the Viya LTS version to LTS 2024.09 and then upgrade Kubernetes to 1.29. That’s the only way to remain supported during these operations.
As we can see in the table, if there was a "2-steps" move from 1.27 to 1.29 without updating SAS Viya at the 1.28 milestone, they we would be running Viya LTS 2024.03 on K8s 1.29 (which is not supported).
An interesting customer use case
The context
Here is a bit of background information, provided by our customer (a bank in Germany testing SAS Viya in a development environment before moving to production) :
Setup/Use case:
- Deployment on OpenShift
- OpenShift Platform is managed by another Team
- Update-Strategy of OpenShift-Platform:
- Only update every second (even) release
Example to illustrate the problem:
- OpenShift version 4.14 installed
- LTS 2024.03 supports OpenShift versions 4.13.x - 4.15.x (SAS Help Center: Platform-Specific Requirements)
- LTS 2024.09 supports OpenShift versions 4.15.x - 4.16.x (SAS Help Center: Platform-Specific Requirements)
- OpenShift version is being upgraded to 4.16. What are we doing with SAS Viya?
- We cannot update to LTS 2024.09 after the upgrade (2024.03 unsupported - with 4.16) and not prior to the upgrade (2024.09 unsupported - with 4.14).
Some observations on the customer requests
OK... so first a few remarks on this information provided by the customer.
- First of all, they are running SAS Viya on the Red Hat OpenShift Container Platform (OCP). In OpenShift, the version scheme is a bit different: we talk about versions 4.x while in the standard opensource Kubernetes we use versions 1.x.y. However OCP is built on Red Hat Enterprise Linux (RHEL) and Kubernetes. We know, for example that OCP 4.17 uses Kubernetes 1.30, OCP 4.18 uses Kubernetes 1.31 and so on…
- Then we can also notice that the customer is well aware of the requirement to remain in a "supported" situation at all times. Their last comment leads us to think that they are already aware of the documented "Kubernetes upgrade workflow".
- While it is not technically possible to directly upgrade from OCP 4.14 to 4.16 (just like for the standard Kubernetes versions, you cannot skip OCP versions when upgrading their software. It would be a violation of the upgrade policy for kubeadm as explained in the IBM documentation there), the customer explained that the team in charge of the OCP cluster would not allow other operations while they perform the upgrade operations and would only reopen and expose the cluster once moved to the N+2 version (4.16, 4.18, 4.20 etc.).
- The underlying reason of that policy is that Red Hat OpenShift "Extended Update Support" (that we generally recommend for customers choosing the SAS Viya LTS cadence) is only available for "even" version.
We can clearly see it in the OCP Life Cycle table below :
As noted in the OpenShift documentation, "Red Hat denotes all even numbered minor releases (eg 4.8, 4.10, 4.12) as Extended Update Support (EUS) releases".
This explains why the customer’s OpenShift strategy is to only work with "even" versions.
The bad and good and bad news…
First, to ease our life, let’s build the same supported K8s version tables but with the addition of OCP version :
|
SAS Viya Platform Version |
Supported Versions of Kubernetes |
Supported version of OpenShift |
|
2025.03 (LTS) |
1.29, 1.30, 1.31 |
4.16, 4.17, 4.18 |
|
2024.09 (LTS) |
1.28, 1.29, 1.30 |
4.15, 4.16 |
|
2024.03 (LTS) |
1.26, 1.27, 1.28 |
4.13, 4.14, 4.15 |
|
2023.10 (LTS) |
1.25, 1.26, 1.27 |
4.12, 4.13, 4.14 |
As explained in the second section of the post, our "Kubernetes Upgrade workflow" assumes that there is, at least, one OCP version in common between the source LTS version and the target LTS version...
As we can see on the table above, between LTS 2024.03 and LTS 2024.09 there is only ONE common version, which is OCP 4.15 - however since the "odd" version of OCP were not exposed to the customer team they could only have either 4.14 or 4.16 - so the "supported update path" was not available for them !
After talking a little bit more with the customer though, we understood that they were able to manage the situation and update to Viya LTS 2024.09 (although they were on an "unsupported update path") in their Test environment but before going into production environment, but they were now asking if they will have this problem again...
So first there is a SAS R&D initiative where the plan for the future is to always provide support for 3 OCP versions in our Viya LTS releases (unlike what happened with 2024.09).
Here is a little projection of what OCP versions are planned for the future:
There is one good news here : The customer should not face this issue again for their next Viya updates to LTS 2025.09 and then to LTS 2026.03 (because each time there is an "even" version in common between their current and target version).
However … we can, unfortunately, also see that: while there will always be common OCP versions and bridge each Viya LTS release, there will NOT always be the "even" numbered ones.
It's not possible to always have the OCP "even" version in common, given that Viya LTS releases 2x a year and K8s releases 3x a year. The math would not work out for that… ☹️
What are the alternatives?
So the only real solution, in order to always remain on the supported path, would be to ask for an exception to the customer’s standard process in order to be able to perform the SAS Viya update between the move from the odd release (ex: 4.21, 4.23 in the table) before upgrading to the even "EUS" version…
Another smart suggestion from a colleague is to dive a little bit more in the details of the Viya update operation and to break the steps as below:
- Perform the "Before Deployment Commands" steps from the "Deployment notes" in the source environment: (ex: LTS 2026.03 in OCP 4.20),
- then stop SAS Viya,
- perform the OCP cluster upgrade (ex: from 4.20 to 4.21 then to 4.22),
- then get the new deployment assets and re-deploy SAS Viya (ex: LTS 2026.09 in OCP 4.22),
- restart the Viya platform
- and finally perform the "After Deployment Commands"...
Technically it would avoid being in the situation where we would run a SAS Viya version in a non-supported version of OpenShift...However it is not really one of the listed options in the "Kubernetes Upgrade Workflow"…
The caveats of this plan are the following:
- This update scenario has never been tested by SAS.
- If there is an issue with Viya at the end, then it will be hard to know if it's coming from the OCP upgrade or the Viya update…many things could go wrong (for example with 3rd party tools versions incompatibilities).
As a summary the problem describe here is caused by the quite unique way the Extended Support is handled in OCP (only "even" versions)...each SAS LTS version has support for 3 Kubernetes version but unlike RedHat, SAS does not limit support to our even versions.
But unfortunately, as it sometimes happens, there is no magic silver bullet to solve this specific customer issue… But at least there are options to try.
That’s it for today, hopefully this little post gave a useful illustration of the potential challenges of intricate K8s upgrade/Viya updates operations and how to deal with them.
Find more articles from SAS Global Enablement and Learning here.
