Si vous administrez ou déployez la plateforme SAS Viya sur KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya., vous savez à quel point le contrôleur Ingress est une brique critique : c'est la porte d'entrée qui gère le routage des communications réseau externes vers vos services internes. Jusqu'à récemment, le célèbre projet open source ingress-nginx était la seule implémentation supportée pour remplir ce rôle.
Mais le paysage de KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya. évolue. En mars 2026, le projet ingress-nginx a tiré sa révérence. D'ailleurs, si comme moi vous avez vu passer ce thread Reddit avec des DevOps en pleine crise existentielle face à la nouvelle, vous savez qu'on a frôlé la panique générale ! Face à cette fin de vie (EOL), SAS a heureusement pris les devants. À partir de la version 2026.02, Project Contour devient le nouveau contrôleur Ingress recommandé pour SAS Viya.
Voici tout ce que vous devez savoir sur cette transition architecturale majeure et comment la gérer sur vos clusters... avant de finir vous aussi en sueurs froides sur un forum.
Pourquoi abandonner ingress-nginx ?
La communauté KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya. pousse désormais vers un nouveau standard : la "Gateway API". Par conséquent, le dépôt GitHub public d'ingress-nginx a été archivé et la fin de vie du projet a été actée pour mars 2026.
Concrètement, cela signifie qu'il n'y aura plus de nouvelles releases, plus de corrections de bugs, et surtout plus aucun correctif de sécurité (CVE). Même si SAS continuera d'offrir un support de la plateforme Viya avec ingress-nginx jusqu'aux versions 2027.03 (Stable et LTS), conserver ce composant après mars 2026 relèvera de votre propre responsabilité. Un risque de sécurité majeur à éviter en production.
Bienvenue à Project Contour
Pour remplacer ingress-nginx, SAS a sélectionné Project Contour, un contrôleur Ingress certifié par la CNCF (Cloud Native Computing Foundation). Très performant, il fournit un proxy de niveau 7 (L7) et un équilibreur de charge robuste.
Sur le plan architectural, Contour fonctionne en tandem avec Envoy. Envoy agit en tant que reverse proxy haute performance, tandis que Contour lui sert de plan de contrôle (management server) pour lui injecter dynamiquement sa configuration.
Le prérequis versioning : SAS Viya exige actuellement Contour en version 1.31.0 ou ultérieure (compatible avec KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya. de 1.30 à 1.34).
⚠️ Le piège à éviter (La Compression Gzip) : > Contrairement àingress-nginx, Contour active la compression HTTP par défaut. Le problème est que cela fait échouer certains services Viya qui s'appuient sur des "ETags" stricts. La documentation SAS est claire : lors du déploiement de Contour, la compression doit être désactivée (algorithm: "disabled").
Comment réussir votre migration ? Quels impacts ?
Si vous devez faire basculer un environnement SAS Viya existant vers Contour, préparez-vous aux étapes suivantes :
1. Mise à jour de votre Kustomization
Il est impératif d'utiliser les assets de déploiement Viya 2026.02 (ou d'appliquer les derniers patches). Dans votre fichier kustomization.yaml, il suffira généralement de commenter les deux lignes faisant référence aux configurations basées sur "ingress-nginx", et de les remplacer par les références pointant vers Contour.
2. Une interruption de service à anticiper
Changer le contrôleur Ingress nécessite de régénérer le manifest site.yaml et de redéployer. Si KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya. gère les mises à jour des pods de manière fluide (rolling updates), le serveur CASMoteur analytique "in-memory" de SAS Viya. Il traite les données en parallèle (MPP) sur plusieurs nœuds pour offrir une puissance de calcul massive et une exécution ultra-rapide des actions. nécessitera quant à lui un redémarrage. Arrêter CAS signifie vider les données en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. vive. Les utilisateurs subiront une brève coupure, et les données devront être rechargées au redémarrage. Pensez à bien planifier votre fenêtre de maintenance !
3. Changement de l'IP Externe
La création du nouveau service de load balancing pour Contour (Envoy) risque de vous attribuer une nouvelle adresse IP publique ou un nouveau CNAME. Il ne faudra pas oublier de mettre à jour vos enregistrements DNS pour refléter cette nouvelle IP.
L'impact sur le requêtage KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya. : Ingress vs HTTPProxy
Avis à ceux qui ont automatisé leurs environnements ! C'est le changement technique le plus notable pour les DevOps : Contour n'utilise pas les objets Ingress standards de KubernetesKubernetes est l'orchestrateur open source gérant le déploiement, la mise à l'échelle et l'exécution conteneurisée des microservices de l'architecture cloud-native de SAS Viya.. Il s'appuie sur ses propres Custom Resource Definitions (CRD) nommés HTTPProxy.
Si vous aviez des scripts Bash/Python qui récupéraient dynamiquement les URLs de votre environnement web via les objets Ingress, ils ne retourneront plus rien.
Avant la migration :
2
kubectl -n lab get ing sas-landing-app -o custom-columns='hosts:spec.rules[0].host'
Après la migration (Contour) : Contour utilise un objet racine (sas-httpproxy-root) qui détient le FQDN et englobe tous les autres proxies. Votre code devra ressembler à cela :
2
kubectl -n lab get httpproxy sas-httpproxy-root -o jsonpath='{.spec.virtualhost.fqdn}'
Et pour les environnements sur OpenShiftOpenShift est la plateforme Kubernetes d'entreprise de Red Hat conçue pour orchestrer, sécuriser et gérer le cycle de vie des applications conteneurisées.
Pour SAS Viya 4, OpenShift agit comme la fondation "Cloud Native" indispensable : il automatise le déploiement des microservices SAS, garantit la haute disponibilité des calculs analytiques et permet une portabilité totale entre le cloud public (Azure, AWS, GCP) et les infrastructures sur site. ?
Si votre infrastructure repose sur Red Hat OpenShiftOpenShift est la plateforme Kubernetes d'entreprise de Red Hat conçue pour orchestrer, sécuriser et gérer le cycle de vie des applications conteneurisées.
Pour SAS Viya 4, OpenShift agit comme la fondation "Cloud Native" indispensable : il automatise le déploiement des microservices SAS, garantit la haute disponibilité des calculs analytiques et permet une portabilité totale entre le cloud public (Azure, AWS, GCP) et les infrastructures sur site., vous pouvez souffler. Sur OpenShiftOpenShift est la plateforme Kubernetes d'entreprise de Red Hat conçue pour orchestrer, sécuriser et gérer le cycle de vie des applications conteneurisées.
Pour SAS Viya 4, OpenShift agit comme la fondation "Cloud Native" indispensable : il automatise le déploiement des microservices SAS, garantit la haute disponibilité des calculs analytiques et permet une portabilité totale entre le cloud public (Azure, AWS, GCP) et les infrastructures sur site., SAS Viya s'appuie sur une autre technologie native : les OpenShiftOpenShift est la plateforme Kubernetes d'entreprise de Red Hat conçue pour orchestrer, sécuriser et gérer le cycle de vie des applications conteneurisées.
Pour SAS Viya 4, OpenShift agit comme la fondation "Cloud Native" indispensable : il automatise le déploiement des microservices SAS, garantit la haute disponibilité des calculs analytiques et permet une portabilité totale entre le cloud public (Azure, AWS, GCP) et les infrastructures sur site. Routes. Vous n'êtes donc absolument pas concernés par cette migration vers Contour.
En résumé
La fin de vie d'ingress-nginx secoue pas mal l'écosystème cloud-native en ce moment, mais SAS propose un chemin de migration clair et maîtrisé avec Contour. N'attendez pas la dernière minute ou l'apparition de nouvelles failles CVE non corrigées sur l'ancien contrôleur pour planifier votre transition.
