Déployer un cluster Kubernetes chez OUTSCALE avec OKS

Parcours en cours de construction

Ce parcours OUTSCALE est en cours de production. Plusieurs volets sont en construction (signalés « Bientôt » dans la sidebar) et se complètent progressivement. Les pages publiées sont stables et utilisables ; les vues d'ensemble en stub annoncent ce qui est à venir.

OKS (OUTSCALE Kubernetes as a Service) vous permet de déployer un cluster Kubernetes managé en quelques minutes, dans un environnement souverain certifié SecNumCloud 3.2. Contrairement aux plateformes publiques, OKS garantit l'isolation complète de vos ressources sur des infrastructures dédiées, tout en offrant une gestion simplifiée via CLI et API.

Ce que vous allez apprendre

• Créer un profil OKS : Authentification par login/password ou access key
• Déployer un projet : Réservation CIDR et organisation des ressources
• Lancer un cluster Kubernetes managé : Control plane haute disponibilité
• Ajouter des nodepools : Workers nodes avec différents types TINA
• Configurer kubectl : Accès au cluster via kubeconfig
• Gérer les ressources : Mise à jour et suppression des composants

Vous voulez trouver de l'info rapidement sur ...

📦 Installation OKS CLI Python 3.11+, pip install oks-cli, autocomplétion

📊 Vérifier les quotas Projets max, clusters, versions Kubernetes disponibles

🏗️ Créer un projet Réserver un CIDR réseau (/16 recommandé)

☸️ Déployer un cluster Control plane managé, --admin my-ip, --dry-run

🖥️ Ajouter des workers Nodepools avec types TINA (--zone obligatoire)

🔧 Configurer kubectl Générer kubeconfig, TTL, refresh, RBAC

⚠️ Éviter les pièges CIDR trop petit, IP privée, profil default...

📋 Aide-mémoire Toutes les commandes essentielles en un coup d'œil

Comment fonctionne OKS ?

Le workflow est direct : créez un profil d'authentification, réservez un projet avec son CIDR réseau, déployez votre cluster (10 minutes), ajoutez des nodepools, récupérez le kubeconfig et utilisez kubectl. Tout est automatisé, sécurisé et souverain.

Analogie simple

• Profil = votre compte utilisateur
• Projet = un environnement isolé (dev, staging, prod)
• Cluster = l'infrastructure Kubernetes elle-même
• Nodepool = un groupe de machines identiques (comme une flotte de serveurs)
• Kubeconfig = la clé d'accès pour piloter le cluster avec kubectl

Profils OKS

Un profil OKS représente un compte OUTSCALE configuré pour interagir avec l'OKS CLI. Chaque profil est associé à des identifiants spécifiques (login/mot de passe ou clés d'accès) et à une région de déploiement.

L'utilisation de profils permet de :

• Isoler les environnements : séparer les projets par client ou par département.
• Gérer les accès : attribuer des droits spécifiques à chaque utilisateur.
• Suivre les coûts : associer des comptes de facturation distincts pour une meilleure gestion financière.

Projets

Un projet est une entité logique regroupant des clusters et d'autres ressources associées. Il permet d'organiser et d'isoler les ressources cloud, facilitant ainsi la gestion et la facturation.

Analogie : le projet comme un bâtiment

Imaginez un projet comme un immeuble de bureaux avec son propre réseau électrique et internet. Une fois construit, vous ne pouvez plus changer l'adresse de l'immeuble (le CIDR), mais vous pouvez ajouter des bureaux (clusters) à l'intérieur, les déplacer, les rénover. Le CIDR est l'adresse réseau réservée définitivement.

Chaque projet nécessite la réservation d'un bloc CIDR pour le réseau :

• CIDR : plage d'adresses IP utilisée pour les sous-réseaux VPC.
• Tags : métadonnées associées pour une meilleure identification.

CIDR immutable

Une fois le projet créé, le CIDR ne peut plus être modifié. Choisissez une plage suffisamment large (recommandation : /16 soit 65 536 adresses IP) pour anticiper la croissance.

Clusters

Un cluster OKS est un cluster Kubernetes déployé selon une configuration spécifiée. Lors de la création d’un cluster avec OUTSCALE Kubernetes as a Service (OKS), vous devez choisir un type de plan de contrôle (control plane) adapté à vos besoins en termes de performances, de haute disponibilité (HA) et de capacité. Chaque option définit les ressources allouées au plan de contrôle, influençant ainsi la scalabilité et la résilience de votre cluster.

• cp.mono.master :

  • Description : Un seul nœud maître dédié avec 4 Gio de RAM.
  • Haute disponibilité : Non.
  • Mise à niveau : Non.
  • Taille maximale recommandée du cluster : Jusqu’à 10 nœuds.
  • Usage recommandé : Environnements de test ou clusters éphémères.
  • Limitations :
    • Pas d’options de haute disponibilité.
    • Pas d’accord de niveau de service (SLA) applicable.
    • Non adapté à une utilisation en production ou à long terme.
    • Impossible de le mettre à niveau vers une autre taille ; une recréation est nécessaire pour changer de configuration.

• cp.3.masters.small :

  • Description : Trois nœuds maîtres dédiés, chacun avec 4 Gio de RAM.
  • Haute disponibilité : Oui.
  • Mise à niveau : Oui.
  • Taille maximale recommandée du cluster : Jusqu’à 50 nœuds.
  • Usage recommandé : Petits environnements de production ou de développement nécessitant une haute disponibilité.

• cp.3.masters.medium :

  • Description : Trois nœuds maîtres dédiés, chacun avec 8 Gio de RAM.
  • Haute disponibilité : Oui.
  • Mise à niveau : Oui.
  • Taille maximale recommandée du cluster : Jusqu’à 200 nœuds.
  • Usage recommandé : Environnements de production de taille moyenne avec des charges de travail modérées.

• cp.3.masters.large :

  • Description : Trois nœuds maîtres dédiés, chacun avec 16 Gio de RAM.
  • Haute disponibilité : Oui.
  • Mise à niveau : Oui.
  • Taille maximale recommandée du cluster : Jusqu’à 400 nœuds.
  • Usage recommandé : Grands environnements de production avec des charges de travail élevées nécessitant une haute disponibilité renforcée.

