Maîtriser SAS Viya 4 sur Kubernetes : Guide Essentiel pour une Administration Efficace

L'administration de SAS Viya a décidé de faire un grand saut, un peu comme passer du vélo à la fusée, en adoptant une architecture moderne entièrement basée sur Kubernetes. Oui, vous avez bien entendu, entièrement !

Cette évolution, très 'cloud-native' et donc super à la mode, nous promet le tiercé gagnant : flexibilité, scalabilité et cette fameuse résilience qui permet de dormir (presque) sur ses deux oreilles. Pour les administrateurs qui avaient leurs petites habitudes bien rodées avec les versions antérieures, comme la 3.5, ne paniquez pas tout de suite ! Si de nombreux concepts fondamentaux de SAS sont toujours vos fidèles compagnons, leur mise en œuvre et votre café du matin s'en trouvent quelque peu... orchestrés différemment par ce chef d'orchestre un peu geek qu'est Kubernetes.

Cet article a donc pour mission (presque) héroïque de décortiquer les hiéroglyphes Kubernetes indispensables pour que vous puissiez administrer votre plateforme SAS Viya avec brio, et peut-être même avec le sourire.

Les Cadences de Versions de SAS Viya : LTS et Stable

Avant d'entrer dans les aspects techniques, il est utile de rappeler la stratégie de versioning de SAS Viya :

• Long Term Support (LTS) : Identifiées par un format ANNÉE.MOIS (par exemple, 2021.09). Ces versions sont conçues pour les environnements nécessitant une stabilité maximale et des changements moins fréquents. Elles bénéficient d'un support étendu et une nouvelle version LTS est généralement proposée tous les six mois. Les mises à jour se concentrent sur les correctifs de sécurité et de bugs critiques.
• Stable : Également identifiées par ANNÉE.MOIS (par exemple, 2022.03), ces versions sont publiées mensuellement. Elles s'inscrivent dans une démarche d'intégration et de déploiement continus (CI/CD), permettant d'accéder rapidement aux toutes dernières fonctionnalités, améliorations et corrections. Ce rythme plus soutenu est idéal pour les organisations souhaitant innover rapidement.

Le passage à ces nouvelles versions implique une adoption de Kubernetes. Une solide compréhension de l'administration SAS demeure cruciale, mais elle doit désormais être complétée par des compétences en orchestration de conteneurs.

La Double Nature de l'Administration Viya sur Kubernetes

L'administration d'une plateforme SAS Viya moderne se décompose en deux grands domaines de compétences et de responsabilités, chacun s'appuyant sur une documentation dédiée.

1. Tâches spécifiques à Viya : Elles concernent la configuration, la gestion et la maintenance des applications et services SAS Viya déployés au sein du cluster Kubernetes. Cela inclut la gestion des utilisateurs, des données, des modèles, etc. La documentation de référence principale pour ces aspects est "SAS Viya Administration".
2. Tâches spécifiques à Kubernetes : Elles relèvent de la gestion de l'infrastructure du cluster Kubernetes lui-même, qui héberge et orchestre les composants de SAS Viya. Cela comprend le provisionnement des nœuds, la gestion du réseau, du stockage, la surveillance de l'état du cluster, et la sécurité de l'infrastructure. La documentation clé ici est "SAS Viya Operations".

Il est essentiel de concevoir ces responsabilités comme des rôles plutôt que de les attribuer nécessairement à des individus distincts. Selon la taille et la structure de l'organisation, une seule personne peut cumuler ces rôles, ou plusieurs équipes spécialisées (SysAdmins, Ops, Admins SAS) peuvent collaborer. Historiquement, l'administration SAS 9 impliquait déjà une collaboration entre administrateurs système (Linux/Windows) et administrateurs SAS. Cette dualité de compétences est encore plus marquée avec Viya sur Kubernetes.

L'administration SAS 9 impliquait une collaboration entre administrateurs système et administrateurs SAS. Cette dualité de compétences est encore plus marquée avec Viya sur Kubernetes.

Ce Qui Reste Familier : Les Fondations de l'Administration SAS

