Déployer l’Opérateur de Déploiement SAS Viya Platform
L'Opérateur de Déploiement SAS Viya Platform (SAS Viya Platform Deployment Operator) est un outil puissant qui simplifie et automatise le déploiement et la mise à jour de vos environnements SAS Viya sur Kubernetes. Il surveille activement les ressources personnalisées (Custom Resources
ou CRs) de type SASDeployment
et s'assure que votre déploiement SAS Viya correspond à l'état désiré défini dans ces CRs.
Cet article vous guidera à travers les étapes nécessaires pour déployer cet opérateur sur votre cluster Kubernetes.
Comprendre les Modes de l'Opérateur
Avant de commencer, il est important de connaître les deux modes de fonctionnement de l'opérateur :
- Mode Espace de Noms (Namespace Mode) : L'opérateur est déployé dans le même espace de noms (namespace) que votre déploiement SAS Viya. Il ne gère que les déploiements SAS Viya dans cet espace de noms spécifique.
- Mode Cluster-Wide : L'opérateur est déployé dans son propre espace de noms dédié et peut gérer les déploiements SAS Viya dans tous les espaces de noms du cluster.
SAS recommande de n'utiliser qu'un seul mode d'opérateur par cluster pour éviter toute confusion. Même si vous choisissez le mode Espace de Noms, l'opérateur aura besoin de certaines permissions à l'échelle du cluster, comme nous le verrons plus loin.
Prérequis
- Accès à un cluster Kubernetes avec
kubectl
configuré. - Un espace de noms Kubernetes créé :
- Pour le mode Cluster-Wide : Un espace de noms dédié à l'opérateur (ex:
sasoperator
). - Pour le mode Espace de Noms : L'espace de noms où vous déploierez SAS Viya (qui hébergera aussi l'opérateur).
- Pour le mode Cluster-Wide : Un espace de noms dédié à l'opérateur (ex:
- (Optionnel) Si vous utilisez un registre miroir : SAS Mirror Manager doit être installé.
Étape 1 : Récupérer les Fichiers Requis
Les fichiers nécessaires (appelés "deployment assets") sont fournis via un fichier TGZ téléchargeable depuis votre portail my.sas.com.
- Créez un Répertoire de Travail : Sur votre machine
kubectl
(ou une machine accessible), créez un répertoire dédié. SAS recommandeoperator-deploy
. Ce répertoire est désigné par$operator-deploy
dans la suite.operator-deploy cd operator-deploy
Note : Si vous avez un registre miroir et un répertoire$deploy
, créez$operator-deploy
au même niveau. - Téléchargez les Fichiers :
- Connectez-vous à my.sas.com via le lien "Get Started" de votre email de commande (SOE).
- Vérifiez que vous travaillez avec la bonne commande et la bonne version de SAS Viya. Si vous mettez à jour vers une nouvelle version en adoptant l'opérateur, téléchargez les assets de la version cible.
- Dans l'onglet "Downloads", sélectionnez "Deployment Assets" et téléchargez le fichier TGZ.
- Sauvegardez le fichier TGZ dans le répertoire
$operator-deploy
.
- Extrayez les Fichiers :
tar xvfz nom-du-fichier.tgz
Cela crée une structure de répertoiressas-bases/
. - Copiez et Préparez les Fichiers de l'Opérateur : Copiez les fichiers spécifiques à l'opérateur depuis
sas-bases
vers la racine de$operator-deploy
et rendez les fichiers de configuration modifiables.
Assurez-vous d'être dans $operator-deploy
1 |
cd $operator-deploy |
Copiez les fichiers de l'exemple de déploiement de l'opérateur
1 |
cp -r sas-bases/examples/deployment-operator/deploy/* . |
Rendez le fichier transformer.yaml modifiable
1 |
chmod +w site-config/transformer.yaml |
Si vous déployez en mode Cluster-Wide OU sur un cluster sans support seccomp (ex: OpenShift),
rendez aussi le kustomization.yaml principal modifiable :
1 |
chmod +w site-config/transformer.yaml kustomization.yaml |
Étape 2 : Modifier le Fichier transformer.yaml (Point Crucial)
Le fichier $operator-deploy/site-config/transformer.yaml
est essentiel car il adapte la configuration de l'opérateur à votre environnement spécifique. Vous devez y définir deux informations clés.YAML

Explication Détaillée :
- Première Modification (
path: /metadata/name
) : Le Nom duClusterRoleBinding
- Qu'est-ce qu'un
ClusterRoleBinding
? C'est une ressource Kubernetes qui accorde des permissions (définies dans unClusterRole
) à un utilisateur, un groupe ou unServiceAccount
(l'identité sous laquelle l'opérateur s'exécute) à travers l'ensemble du cluster. - Pourquoi l'opérateur en a-t-il besoin ? Même si l'opérateur fonctionne en mode "Espace de Noms", le déploiement de SAS Viya lui-même implique la création de ressources qui ont une portée cluster (par exemple, des
CustomResourceDefinitions
, desClusterRoles
pour certains services SAS, etc.). L'opérateur doit donc avoir les permissions nécessaires pour gérer ces ressources à l'échelle du cluster. - Pourquoi un nom unique (
value: "sasoperator"
) ? Comme leClusterRoleBinding
est une ressource de niveau cluster, son nom doit être absolument unique au sein de votre cluster Kubernetes. Si vous prévoyez (même si ce n'est pas recommandé) d'avoir plusieurs instances de l'opérateur dans le même cluster (par exemple, gérant différentes versions de Viya ou pour des environnements distincts), chaque instance doit avoir unClusterRoleBinding
avec un nom différent pour éviter les conflits. Choisissez un nom descriptif et unique, commesas-viya-prod-operator-binding
ouoperateur-sas-finance
. L'exemple utilisesasoperator
.
- Qu'est-ce qu'un
- Deuxième Modification (
path: /subjects/0/namespace
) : L'Espace de Noms de l'Opérateur- À quoi sert cette valeur ? Elle spécifie l'espace de noms (
namespace
) dans lequel l'opérateur lui-même sera déployé. C'est aussi là que seront créées les ressources associées à l'opérateur, notamment sonServiceAccount
(son identité dans le cluster). - Quelle valeur mettre (
value: "sasoperator"
) ? Vous devez indiquer ici le nom exact de l'espace de noms que vous avez créé pour l'opérateur. Si vous êtes en mode Cluster-Wide, ce sera l'espace de noms dédié (ex:sasoperator
). Si vous êtes en mode Espace de Noms, ce sera l'espace de noms où SAS Viya sera également déployé (ex:viya-prod
). L'exemple utilisesasoperator
.
- À quoi sert cette valeur ? Elle spécifie l'espace de noms (
La documentation mentionne la nécessité d'un ClusterRoleBinding
unique pour chaque instance de l'opérateur SAS Viya Platform Deployment, mais elle se concentre sur la manière de personnaliser son nom et le namespace via des patches kustomize
, plutôt que sur sa création initiale ou le ClusterRole
sous-jacent.
Voici comment cela fonctionne généralement et comment aborder votre question :
-
Le
ClusterRole
est fourni par SAS : Vous n'avez normalement pas besoin de créer leClusterRole
vous-même. SAS fournit la définition duClusterRole
nécessaire dans le cadre des manifestes de déploiement de l'opérateur (souvent dans les répertoiresbase
ouresources
utilisés parkustomize
). CeClusterRole
contient toutes les permissions étendues requises par l'opérateur pour gérer les ressources Kubernetes au niveau du cluster (même s'il est déployé dans un namespace spécifique), comme la création deCustomResourceDefinitions
(CRDs), deNamespaces
(si configuré), deRoles
,RoleBindings
, etc., nécessaires au déploiement de SAS Viya.- Nom typique : Le nom de ce
ClusterRole
est souvent quelque chose commesas-deployment-operator-role
ou un nom similaire défini par SAS dans ses fichiers de déploiement. Vous le trouverez référencé dans la définition de base duClusterRoleBinding
fournie par SAS.
- Nom typique : Le nom de ce
-
Le
ServiceAccount
est créé pour l'opérateur : Lorsque vous déployez l'opérateur dans un namespace donné, unServiceAccount
est créé pour lui (par exemple,sas-deployment-operator
). C'est cette identité (ServiceAccount
) qui a besoin des permissions définies dans leClusterRole
. -
Le
ClusterRoleBinding
lie les deux : LeClusterRoleBinding
est la ressource Kubernetes qui accorde les permissions définies dans leClusterRole
(fourni par SAS) auServiceAccount
de l'opérateur.- Définition de base : SAS fournit également une définition de base de ce
ClusterRoleBinding
dans ses manifestes. Cette définition de base spécifie déjà :- Quel
ClusterRole
utiliser (viaroleRef
). - Quel type d'entité (
ServiceAccount
) cibler (viasubjects
). - Le nom par défaut du
ServiceAccount
(souventsas-deployment-operator
).
- Quel
- Définition de base : SAS fournit également une définition de base de ce
En résumé pour transformer.yaml
: Vous fournissez un nom unique à l'échelle du cluster pour les permissions de l'opérateur et vous indiquez dans quel espace de noms l'opérateur doit être installé.
Étape 3 : Modifier kustomization.yaml pour le Mode Cluster-Wide (Si applicable)
Si vous déployez l'opérateur en mode Espace de Noms, sautez cette étape.
Si vous utilisez le mode Cluster-Wide, ouvrez le fichier kustomization.yaml
à la racine de $operator-deploy
et décommentez la ligne qui inclut site-config/cluster-wide-transformer.yaml
:YAML

Étape 4 : Modifier kustomization.yaml pour seccomp (Si applicable)
Si votre cluster Kubernetes ne supporte pas le mode seccomp
(Secure Computing Mode), ce qui est souvent le cas pour Red Hat OpenShift, vous devez l'indiquer.
Ouvrez le fichier kustomization.yaml
(à la racine de $operator-deploy
) et décommentez la ligne qui inclut site-config/remove-seccomp-transformer.yaml
:YAML

Étape 5 : Configurer le Registre Miroir (Optionnel)
Si vous n'utilisez pas de registre miroir, sautez cette étape. Je vous invite également à lire mon article Comprendre le Registry Flattened dans SAS Viya
- Copiez le Fichier de Configuration Miroir :
- Copiez
mirror.yaml
(pour la plupart des registres) oumirror-flattened.yaml
(pour OpenShift Container Registry) depuis$deploy/sas-bases/examples/mirror/
vers$operator-deploy/site-config/
.
- Copiez
- Modifiez le Fichier Copié :
- Pour
mirror.yaml
: Remplacez chaque{{ MIRROR-HOST }}
par l'adresse complète de votre registre miroir, suivie du namespace du registre et desasdeployment
. Format :FQDN/registry-namespace/sasdeployment
(ex:monregistre.entreprise.com/sas-images/sasdeployment
). - Pour
mirror-flattened.yaml
(OpenShift) :- Trouvez le nom de service et le port du registre interne :
oc get svc -n <namespace-du-registre-openshift>
(souventopenshift-image-registry
). Notez le nom (ex:image-registry
) et le port (ex:5000
). - Remplacez chaque
{{ MIRROR-HOST }}
par la route interne du registre suivie du nom de l'espace de noms où SAS Viya sera déployé. Format :nom-service.namespace-registre.svc:port/namespace-viya
(ex:image-registry.openshift-image-registry.svc:5000/viya-prod
).
- Trouvez le nom de service et le port du registre interne :
- Pour
- Ajoutez le Fichier à
kustomization.yaml
: Dans le fichierkustomization.yaml
principal ($operator-deploy/kustomization.yaml
), ajoutez le chemin vers votre fichier miroir (mirror.yaml
oumirror-flattened.yaml
) dans la sectiontransformers
.

Étape 6 : Ajouter un imagePullSecret (Optionnel)
Si votre registre miroir nécessite une authentification pour tirer les images SAS, vous devez configurer un imagePullSecret
. Sinon, sautez cette étape.
- Méthode Générale :
- Créez un secret de type
kubernetes.io/dockerconfigjson
contenant vos identifiants pour le registre miroir (voir la documentation Kubernetes "Pull an Image from a Private Registry"). - Modifiez le fichier
$operator-deploy/kustomization.yaml
pour générer ce secret et l'ajouter au déploiement de l'opérateur :
- Créez un secret de type

Étape 7 : Configurer les Informations Proxy (Optionnel)
Si votre cluster nécessite un proxy sortant (forward proxy) pour accéder à Internet (par exemple, pour télécharger des outils ou contacter SAS), et que vous souhaitez configurer ce proxy globalement pour l'opérateur, modifiez $operator-deploy/operator-base/deployment.yaml
.
Repérez la section env:
sous containers:
et ajoutez les variables d'environnement HTTP_PROXY
, HTTPS_PROXY
, et NO_PROXY
.YAML

Important pour NO_PROXY
: Incluez toujours kubernetes.default.svc
, l'adresse IP ou le nom d'hôte de l'API Server Kubernetes de votre cluster, ainsi que les domaines internes et les adresses IP qui ne doivent pas passer par le proxy.
Alternative : Vous pouvez configurer le proxy spécifiquement pour chaque déploiement SAS Viya via la ressource personnalisée SASDeployment
, plutôt que globalement pour l'opérateur.
Étape 8 : Appliquer les Ressources de l'Opérateur au Cluster
Une fois toutes les configurations effectuées, placez-vous dans le répertoire $operator-deploy
et exécutez la commande suivante pour construire la configuration finale avec Kustomize et l'appliquer à votre cluster :
1 |
kustomize build . | kubectl -n apply -f - |
Cette commande :
kustomize build .
: Lit lekustomization.yaml
et tous les fichiers référencés pour générer les manifestes Kubernetes finaux.|
: Envoie (pipe) la sortie (les manifestes YAML) à la commande suivante.kubectl -n <namespace-operateur> apply -f -
: Applique les manifestes reçus (-f -
) dans l'espace de noms spécifié (-n <namespace-operateur>
) de votre cluster.
Conclusion
Après l'exécution de cette dernière commande, le SAS Viya Platform Deployment Operator sera déployé et commencera à s'exécuter dans l'espace de noms spécifié. Il est maintenant prêt à surveiller et à gérer les ressources personnalisées SASDeployment
que vous créerez pour déployer ou mettre à jour vos environnements SAS Viya Platform. N'oubliez pas que la configuration correcte du fichier transformer.yaml
, notamment le nom unique du ClusterRoleBinding
et l'espace de noms cible, est cruciale pour un déploiement réussi.