Remarques importantes :

• Le choix du type de plan de contrôle n’affecte pas la disponibilité des outils de gestion des clusters.
• La taille maximale recommandée du cluster est basée sur des environnements à faible charge. Des clusters de production à forte charge peuvent nécessiter un plan de contrôle d’une plus grande taille.

Lors de la création d'un cluster, il est possible de spécifier :

• Nom du cluster : identifiant unique.
• Version de Kubernetes : version souhaitée.
• Type de plan de contrôle : détermine les caractéristiques matérielles.
• Plages CIDR pour pods et services : configuration réseau.

Nodepools

Un nodepool est un groupe de nœuds de travail homogènes au sein d'un cluster OKS. Chaque nodepool contient des nœuds du même type, situés dans une seule région ou répartis sur plusieurs sous-régions.

Caractéristiques des nodepools :

• Homogénéité : tous les nœuds ont le même type TINA.
• Flexibilité : possibilité de créer plusieurs nodepools pour un cluster et d'y attacher des GPU.
• Gestion simplifiée : ajout ou suppression de nœuds sans perturber la disponibilité du cluster.

Note : Les nœuds de travail ne sont ni visibles ni directement accessibles dans votre compte OUTSCALE, conformément aux meilleures pratiques Kubernetes.

Installation et configuration de l’OKS CLI

OKS CLI est l’outil en ligne de commande fourni par OUTSCALE pour gérer vos projets, clusters et nodepools dans l’environnement OKS. Il permet de piloter l’ensemble de votre infrastructure Kubernetes directement depuis un terminal.

Prérequis système

Avant d’installer l’OKS CLI, assurez-vous que votre environnement dispose des éléments suivants :

• Python 3.11 ou supérieur
• pip (le gestionnaire de paquets Python)
• virtualenv (optionnel mais recommandé pour isoler les dépendances)
• kubectl doit être installé au moment de la création des nodepools.

Activation du service OKS requise

Avant toute utilisation, vous devez demander l'activation du service OKS auprès du Support OUTSCALE. Sans cette activation, les commandes oks-cli retourneront des erreurs d'accès. Prévoyez 24-48h pour l'activation.

Étapes d'installation

Commençons par vérifier que vous disposez de Python 3.11 ou supérieur, car l’OKS CLI nécessite cette version minimale.

python3 --version

Si la version est inférieure à 3.11, installez une version plus récente avec pyenv ou brew par exemple.

Créez ensuite un environnement virtuel pour isoler les dépendances de l’OKS CLI :

python3 -m venv oks-env
source oks-env/bin/activate

Ensuite, mettez à jour pip pour vous assurer que vous disposez de la dernière version :

pip install --upgrade pip

Installez l’OKS CLI en utilisant pip :

pip install oks-cli
# Résultat : Successfully installed oks-cli-X.X.X

Astuce

Vous pouvez aussi installer oks-cli avec pipx pour une installation globale isolée : pipx install oks-cli

Pour mettre à jour vers la dernière version : pip install --upgrade oks-cli

Vérifiez l'installation :

oks-cli version

Résultat attendu

1.18

Comment fonctionne OKS CLI ?

Avant de plonger dans les commandes, comprenons la logique. Toutes les commandes OKS CLI suivent le même schéma : vous indiquez la ressource (profile, project, cluster) puis l'action (add, create, list, delete...).

🧠 Modèle mental — oks-cli = une ressource, une action

Toutes les commandes OKS CLI suivent le même schéma : vous indiquez la ressource (profile, project, cluster...) puis l'action à effectuer. La hiérarchie est stricte : Profil → Projet → Cluster → Nodepools.

Points clés

• Toujours la même structure : oks-cli <ressource> <action>
• Hiérarchie stricte : Profil → Projet → Cluster → Nodepools
• Le CIDR du projet est immutable après création
• Le kubeconfig expire par défaut après 7 jours

Règles d'or

1

Toujours vérifier votre profil actif avant de créer/supprimer oks-cli profile list évite de déployer sur le mauvais compte

2

Choisir un CIDR /16 minimum pour les projets Le CIDR est immutable : anticipez la croissance dès le début

3

Activer le support OKS 24-48h avant votre premier déploiement Sans activation, toutes les commandes retournent des erreurs d'accès

Vocabulaire essentiel

Profil

Configuration d'authentification (login/password ou access key)

Projet

Environnement isolé avec un CIDR réservé (immutable)

Cluster

Cluster Kubernetes avec control plane managé

Nodepool

Groupe de workers nodes homogènes (même type TINA)

CIDR

Plage d'adresses IP réservée pour le projet

TINA

Type d'instance OUTSCALE (ex: tinav6.c1r1p2)

Configuration de l’OKS CLI

Activation de l’autocomplétion

L’OKS CLI prend en charge l’autocomplétion pour les commandes, sous-commandes et paramètres. Pour l’activer, vous devez générer les scripts d’autocomplétion pour votre shell préféré (Bash, Zsh ou Fish) et les ajouter à votre configuration de shell.

• Pour Bash :

mkdir -p ~/.oks_cli/completions
_OKS_CLI_COMPLETE=bash_source oks-cli > $HOME/.oks_cli/completions/oks-cli.bash
echo '. $HOME/.oks_cli/completions/oks-cli.bash' >> $HOME/.bashrc
source $HOME/.oks_cli/completions/oks-cli.bash

• Pour Zsh :

mkdir -p ~/.oks_cli/completions
_OKS_CLI_COMPLETE=zsh_source oks-cli > $HOME/.oks_cli/completions/oks-cli.zsh
echo '. $HOME/.oks_cli/completions/oks-cli.zsh' >> $HOME/.zshrc
source $HOME/.oks_cli/completions/oks-cli.zsh

• Pour Fish :

mkdir -p ~/.oks_cli/completions
_OKS_CLI_COMPLETE=fish_source oks-cli > $HOME/.config/fish/completions/oks-cli.fish

Ajout d’un profil OKS