Pour les administrateurs SAS aguerris, une partie significative des tâches quotidiennes conservera une saveur familière. Les concepts métiers et les objectifs fonctionnels n'ont pas changé, même si les interfaces ou les outils sous-jacents peuvent présenter des évolutions.

• Identity Management (Gestion des Identités) : La création et la gestion des utilisateurs, des groupes, l'intégration avec des annuaires d'entreprise (comme LDAP ou Azure AD) restent des piliers.
• Sécurité des Dossiers et des Contenus : L'application des permissions, la définition des règles d'accès (Authorization Rules) pour contrôler qui peut voir ou modifier quels objets (rapports, modèles, données).
• Création de Caslibs : La définition des bibliothèques de données pour le serveur CAS (Cloud Analytic Services), y compris les connexions aux sources de données.
• Sécurité des Accès CAS : La gestion fine des droits d'accès aux données et aux fonctionnalités au sein du serveur CAS.

Ces opérations continuent d'être principalement réalisées via :

• SAS Environment Manager : L'interface web centrale pour l'administration de Viya. Bien que son apparence et certaines fonctionnalités aient évolué (par exemple, le dashboard d'accueil principal et le bouton "Backup and Restore" ont disparu, ces fonctions étant désormais gérées par des mécanismes Kubernetes, et le monitoring des machines physiques est externalisé), elle intègre de nouvelles capacités comme un bouton "Import" et une section "Metrics" pour un aperçu des métriques applicatives.
• SAS Viya CLI (Command Line Interface) : Un ensemble d'interfaces en ligne de commande, toujours aussi puissant pour l'automatisation, le scripting des tâches d'administration et les intégrations avec des systèmes tiers.

Les Transformations Majeures : L'Ère Kubernetes

C'est dans ce domaine que l'impact de Kubernetes est le plus profond, redéfinissant la manière d'opérer la plateforme.

• Déploiement de la solution logicielle.
• Gestion des services et des microservices Viya.
• Gestion et configuration du serveur CAS.
• Gestion du stockage partagé et persistant.
• Fonctionnement et configuration du Runtime Programming (SPRE/Compute Engine – le moteur SAS 9 traditionnel).
• Logging (Journalisation) et Monitoring (Surveillance) : une refonte complète et puissante.
• Stratégies de Sauvegarde (Backup) et de Restauration.
• Procédures d'Arrêt et de Démarrage de la plateforme.

Pour aborder ces nouvelles tâches, un arsenal d'outils spécifiques à l'écosystème Kubernetes devient indispensable :

• kubectl : L'outil en ligne de commande fondamental pour toute interaction avec un cluster Kubernetes. Il permet d'inspecter, de gérer et de modifier les ressources du cluster. Bien que puissant, sa prise en main peut être facilitée par des outils graphiques comme Lens pour une visualisation et une gestion plus intuitives.
• kustomize : Un utilitaire open-source intégré à kubectl qui permet de personnaliser les configurations Kubernetes de manière structurée, sans modifier les fichiers de base. Il est central dans le processus de déploiement et de mise à jour de SAS Viya.
• Fichiers YAML (YAML Ain't Markup Language) : Un format de sérialisation de données lisible par l'homme, universellement utilisé dans Kubernetes pour définir l'état désiré de toutes les ressources (déploiements, services, pods, configurations, etc.).
• SAS Environment Manager et SAS Viya CLI : Conservent leur pertinence pour des interactions spécifiques à Viya qui s'interfacent avec les objets Kubernetes sous-jacents.
• Solutions Tierces (Third-Party) : Surtout pour le logging et le monitoring avancé, où des piles technologiques open-source éprouvées sont souvent intégrées.

Exploration Détaillée des Tâches Transformées :

1. Déploiement de Viya : Une Approche Déclarative
   • Concepts Kubernetes Fondamentaux :
     • Conteneurs : SAS Viya est livrée sous forme d'un ensemble d'images conteneurisées (généralement au format Docker/OCI). Chaque microservice de Viya s'exécute dans son propre conteneur.
     • Pods : L'unité atomique de déploiement dans Kubernetes. Un pod encapsule un ou plusieurs conteneurs (avec des ressources de stockage et réseau partagées). Les pods sont éphémères par nature. Chaque pod est défini par un fichier YAML.
     • Nœuds (Nodes) : Ce sont les machines (physiques ou virtuelles) qui constituent la puissance de calcul du cluster. Chaque nœud exécute Kubelet, un agent qui gère les pods sur ce nœud.
     • Cluster : Un ensemble de nœuds maîtres (control plane) et de nœuds travailleurs (worker nodes) qui exécutent les applications conteneurisées.
     • Pool de Nœuds (Node Pools) : Des regroupements de nœuds au sein d'un cluster, souvent avec des configurations matérielles identiques (CPU, RAM, type de disque), permettant d'affecter des charges de travail spécifiques à des types de matériel adaptés.
     • Namespaces : Fournissent un mécanisme pour isoler des groupes de ressources au sein d'un même cluster physique. Utile pour créer des environnements virtuels (développement, test, production) ou pour séparer les applications. SAS Viya est typiquement déployée dans son propre namespace dédié.
   • Processus de Déploiement avec kustomize :
     • sas-base : Un répertoire fourni par SAS contenant l'ensemble des fichiers YAML de base (manifestes Kubernetes) décrivant les objets standards de Viya. Ce contenu est en lecture seule pour l'administrateur et est mis à jour par SAS à chaque nouvelle version de Viya.
     • site-config : Le répertoire où l'administrateur place ses propres fichiers YAML de personnalisation (overlays, patches) pour adapter le déploiement à ses besoins spécifiques (configuration de l'ingress, ressources, etc.).
     • kustomize utilise les fichiers de sas-base comme fondation et applique les personnalisations de site-config pour générer un manifeste de déploiement complet et consolidé : le fichier site.yaml.
     • kubectl apply -f site.yaml : Cette commande est ensuite utilisée pour soumettre ce manifeste au cluster. Kubernetes interprète alors cet "état désiré" et s'efforce de faire converger l'état réel du cluster vers cet état, en créant, modifiant ou supprimant les ressources nécessaires.
2. Gestion des Services (Microservices Viya) :
   • Avec kubectl, on peut lister les pods (kubectl get pods -n <namespace-viya>), inspecter leurs logs (kubectl logs <nom-du-pod>), ou décrire leur état (kubectl describe pod <nom-du-pod>).
   • Pour "redémarrer" un service (un pod), la pratique courante est de supprimer le pod concerné (kubectl delete pod <nom-du-pod>). Kubernetes, grâce aux contrôleurs de plus haut niveau comme les Deployments ou StatefulSets (qui assurent que le nombre désiré de réplicas d'un pod est toujours en cours d'exécution), détectera la disparition du pod et en créera automatiquement un nouveau pour le remplacer.
3. Mises à Jour et Personnalisations Dynamiques :
   • Pour toute modification (configurer une nouvelle fonctionnalité, ajuster les ressources d'un pod, mettre à jour Viya), le processus implique de modifier les fichiers YAML dans site-config ou de mettre à jour le contenu de sas-base (pour une nouvelle version de Viya).
   • Ensuite, on régénère le manifeste site.yaml avec kustomize.
   • Finalement, on applique ce nouveau site.yaml via kubectl apply.
   • Kubernetes gère la transition de l'ancien état vers le nouvel état de manière contrôlée, souvent via des stratégies de "rolling update" qui minimisent, voire éliminent, les interruptions de service pour les utilisateurs finaux.
4. Gestion et Évolution du Serveur CAS :
   • Par défaut, le serveur CAS est souvent déployé en mode SMP (Single Machine Processing). Pour des besoins de performance accrus ou pour traiter de plus grands volumes de données, il est fréquent de vouloir le passer en mode MPP (Massively Parallel Processing).
   • SAS fournit des exemples de configurations YAML (dans sas-base/examples/cas/) pour faciliter ces transitions, par exemple, en utilisant un fichier comme cas-managed-workers.yaml.
   • Ce fichier est copié et adapté dans site-config pour définir le nombre de workers CAS souhaités et d'autres paramètres. Il est ensuite référencé comme "transformer" ou "patch" dans le fichier kustomization.yaml principal.
   • Après régénération et application du site.yaml, et un redémarrage des pods CAS, la nouvelle topologie est active.
   • Concernant la configuration fine des options du serveur CAS ou du moteur SPRE (variables d'environnement, options de démarrage), elle s'effectue désormais principalement via SAS Environment Manager ou des modifications déclaratives dans les fichiers YAML, plutôt qu'en éditant directement des fichiers de configuration sur le serveur (comme les anciens casconfig_usermode.lua). Cette approche centralisée et déclarative améliore la traçabilité et la reproductibilité des configurations.
5. Logging et Monitoring : Une Visibilité Accrue et Centralisée
   • Par défaut, les conteneurs écrivent leurs logs sur les flux stdout (sortie standard) et stderr (erreur standard). Ces logs sont éphémères et disparaissent avec le pod si non collectés.
   • Kubelet, l'agent Kubernetes s'exécutant sur chaque nœud, collecte ces flux et les stocke localement sur le nœud (généralement dans /var/log/containers).
   • Le Metric Server est un composant standard de Kubernetes qui collecte des métriques de base sur l'utilisation des ressources (CPU, mémoire) par les nœuds et les pods.
   • Des commandes comme kubectl top pods ou kubectl logs permettent un accès direct mais limité.
   • Pour une solution robuste et centralisée, SAS propose et supporte "SAS Viya Monitoring for Kubernetes". Ce projet, disponible sur GitHub, déploie une pile de monitoring et de logging open-source complète, préconfigurée pour SAS Viya :
     • Logging : Utilise souvent Fluent Bit (ou un autre agent de collecte) pour acheminer les logs vers OpenSearch (ou Elasticsearch) pour le stockage, l'indexation et la recherche. OpenSearch Dashboards (ou Kibana) fournit une interface web pour explorer et visualiser ces logs.
     • Monitoring & Alerting : Prometheus collecte et stocke des métriques de performance (issues des composants Viya et de Kubernetes). Grafana permet de créer des tableaux de bord dynamiques pour visualiser ces métriques. AlertManager gère les alertes basées sur des seuils définis dans Prometheus.
   • Cette pile offre des tableaux de bord et des alertes préconfigurés, spécifiquement adaptés à la surveillance de la santé et des performances de SAS Viya. Des alternatives existent, comme l'utilisation des services de monitoring natifs des fournisseurs cloud (Azure Monitor, AWS CloudWatch, Google Cloud Monitoring) ou le déploiement d'une solution de monitoring maison (ce qui demande un effort d'intégration plus conséquent).
6. Stratégies de Sauvegarde et Restauration Modernisées :
   • Les sauvegardes s'appuient sur les mécanismes de Jobs Kubernetes (pour des opérations ponctuelles) et de CronJobs Kubernetes (pour des tâches planifiées et récurrentes).
   • SAS fournit un job type, sas-scheduled-backup-job, qui peut être utilisé comme base pour un CronJob. Par défaut, un CronJob est souvent configuré lors du déploiement initial pour effectuer une sauvegarde hebdomadaire (par exemple, chaque dimanche à 1h du matin).
   • Les données de sauvegarde (contenu de SAS Configuration Server (Consul), potentiellement des données de PostgreSQL si utilisé, et d'autres métadonnées critiques) sont stockées sur des volumes persistants (Persistent Volumes - PVs). Les PVs sont des ressources de stockage dans le cluster qui existent indépendamment du cycle de vie d'un pod.
   • Une sauvegarde ad hoc peut être déclenchée avec une commande comme : kubectl create job mon-backup-adhoc --from=cronjob/sas-scheduled-backup-job -n <namespace-viya>.
   • Il est crucial de noter que la stratégie de sauvegarde doit aussi englober la sauvegarde des PVs eux-mêmes (via des snapshots au niveau de l'infrastructure de stockage sous-jacente) et la configuration du cluster Kubernetes.
7. Démarrage et Arrêt Contrôlés de la Plateforme :
   • SAS fournit des jobs Kubernetes dédiés pour orchestrer le démarrage (sas-start-all) et l'arrêt (sas-stop-all) ordonnés des différents services Viya.
   • Pour initier un arrêt, par exemple : kubectl create job mon-arret-viya --from=job/sas-stop-all -n <namespace-viya>.
   • Une autre approche, plus granulaire, pour arrêter (ou démarrer) la plateforme consiste à "scaler" (mettre à l'échelle) les déploiements Kubernetes à zéro (pour arrêter) ou au nombre de réplicas désiré (pour démarrer). Cela se fait en modifiant les fichiers YAML dans site-config et en réappliquant via kustomize et kubectl.

Récapitulatif Synthétique des Évolutions

Tâche d'Administration	Approche Historique (ex: Viya 3.5)	Approche Moderne (Viya sur Kubernetes)
Identity Management, Sécurité Contenu/CAS	SAS Environment Manager, CLI Viya	SAS Environment Manager, CLI Viya (interactions traduites en opérations K8s pour certaines configurations)
Déploiement Logiciel	Principalement Ansible	kubectl, kustomize, manifestes YAML (approche déclarative)
Gestion des Services Applicatifs	Commandes OS, scripts spécifiques	kubectl (gestion des pods, deployments, statefulsets)
Configuration Serveur CAS (topologie, options)	Fichiers de conf. (ex: .lua)	SAS Environment Manager pour options, YAML (kustomize) pour topologie (SMP/MPP, ressources) et options de bas niveau.
Logging & Monitoring	Outils SAS spécifiques, logs fichiers	kubectl logs, SAS Viya Monitoring for K8s (OpenSearch, Grafana, Prometheus), outils K8s natifs. Centralisé et basé sur des standards ouverts.
Sauvegarde/Restauration	Outil Backup/Restore intégré	Jobs/CronJobs Kubernetes (kubectl, YAML), gestion des Persistent Volumes.
Démarrage/Arrêt de la Plateforme	Scripts OS, ordonnancement manuel	Jobs Kubernetes (kubectl, YAML), scaling des déploiements K8s (kustomize).

Domaines d'Approfondissement Recommandés

Pour exceller dans l'administration de SAS Viya sur Kubernetes, il est conseillé de développer une compréhension plus poussée des sujets suivants :

• SAS Deployment Operator : Proposé par SAS, cet opérateur Kubernetes peut simplifier et automatiser de nombreuses tâches de déploiement et de gestion du cycle de vie de Viya, offrant une alternative à la manipulation directe de kubectl et kustomize pour certaines opérations complexes.
• Syntaxe et Bonnes Pratiques YAML : La maîtrise de YAML est non négociable, car c'est le langage utilisé pour décrire toutes les configurations dans Kubernetes.
• Objets et Contrôleurs Kubernetes Avancés : Au-delà des Pods et Deployments, comprendre les StatefulSets (pour les applications avec état comme PostgreSQL ou Consul), ReplicaSets, Services (pour l'exposition réseau), Ingress (pour l'accès externe), PersistentVolumeClaims, ConfigMaps, Secrets, et Horizontal Pod Autoscaler (HPA) est crucial pour optimiser, sécuriser et faire évoluer la plateforme.
• Labels et Annotations Kubernetes : Ces métadonnées sont fondamentales pour organiser les ressources, permettre des sélections fines (pour les politiques réseau, l'affectation de charges de travail à des nœuds spécifiques – node affinity/anti-affinity, taints/tolerations), et pour le bon fonctionnement de nombreux outils de l'écosystème.

Conclusion

L'intégration de SAS Viya avec Kubernetes est une avancée majeure, alignant la plateforme analytique sur les standards de l'infrastructure cloud-native. Cette transition ouvre la voie à une agilité, une scalabilité et une efficacité opérationnelle sans précédent. Bien que la courbe d'apprentissage de Kubernetes puisse paraître intimidante au premier abord, une approche méthodique, axée sur la compréhension des outils clés (kubectl, kustomize, YAML) et des solutions de monitoring dédiées, permet aux administrateurs SAS de non seulement s'adapter mais aussi de tirer pleinement parti de cette puissante architecture. L'investissement dans ces nouvelles compétences est la clé pour garantir des déploiements SAS Viya robustes, performants et pérennes.