Un ConfigMap modifié ne redémarre aucun pod automatiquement, un problème que la technique du hash d’annotation dans un chart Helm résout de façon permanente. Pour un besoin ponctuel, une seule fois, sans modifier le template du Deployment, kubectl rollout restart répond au même problème d’une façon plus directe.

Ce que la commande fait réellement

kubectl rollout restart ajoute une annotation kubectl.kubernetes.io/restartedAt au template de pod du Deployment, avec l’horodatage courant. Ce changement, même minime, modifie le template, ce qui déclenche un rolling update parfaitement normal : les nouveaux pods remplacent progressivement les anciens, dans le respect de la stratégie de déploiement configurée (maxUnavailable, maxSurge), exactement comme un changement d’image le ferait.

kubectl rollout restart deployment/my-app
# L'annotation ajoutée, la seule modification
# réelle qui déclenche le rolling update
spec:
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/restartedAt: "2026-07-28T10:00:00Z"

Pourquoi c’est différent (et plus sûr) que kubectl delete pod

Supprimer manuellement chaque pod d’un Deployment force bien leur recréation, mais sans respecter la stratégie de rolling update : selon la vitesse d’exécution des suppressions, plusieurs pods peuvent se retrouver simultanément indisponibles, un risque que rollout restart élimine en passant par le mécanisme normal de rolling update du contrôleur.

# Risque réel : plusieurs pods indisponibles en même temps
# si les suppressions s'enchaînent trop vite
kubectl delete pod my-app-7d9f8c-x2k4p my-app-7d9f8c-y3m5q

Le cas d’usage le plus courant : forcer la relecture d’un ConfigMap

Un pod dont les variables d’environnement proviennent d’un ConfigMap ne relit jamais ce ConfigMap après son démarrage, comme détaillé dans l’article dédié. kubectl rollout restart force chaque pod à redémarrer et donc à relire ses variables d’environnement à jour, sans jamais avoir besoin de modifier le Deployment lui-même ni d’attendre un futur déploiement de code.

# Recharge les variables d'environnement issues du ConfigMap,
# sans toucher à l'image ni à aucun autre champ du Deployment
kubectl rollout restart deployment/my-app -n production

Ce que la commande ne fait jamais

rollout restart ne modifie ni l’image, ni aucun autre champ du spec en dehors de cette annotation : elle ne sert qu’à provoquer un rolling update propre sur la configuration déjà en place, jamais à déployer une nouvelle version de code. Confondre les deux usages (redémarrer pour relire une config contre déployer un changement de code) mène parfois à utiliser cette commande là où un vrai déploiement de nouvelle image serait attendu, un mauvais réflexe qui masque l’absence de changement réel dans les logs de déploiement.

À retenir

kubectl rollout restart ajoute une annotation d’horodatage au template de pod, un changement minime mais suffisant pour déclencher un rolling update complet et respectueux de la stratégie de déploiement configurée, contrairement à des suppressions manuelles de pods qui risquent une indisponibilité simultanée. Le cas d’usage le plus courant force la relecture d’un ConfigMap modifié, une alternative ponctuelle au hash d’annotation Helm quand le besoin ne se répète pas à chaque déploiement. La commande ne déploie jamais de nouveau code, seulement un nouveau rollout de ce qui existe déjà, une nuance qui compte pour toute équipe qui opère un industrialisation CI/CD reposant sur des redémarrages propres.