Dans un premier temps, vous devez configurer un profil OKS. Deux méthodes d’authentification sont disponibles :

Par identifiants (login/mot de passe) :

oks-cli profile add \
  --profile-name "default" \
  --username "MON_LOGIN" \
  --password "MON_MOT_DE_PASSE" \
  --region "eu-west-2"

Par clés d’accès (access key/secret key) :

oks-cli profile add \
  --profile-name "production" \
  --access-key "MA_ACCESS_KEY" \
  --secret-key "MA_SECRET_KEY" \
  --region "eu-west-2"

Résultat

Profile production has been successfully added

Remarque : L’authentification utilise un mot de passe à usage unique (OTP) si l’authentification multifacteur est activée.

Les profils sont enregistrés dans le fichier ~/.oks_cli/config.json. Vous pouvez y gérer plusieurs profils pour différents environnements ou régions.

Vérifier vos profils :

oks-cli profile list

Résultat

Profile: production Account type: ak/sk Region: eu-west-2 Endpoint: https://api.eu-west-2.oks.outscale.com/api/v2/ Enabled JWT auth: False

Vérifier les quotas disponibles

Avant de créer des ressources, vérifiez vos quotas :

oks-cli quotas --profile production

Résultat

{
    "Projects": 2,
    "ClustersPerProject": 2,
    "KubeVersions": [
        "1.30",
        "1.31",
        "1.32",
        "1.28",
        "1.29"
    ],
    "CPSubregions": [
        "2a",
        "2b",
        "2c"
    ]
}

Cela vous indique :

• Nombre maximal de projets : 2
• Clusters par projet : 2
• Versions Kubernetes disponibles : 1.28 à 1.32
• Sous-régions disponibles pour le control plane : 2a, 2b, 2c

Création et gestion des projets OKS

Provider Terraform

Sachez qu'à partir de ce point il est possible d'utiliser Terraform pour gérer les projets, clusters et nodepools OKS.

Lien vers documentation du provider

Dans OUTSCALE Kubernetes as a Service (OKS), un projet constitue une entité logique regroupant des clusters et des ressources associées. Il permet d'organiser, d'isoler et de contrôler les environnements, facilitant ainsi la gestion et la facturation.

Création d'un projet

Pour créer un projet, utilisez la commande suivante :

oks-cli project create \
    --project-name "demo-guide" \
    --cidr "10.60.0.0/16" \
    --profile production

Résultat

{
    "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "name": "demo-guide",
    "description": "",
    "cidr": "10.60.0.0/16",
    "region": "eu-west-2",
    "status": "pending",
    "tags": {},
    "disable_api_termination": false,
    "created_at": "2026-01-29T08:43:42.672702Z",
    "updated_at": "2026-01-29T08:43:42.672702Z"
}

Le projet passe par l'état pending pendant ~2-5 minutes le temps que le VPC soit provisionné. Vérifiez le statut :

oks-cli project get --project-name demo-guide --profile production

Résultat quand ready

{
    "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "name": "demo-guide",
    "description": "",
    "cidr": "10.60.0.0/16",
    "region": "eu-west-2",
    "status": "ready",
    "tags": {},
    "disable_api_termination": false,
    "created_at": "2026-01-29T08:43:42.672702Z",
    "updated_at": "2026-01-29T08:46:04.115236Z"
}

Paramètres :

• --project-name : Nom unique du projet.
• --description : Description facultative.
• --cidr : Plage d'adresses IP au format CIDR pour les sous-réseaux VPC.
• --tags : Paires clé=valeur pour catégoriser le projet.

Remarques :

• Le CIDR doit être un bloc privé conforme à la RFC 1918, avec une taille minimale de /23.
• Le CIDR 172.31.0.0/16 est réservé et ne doit pas être utilisé.
• Une fois le projet créé, le CIDR ne peut plus être modifié.

Un projet est créé dans un état pending et passe à ready une fois toutes les ressources nécessaires provisionnées. Vous pouvez vérifier l'état du projet avec la commande oks-cli project list.

oks-cli project list
+------------+---------------+---------------+------------+---------+
|    NAME    |    CREATED    |    UPDATED    |   STATUS   | DEFAULT |
+------------+---------------+---------------+------------+---------+
| mon-projet | 3 minutes ago |  a second ago |   ready    |    *    |
+------------+---------------+---------------+------------+---------+

Ici mon projet est dans l'état ready, ce qui signifie qu'il est prêt à être utilisé. Il est donc possible d'y créer des clusters.

Consultation des projets

Pour lister tous les projets existants :

oks-cli project list --profile production

Résultat (exemple avec un projet)

+------------+------------+-----------+---------------+---------------+------------+---------+
|  PROJECT   |  PROFILE   |   REGION  |    CREATED    |    UPDATED    |   STATUS   | DEFAULT |
+------------+------------+-----------+---------------+---------------+------------+---------+
| demo-guide | production | eu-west-2 |  5 minutes ago|  2 minutes ago|   ready    |         |
+------------+------------+-----------+---------------+---------------+------------+---------+

Cette commande affiche les colonnes suivantes :

• PROJECT : Nom du projet.
• PROFILE : Profil utilisé.
• REGION : Région de déploiement.
• CREATED : Temps écoulé depuis la création.
• UPDATED : Temps écoulé depuis la dernière mise à jour.
• STATUS : État actuel (pending, ready, deleting).
• DEFAULT : Indique si le projet est défini par défaut (*).

Définir un projet par défaut

Pour définir un projet comme projet par défaut :

oks-cli project login \
    --project-name "mon-projet"
Logged into project: mon-projet

Le projet est toujours en cours de création, mais il est déjà défini comme projet par défaut. Vous pouvez vérifier cela avec la commande oks-cli project list.

Mise à jour d'un projet

Certaines propriétés d'un projet peuvent être modifiées après sa création :

oks-cli project update \
    --project-name "mon-projet" \
    --tags "environnement=prod,projet=beta"

Paramètres modifiables :

• --disable-api-termination : Empêche la suppression du projet via l'API si défini sur true.
• --tags : Met à jour les tags associés au projet.

Suppression d'un projet

