A new Ingress Controller for SAS Viya

[#1]

TL;DR : The SAS Viya platform requires an Ingress Controller to route network communications to services. Up until recently, only the ingress-nginx project was supported in this role, but it has reached EOL in March 2026 (no further release, no bug-fixes, no updates to fix CVEs) – As a consequence, from version 2026.02, SAS Viya supports Contour ingress controller 1.31.0 and later as the new recommended Ingress Controller.

So what does it mean for your SAS Viya environment ? Well...let me break it down for you in this post 🙂

Note: A small FAQ section is also provided at the end of this post to answer most common questions expected for this change.

The SAS Viya platform relies on a few open-source Kubernetes "third party" components to allow the software to be operational.

An "Ingress Controller" is one of them.

Its role is to allow end-users located outside of the Kubernetes cluster to be able to access the applications running inside the cluster (and there are already a bunch of posts which detail how it works and how it is configured for SAS Viya – you could start with this one).

 Since the release of SAS Viya 2020.1, only one specific implementation of the Ingress Controller was supported with SAS Viya on most of the Kubernetes platforms (Azure AKS, Amazon EKS, Google GKE, Upstream opensource) : the ingress-nginx project (not be confused with the F5 NGINX Ingress Controller).

However a few months ago, for various reasons (The Kubernetes community is now pushing the "Gateway API"  as the new implementation standard) the ingress-nginx project's End Of Life (EOL) was announced for March 2026.

This post discusses the replacement of the ingress-nginx Ingress Controller and the impact for your SAS Viya deployments.

Here is a little ToC to help you naviguate 🙂

• Good bye ingress-nginx, Hello Project Contour!
• Official Support in SAS Viya
• Contour requirements
  • • Versions
    • Other Requirements
• How to install Contour?
• What are the impacts of using Contour?
  • SAS Viya configuration changes
  • Switching to Contour in an existing Deployment
  • Other impacts
• Conclusion
• FAQ
• References

Good bye ingress-nginx, Hello Project Contour!

The ingress-nginx public GitHub repository has now been archived.

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

As soon as its retirement was decided and announced on the Kubernetes project page, SAS started to look into a replacement solution. It is understandable and was expected that customers would prefer to stop using a 3^rd party tool that is no longer maintained...

From January 2026, official communications were published on the SAS Communities to inform them that SAS was actively working on a solution to allow the SAS Viya platform to operate without the ingress-nginx component.

In the following updates of the communities page, the replacement solution (Contour Ingress Controller) and the plan to release and implement this alternative solution was added in the announcement.

Project Contour is a very popular and "CNCF certified" open source Kubernetes Ingress Controller. It provides a high performance L7 proxy and load balancer.

From an architecture standpoint, the Contour Ingress controller is a collaboration between:

• Envoy, which provides the high performance reverse proxy.
• Contour, which acts as a management server for Envoy and provides it with configuration.

These containers are deployed separately, Contour as a Deployment and Envoy as a Kubernetes Daemonset or Deployment.

You can learn more about Contour and its architecture here.

Official Support in SAS Viya

Since the 2026.03 version release date (March 20^th), SAS provides Standard Support for Contour for all Stable and Long-Term Support (LTS) releases of the SAS Viya platform and software offerings in Standard Support at that time.

It means that, for example, if a customer is running LTS 2024.09 or stable 2025.12 (still supported at the time I'm writing this post) they can change their Ingress Controller to "Contour" while applying a patch update.

For environments that keep ingress-nginx as their Ingress Controller, the SAS Viya platform will continue to be in Standard support (from the SAS standpoint), until Stable 2027.03 and Long-Term Support 2027.03. However, neither SAS nor the Kubernetes community will address bugs or security issues for that component. Organizations continuing to use ingress-nginx after March, 2026 will do so at their own risk…

For customers ready to switch to Contour, SAS provides instructions under the "Changing Ingress Controllers" section of the official documentation.

Contour requirements

Versions

Just like with the ingress-nginx project, there are different versions and the Contour version determines the version of the Kubernetes the software is compatible with.

The Contour documentation offers a "compatibility matrix" page , see below an extract of the table.

As of April 2026, the required version of Contour for SAS Viya is 1.31.0 and later.
From the table above we can see that this range of version can make Contour compatible with Kubernetes from version 1.30 to 1.34.

In case we want to install Contour with Helm, we need to provide the Helm chart version that corresponds to the Contour version…the table below (available from https://artifacthub.io/packages/helm/contour/contour ) shows this mapping between the versions.

Other Requirements

When using Contour (Envoy) as the Ingress Controller, HTTP compression is enabled by default. This behavior causes failures in Viya services that use strong ETags, resulting in incorrect request handling. In ingress‑nginx gzip compression is disabled by default.

While a longer-term fix has been identified (standardize all the SAS Viya services on "Weak" Etags, compatible with compression) and is being researched, the near-term solution, to avoid customers failures is to disable the gzip compression in Contour.

As a consequence, the compression must currently be disabled as noted in the SAS Documentation, in the Contour configuration. Specifically, the algorithm field must be set to "disabled" (by default, it is set to "gzip"), we'll see an example soon.

How to install Contour?

There are many ways to install the Contour (Envoy) Ingress Controller.

Here is the script that we use to manually install, configure and check it on Upstream Open-source Kubernetes in the GEL SAS Viya Deployment Workshop's hands-on (not published yet – planned to be released after LTS 2026.03):

kubectl create ns projectcontour
# Install the Helm repo
helm repo add contour https://projectcontour.github.io/helm-charts/
helm repo update
# Install the ingress controller (Contour)
# We install it in HA mode
CONTOUR_Version="0.2.1"
helm install  contour --namespace projectcontour \
    --set contour.resourcePreset=small \
    --set envoy.resourcePreset=small \
    --set envoy.shutdownManager.resourcesPreset=small \
    --set envoy.autoscaling.enabled=true \
    --set envoy.autoscaling.minReplicas=2 \
    --set envoy.autoscaling.maxReplicas=5 \
    --set envoy.autoscaling.targetCPU=90 \
    --set envoy.autoscaling.targetMemory=90 \
    --set envoy.service.externalTrafficPolicy=Cluster \
    --version ${CONTOUR_Version} \
    contour/contour

kubectl wait -n projectcontour --for=condition=available  --all deployments --timeout=60s

# SAS recommands to disable the compression
kubectl get cm contour -n projectcontour -o jsonpath='{.data.contour\.yaml}' | yq '.compression.algorithm = "disabled"' | jq -Rs '{"data":{"contour.yaml": .}}' | kubectl patch cm contour -n projectcontour --type merge --patch-file /dev/stdin

kubectl -n projectcontour rollout restart deploy/contour-contour

# Wait for external IP to be assigned
while [[ $(kubectl -n projectcontour get svc contour-envoy -o 'jsonpath={..status.loadBalancer.ingress}') = "" ]] ;
    do logit "***** Waiting for Contour External IP *****"
    sleep 5;
done

kubectl get svc -n projectcontour

Here are some observations on what we are doing here.

• We use Helm as the deployment tool. We use the "set" flags instead of a "values file" to set the Contour parameters – see this page for a list of Contour parameters.
• We install the Contour helm chart in version "0.2.1" which corresponds to the version "1.33.1" of Contour (which is compatible with the SAS Viya requirement 😊).
• The resourcePreset flags act as shorthand templates for CPU and Memory requests and limits. Instead of manually defining every millisecond of CPU or megabyte of RAM, the Contour maintainers have defined standard "buckets" (like small, medium, and large). We also define some autoscaling parameters and set the number of replicas (with a minimum of 2 for higher availability).
• The service.externalTrafficPolicy differs depending on the Cluster implementation. While most of the time, the externalTrafficPolicy entry is "Local" (it is the default value in the project contour Helm Chart and in the viya4-deployment project), we set the value to "Cluster" here because it is a specific requirement when we deploy in the Upstream open-source Kubernetes with "kube-vip" providing the virtual IP and load-balancer.
• By default the type of the Envoy service that is created is "LoadBalancer", however it is possible (if preferred or needed in on-premise environments) to generate a "NodePort" service type  (NodePort http and https can be set explicitly in that case with envoy.service.nodePorts.http and envoy.service.nodePorts.https Helm parameters)
• As recommended by SAS (and noted in the official documentation), we also disable the compression with a "patch" command.

Keep in mind that, as explained above, the provided example is relevant for an installation of Contour in an on-premise Upstream Open-source Kubernetes platform (with “kube-vip”).

However in Public Cloud environments, additional annotations could be required, to allow inbound connections from specific Cloud services (for example from Entra ID in Azure when SCIM is configured).

Here is an example of additional flags that could be needed in Azure:

--set-string envoy.service.annotations."service\.beta\.kubernetes\.io/azure-allowed-service-tags"="AzureActiveDirectory" \

--set-string envoy.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"="/healthz" \

--set-string envoy.service.annotations."service\.beta\.kubernetes\.io/azure-allowed-ip-ranges"="<an IP Range>" \

Note that if you use the viya4-deployment project to install the SAS Viya pre-requisites, Contour is now installed by default as of Release v9.5.0.

What are the impacts of using Contour?

SAS Viya configuration changes

A few changes are required in the kustomization.yaml file to make the SAS Viya components use Contour instead of ingress-nginx and are described in this page.

Generally, you simply need to remove or comment 2 lines that reference "ingress-nginx based" configuration files and add the references to the "contour-based" configuration files.

See below an example with full-stack TLS (without the use of cert-manager to generate the certificates).

 

Switching to Contour in an existing Deployment

If have already a running SAS Viya environment and you need to change the Ingress Controller from "ingress-nginx" to "Contour" in an existing SAS Viya Deployment, there are two things to do:

1) The very first thing to do is to make sure you have the deployment assets with the Contour support. You can either update to SAS Viya 2026.02 or later or apply a patch updates

It is critical : a customer can only switch to Contour if recent deployment assets (2026.2 or patch updates) have been applied in their environment.

2) Then you'll need to implement and apply the configuration changes in the Kustomization.yaml file (reference).

You can either apply the "patch update" and kustomization changes at the same time or apply the latest patches first and then make the modifications for kustomization.yaml and redeploy in a second step. You could even take the opportunity of a Viya version update operations to make the Ingress Controller change.

To makes these changes a redeployment of the software is required (that's why it is often better to group them with an update operation). The redeployment implies reapplying a newly generated site.yaml manifest. The exact process and steps depends on the deployment method.

While the redeployment is usually pretty transparent for the end-users (thanks to the Kubernetes pod’s rolling update and the default HA configuration of the StatefulSets), a restart of CAS server is also needed.
Stopping CAS means dropping all the “in-memory” data and restart new CAS pods and (then likely reload them with data). It could cause an outage that may be noticeable for the end users, so you need to make plans accordingly.

Before making these changes, it is expected that you have installed Contour in the Kubernetes cluster (and likely uninstalled ingress-nginx).

The switch of Ingress Controller may also lead to a change in the external IP address (or external CNAME in AWS) associated to the LoadBalancer service.

For example, before the switch, looking at the service object in your ingress-nginx namespace (kubectl get svc), you can see that your Ingress Controller load-balancer service is associated to a given external IP address:

But after installing Contour, you would realize that a different external IP address has been created and associated to the "load-balancer" service:

In such case, it means that you'll need to update your DNS alias to make sure that the URL, typed by the end-users, in their web browser send them to the new endpoint 🙂

In a Cloud-based environment, when you install Contour (as shown above), by default an external IP address is automatically found and assigned. However, you can also "preset" the IP address to a static or reserved value (with the contour.service.loadBalancerIP parameter)…which ensure the DNS record does not have to be updated.

Other impacts

The main change that you will see, with Contour, in your SAS Viya deployment is that: instead of having a hundred or more Ingress objects in the SAS Viya namespace, you will have a hundred or more HTTPProxy objects.

You may have written some scripts that relies on the ingress objects, for example to generate the SAS Web applications URLs.

Something like that, maybe :

NS=lab
LANDING_URL="https://$(kubectl -n ${NS} get ing sas-landing-app -o custom-columns='hosts:spec.rules[0].host' --no-headers)/SASLanding/"
EV_URL="https://$(kubectl -n ${NS} get ing sas-landing-app -o custom-columns='hosts:spec.rules[0].host' --no-headers)/SASEnvironmentManager/"
printf "\n* [SAS Landing (lab) URL (HTTP**S**)](${LANDING_URL} )\n\n" | tee -a /home/cloud-user/urls.md
printf "\n* [Viya Environment Manager (lab) URL (HTTP**S**)](${EV_URL} )\n\n" | tee -a /home/cloud-user/urls.md

Well... I'm sorry but after the move to Contour, this code snippet would not work any longer ("kubectl get ingress" won't return any results)…

You'll need to rewrite it with something like  :

NS=lab
ROOT_PROXY_HOST=$(kubectl -n ${NS} get httpproxy sas-httpproxy-root -o jsonpath='{.spec.virtualhost.fqdn}')
LANDING_URL="https://${ROOT_PROXY_HOST}/SASLanding/"
EV_URL="https://${ROOT_PROXY_HOST}/SASEnvironmentManager/"
printf "\n* [SAS Landing (lab) URL (HTTP**S**)](${LANDING_URL} )\n\n" | tee -a /home/cloud-user/urls.md
printf "\n* [Viya Environment Manager (lab) URL (HTTP**S**)](${EV_URL} )\n\n" | tee -a /home/cloud-user/urls.md

Note, that unlike with ingress objects only one HTTProxy object (called "sas-httpproxy-root"), considered as the "root" HTTPProxy, holds the FQDN name and includes all the other proxies definitions.

Conclusion

Because it was very popular and widely used, the news of the retirement of the ingress-nginx open-source project  back in November 2025 came as a surprise and was immediately identified as a "high impact" change... (Not only for SAS Viya deployments but also for many software and cloud vendors!).

From this announcement, SAS worked tirelessly to bring a robust replacement solution and limit the impact of this changes on our customers. At the date of the ingress-nginx project's effective deprecation (March 2026), new deployments can be done with Contour (instead of ingress-nginx), and every customer already running a supported SAS Viya version can rely on a simple procedure, documented by SAS, to switch to Contour (see Reference section).

Annex 1 : FAQ

1. For an existing customer moving from ingress-nginx to Contour, is there an outage to plan?
2. Is my customer's SAS Viya Platform supported, even if they keep ingress-nginx for their Ingress Cont...
3. My customer is running an older LTS version, can they move to Contour ?
4. My customer has deployed SAS Viya on Openshift, are they impacted by this change?
5. Can I deploy both ingress-nginx and contour in the same Kubernetes cluster ?
6. Is the F5 NGINX Ingress Controller a supported Ingress Controller?
7. Can I use the new "Gateway API"  for my SAS Viya deployment?
8. Can I deploy a 3rd party tool that creates ingress if my Ingress Controller is Contour?

1.     For an existing customer moving from ingress-nginx to Contour, is there an outage to plan?

Yes. As noted above in the "Moving from ingress-nginx to Contour in an existing Deployment" section, it is necessary to restart the SAS Viya platform (including CAS) which can briefly impact the platform availability for the end-users. Also note that the external IP address routing user's requests to the web applications endpoints may also change.

2.     Is my customer's SAS Viya Platform supported, even if they keep ingress-nginx for their Ingress Controller?

Yes. As noted above, the customer's SAS Viya platform remains supported, even with ingress-nginx as the Ingress Controller, until Stable 2027.03 and Long-Term Support 2027.03. But customers will do that at their own risks (no vulnerability of bug fix will be provided).

3.     My customer has deployed SAS Viya on Openshift, are they impacted by this change?

No. On openshift, a different ingress technology is used (called openshift routes).

4.     My customer is running an older LTS version, can they move to Contour ?

At the time of this write-up, the 4 supported SAS Viya LTS versions are : LTS 2025.09, LTS 2025.03, LTS 2024.09 and LTS 2024.03. The customer can switch to Contour and apply a patch update in their existing deployment (same version but newer release) for all LTS version except the oldest one : LTS 2024.03. The reason is that LTS 2024.03 is only supported on Kubernetes versions 1.26 to 1.28 or RedHat Openshift 4.14. But except for Openshift, all the supported Kubernetes platforms running Kubernetes 1.26 to 1.28 have now reached EOL and since Openshift requires its own specific Ingress Controller (working with openshift routes), there is no supported Kubernetes platform for this Viya LTS version where Contour could run. 

5.     Can I deploy both ingress-nginx and Contour in the same Kubernetes cluster?

Yes, Kubernetes is designed to support multiple Ingress Controllers simultaneously. It's actually a common pattern for teams who need different features for different applications.

6.     Is the F5 NGINX Ingress Controller a supported Ingress Controller?

No. While the names are very similar,  NGINX Ingress is different from ingress-nginx…As of April 2026, only ingress-nginx or Contour are supported for SAS Viya deployments on the following Kubernetes platforms : Azure AKS, Amazon EKS, Google GKE, and Upstream opensource Kubernetes. For SAS Viya deployment on Red Hat Openshift, only only the OpenShift Ingress Operator (OCP routes) is supported.

7.     Can I use the new "Gateway API"  for my SAS Viya deployment?

At this time SAS Viya Platform does not support the Gateway API (new implementation standard in Kubernetes). Viya continues to use the Ingress API with a new Ingress Controller (Contour). The Gateway API may be supported in future SAS Viya versions, but there are no official announcements or commitments yet.

8.     Can I deploy a 3^rd party tool that creates and use ingress objects if my Ingress Controller is Contour?

Yes. For example  the official Harbor Helm chart doesn't have a "native" toggle to generate an HTTPProxy object, however we can either modify the Harbor helm chart to set the ingressClassName to "contour" (it stills create ingress objects) or even create our own HTTPProxy manifests to point to the Harbor services.

Annex 2 : References

• SAS Doc : Critical change: Ingress Controller
• SAS Doc : Cluster ingress requirements (2026.03)
• SAS Doc : Replacing ingress-nginx with Contour Ingress Controller

Find more articles from SAS Global Enablement and Learning here.