Déployer un cluster Kubernetes chez OUTSCALE avec OKS

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.

Workflow de déploiement OKS

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.

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.

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.

É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

Vérifiez l’installation :

oks-cli version

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.

Structure d'une commande OKS CLI : oks-cli + ressource + action + options

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

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

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

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"

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

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

{
    "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

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

{
    "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

{
    "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

+------------+------------+-----------+---------------+---------------+------------+---------+
|  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"

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

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

{
    "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"

{
  "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"

{
  "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"

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"
}

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"

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 :

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

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`

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"

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

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.

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"

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

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

Solutions :

Créer un second nodepool avant de supprimer le premier
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

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

/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

/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

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

À retenir

OKS = Kubernetes souverain certifié SecNumCloud : Control plane managé par OUTSCALE, nodepools dédiés sur infrastructure isolée
Hiérarchie : Profil → Projet → Cluster → Nodepool : Organisez vos environnements par projet (dev, staging, prod)
CIDR immutable : Choisissez une plage /16 dès la création du projet, impossible de la modifier ensuite
Control plane managé et facturé : Facturé à l’heure selon le type (cp.mono.master, cp.3.masters.*). Les nodepools sont facturés en plus
Kubeconfig valide 7 jours par défaut : Ajustable avec --ttl (ex: 2h, 1w). Utilisez --refresh pour renouveler sans regénérer
Nodepools homogènes : Un nodepool = un seul type TINA. Créez plusieurs nodepools pour mixer les types
Services par défaut minimaux : Cilium (réseau), CoreDNS, Metrics-server, CSI OUTSCALE. Installez le reste selon vos besoins
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 courantes peuvent faire perdre du temps ou causer des dégâts. Les pièges les plus critiques sont affichés en premier.

Danger

Le piège : oks-cli project create --project-name demo --cidr 10.50.0.0/24

Symptôme : Impossible d'ajouter plus de nœuds ou de clusters après quelques mois

Cause : CIDR /24 = 256 IPs. Avec 1 cluster de 20 nodes + pods, vous êtes vite limité. Le CIDR est **immutable** après création.

Correction : Utiliser un CIDR /16 minimum (65k IPs) pour anticiper la croissance

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

Danger

Le piège : 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 lui, la commande échoue immédiatement.

Correction : Toujours spécifier la zone (eu-west-2a, eu-west-2b ou eu-west-2c)

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

Danger

Le piège : 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 RFC1918 (10.x, 172.16-31.x, 192.168.x) sont **interdites** dans --admin. Seules les IPs publiques sont acceptées.

Correction : Utiliser 'my-ip' pour auto-détection ou votre IP publique réelle

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

Danger

Le piège : Toute commande oks-cli → Error: access denied / unauthorized

Symptôme : Impossible d'utiliser OKS malgré des credentials valides

Cause : Le service OKS doit être **activé manuellement** par le support OUTSCALE. Prévoyez 24-48h de délai.

Correction : Contacter support@outscale.com pour activer OKS sur votre compte avant toute utilisation

Danger

Le piège : oks-cli cluster delete --project-name prod-project --cluster-name prod-cluster

Symptôme : Cluster de production supprimé au lieu de dev

Cause : Si vous avez plusieurs profils, vous risquez de supprimer sur le mauvais compte sans le vouloir.

Correction : Toujours vérifier le profil actif avec 'profile list' avant toute suppression

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

Attention

Le piège : kubectl get nodes → error: You must be logged in to the server (Unauthorized)

Symptôme : Impossible d'accéder au cluster après 7 jours sans message explicite

Cause : Le kubeconfig expire par défaut après **7 jours**. Au-delà, vous devez le renouveler.

Correction : Utiliser --refresh pour renouveler le token sans tout regénérer

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

Attention

Le piège : oks-cli project list --profile production → Error: profile [default] not found

Symptôme : Erreur même avec --profile explicite

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

Correction : Créer un profil 'default' même si vous utilisez d'autres profils

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

Attention

Le piège : 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 ait **au moins 1 nodepool** actif. Sécurité pour éviter un cluster vide.

Correction : Créer un second nodepool avant suppression, OU supprimer le cluster entier

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

Aide-mémoire

📝 Syntaxe :

oks-cli <ressource> <action> [--options] Schéma général

oks-cli --help Aide globale

oks-cli <ressource> --help Aide sur une ressource

oks-cli version Version du CLI

⚙️ Options

`profile add --profile-name X`	Ajouter profil (login/password)	`--login user@ex.com --password Y`
`profile add --profile-name X`	Ajouter 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`

🔍 Filtres

`project create --project-name X --cidr Y`	Créer un projet (CIDR immutable)	`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`

🎯 Conditions

`cluster create --project-name X`	Créer un cluster HA	`--control-plane cp.3.masters.small`
`--admin my-ip`	Auto-détection IP publique	`203.0.113.100/32`
`--dry-run`	Tester sans créer	`Valide la config`
`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`

⚡ Actions

`nodepool create --nodepool-name Z`	Créer un nodepool	`--count 3 --type tinav6.c2r4p2`
`--zone eu-west-2a`	Zone obligatoire (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 dernier`

🔗 Composition

`kubeconfig --print-path`	Générer kubeconfig (TTL 7j)	`~/.oks_cli/cache/PROJECT-CLUSTER/`
`--ttl 2h`	Kubeconfig temporaire	`2h, 1w, 30d`
`--refresh`	Rafraîchir sans regénérer	`Renouvelle le token`
`--user alice --group devs`	Kubeconfig 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 control plane	`https://cluster.project.oks...`

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

Déployer un cluster Kubernetes chez OUTSCALE avec OKS

Ce que vous allez apprendre

Vous voulez trouver de l’info rapidement sur …

Comment fonctionne OKS ?

Profils OKS

Projets

Clusters

Nodepools

Installation et configuration de l’OKS CLI

Prérequis système

Étapes d’installation

Comment fonctionne OKS CLI ?

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

Points clés

Règles d'or

Vocabulaire essentiel

Configuration de l’OKS CLI

Activation de l’autocomplétion

Ajout d’un profil OKS

Vérifier les quotas disponibles

Création et gestion des projets OKS

Création d’un projet

Consultation des projets

Définir un projet par défaut

Mise à jour d’un projet

Suppression d’un projet

Création et gestion des clusters OKS

Création d’un cluster

Lister les clusters

Obtenir des informations sur un cluster

Mise à jour d’un cluster

Suppression d’un cluster

Création et gestion des nodepools OKS

Création d’un nodepool

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

Lister les nodepools

Suppression d’un nodepool

Accès au cluster Kubernetes

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

Méthode 2 : kubeconfig (usage quotidien)

Prérequis

Récupérer le fichier kubeconfig

Utiliser le kubeconfig avec kubectl

Bonnes pratiques de sécurité

Commandes de diagnostic

À retenir

Pièges à éviter

Aide-mémoire

📋 Cheatsheet oks-cli

📝 Syntaxe :

⚙️ Options

🔍 Filtres

🎯 Conditions

⚡ Actions

🔗 Composition

Conclusion

Prochaines étapes

Ressources officielles

Récupérer le fichier `kubeconfig`

Utiliser le `kubeconfig` avec `kubectl`

📋 Cheatsheet `oks-cli`