Pour supprimer un projet :

oks-cli project delete \
    --project-name "demo-guide"

Résultat (avec confirmation)

Are you sure you want to delete the project with name demo-guide? [y/N]: y
{
    "Details": "Project aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee successfully deleted"
}

Conditions :

• Le projet ne doit contenir aucun cluster actif.
• Si --disable-api-termination est défini sur true, il doit être réinitialisé à false avant la suppression.
• La suppression nécessite une confirmation interactive (y).

Création et gestion des clusters OKS

Dans OUTSCALE Kubernetes as a Service (OKS), un cluster est une instance Kubernetes managée, composée d’un plan de contrôle (control plane) et de nœuds de travail (worker nodes). Le plan de contrôle est entièrement géré par OUTSCALE, assurant la gestion et la coordination des ressources du cluster. Lors de la création d'un cluster, seul le plan de contrôle est créé ; les nœuds de travail doivent être ajoutés ultérieurement via des nodepools.

Création d’un cluster

⚠️ Admin whitelist : erreur fréquente

L'option --admin est critique. Si vous ne la configurez pas correctement :

• Aucune IP → cluster inaccessible (vous serez bloqué)
• IP privée RFC1918 (10.x, 172.16-31.x, 192.168.x) → erreur 422 (interdites)
• Astuce débutant : utilisez --admin my-ip pour auto-détecter votre IP publique
• Plusieurs IPs : séparez par virgules --admin "1.2.3.4/32,5.6.7.8/32"

Assurez-vous d'utiliser votre IP publique en notation CIDR (/32 pour une IP unique).

Utilisez la commande suivante pour créer un cluster :

Exemple avec IP manuelle :

oks-cli cluster create \
    --project-name "mon-projet" \
    --cluster-name "mon-cluster" \
    --admin "1.2.3.4/32" \
    --control-plane "cp.3.masters.small" \
    --version "1.31"

Exemple avec auto-détection IP (recommandé) :

oks-cli cluster create \
    --project-name "demo-guide" \
    --cluster-name "test-cluster" \
    --admin my-ip \
    --control-plane "cp.mono.master" \
    --version "1.31" \
    --profile production

Résultat (début du déploiement)

{
    "project_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "id": "11111111-2222-3333-4444-555555555555",
    "name": "test-cluster",
    "description": "",
    "cp_multi_az": false,
    "cp_subregions": [
        "2a"
    ],
    "version": "1.31",
    "cni": "cilium",
    "admin_whitelist": [
        "203.0.113.100/32"
    ],
    "statuses": {
        "created_at": "2026-01-29T08:49:01.097530Z",
        "updated_at": "2026-01-29T08:49:01.097530Z",
        "status": "pending",
        "available_upgrade": ""
    },
    "control_planes": "cp.mono.master",
    "cidr_pods": "10.91.0.0/16",
    "cidr_service": "10.92.0.0/16",
    "cluster_dns": "10.92.0.10"
}

Notez que :

• my-ip a été automatiquement remplacé par votre IP publique (203.0.113.100/32 dans cet exemple)
• Le cluster démarre en status: "pending", puis passe par "deploying" avant d'atteindre "ready" (~10-15 minutes)
• Le CIDR des pods (10.91.0.0/16) et services (10.92.0.0/16) sont attribués automatiquement

Tester sans créer (--dry-run) :

oks-cli cluster create \
    --project-name "mon-projet" \
    --cluster-name "mon-cluster" \
    --admin my-ip \
    --control-plane "cp.3.masters.small" \
    --version "1.31" \
    --dry-run
# Valide la configuration sans créer réellement le cluster

Sortie attendue (simplifiée) :

{
    "project_id": "c4f5d04b-3cdd-4ba7-967e-a8840a5655b7",
    "id": "933d1896-9d94-4033-8ae8-0b1c63feb404",
    "name": "mon-cluster",
    "description": null,
    "cp_multi_az": false,
    "cp_subregions": [
        "2a"
    ],
    "version": "1.31",
    "cni": "cilium",
    "admin_lbu": false,
    "admission_flags": {
        "disable_admission_plugins": [],
        "enable_admission_plugins": [],
        "applied_admission_plugins": [
            "RuntimeClass",
            "DefaultTolerationSeconds",
            "PodSecurity",
            "ServiceAccount",
            "LimitRanger",
            "DefaultStorageClass",
            "ResourceQuota",
            "DefaultIngressClass",
            "ValidatingAdmissionPolicy",
            "Priority",
            "PersistentVolumeClaimResize",
            "NamespaceLifecycle",
            "CertificateSigning",
            "MutatingAdmissionWebhook",
            "ValidatingAdmissionWebhook",
            "ClusterTrustBundleAttest",
            "StorageObjectInUseProtection",
            "CertificateSubjectRestriction",
            "CertificateApproval",
            "TaintNodesByCondition"
        ]
    },
    "cidr_pods": "10.91.0.0/16",
    "cidr_service": "10.92.0.0/16",
    "cluster_dns": "10.92.0.10",
    "tags": {},
    "auto_maintenances": {
        "minor_upgrade_maintenance": {
            "enabled": true,
            "duration_hours": 1,
            "start_hour": 12,
            "week_day": "Tue",
            "tz": "UTC"
        },
        "patch_upgrade_maintenance": {
            "enabled": true,
            "duration_hours": 1,
            "start_hour": 12,
            "week_day": "Tue",
            "tz": "UTC"
        }
    },
    "control_planes": "cp.3.masters.small",
    "admin_whitelist": [
        "1.2.3.4/32"
    ],
    "statuses": {
        "created_at": "2025-06-07T07:32:38.835841Z",
        "deleted_at": null,
        "updated_at": "2025-06-07T07:32:38.835841Z",
        "status": "pending",
        "available_upgrade": ""
    },
    "disable_api_termination": false
}

Paramètres :

• --project-name : Nom du projet existant.
• --cluster-name : Nom unique du cluster (jusqu’à 40 caractères alphanumériques et tirets).
• --admin : Liste des CIDR autorisés à accéder au cluster.
• --control-plane : Type de plan de contrôle souhaité.
• --version : Version de Kubernetes à déployer.

