Rolling Updates et Rollbacks Kubernetes : mises à jour progressives

Comment mettre à jour une application en production avec un risque d'interruption minimal ? Kubernetes propose les rolling updates : vos nouveaux Pods démarrent progressivement pendant que les anciens sont supprimés. Si quelque chose se passe mal, un rollback déclenche un nouveau déploiement vers une révision précédente.

Ce guide vous montre comment configurer des mises à jour progressives fiables et revenir en arrière si nécessaire.

Prérequis : Deployments Kubernetes et kubectl configuré.

Ce que vous allez apprendre

• Déclencher une rolling update avec kubectl set image ou en modifiant le manifeste
• Suivre la progression avec kubectl rollout status
• Configurer la stratégie de déploiement (maxSurge, maxUnavailable)
• Détecter un rollout bloqué avec progressDeadlineSeconds
• Effectuer un rollback vers une version précédente
• Consulter et annoter l'historique des révisions

Comment fonctionne une rolling update

Un Deployment ne pilote pas directement les Pods : il crée un ReplicaSet, l'objet qui maintient un nombre donné de copies identiques. Une mise à jour ne modifie donc jamais les Pods existants, elle fait cohabiter deux ReplicaSets le temps du basculement. Le contrôleur ajuste le compteur de réplicas de chacun jusqu'à ce que l'ancien tombe à zéro.

Quand vous modifiez le Pod template (.spec.template) d'un Deployment, Kubernetes :

1. Crée un nouveau ReplicaSet pour la nouvelle version
2. Augmente progressivement le nouveau ReplicaSet
3. Attend que les nouveaux Pods deviennent Ready, puis Available (si minReadySeconds est défini)
4. Réduit l'ancien ReplicaSet au fur et à mesure
5. Considère le rollout complet quand toutes les nouvelles réplicas sont disponibles et qu'aucune ancienne ne tourne

Ready vs Available

Un Pod Ready répond positivement à sa readinessProbe. Un Pod Available est Ready depuis au moins minReadySeconds. Le rollout progresse quand les Pods deviennent Ready ou Available selon la configuration.

Ce qui déclenche un rollout

Seules les modifications du Pod template (.spec.template) déclenchent une nouvelle révision. Un kubectl scale ne crée pas de nouvelle révision, il ajuste simplement le nombre de réplicas du ReplicaSet actuel.

Déclencher une rolling update

Trois façons d'obtenir le même résultat, qui diffèrent par ce qu'elles laissent derrière elles. Les deux méthodes impératives (set image et edit) modifient l'objet dans le cluster sans toucher à vos fichiers : votre dépôt Git ne reflète plus la réalité tant que vous ne l'avez pas mis à jour. La méthode déclarative reste la seule cohérente avec une gestion en GitOps.

Méthode 1 : kubectl set image

La façon la plus rapide de mettre à jour l'image :

kubectl set image deployment/mon-app conteneur=image:nouvelle-version

Exemple :

kubectl set image deployment/nginx-rolling nginx=nginx:1.25

Méthode 2 : modifier le manifeste

Changez l'image dans votre fichier YAML :

deployment.yaml

spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25  # Anciennement 1.24

Puis appliquez :

kubectl apply -f deployment.yaml

Méthode 3 : kubectl edit

kubectl edit ouvre le manifeste courant dans l'éditeur défini par la variable KUBE_EDITOR ou EDITOR, et applique la modification à l'enregistrement du fichier.

kubectl edit deployment/mon-app

Modifiez l'image dans l'éditeur qui s'ouvre, puis sauvegardez.

Suivre la progression

Trois niveaux d'observation répondent à trois questions différentes : le rollout avance-t-il, quels Pods sont concernés, et où en sont les deux ReplicaSets. Commencez par le premier, descendez aux suivants seulement si quelque chose bloque.

Statut en temps réel

La commande reste attachée au terminal et affiche une ligne à chaque progression, jusqu'à la fin du rollout ou son échec :

kubectl rollout status deployment/nginx-rolling

Sortie :

Waiting for deployment "nginx-rolling" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-rolling" rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-rolling" successfully rolled out

Observer les Pods

