Lab 06 : Autoscaling d’un Cluster OKS

Objectifs du Lab

Dans ce TP, vous allez apprendre à activer et tester l’autoscaling d’un cluster Kubernetes déployé avec OKS. L’objectif est d’observer comment le cluster ajoute ou supprime automatiquement des nœuds en fonction de la charge de travail.

Architecture du TP

À la fin de ce TP, vous saurez :

• Configurer un NodePool avec autoscaling activé.
• Déployer une charge variable sur le cluster.
• Observer le comportement de scale-up et scale-down.

Préparation de l’environnement

Avant de commencer ce TP, assurez-vous de disposer des éléments suivants :

• Un cluster OKS. 👉 Cliquez ici pour accéder au TP de création d’un cluster OKS si ce n’est pas encore fait.

Création du NodePool avec autoscaling

⚠️ Important :

• L’autoscaling n’est pris en charge que pour les NodePools mono-Subregion (mono-AZ).
• Si votre NodePool est déployé sur plusieurs sous-régions (multi-AZ), l’option autoscaling: true ne sera pas fonctionnelle.
• Les nœuds contenant des volumes locaux (par exemple montés via hostPath) sont exclus des opérations d’autoscaling et de mise à jour afin d’éviter toute perte de données.

---

Une fois le cluster OKS opérationnel, nous allons créer un NodePool configuré pour s’adapter automatiquement à la charge.

Étape 1 : Créer le fichier YAML du NodePool

Créez un fichier nommé nodepool.yaml avec le contenu suivant :

apiVersion: oks.dev/v1beta2
kind: NodePool
metadata:
  name: nodepool-01
spec:
  desiredNodes: 2
  minNodes: 2
  maxNodes: 4
  autoscaling: true
  nodeType: tinav7.c2r4p1
  zones:
  - eu-west-2a
  rootVolume:
    storageType: gp2
    size: 20
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0
    autoUpgradeEnabled: true
    autoUpgradeMaintenance:
      durationHours: 1
      startHour: 12
      weekDay: Tue
  autoHealing: true

Appliquez la configuration sur le cluster :

kubectl apply -f nodepool.yaml

Étape 2 : Vérifier la création du NodePool

Listez les NodePools créés :

kubectl get nodepools.oks.dev

Exemple de sortie :

NAME          TYPE             DESIRED NODES   ATTACHED   READY   RUNNING   PENDING   CURRENT PROCESSING PHASE
nodepool-01   tinav7.c2r4p1    2               2          2       2         0         idle

Vérifiez également les nœuds du cluster :

kubectl get nodes

Exemple de sortie :

NAME              STATUS   ROLES    AGE   VERSION
ip-10-50-34-159   Ready    <none>   12d   v1.32.5
ip-10-50-42-1     Ready    <none>   12d   v1.32.5

Test de l’autoscaling avec une charge CPU réelle

Dans cette partie, nous allons déployer une application qui consomme réellement des ressources CPU afin d’observer le comportement de l’autoscaling du cluster OKS.

Cette méthode utilise l’image vish/stress pour simuler une charge CPU et mémoire sur chaque pod.

---

Étape 1 : Créer le fichier stress-test.yaml

Créez un fichier nommé stress-test.yaml avec le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stress-test
spec:
  replicas: 7
  selector:
    matchLabels:
      app: stress
  template:
    metadata:
      labels:
        app: stress
    spec:
      containers:
      - name: stress
        image: vish/stress
        args: ["-cpus", "2"]
        resources:
          requests:
            cpu: "1500m"
            memory: "512Mi"
          limits:
            cpu: "2000m"
            memory: "1Gi"

Appliquez ce déploiement :

kubectl apply -f stress-test.yaml

Une fois le NodePool créé et prêt, nous allons maintenant vérifier son bon fonctionnement en déclenchant une montée en charge simulée.

Étape 2 : Observer le comportement du cluster

Surveillez la création des pods :

kubectl get pods

Exemple de sortie :

NAME                           READY   STATUS    RESTARTS   AGE
stress-test-7dc77b76f5-22phs   1/1     Running   0          2m11s
stress-test-7dc77b76f5-d96bc   0/1     Pending   0          2m11s
stress-test-7dc77b76f5-gvqjc   1/1     Running   0          2m11s
stress-test-7dc77b76f5-nwbwp   0/1     Pending   0          2m11s
stress-test-7dc77b76f5-p9lsw   1/1     Running   0          2m11s
stress-test-7dc77b76f5-qg9lf   1/1     Running   0          2m11s
stress-test-7dc77b76f5-tls8c   1/1     Running   0          2m11s

Puis observez le nombre de nœuds dans le cluster :

kubectl get nodepools.oks.dev

Exemple de sortie :

NAME          TYPE             DESIRED NODES   ATTACHED   READY   RUNNING   PENDING   CURRENT PROCESSING PHASE
nodepool-01   tinav7.c2r4p1    4               3          3       3         0         idle
nodepool-01   tinav7.c2r4p1    4               3          3       3         0         reconciliation
nodepool-01   tinav7.c2r4p1    4               3          3       4         1         reconciliation

Test du scale-down

Après avoir vérifié que le scale-up fonctionne correctement, nous allons maintenant tester le scale-down automatique du cluster.

---

Supprimez le déploiement afin de retirer la charge CPU simulée :

kubectl delete -f stress-test.yaml

Surveillez l’état du cluster et le nombre de nœuds :

kubectl get nodes

Exemple de sortie :

NAME              STATUS   ROLES    AGE   VERSION
ip-10-50-33-211   Ready    <none>   14m   v1.32.5
ip-10-50-34-159   Ready    <none>   12d   v1.32.5
ip-10-50-42-1     Ready    <none>   12d   v1.32.5
ip-10-50-57-106   Ready    <none>   14m   v1.32.5

Après un délai d’environ 10 minutes, l’autoscaler supprime le nœud afin de réduire la capacité inutilisée et les coûts.

Lorsque le scale-down est terminé, le nombre de nœuds doit être revenu à la valeur minimale définie dans le NodePool.

Exemple de sortie :

NAME              STATUS   ROLES    AGE   VERSION
ip-10-50-34-159   Ready    <none>   12d   v1.32.5
ip-10-50-57-106   Ready    <none>   26m   v1.32.5

Résultat attendu

Lors de ce TP :

• Le cluster OKS a automatiquement ajouté des nœuds lorsque la charge CPU a augmenté (scale-up).
• Après environ 10 minutes d’inactivité, il a supprimé les nœuds excédentaires pour revenir à la configuration minimale (minNodes: 2).