Remarque : Le nom du cluster ne doit pas commencer ou se terminer par un tiret.

Comptez environ 10 minutes pour que le cluster soit créé et passe à l'état ready.

Lister les clusters

Pour afficher la liste des clusters dans un projet :

oks-cli cluster list \
    --project-name "mon-projet"
+--------------------------------------+-------------+---------------+---------------+------------+---------+
|                  ID                  |     NAME    |    CREATED    |    UPDATED    |   STATUS   | DEFAULT |
+--------------------------------------+-------------+---------------+---------------+------------+---------+
| 933d1896-9d94-4033-8ae8-0b1c63feb404 | mon-cluster |  a minute ago |  a minute ago |  pending   |         |
+--------------------------------------+-------------+---------------+---------------+------------+---------+

Cette commande retourne les informations suivantes :

• NAME : Nom du cluster.
• CREATED : Temps écoulé depuis la création.
• UPDATED : Temps écoulé depuis la dernière mise à jour.
• STATUS : État actuel du cluster (pending, ready, deleting).

Obtenir des informations sur un cluster

Pour obtenir des détails sur un cluster spécifique :

oks-cli cluster get --cluster-name test-cluster \
    --project-name "demo-guide"

Résultat (extrait)

{
  "name": "test-cluster",
  "version": "1.31",
  "status": "ready",
  "control_planes": "cp.mono.master",
  "admin_whitelist": [
    "203.0.113.100/32"
  ],
  "cidr_pods": "10.91.0.0/16",
  "cidr_service": "10.92.0.0/16"
}

Mise à jour d’un cluster

Certaines propriétés d’un cluster peuvent être modifiées après sa création. Par exemple, pour mettre à jour la liste des CIDR autorisés :

oks-cli cluster update \
    --project-name "demo-guide" \
    --cluster-name "test-cluster" \
    --admin "203.0.113.42/32"

Résultat

{
  "name": "test-cluster",
  "version": "1.31",
  "status": "updating",
  "control_planes": "cp.mono.master",
  "admin_whitelist": [
    "203.0.113.42/32"
  ]
}

Remarque :

• Les paramètres project-name et profile ne peuvent pas être modifiés après la création du cluster.
• Lors de la mise à jour, le cluster doit être dans un état ready.
• La mise à jour met le cluster dans un état updating jusqu'à ce que la modification soit appliquée (~1-2 minutes).

Suppression d’un cluster

Pour supprimer un cluster :

oks-cli cluster delete \
    --project-name "demo-guide" \
    --cluster-name "test-cluster"

Résultat (avec confirmation)

Are you sure you want to delete the cluster with name test-cluster? [y/N]: y
{
    "Details": "Cluster 11111111-2222-3333-4444-555555555555 successfully deleted"
}

Limitation importante

Vous ne pouvez pas supprimer le dernier nodepool d'un cluster. Si vous essayez :

ERROR: User 'cluster-admin' cannot delete resource 'nodepools' in API group 'oks.dev'
at the cluster scope: can not delete the last remaining oks.dev/nodepools

Solution : Supprimez d'abord le cluster entier, ou créez un second nodepool avant de supprimer le premier.

Conditions :

• Le cluster doit être dans un état ready.
• La suppression nécessite une confirmation interactive (y).

Création et gestion des nodepools OKS

Dans OUTSCALE Kubernetes as a Service (OKS), un nodepool est un groupe homogène de nœuds de travail (worker nodes) au sein d'un cluster. Chaque nodepool contient des nœuds du même type TINA, situés dans une seule région ou répartis sur plusieurs sous-régions.

Création d'un nodepool

Utilisez la commande suivante pour créer un nodepool :

oks-cli cluster \
    --project-name "demo-guide" \
    --cluster-name "test-cluster" \
    nodepool create \
    --nodepool-name "workers" \
    --count 2 \
    --type "tinav6.c2r4p2" \
    --zone "eu-west-2a"

Résultat

nodepool.oks.dev/workers created

Paramètres :

• --project-name : Nom du projet existant.
• --cluster-name : Nom du cluster existant.
• --nodepool-name : Nom unique du nodepool.
• --count : Nombre de nœuds à créer.
• --type : Type de nœud, au format tinavW.cXrYpZ (par exemple, tinav6.c1r1p2) ou tinav6.c1r1p2.gpu pour un nodepool avec GPU.
• --zone : Obligatoire (depuis août 2025). Sous-région où déployer les nœuds (ex: eu-west-2a).

Remarque :

• Tous les nœuds d'un nodepool doivent être du même type. Si vous avez besoin de types différents, créez plusieurs nodepools correspondants.
• Le cluster doit être dans un état ready avant de pouvoir y ajouter des nodepools.
• L'IP depuis la machine où vous exécutez la commande doit être autorisée dans la liste des admins du cluster.

Création via manifest YAML (méthode déclarative)

Pour des configurations avancées (volumes, auto-healing, autoscaling, multi-AZ), utilisez un manifest Kubernetes au lieu de la CLI.

1. Créer le fichier nodepool.yaml :

nodepool.yaml

apiVersion: oks.dev/v1beta2
kind: NodePool
metadata:
  name: workers-prod
spec:
  desiredNodes: 3
  nodeType: tinav6.c4r8p2

  # Multi-AZ pour haute disponibilité
  zones:
    - eu-west-2a
    - eu-west-2b

  # Volumes personnalisés
  volumes:
    - device: root
      size: 100
      type: gp2
      dir: /
    - size: 300
      type: gp2
      dir: /var/lib/longhorn  # Stockage distribué

  # Auto-healing
  autoHealing: true

  # Stratégie de mise à jour rolling
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0
    autoUpgradeEnabled: true
    autoUpgradeMaintenance:
      durationHours: 2
      weekDay: Sun
      startHour: 2  # Dimanche 2h du matin

  # Placement physique (optionnel)
  physicalPlacement:
    nodeRepulseServer: app-backend  # Répartir sur serveurs différents

  # Autoscaling (Beta)
  minNodes: 2
  maxNodes: 10
  autoscaling: true

