Problèmes de scaling Kubernetes : diagnostic et solutions

Le scaling automatique dans Kubernetes peut échouer pour de multiples raisons : limites de ressources, métriques mal configurées, ou contraintes d'infrastructure. Pour tout ingénieur opérations Cloud Kubernetes certification CKS, savoir diagnostiquer et résoudre ces problèmes de scaling Kubernetes est une compétence critique en production.

TL;DR

Les problèmes de scaling se répartissent en trois catégories : configuration HPA/VPA incorrecte, ressources cluster insuffisantes, et métriques manquantes. Le diagnostic commence par kubectl describe hpa et l'analyse des événements cluster.

Pour maîtriser ces compétences, découvrez la formation LFS458 Administration Kubernetes.

Selon le rapport Spectro Cloud State of Kubernetes 2025, 80% des organisations exécutent Kubernetes en production avec une moyenne de 20+ clusters. À cette échelle, les problèmes de scaling impactent directement la disponibilité des services.

Pourquoi le HPA ne scale-t-il pas ? Diagnostic pour l'ingénieur opérations Cloud Kubernetes certification CKS

Le Horizontal Pod Autoscaler (HPA) est un contrôleur qui ajuste automatiquement le nombre de réplicas d'un Deployment selon des métriques observées. Quand il cesse de fonctionner, plusieurs causes sont possibles.

Vérifiez l'état du HPA :

kubectl describe hpa my-app -n production

Sortie typique d'un HPA en échec :

Name:                                                  my-app
Namespace:                                             production
Reference:                                             Deployment/my-app
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 80%
Min replicas:                                          2
Max replicas:                                          10
Conditions:
  Type            Status  Reason                   Message
  ----            ------  ------                   -------
  AbleToScale     True    ReadyForNewScale         recommended size matches current size
  ScalingActive   False   FailedGetResourceMetric  the HPA was unable to compute the replica count

À retenir : dans les métriques signifie que le metrics-server ne collecte pas les données. Vérifiez que metrics-server est déployé et fonctionnel.

kubectl get pods -n kube-system | grep metrics-server
kubectl top pods -n production

Les tutoriels et guides pratiques Kubernetes détaillent la configuration complète du metrics-server.

Les ressources requests sont-elles définies correctement ?

Le HPA calcule l'utilisation CPU/mémoire en pourcentage des requests. Sans requests définies, le calcul est impossible.

Configuration incorrecte :

# ❌ Pas de requests = HPA ne peut pas calculer
spec:
  containers:
    - name: app
      image: my-app:v1
      resources:
        limits:
          cpu: "1"
          memory: "512Mi"

Configuration correcte :

# ✅ Requests définies = HPA fonctionne
spec:
  containers:
    - name: app
      image: my-app:v1
      resources:
        requests:
          cpu: "200m"
          memory: "256Mi"
        limits:
          cpu: "1"
          memory: "512Mi"

Auditez vos Deployments :

kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: requests={.spec.template.spec.containers[0].resources.requests}{"\n"}{end}'

Comme le recommande TealHQ dans son guide Kubernetes DevOps : « Don't let your knowledge remain theoretical - set up a real Kubernetes environment to solidify your skills. »

Comment résoudre les problèmes de métriques custom ?

Pour scaler sur des métriques applicatives (requêtes/seconde, latence), vous devez configurer un adapter de métriques custom.

Déployez prometheus-adapter :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter \
  --namespace monitoring \
  --set prometheus.url=http://prometheus-server.monitoring.svc

Configurez une règle de métrique custom :

# prometheus-adapter-config.yaml
rules:
  - seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
    resources:
      overrides:
        namespace: {resource: "namespace"}
        pod: {resource: "pod"}
    name:
      matches: "^(.*)_total$"
      as: "${1}_per_second"
    metricsQuery: 'rate(<<.Series>>{<<.LabelMatchers>>}[2m])'

À retenir : Les métriques custom nécessitent une configuration explicite de l'adapter. Sans règle correspondante, le HPA affiche FailedGetExternalMetric.

La FAQ déploiement Kubernetes répond aux questions courantes sur cette configuration.

Le cluster a-t-il suffisamment de ressources pour scaler ?

Même avec un HPA correctement configuré, le scaling échoue si le cluster manque de capacité.

Identifiez les Pods en Pending :

kubectl get pods -A | grep Pending
kubectl describe pod <pending-pod> -n <namespace>

