Cluster-Upgrade

centron installiert Patches und Sicherheitsupdates für Control Plane und Worker Nodes automatisch. Sie steuern, wann das geschieht und wie umfangreich automatisch aktualisiert wird.

Alle Einstellungen finden Sie im Tab Settings des Clusters.

Voraussetzungen

• Zugang zum centron Control Panel
• Ein Kubernetes Cluster im Status Running und eine geprüfte Verbindung per kubectl

Automatische Patch-Upgrades

Unter Automatically upgrade minor version patches legen Sie fest, wie mit neuen Patch-Versionen verfahren wird:

Einstellung	Anzeige im Control Panel
Enabled	New minor version patches are installed automatically.
Disabled	Only required updates will install automatically.

Unabhängig von dieser Einstellung installiert centron zwingend erforderliche Updates. Der Zustand wird auch im Tab Overview im Abschnitt Version angezeigt.

Zum Ändern klicken Sie auf Edit, setzen die Option und bestätigen mit Save.

Tipp

Für produktive Cluster wird Enabled empfohlen. Patch-Versionen enthalten Fehlerbehebungen und Sicherheitsupdates innerhalb derselben Minor-Version und ändern keine APIs – das Risiko einer Inkompatibilität ist gering, der Sicherheitsgewinn dagegen unmittelbar.

Upgrade-Fenster

Unter Upgrade window legen Sie den Zeitraum fest, in dem Upgrades installiert werden. Über Edit wählen Sie:

• Select Day – Ein Wochentag oder Any day
• Select Time – Startzeit des Fensters

Ab der gewählten Startzeit steht ein vierstündiges Fenster zur Verfügung. Die Anzeige lautet anschließend etwa Any day after 22:00 (GMT+2).

Wählen Sie einen Zeitraum mit geringer Auslastung – etwa nachts oder am Wochenende. Auch wenn Upgrades bei ausreichend dimensionierten Pools ohne Ausfallzeit verlaufen, werden Pods dabei zwischen Nodes verlagert.

Surge Upgrades

Unter Surge upgrades steuern Sie, ob während eines Upgrades temporär zusätzliche Nodes bereitgestellt werden:

Einstellung	Verhalten
Enabled	Vor dem Entfernen alter Nodes werden temporär zusätzliche Nodes bereitgestellt (maximal 10).
Disabled	Nodes werden nacheinander ersetzt, ohne zusätzliche Kapazität.

Mit aktivierten Surge Upgrades bleibt die volle Kapazität des Clusters während des gesamten Upgrades erhalten. Ohne sie steht zeitweise ein Node weniger zur Verfügung – bei knapp dimensionierten Pools kann das zu Engpässen führen.

Ablauf eines Upgrades

Nodes werden rollierend aktualisiert, also nacheinander:

1. Ein Node wird für neue Pods gesperrt.
2. Seine Pods werden auf andere Nodes verlagert.
3. Der Node wird aktualisiert bzw. ersetzt.
4. Der nächste Node folgt.

Damit dabei keine Ausfallzeit entsteht, sind erforderlich:

• Mindestens 2 Nodes je Node Pool

• Mehrere Replicas je produktiver Anwendung

• Readiness Probes, damit nur einsatzbereite Pods Datenverkehr erhalten

• Optional ein PodDisruptionBudget:

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: web-pdb
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: web

Wechsel der Minor-Version

Ein Wechsel der Minor-Version – etwa von 1.32 auf 1.33 – ist ein bewusster Schritt und wird nicht automatisch durchgeführt. Prüfen Sie vorher:

• Ob von Ihren Manifesten verwendete API-Versionen in der Zielversion noch verfügbar sind
• Ob Ihre kubectl-Version zur Zielversion passt (eine Minor-Version Abweichung ist zulässig)
• Ob Operatoren, Ingress Controller und Helm Charts die Zielversion unterstützen

Die installierte Version sehen Sie in der Kopfzeile der Cluster-Detailansicht neben Projekt und Region.

Status prüfen

# Version von Client und Server
kubectl version

# Version je Node
kubectl get nodes

# Laufende Änderungen an Nodes
kubectl get nodes --watch

Während eines Upgrades können Nodes vorübergehend die Status Provisioning oder Deleting aufweisen. Im Tab Resources verfolgen Sie den Fortschritt je Node Pool.

Verwandte Themen

• Unterstützte Versionen
• Hochverfügbarkeit
• Changelog