2. Appliquer le manifest :

# Récupérer le kubeconfig
oks-cli cluster kubeconfig \
    --project-name "demo-guide" \
    --cluster-name "test-cluster" \
    --output kubeconfig.yaml

# Appliquer le nodepool
kubectl apply -f nodepool.yaml --kubeconfig kubeconfig.yaml

Résultat

nodepool.oks.dev/workers-prod created

3. Vérifier le déploiement :

# Lister les nodepools
kubectl get nodepools --kubeconfig kubeconfig.yaml

# Détails complets
kubectl describe nodepool workers-prod --kubeconfig kubeconfig.yaml

Paramètres avancés du manifest :

Paramètre	Description	Exemple
desiredNodes	Nombre de nœuds souhaités	3
nodeType	Format tinavW.cXrYpZ (W=gen CPU, X=vCPUs, Y=RAM Go, Z=perf)	tinav6.c4r8p2
zones	Liste des sous-régions (multi-AZ)	[eu-west-2a, eu-west-2b]
volumes	Disques additionnels (root, gp2, io1, standard)	Voir exemple ci-dessus
autoHealing	Reboot auto si NotReady > 5 min	true / false
upgradeStrategy	Contrôle rolling updates	maxUnavailable: 1
physicalPlacement	Placement serveurs/clusters Cisco UCS	nodeRepulseServer / nodeAttractServer
autoscaling	Scaling auto entre min/max	true + minNodes / maxNodes
fgpu	Support GPU flexible	model: nvidia-p6

Glissez pour voir

Quand utiliser le manifest YAML ?

Privilégiez le manifest pour :

• Multi-AZ : répartir les nœuds sur plusieurs zones (haute dispo).
• Volumes personnalisés : io1 3000 IOPS, Longhorn, Filebeat.
• Auto-healing : remplacement auto des nœuds NotReady.
• Fenêtres de maintenance : upgrades planifiées (dimanche 2h).
• Autoscaling : scaling automatique selon la charge.
• GPU : allocation de fGPUs NVIDIA.

Utilisez oks-cli nodepool create pour des nodepools simples et rapides.

Lister les nodepools

Pour afficher la liste des nodepools d'un cluster :

oks-cli cluster nodepool list \
    --project-name "demo-guide" \
    --cluster-name "test-cluster"

Résultat (en création)

NAME      TYPE            MIN NODES   MAX NODES   DESIRED NODES   ATTACHED   READY   RUNNING   PENDING   STOPPING   STOPPED   SHUTTING DOWN   CURRENT PROCESSING PHASE   LAST ERROR
workers   tinav6.c2r4p2   n/a         n/a         2               0          0       0         2         0          0         0               idle                       None

Résultat (ready après ~5 min)

NAME      TYPE            MIN NODES   MAX NODES   DESIRED NODES   ATTACHED   READY   RUNNING   PENDING   STOPPING   STOPPED   SHUTTING DOWN   CURRENT PROCESSING PHASE   LAST ERROR
workers   tinav6.c2r4p2   n/a         n/a         2               2          2       2         0         0          0         0               idle                       None

La colonne RUNNING indique le nombre de nodes actifs, PENDING ceux en création, READY ceux disponibles.

Résultat

NAME           TYPE            DESIRED NODES   ATTACHED   READY   RUNNING   PENDING   STOPPING   STOPPED   SHUTTING DOWN   CURRENT PROCESSING PHASE   LAST ERROR
mon-nodepool   tinav6.c1r1p2   2               0          0       0         2         0          0         0               creation                   None

Cette commande retourne les informations suivantes :

• NAME : Nom du nodepool.
• TYPE : Type de nœud.
• DESIRED NODES : Nombre de nœuds souhaités.
• ATTACHED : Nombre de nœuds attachés.
• READY : Nombre de nœuds prêts.
• RUNNING : Nombre de nœuds en cours d'exécution.
• PENDING : Nombre de nœuds en attente.
• STOPPING : Nombre de nœuds en cours d'arrêt.
• STOPPED : Nombre de nœuds arrêtés.
• SHUTTING DOWN : Nombre de nœuds en cours de suppression.
• CURRENT PROCESSING PHASE : Phase de traitement actuelle.
• LAST ERROR : Dernière erreur rencontrée.

Suppression d'un nodepool

Pour supprimer un nodepool :

oks-cli cluster nodepool delete \
    --project-name "demo-guide" \
    --cluster-name "test-cluster" \
    --nodepool-name "workers"

Limitation : dernier nodepool

Vous ne pouvez pas supprimer le dernier nodepool d'un cluster. Si vous essayez :

Erreur

ERROR: User 'cluster-admin' cannot delete resource 'nodepools' in API group 'oks.dev'
at the cluster scope: can not delete the last remaining oks.dev/nodepools

Raison : OKS exige qu'un cluster ait au moins un nodepool pour fonctionner.

Solutions :

1. Créer un second nodepool avant de supprimer le premier
2. Supprimer le cluster entier avec oks-cli cluster delete

Remarque : La suppression d'un nodepool entraîne la suppression de tous les nœuds associés (~2-3 minutes).

Accès au cluster Kubernetes

Une fois votre cluster et vos nodepools créés, vous avez deux méthodes pour interagir avec le cluster.

Méthode 1 : kubectl direct (débutant)

La méthode la plus simple utilise oks-cli comme proxy vers kubectl :

oks-cli cluster kubectl \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  get nodes

Résultat

NAME              STATUS   ROLES    AGE    VERSION
ip-10-60-35-89    Ready    <none>   5m     v1.31.13
ip-10-60-59-231   Ready    <none>   5m     v1.31.13

Avantages :

• Pas de gestion de kubeconfig
• Authentification automatique via le profil OKS
• Idéal pour tests rapides

Inconvénient : commandes longues à taper.

Méthode 2 : kubeconfig (usage quotidien)

Pour un usage quotidien, générez un fichier kubeconfig contenant les informations d'accès au cluster.

Prérequis

• Un cluster OKS dans un état ready
• L’OKS CLI installé et configuré
• kubectl installé sur votre machine

Récupérer le fichier kubeconfig