Message typique :

Events:
  Type     Reason            Message
  ----     ------            -------
  Warning  FailedScheduling  0/5 nodes are available: 5 Insufficient cpu.

Analysez la capacité cluster :

kubectl top nodes
kubectl describe nodes | grep -A 5 "Allocated resources"

Solutions :

1. Ajoutez des nodes via Cluster Autoscaler
2. Optimisez les requests : souvent surdimensionnées
3. Utilisez des priorités : PriorityClass pour les workloads critiques

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Critical production workloads"

La gestion multi-environnements Kubernetes explique comment isoler les ressources par environnement.

Comment diagnostiquer les problèmes de VPA ? Approche ingénieur opérations Cloud Kubernetes certification CKS

Le Vertical Pod Autoscaler (VPA) ajuste les requests/limits au lieu du nombre de réplicas. Ses problèmes sont différents du HPA.

Installez VPA :

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

Vérifiez les recommandations VPA :

kubectl describe vpa my-app-vpa -n production

Problèmes courants :

Configuration VPA avec garde-fous :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: app
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "2"
          memory: "2Gi"

À retenir : Ne combinez jamais HPA CPU et VPA sur le même Deployment. Utilisez HPA sur métriques custom si vous activez VPA.

Pour approfondir, consultez la formation administrateur système Kubernetes.

Comment optimiser le scaling cluster avec le Cluster Autoscaler ?

Le Cluster Autoscaler ajoute ou supprime des nodes selon la demande de Pods. Son bon fonctionnement est critique pour le scaling horizontal.

Vérifiez les logs du Cluster Autoscaler :

kubectl logs -n kube-system -l app=cluster-autoscaler --tail=100

Erreurs fréquentes :

scale_up: group my-node-pool max size reached

Ajustez les limites du node pool (exemple GKE) :

gcloud container clusters update my-cluster \
  --enable-autoscaling \
  --min-nodes=3 \
  --max-nodes=50 \
  --node-pool=default-pool

Selon le rapport CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. L'autoscaling est devenu un standard.

La section résoudre les erreurs de déploiement Kubernetes couvre d'autres scénarios de dépannage.

Comment débugger les problèmes de scaling liés aux PodDisruptionBudgets ?

Un PDB trop restrictif peut bloquer le scaling en empêchant l'éviction de Pods.

Identifiez les PDB :

kubectl get pdb -A
kubectl describe pdb my-app-pdb -n production

Configuration problématique :

# ❌ Bloque toute éviction si 3 réplicas ou moins
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: my-app

Configuration équilibrée :

# ✅ Permet l'éviction d'un Pod à la fois
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

À retenir : Utilisez maxUnavailable plutôt que minAvailable pour éviter les blocages lors du scale-down.

Pour comprendre l'impact sur les déploiements, consultez migrer vers une architecture GitOps.

Checklist de diagnostic scaling Kubernetes

Exécutez cette séquence lors d'un problème de scaling :

# 1. État du HPA
kubectl get hpa -A
kubectl describe hpa <name> -n <namespace>

# 2. Metrics-server fonctionnel
kubectl top pods -n <namespace>
kubectl top nodes

# 3. Capacité cluster
kubectl describe nodes | grep -E "(Allocatable|Allocated)"

# 4. Pods en attente
kubectl get pods -A --field-selector=status.phase=Pending

# 5. Événements récents
kubectl get events -A --sort-by='.lastTimestamp' | tail -20

# 6. Logs Cluster Autoscaler
kubectl logs -n kube-system -l app=cluster-autoscaler --tail=50

Le pipeline CI/CD pour Kubernetes intègre ces vérifications dans les tests de déploiement.

Passez à l'action : maîtrisez le scaling Kubernetes

Comme l'indique un CTO interrogé par Spectro Cloud : « Just given the capabilities that exist with Kubernetes, and the company's desire to consume more AI tools, we will use Kubernetes more in future. » Maîtriser le scaling est essentiel pour accompagner cette croissance.

Pour développer ces compétences :

• La formation LFS458 Administration Kubernetes couvre l'autoscaling et le troubleshooting sur 4 jours
• La formation LFS460 Sécurité Kubernetes prépare à la certification CKS
• Pour une introduction complète, découvrez Kubernetes, les fondamentaux

Contactez-nous pour un accompagnement personnalisé.