L'option -w (watch) laisse la commande ouverte et affiche une nouvelle ligne à chaque changement d'état, ce qui rend visible le remplacement en direct :

kubectl get pods -l app=nginx-rolling -w

Vous verrez les nouveaux Pods apparaître (ContainerCreating → Running) et les anciens disparaître (Terminating).

Voir les ReplicaSets

C'est la vue la plus parlante pour comprendre un rollout : chaque révision correspond à un ReplicaSet distinct, et la colonne DESIRED montre où en est le transfert de réplicas de l'un vers l'autre.

kubectl get rs -l app=nginx-rolling

Sortie :

NAME                       DESIRED   CURRENT   READY   AGE
nginx-rolling-64757d479    0         0         0       5m    # Ancien
nginx-rolling-7bf8c77b47   3         3         3       30s   # Nouveau

L'ancien ReplicaSet reste (DESIRED=0) pour permettre un rollback.

Configurer la stratégie de déploiement

Le rythme du remplacement se règle dans .spec.strategy, et l'arbitrage est toujours le même : plus vous acceptez de Pods indisponibles, plus la mise à jour est rapide ; plus vous exigez de disponibilité, plus il faut de ressources libres dans le cluster. Deux paramètres suffisent à décrire ce compromis, complétés par deux garde-fous temporels.

Les paramètres clés

Ce manifeste regroupe les quatre réglages qui gouvernent un rollout, avec la readinessProbe sans laquelle aucun d'eux n'a de sens :

deployment-strategy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-rolling
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Combien de Pods en plus pendant l'update
      maxUnavailable: 1  # Combien de Pods peuvent être indisponibles
  progressDeadlineSeconds: 600  # Timeout pour détecter un rollout bloqué
  minReadySeconds: 10           # Attendre 10s après Ready avant de continuer
  selector:
    matchLabels:
      app: nginx-rolling
  template:
    metadata:
      labels:
        app: nginx-rolling
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3

maxSurge et maxUnavailable

Ces deux valeurs s'expriment en nombre entier de Pods ou en pourcentage du champ replicas. maxSurge est arrondi à l'entier supérieur, maxUnavailable à l'entier inférieur. Elles ne peuvent pas valoir zéro toutes les deux : le rollout n'aurait alors aucun moyen de progresser, et l'API rejette le manifeste.

Paramètre	Valeur par défaut	Description
maxSurge	25%	Nombre de Pods supplémentaires créés pendant l'update (au-delà de replicas)
maxUnavailable	25%	Nombre maximal de Pods pouvant être indisponibles pendant l'update

Glissez pour voir

Valeurs par défaut

Si vous ne spécifiez pas ces paramètres, Kubernetes utilise 25% pour les deux. Avec 4 réplicas, cela signifie 1 Pod en surge et 1 Pod pouvant être indisponible.

Comprendre maxUnavailable

maxUnavailable contrôle combien de Pods peuvent être indisponibles (pas juste "non-Running"). Un Pod peut être Running sans être Ready ni Available, c'est la disponibilité qui compte, pas l'état Running.