Utilisez la commande suivante pour récupérer le kubeconfig :

oks-cli cluster kubeconfig \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  --print-path

Résultat

/home/user/.oks_cli/cache/PROJECT_ID-CLUSTER_ID/default/default/kubeconfig

Options avancées :

# Kubeconfig valide 2 heures (au lieu de 7 jours par défaut)
oks-cli cluster kubeconfig \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  --ttl 2h \
  --print-path

# Rafraîchir un kubeconfig existant sans le regénérer
oks-cli cluster kubeconfig \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  --refresh \
  --print-path

# Forcer la regénération complète
oks-cli cluster kubeconfig \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  --force \
  --print-path

# Kubeconfig pour un utilisateur/groupe spécifique (RBAC)
oks-cli cluster kubeconfig \
  --project-name "demo-guide" \
  --cluster-name "test-cluster" \
  --user "alice" \
  --group "developers" \
  --print-path

Résultat avec user/group

/home/user/.oks_cli/cache/PROJECT_ID-CLUSTER_ID/alice/developers/kubeconfig

Le fichier est généré dans le répertoire ~/.oks_cli.

Utiliser le kubeconfig avec kubectl

Définissez la variable d’environnement KUBECONFIG pour pointer vers le fichier généré :

export KUBECONFIG="$(oks-cli cluster kubeconfig --project-name "mon-projet" --cluster-name "mon-cluster" --print-path)"

Vous pouvez ensuite interroger le cluster :

kubectl get nodes
NAME              STATUS   ROLES    AGE     VERSION
ip-10-50-59-222   Ready    <none>   6m54s   v1.31.2
ip-10-50-59-77    Ready    <none>   6m54s   v1.31.2

Bonnes pratiques de sécurité

• Le fichier kubeconfig contient des certificats et tokens sensibles : stockez-le avec permissions 600
• TTL par défaut : 7 jours. Ajustez avec --ttl selon vos besoins (ex: 2h pour tests, 1w pour production)
• Utilisez --refresh pour renouveler un kubeconfig sans regénérer complètement
• Pour la gestion d'accès multi-utilisateurs, utilisez --user et --group avec RBAC Kubernetes

Kubeconfig stocké en clair

