Architecture d'OKS
Avant de créer votre premier cluster, il est essentiel de comprendre comment OKS est structuré. Cette architecture en couches déterminera vos choix de configuration et impactera la façon dont vous organiserez vos workloads.
🎯 Objectifs de cette leçon
À la fin de cette leçon, vous saurez :
- Expliquer la hiérarchie OKS (Profil → Projet → Cluster → Nodepool)
- Choisir le bon type de control plane
- Comprendre les versions Kubernetes supportées
La hiérarchie OKS
OKS organise vos ressources selon une hiérarchie stricte à 4 niveaux. Chaque niveau englobe le suivant, un peu comme des poupées russes. Cette organisation permet d'isoler les environnements, de gérer les permissions et de contrôler les coûts par projet.
Pensez à cette hiérarchie comme une entreprise :
- Profil = Votre badge d'entrée
- Projet = Un département avec son budget
- Cluster = Une équipe avec son manager (control plane)
- Nodepool = Les employés qui font le travail
1. Le Profil
Le profil est votre identité sur le cloud OUTSCALE. Il contient vos credentials d'authentification et détermine la région dans laquelle vous travaillez. Vous pouvez avoir plusieurs profils pour gérer différents environnements (dev, prod) ou différentes régions.
Deux modes d'authentification
OKS propose deux façons de s'authentifier, chacune adaptée à un usage spécifique :
| Mode | Avantages | Cas d'usage |
|---|---|---|
| Access Key / Secret Key | Pas d'expiration | CI/CD, scripts |
| Login / Password | Token temporaire | Usage interactif |
Pour l'automatisation (CI/CD, Terraform), préférez les Access Keys. Pour un usage manuel quotidien, le login/password avec token temporaire est plus sécurisé.
# Créer un profil avec AK/SK
oks profile create mon-profil \
--access-key ABCDEFGHIJ1234567890 \
--secret-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
--region eu-west-2
# Créer un profil avec login/password
oks profile create mon-profil \
--login mon-email@exemple.fr \
--region eu-west-2
# (Le mot de passe sera demandé interactivement)
2. Le Projet
Le projet est un environnement réseau isolé. À sa création, OKS provisionne automatiquement un VPC (Virtual Private Cloud) dédié avec le CIDR que vous spécifiez. Ce VPC isole complètement vos clusters des autres projets.
Caractéristiques importantes
Certaines propriétés du projet sont définitives à la création. Il est donc crucial de bien planifier avant de créer un projet :
| Propriété | Modifiable | Notes |
|---|---|---|
| Nom | ❌ Non | Définitif à la création |
| CIDR | ❌ Non | Immutable - Choisissez bien ! |
| Description | ✅ Oui | Peut être mise à jour |
Le CIDR du projet ne peut pas être modifié après création. Choisissez
une plage suffisamment grande (ex: /16 = 65 534 IPs) pour permettre
l'expansion future. Un /24 (254 IPs) sera vite limitant en production.
Exemple de création
oks project create mon-projet \
--description "Environnement de production" \
--cidr 10.0.0.0/16
3. Le Cluster
Le cluster est l'instance Kubernetes elle-même. Il comprend un control plane entièrement géré par OUTSCALE : vous n'avez pas accès aux masters, mais vous n'avez pas non plus à les maintenir.
Types de control planes
Le choix du control plane détermine la haute disponibilité et la capacité maximale de votre cluster. Voici les options disponibles :
| Type | Masters | Max Nodes | RAM | Usage |
|---|---|---|---|---|
cp.mono.master | 1 | 10 | 4 Go | 🧪 Tests, POC |
cp.3.masters.small | 3 | 50 | 12 Go | 🏢 Petite production |
cp.3.masters.medium | 3 | 200 | 24 Go | 🏭 Production moyenne |
cp.3.masters.large | 3 | 400 | 48 Go | 🏗️ Grande production |
- Développement/Tests →
cp.mono.master(économique, pas de HA) - Production →
cp.3.masters.*(haute disponibilité obligatoire) - Sizing → Comptez vos nodes actuels + 50% de marge de croissance
Versions Kubernetes supportées
OKS maintient les 5 dernières versions mineures de Kubernetes. Cela vous laisse le temps de planifier vos mises à jour tout en bénéficiant des dernières fonctionnalités :
| Version | Status | Notes |
|---|---|---|
| 1.32 | ✅ Actuelle | Dernière version stable |
| 1.31 | ✅ | Recommandée pour la production |
| 1.30 | ✅ | Support complet |
| 1.29 | ✅ | Support complet |
| 1.28 | ⚠️ | Fin de support proche |
Les patches de sécurité (ex: 1.31.1 → 1.31.2) sont appliqués automatiquement par OUTSCALE. Les mises à jour mineures (ex: 1.30 → 1.31) restent manuelles pour vous laisser le contrôle.
4. Le Nodepool
Le nodepool (ou pool de nœuds) est un groupe de worker nodes homogènes qui exécutent vos applications. Un cluster peut avoir plusieurs nodepools avec des caractéristiques différentes, par exemple un pool standard et un pool GPU.
Caractéristiques d'un nodepool
Chaque nodepool définit le type de machines utilisées et leur nombre. Vous pouvez aussi y attacher des labels pour diriger vos workloads :
| Propriété | Description |
|---|---|
| Type de VM | Taille des instances (CPU, RAM) |
| Nombre de nodes | Fixe ou dynamique (autoscaling) |
| Zone | Sous-région de déploiement |
| Labels | Pour cibler les déploiements Kubernetes |
Types de VM disponibles
Les VMs OUTSCALE utilisent une nomenclature standardisée qui encode directement les caractéristiques de la machine :
tinav6.c2r4p2
│ │ │
│ │ └── Génération réseau (p2 = standard)
│ └──── RAM en Go (r4 = 4 Go)
└────── CPU cores (c2 = 2 vCPU)
Voici les types les plus couramment utilisés :
| Type | vCPU | RAM | Usage type |
|---|---|---|---|
tinav6.c1r1p2 | 1 | 1 Go | Micro services légers |
tinav6.c2r4p2 | 2 | 4 Go | Applications standard |
tinav6.c4r8p2 | 4 | 8 Go | Applications gourmandes |
tinav6.c8r16p2 | 8 | 16 Go | Bases de données |
tinav6.c16r32p2 | 16 | 32 Go | Big Data, ML |
Schéma complet de l'architecture
Ce schéma récapitule tous les niveaux de la hiérarchie OKS et montre comment les différents composants s'imbriquent :
📌 Points clés à retenir
- Hiérarchie stricte : Profil → Projet → Cluster → Nodepool
- CIDR immutable : Planifiez votre adressage réseau dès le départ
- Control plane :
mono.masterpour les tests,3.masters.*pour prod - Versions K8s : 5 versions maintenues, patches automatiques
- Nodepools multiples : Mixez différents types de VMs (standard, GPU)
Prochaine étape
Maintenant que vous comprenez l'architecture, passons à la pratique : dans le prochain module, nous allons installer OKS CLI et configurer notre environnement de travail.