Valeur	Effet
maxUnavailable: 1	1 Pod peut être indisponible pendant l'update
maxUnavailable: 25%	25% des Pods peuvent être indisponibles (arrondi à l'inférieur)
maxUnavailable: 0	Aucun Pod ne doit devenir indisponible, rollout plus prudent mais plus lent

Glissez pour voir

Exemples de stratégies

Deux réglages opposés, à choisir selon ce que vous pouvez sacrifier. Le premier remplace la moitié de la flotte d'un coup et convient à un environnement de recette ; le second ne retire jamais un Pod avant d'en avoir un nouveau prêt, au prix d'une capacité supplémentaire à mobiliser pendant toute la durée de l'opération.

Mise à jour rapide (priorité à la vitesse) :

strategy:
  rollingUpdate:
    maxSurge: 50%
    maxUnavailable: 50%

Mise à jour prudente (priorité à la disponibilité) :

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Ressources requises

Avec maxUnavailable: 0, Kubernetes doit créer les nouveaux Pods avant de supprimer les anciens. Votre cluster doit avoir suffisamment de ressources pour accueillir temporairement plus de Pods.

Détecter un rollout bloqué

Un rollout qui n'aboutit pas ne s'annule pas tout seul : les anciens Pods continuent de servir le trafic et le Deployment reste indéfiniment en cours. Sans minuteur, personne ne s'en aperçoit avant la prochaine consultation manuelle. Kubernetes fournit un délai de non-progression qui bascule le Deployment en échec et rend la situation détectable par une supervision.

progressDeadlineSeconds

Ce paramètre définit le délai après lequel Kubernetes considère que le rollout n'avance plus :

spec:
  progressDeadlineSeconds: 600  # 10 minutes

Si le rollout n'a pas progressé pendant cette durée (pas de nouveau Pod Ready/Available), le contrôleur marque le Deployment comme failed dans son statut.

Vérifier le statut :

kubectl describe deployment/nginx-rolling | grep -A 5 "Conditions"

Sortie si bloqué :

Conditions:
  Type           Status   Reason
  ----           ------   ------
  Available      True     MinimumReplicasAvailable
  Progressing    False    ProgressDeadlineExceeded

Valeur recommandée

Définissez progressDeadlineSeconds légèrement supérieur au temps normal de démarrage de votre application. Trop court = faux positifs. Trop long = détection tardive des problèmes.

Revérifier avec kubectl rollout status

L'option --timeout borne l'attente côté client, indépendamment de progressDeadlineSeconds qui agit côté contrôleur. C'est ce qui rend la commande utilisable comme étape bloquante dans un pipeline de déploiement.

kubectl rollout status deployment/nginx-rolling --timeout=5m

La commande retourne un code d'erreur si le rollout échoue ou dépasse le timeout.

Stratégie Recreate (arrêt complet)

Recreate est la seule alternative à RollingUpdate dans un Deployment. Elle supprime la totalité des Pods de l'ancienne révision, attend leur disparition effective, puis crée ceux de la nouvelle. Les paramètres maxSurge et maxUnavailable ne s'appliquent pas à cette stratégie, il n'y a rien à doser :

spec:
  strategy:
    type: Recreate

Interruption de service

La stratégie Recreate tue tous les anciens Pods avant de créer les nouveaux. Cela provoque une interruption de service complète pendant la mise à jour.

Quand utiliser Recreate

Recreate convient pour :

• Migrations de schéma incompatibles avec la cohabitation de versions
• Applications qui ne supportent pas plusieurs instances en parallèle

Cependant, si vous avez besoin de garanties fortes sur l'identité et l'ordre des Pods (base de données, systèmes distribués), un StatefulSet est généralement plus adapté qu'un Deployment avec Recreate.

Rollback : revenir en arrière

Un rollback déclenche un nouveau rollout vers une révision précédente. Ce n'est pas un basculement instantané, Kubernetes applique la même stratégie de rolling update pour revenir en arrière.

Rollback vers la révision précédente

Sans argument, undo restaure le Pod template de l'avant-dernière révision et l'enregistre comme une nouvelle révision : l'historique s'allonge, il ne recule pas.

kubectl rollout undo deployment/nginx-rolling

Sortie :

deployment.apps/nginx-rolling rolled back

Vérifier la version restaurée

L'expression jsonpath extrait un seul champ de l'objet, ici l'image du premier conteneur, ce qui évite de relire tout le manifeste pour confirmer le retour arrière :

kubectl get deployment nginx-rolling -o jsonpath='{.spec.template.spec.containers[0].image}'

Consulter l'historique des révisions

Chaque révision correspond à un ancien ReplicaSet encore conservé. La colonne CHANGE-CAUSE affiche <none> tant que l'annotation dédiée n'a pas été posée, ce qui est le cas par défaut :

kubectl rollout history deployment/nginx-rolling

Sortie :

REVISION  CHANGE-CAUSE
1         Initial deployment
2         Upgrade vers nginx 1.25 pour CVE-2024-xxxx
3         <none>

Rollback vers une révision spécifique

--to-revision prend un numéro issu de la colonne REVISION de l'historique ; si ce numéro n'existe plus, la commande échoue sans rien modifier.

kubectl rollout undo deployment/nginx-rolling --to-revision=1

Voir les détails d'une révision

Avec --revision, la commande affiche le Pod template complet enregistré à ce moment-là : image, variables d'environnement, probes. C'est le seul moyen de vérifier vers quoi vous allez revenir avant de lancer le rollback.

kubectl rollout history deployment/nginx-rolling --revision=2

Annoter les changements

L'historique des révisions ne conserve aucune trace de la raison d'un déploiement : face à cinq révisions, rien ne distingue un correctif de sécurité d'un changement de configuration. L'ancienne option --record qui remplissait ce champ automatiquement est dépréciée, la mention doit désormais être posée explicitement. Pour garder une trace des raisons de chaque déploiement, annotez avec kubernetes.io/change-cause :

kubectl annotate deployment/nginx-rolling \
  kubernetes.io/change-cause="Upgrade vers nginx 1.25 pour CVE-2024-xxxx"

Ou définissez l'annotation dans le manifeste :

metadata:
  annotations:
    kubernetes.io/change-cause: "Upgrade vers nginx 1.25 pour CVE-2024-xxxx"

Bonne pratique

Annotez vos déploiements avec une raison claire. Cela facilite l'identification de la bonne révision lors d'un rollback et documente l'historique des changements.

Limiter l'historique des révisions

Chaque révision conservée laisse un ReplicaSet à zéro réplica dans le namespace. Ces objets ne consomment ni CPU ni mémoire, mais ils encombrent les listes et alourdissent les requêtes à l'API sur un cluster qui déploie plusieurs fois par jour. Par défaut, Kubernetes conserve 10 révisions (anciens ReplicaSets). Pour économiser de l'espace :

spec:
  revisionHistoryLimit: 5

revisionHistoryLimit: 0

Avec revisionHistoryLimit: 0, Kubernetes supprime immédiatement tous les anciens ReplicaSets. Vous ne pourrez plus faire de rollback car l'historique est vide.

Pause et reprise d'un rollout

Mettre un Deployment en pause suspend la prise en compte des modifications du Pod template : vous pouvez enchaîner plusieurs changements sans qu'aucun ne déclenche de rollout. Rien ne repart tant que la reprise n'a pas été demandée, et un Deployment laissé en pause reste dans cet état indéfiniment.

Mettre en pause

La pause s'applique immédiatement, y compris au milieu d'un rollout déjà lancé, qui se fige alors dans son état intermédiaire :

kubectl rollout pause deployment/nginx-rolling

Utile pour :

• Faire plusieurs modifications avant de reprendre (évite des rollouts intermédiaires)
• Investiguer un problème sans que le rollout continue

Reprendre

La reprise applique en une seule fois toutes les modifications accumulées pendant la pause, et ne crée donc qu'une seule nouvelle révision :

kubectl rollout resume deployment/nginx-rolling

Rollback impossible si pausé

Vous ne pouvez pas faire de rollback sur un Deployment en pause. Vous devez d'abord le reprendre avec kubectl rollout resume, puis effectuer le rollback.

Pause ≠ Canary natif

Mettre en pause un rollout après set image n'est pas une stratégie canary. Kubernetes ne fait pas de répartition de trafic contrôlée, il remplace progressivement les Pods selon sa stratégie. Pour un vrai canary avec contrôle du trafic, utilisez :

• Deux Deployments avec un Ingress/Service qui répartit le trafic
• Argo Rollouts ou Flagger
• Un service mesh (Istio, Linkerd)

Rollouts multiples en cours (rollover)

Rien n'oblige à attendre la fin d'un rollout pour en lancer un autre. Kubernetes ne met pas les mises à jour en file d'attente : il abandonne celle en cours au profit de la dernière demandée. Le comportement est sain, mais il rend l'état du cluster difficile à lire quand plusieurs déploiements s'enchaînent en quelques secondes.

Si vous modifiez à nouveau le Deployment pendant qu'un rollout est en cours, Kubernetes :

1. Crée un nouveau ReplicaSet pour la dernière version
2. Commence à abandonner le rollout précédent
3. Scale down le ReplicaSet de la version intermédiaire

Exemple :

# Rollout en cours vers v2
kubectl set image deployment/app app=image:v2

# Avant que v2 soit complètement déployé, vous changez pour v3
kubectl set image deployment/app app=image:v3

Kubernetes va progressivement abandonner v2 et passer directement à v3.

Comportement documenté

C'est le comportement normal de Kubernetes, appelé rollover. Il évite de terminer un rollout vers une version intermédiaire que vous ne voulez plus. Cependant, cela peut créer de la confusion si plusieurs apply s'enchaînent rapidement en production.

Tableau de décision

Il n'existe pas de réglage universellement bon : le bon choix dépend de la contrainte qui vous limite, disponibilité, vitesse ou capacité disponible. Repérez la ligne qui décrit votre situation et appliquez la combinaison correspondante, quitte à la valider en recette avant la production.

Situation	Réglage conseillé
Priorité à la disponibilité	maxUnavailable: 0, maxSurge faible, readinessProbe, minReadySeconds
Priorité à la rapidité	maxSurge élevé (50%+), maxUnavailable non nul
Cluster contraint en ressources	Rolling update conservateur, maxSurge faible, éviter le surge
Application fragile au démarrage	readinessProbe stricte, minReadySeconds élevé, progressDeadlineSeconds adapté
Déploiement bleu-vert	maxSurge: 100%, maxUnavailable: 0 (double temporaire des ressources)
Migration incompatible	Stratégie Recreate ou StatefulSet

Glissez pour voir

Bonnes pratiques

Ces cinq réglages se posent une fois dans le manifeste et couvrent l'essentiel des incidents de déploiement. Les trois premiers déterminent si Kubernetes sait reconnaître qu'un Pod est réellement opérationnel, les deux derniers conditionnent votre capacité à revenir en arrière.

1. Toujours configurer une readinessProbe

Sans readinessProbe, Kubernetes risque de considérer un Pod disponible trop tôt, ce qui peut dégrader le rollout et exposer des Pods non réellement prêts au trafic.

spec:
  containers:
  - name: app
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 3
      failureThreshold: 3

2. Définir minReadySeconds

Attendez quelques secondes après le Ready avant de continuer le rollout :

spec:
  minReadySeconds: 10  # Le Pod doit être Ready pendant 10s avant d'être considéré Available

3. Définir progressDeadlineSeconds

Détectez automatiquement les rollouts bloqués :

spec:
  progressDeadlineSeconds: 600  # 10 minutes

4. Annoter les déploiements

Une annotation posée au moment du déploiement vous fera gagner un temps considérable le jour où il faudra choisir une révision de repli sous pression.

kubectl annotate deployment/app \
  kubernetes.io/change-cause="Upgrade vers v2.1 - fix bug #1234"

5. Conserver un historique raisonnable

Trois à cinq révisions suffisent en pratique : au-delà, la configuration a généralement trop divergé pour qu'un retour arrière soit encore pertinent.

spec:
  revisionHistoryLimit: 5  # Pas 0, sinon pas de rollback possible

Anti-patterns à éviter

Ces erreurs ont un point commun : elles ne se voient pas au moment où on les commet, seulement le jour de l'incident. Un Deployment sans probe se déploie parfaitement bien jusqu'à ce qu'il expose des Pods qui ne répondent pas encore.

Anti-pattern	Problème	Solution
Pas de readinessProbe	Pods exposés avant d'être prêts	Configurer une probe réaliste
revisionHistoryLimit: 0	Impossible de faire un rollback	Garder au moins 3-5 révisions
Rollback sur Deployment pausé	Échoue	Reprendre d'abord avec resume
Supposer "zéro downtime" garanti	Le rollout dépend de la config et des ressources	Configurer stratégie + probes + tests
Utiliser Recreate pour la persistance	Interruption de service, pas de garantie d'ordre	Utiliser un StatefulSet
Modifier le selector après création	Immutable en apps/v1	Recréer le Deployment si nécessaire
Enchaîner les apply sans vérifier	Rollover peut créer de la confusion	Attendre rollout status entre les déploiements

Glissez pour voir

Dépannage

Le réflexe est toujours le même face à un rollout qui n'aboutit pas : regarder l'état des nouveaux Pods avant de toucher au Deployment. Le tableau associe chaque symptôme visible à sa cause la plus fréquente ; les commandes de diagnostic suivent.

Symptôme	Cause probable	Solution
Rollout bloqué à "Waiting"	Nouveaux Pods pas Ready	Vérifier les logs et les probes
ProgressDeadlineExceeded	Rollout n'avance plus depuis X secondes	Investiguer les Pods, éventuellement rollback
Pods en CrashLoopBackOff	Erreur dans la nouvelle image	Rollback immédiat
Rollout très lent	maxUnavailable: 0 + ressources limitées	Augmenter maxSurge ou les ressources
Historique vide	revisionHistoryLimit: 0	Augmenter la limite
Rollback échoue	Deployment pausé	kubectl rollout resume d'abord
Anciens Pods qui ne disparaissent pas	terminationGracePeriodSeconds trop long	Réduire ou vérifier que l'app gère SIGTERM

Glissez pour voir

Voir pourquoi un Pod n'est pas Ready

Le bloc Conditions indique quelle condition bloque, et l'option --previous récupère les logs du conteneur avant son dernier redémarrage, seuls exploitables sur un Pod en boucle de crash :

kubectl describe pod nom-du-pod | grep -A 10 "Conditions"
kubectl logs nom-du-pod --previous

Voir les événements du Deployment

Les événements retracent les décisions du contrôleur, notamment les montées et descentes en charge de chaque ReplicaSet. Ils sont conservés une heure par défaut, au-delà la trace est perdue.

kubectl describe deployment/nginx-rolling | grep -A 20 "Events"

Vérifier le statut du rollout

Cette requête liste les types de conditions portées par le Deployment, typiquement Available et Progressing, ce qui permet de scripter un contrôle sans analyser la sortie de describe :

kubectl get deployment nginx-rolling -o jsonpath='{.status.conditions[*].type}'

Réflexes CKAD

L'épreuve CKAD est chronométrée : ces six gestes doivent être exécutés sans hésitation ni consultation de la documentation. Ils couvrent le cycle complet, du déclenchement d'une mise à jour à son annulation.

1. Déclencher une rolling update

   kubectl set image deployment/app app=image:v2

2. Suivre la progression

   kubectl rollout status deployment/app

3. Consulter l'historique

   kubectl rollout history deployment/app

4. Rollback

   kubectl rollout undo deployment/app
   # Ou vers une révision spécifique
   kubectl rollout undo deployment/app --to-revision=2

5. Vérifier les ReplicaSets

   kubectl get rs
   kubectl describe deployment/app

6. Piège courant

   kubectl scale ne crée pas de nouvelle révision. Seules les modifications du Pod template déclenchent un rollout.

À retenir

1. Rolling update = mise à jour progressive avec interruption minimale si bien configurée
2. Seules les modifications du Pod template déclenchent une nouvelle révision
3. maxSurge et maxUnavailable valent 25% par défaut
4. maxUnavailable: 0 = aucun Pod indisponible, mais nécessite plus de ressources
5. progressDeadlineSeconds détecte les rollouts bloqués
6. Un rollback déclenche un nouveau rollout vers une ancienne révision, ce n'est pas instantané
7. Impossible de rollback un Deployment pausé, reprendre d'abord
8. revisionHistoryLimit: 0 = pas de rollback possible
9. Toujours configurer des readinessProbes et minReadySeconds
10. Pour un vrai canary avec contrôle du trafic, utilisez Argo Rollouts ou un service mesh

Testez vos connaissances

Sept questions pour vérifier que les points sensibles sont acquis : valeurs par défaut, ce qui déclenche une révision, et les situations où le rollback devient impossible.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Définir les Probes : Les health checks sans lesquels un rollout progresse sur des Pods morts.
• Débugger une application : Le diagnostic d'un rollout bloqué, avant d'annuler la mise à jour.
• Horizontal Pod Autoscaler : L'ajustement automatique du nombre de replicas pendant et après un rollout.

×

📖 Voir la documentation →