Le kubeconfig est chiffré en transit mais stocké localement en clair. Assurez-vous que les permissions du fichier sont 600 (chmod 600 ~/.oks_cli/cache/*/kubeconfig) pour éviter les accès non autorisés.

Commandes de diagnostic

En cas de problème, utilisez les commandes suivantes pour diagnostiquer l’état de votre projet, cluster et nodepools :

# Vérifier l'état détaillé d'un projet
oks-cli project get --project-name "mon-projet"

# Vérifier l'état d'un cluster
oks-cli cluster get --project-name "mon-projet" --cluster-name "mon-cluster"

# Lister tous les nodepools avec leur état
oks-cli cluster nodepool list --project-name "mon-projet" --cluster-name "mon-cluster"

# Vérifier la connectivité kubectl
kubectl cluster-info
kubectl get nodes

# Tester l'accès API OUTSCALE
curl -I https://api.eu-west-2.outscale.com/api/v1/
# Résultat attendu : HTTP/2 200

# Afficher la configuration OKS CLI
cat ~/.oks_cli/config.json | jq

Support OUTSCALE

En cas de problème persistant, contactez le support OUTSCALE avec les informations suivantes : ID du projet, ID du cluster, région, logs de la commande oks-cli avec --debug.

À retenir

1. OKS = Kubernetes souverain certifié SecNumCloud : Control plane managé par OUTSCALE, nodepools dédiés sur infrastructure isolée
2. Hiérarchie : Profil → Projet → Cluster → Nodepool : Organisez vos environnements par projet (dev, staging, prod)
3. CIDR immutable : Choisissez une plage /16 dès la création du projet, impossible de la modifier ensuite
4. Control plane managé et facturé : Facturé à l'heure selon le type (cp.mono.master, cp.3.masters.*). Les nodepools sont facturés en plus
5. Kubeconfig valide 7 jours par défaut : Ajustable avec --ttl (ex: 2h, 1w). Utilisez --refresh pour renouveler sans regénérer
6. Nodepools homogènes : Un nodepool = un seul type TINA. Créez plusieurs nodepools pour mixer les types
7. Services par défaut minimaux : Cilium (réseau), CoreDNS, Metrics-server, CSI OUTSCALE. Installez le reste selon vos besoins
8. Timings réels de provisionnement (testés janvier 2025) :
   • Projet : ~3 minutes (status pending → ready)
   • Cluster : ~10-15 minutes (status pending → deploying → ready)
   • Nodepool : ~5 minutes (phase PENDING → RUNNING → READY)
   • Total end-to-end : ~20 minutes pour un cluster prêt à l'emploi

Pièges à éviter

Ces erreurs sont spécifiques à OKS et reviennent régulièrement. Plusieurs touchent des paramètres immuables ou des limitations du service : les anticiper évite des blocages coûteux.

CIDR projet trop petit

oks-cli project create --project-name demo --cidr 10.50.0.0/24

Symptôme : impossible d'ajouter de nouveaux nœuds ou clusters après quelques mois.

Cause : un CIDR /24 ne fournit que 256 IPs. Avec un cluster de 20 nœuds et leurs pods, la plage est vite saturée — et le CIDR est immuable après création.

oks-cli project create --project-name demo --cidr 10.50.0.0/16

Oublier --zone à la création d'un nodepool

oks-cli cluster nodepool create --nodepool-name workers --count 3 --type tinav6.c2r4p2

Symptôme : erreur missing required option '--zone'.

Cause : depuis août 2025, --zone est obligatoire. Sans elle, la commande échoue immédiatement.

oks-cli cluster nodepool create --nodepool-name workers --count 3 \
  --type tinav6.c2r4p2 --zone eu-west-2a

Utiliser une IP privée dans --admin

oks-cli cluster create --project-name demo --cluster-name test --admin 192.168.1.10/32

Symptôme : erreur 422: IP addresses in admin whitelist must be public.

Cause : les IPs privées RFC 1918 (10.x, 172.16-31.x, 192.168.x) sont interdites dans --admin. Seules les IPs publiques sont acceptées.

oks-cli cluster create --project-name demo --cluster-name test --admin my-ip

Kubeconfig expiré après 7 jours

kubectl get nodes
# error: You must be logged in to the server (Unauthorized)

Symptôme : accès au cluster impossible après 7 jours, sans message explicite.

Cause : le kubeconfig expire par défaut au bout de 7 jours. Au-delà, il faut le renouveler.

oks-cli cluster kubeconfig --project-name X --cluster-name Y --refresh --print-path

Bug CLI : profil default requis malgré --profile

oks-cli project list --profile production
# Error: profile [default] not found

Symptôme : l'erreur survient même avec un --profile explicite.

Cause : bug d'OKS CLI v1.18 — la CLI cherche toujours le profil default en plus du profil spécifié.

oks-cli profile add --profile-name default --access-key AK --secret-key SK --region eu-west-2

Impossible de supprimer le dernier nodepool

oks-cli cluster nodepool delete --nodepool-name workers

Symptôme : ERROR: can not delete the last remaining oks.dev/nodepools.

Cause : OKS exige qu'un cluster conserve au moins un nodepool actif — une sécurité contre les clusters vides. Créez un second nodepool avant la suppression, ou supprimez le cluster entier.

oks-cli cluster delete --project-name X --cluster-name Y

Service OKS non activé par le support

Toute commande oks-cli renvoie Error: access denied / unauthorized.

Symptôme : OKS est inutilisable malgré des credentials valides.

Cause : le service OKS doit être activé manuellement par le support OUTSCALE. Prévoyez 24 à 48 h de délai. Contactez support@outscale.com pour faire activer OKS sur votre compte avant toute utilisation.

Supprimer le mauvais cluster par confusion de profil

oks-cli cluster delete --project-name prod-project --cluster-name prod-cluster

Symptôme : un cluster de production est supprimé à la place d'un cluster de dev.

Cause : avec plusieurs profils, on risque d'agir sur le mauvais compte sans s'en rendre compte. Vérifiez toujours le profil actif avant une suppression.

oks-cli profile list && \
  oks-cli cluster delete --project-name dev-project --cluster-name dev-cluster --profile dev

Aide-mémoire

À garder sous la main : la syntaxe générale d'OKS CLI et les commandes les plus courantes pour piloter profils, projets, clusters, nodepools et kubeconfig.

Syntaxe et aide

Syntaxe	Signification	Exemple
oks-cli <ressource> <action> [--options]	Schéma général d'une commande	oks-cli cluster create
oks-cli --help	Aide globale	oks-cli --help
oks-cli <ressource> --help	Aide sur une ressource	oks-cli cluster --help
oks-cli version	Version du CLI	1.18

Glissez pour voir

Profils

Syntaxe	Signification	Exemple
profile add --profile-name X	Ajouter un profil (login/password)	--login user@ex.com --password Y
profile add --profile-name X	Ajouter un profil (access key)	--access-key AK --secret-key SK
profile list	Lister les profils	production, staging
profile delete --profile-name X	Supprimer un profil	production

Glissez pour voir

Projets

Syntaxe	Signification	Exemple
project create --project-name X --cidr Y	Créer un projet (CIDR immuable)	10.50.0.0/16
project list	Lister les projets	demo-guide, prod
project get --project-name X	Détails d'un projet	status: ready
project delete --project-name X	Supprimer un projet	demo-guide

Glissez pour voir

Clusters

Syntaxe	Signification	Exemple
cluster create --project-name X	Créer un cluster HA	--control-plane cp.3.masters.small
--admin my-ip	Auto-détection de l'IP publique	203.0.113.100/32
--dry-run	Tester sans créer	Valide la configuration
cluster list --project-name X	Lister les clusters	test-cluster, prod-cluster
cluster get --cluster-name Y	Détails d'un cluster	version: 1.31, status: ready
cluster delete --cluster-name Y	Supprimer un cluster	Confirmation requise

Glissez pour voir

Nodepools

Syntaxe	Signification	Exemple
nodepool create --nodepool-name Z	Créer un nodepool	--count 3 --type tinav6.c2r4p2
--zone eu-west-2a	Zone obligatoire (depuis août 2025)	eu-west-2a, eu-west-2b, eu-west-2c
nodepool list	Lister les nodepools	workers: 2 RUNNING
nodepool delete --nodepool-name Z	Supprimer un nodepool	Impossible si c'est le dernier

Glissez pour voir

Kubeconfig et accès

Syntaxe	Signification	Exemple
kubeconfig --print-path	Générer le kubeconfig (TTL 7 jours)	~/.oks_cli/cache/PROJECT-CLUSTER/
--ttl 2h	Kubeconfig temporaire	2h, 1w, 30d
--refresh	Rafraîchir sans tout regénérer	Renouvelle le token
--user alice --group devs	Kubeconfig avec RBAC	alice/developers/kubeconfig
export KUBECONFIG="$(... --print-path)"	Utiliser avec kubectl	kubectl get nodes
kubectl get nodes	Vérifier les workers	2 Ready
kubectl cluster-info	URL du control plane	https://cluster.project.oks...

Glissez pour voir

Conclusion

Voilà, vous avez déployé votre premier cluster OKS, configuré et prêt à l’emploi. Vous disposez désormais d’un environnement Kubernetes souverain, épuré et sécurisé, entièrement géré par OUTSCALE.

Prochaines étapes

kubectl : maîtriser l'outil de gestion Kubernetes Commandes essentielles pour piloter votre cluster OKS

Helm : gestionnaire de paquets Kubernetes Déployez des applications complexes en quelques commandes

Sécuriser Kubernetes : bonnes pratiques RBAC, Network Policies, Pod Security Standards

CLI OAPI : piloter l'infrastructure OUTSCALE Automatisez la gestion de vos ressources cloud souveraines

Ressources officielles

• Documentation OUTSCALE Kubernetes (OKS)
• GitHub OUTSCALE
• Blog OUTSCALE

×

📖 Voir la documentation →