Résumé

  • Linode prévoit de rendre indisponibles son Cloud Manager, son API et sa CLI entre 04 h 00 et 05 h 30 UTC le 19 août. Il sera impossible de créer, démarrer, migrer, sauvegarder, arrêter ou supprimer des instances pendant cette période.
  • Les machines et les charges Kubernetes déjà actives doivent continuer à fonctionner. En revanche, l’API Kubernetes, l’autoscaling, les opérations sur les volumes et plusieurs changements dynamiques dépendant de l’API seront bloqués.

La maintenance que Linode s’apprête à engager ne vise pas, selon l’entreprise, les calculs déjà en cours. Elle retire temporairement aux clients la capacité normale de les piloter.

L’avis officiel fixe une fenêtre de 90 minutes, de 04 h 00 à 05 h 30 UTC le 19 août 2026. Le Cloud Manager, l’API et l’interface en ligne de commande seront hors service. Les clients ne pourront ni se connecter à la console ni lancer les actions administratives citées par Linode : création, suppression, démarrage, migration, sauvegarde ou arrêt d’une instance.

Cette annonce distingue nettement deux réalités opérationnelles. Le plan de données doit rester en fonctionnement : Linode affirme que les instances en cours d’exécution et les services associés ne seront pas interrompus. Le plan de contrôle, lui, ne recevra plus les décisions permettant de modifier l’état de ces ressources.

La différence est particulièrement visible dans Linode Kubernetes Engine. L’API Kubernetes sera touchée, de même que l’autoscaling, le recyclage et le redémarrage de nœuds, l’attachement ou le détachement de volumes persistants, le provisionnement de NodeBalancers et la création de nouveaux clusters. Linode prévoit néanmoins que les nœuds existants et les charges qu’ils exécutent restent actifs.

Une application peut donc continuer à répondre tout en devenant temporairement plus difficile à adapter. Une équipe ayant dimensionné sa capacité avant la fenêtre peut ne constater aucun effet côté utilisateur. Une équipe qui doit absorber un pic, remplacer un nœud, joindre un volume ou modifier la répartition de charge dépendra d’une commande que le fournisseur n’acceptera pas pendant la maintenance.

Le dispositif de support sera lui aussi réduit. Les tickets ne seront pas accessibles. Le téléphone restera ouvert, mais les équipes de support ne pourront pas authentifier les clients ni intervenir sur les problèmes liés au Manager ou à l’API. La création de comptes et l’authentification des nouveaux clients en attente seront également suspendues.

Cette dépendance commune correspond au fonctionnement normal décrit par Linode. La présentation de Cloud Manager indique que l’interface web repose entièrement sur l’API publique, tandis que le guide de la CLI décrit l’outil en ligne de commande comme une enveloppe de cette API. La référence de l’API couvre notamment les instances, LKE, les volumes et NodeBalancers. Le guide d’exploitation LKE distingue en outre l’API d’infrastructure Linode de l’API Kubernetes qui gère les objets du cluster.

Le dossier Statuspage rattache l’opération au Cloud Manager et à l’API ainsi qu’à 43 régions nommées sur plusieurs continents. À 01 h 13 UTC le 19 août, ces composants étaient indiqués comme opérationnels et la maintenance portait encore le statut scheduled.

Il s’agit donc d’un programme, pas d’un résultat observé. L’avis, publié le 9 juillet, ne précise ni le changement technique réalisé, ni sa cause, ni le plan de retour arrière. Il ne permet pas d’affirmer que les travaux ont commencé, qu’ils se termineront à l’heure ou que l’absence d’impact sur les charges a été mesurée indépendamment.

La préparation utile est concrète : terminer avant 04 h 00 UTC les changements d’état urgents, vérifier les besoins de capacité de LKE, anticiper les opérations sur les volumes et les équilibreurs, et savoir quelles actions restent possibles à l’intérieur d’une charge déjà active quand le plan de contrôle du fournisseur ne répond plus.

La prochaine mise à jour officielle dira si la maintenance commence à l’heure, si le contrôle revient avant 05 h 30 UTC et si une limitation persiste après la réouverture.

Source