Zusammenfassung

  • Linode hat für Cloud Manager, API und CLI am 19. August von 04:00 bis 05:30 Uhr UTC ein Wartungsfenster angesetzt. Instanzen lassen sich dann weder anlegen noch löschen, starten, migrieren, sichern oder abschalten.
  • Laufende Linodes und Kubernetes-Workloads sollen verfügbar bleiben. Nicht verfügbar sind dagegen die Kubernetes-API, automatische Skalierung, Speicheroperationen und weitere Änderungen, die von der Linode-API abhängen.

Eine Cloud kann weiter Rechenarbeit leisten, obwohl ihre Kunden vorübergehend nicht über sie verfügen können. Genau diese Trennung macht Linodes angekündigte Wartung sichtbar.

Die offizielle Wartungsmeldung setzt das Zeitfenster auf den 19. August 2026 von 04:00 bis 05:30 Uhr UTC. Cloud Manager, API und Kommandozeilenschnittstelle sollen offline sein. Kunden können sich nicht anmelden und keine administrativen Vorgänge wie Erstellen, Löschen, Starten, Migrieren, Sichern oder Herunterfahren einer Instanz auslösen.

Für bereits laufende Systeme kündigt Linode dagegen keine Unterbrechung an. Instanzen und zugehörige Dienste sollen in Betrieb bleiben. Damit zieht die Meldung eine klare Grenze: Die Datenebene trägt laufende Berechnung und Verkehr weiter, während die Kontrollebene keine Entscheidungen zur Änderung des Ressourcenzustands annimmt.

Beim Linode Kubernetes Engine wird diese Grenze besonders relevant. Auch die Kubernetes-API fällt in das Wartungsfenster. Linode nennt Autoscaling, Austausch und Neustart von Knoten, das An- und Abhängen persistenter Volumes, die Bereitstellung von NodeBalancern und das Erstellen neuer Cluster als betroffene Funktionen. Bestehende Knoten und darauf laufende Workloads sollen nicht ausfallen.

Das ist keine Meldung über einen bereits eingetretenen Workload-Ausfall. Eine Anwendung kann erreichbar bleiben, während ihr Betreiber auf eine Lastspitze, einen ausgefallenen Knoten, zusätzlichen Speicherbedarf oder eine Änderung des Load Balancings nicht über den normalen Weg reagieren kann. Wer Kapazität vorab bereitgestellt hat, besitzt während dieser 90 Minuten einen anderen Spielraum als ein Dienst, der auf eine automatische Skalierungsaktion angewiesen ist.

Auch der Unterstützungsweg wird enger. Das Ticketsystem soll laut Linode nicht verfügbar sein. Der Telefonsupport bleibt zwar erreichbar, kann Kunden während der Wartung aber weder authentifizieren noch bei Problemen mit Cloud Manager oder API handeln. Neue Kontoanträge und ausstehende Authentifizierungen werden ebenfalls pausiert.

Diese gemeinsame Abhängigkeit entspricht Linodes eigener Produktbeschreibung. Die Übersicht zu Cloud Manager erklärt, dass die Weboberfläche vollständig auf der öffentlichen API aufsetzt; der CLI-Leitfaden bezeichnet das Kommandozeilenwerkzeug als API-Hülle. Die API-Referenz umfasst unter anderem Instanzen, LKE, Blockspeicher und NodeBalancer. Der LKE-Betriebsleitfaden trennt zudem die Linode-API für Infrastruktur von der Kubernetes-API für Clusterobjekte.

Der offizielle Datensatz ordnet der Wartung Cloud Manager und API sowie 43 benannte Regionen in Nordamerika, Europa, dem asiatisch-pazifischen Raum, Lateinamerika und Afrika zu. Um 01:13 Uhr UTC am 19. August wurden alle Komponenten als betriebsbereit angezeigt; der Wartungsstatus lautete weiterhin „geplant“.

Diese zeitliche Grenze darf nicht verloren gehen. Linode veröffentlichte den Hinweis am 9. Juli, die Arbeiten selbst sind jedoch für den 19. August vorgesehen. Der Hinweis nennt weder die konkrete technische Änderung noch eine Ursache oder einen Rückfallplan. Er belegt nicht, dass die Wartung begonnen hat, um 05:30 Uhr endet oder die erwartete Verfügbarkeit laufender Workloads tatsächlich gemessen wurde.

Kunden können sich auf die veröffentlichte Grenze vorbereiten, ohne daraus einen Ausfall zu machen. Zeitkritische Instanzänderungen sollten vor 04:00 Uhr UTC abgeschlossen sein. LKE-Teams können prüfen, ob absehbare Skalierung, Knotentausch, Speicheranbindung oder Load-Balancer-Änderungen von den nicht verfügbaren APIs abhängen. Wiederanlaufpläne sollten außerdem festhalten, was innerhalb eines laufenden Workloads noch möglich ist, wenn die Verwaltungsebene des Anbieters keinen Befehl annimmt.

Entscheidend wird der nächste Status-Eintrag: ob die Arbeiten pünktlich beginnen, ob die Verwaltungsoberflächen bis 05:30 Uhr zurückkehren und ob danach noch Einschränkungen bestehen.

Quelle