System Upgrade Controller

System Upgrade Controller

#

The Rancher System Upgrade Controller is a Kubernetes-native upgrade controller for nodes. It introduces a new Custom Resource Definition (CRD) called “Plan” to define upgrade policies, allowing for automated and controlled upgrades of Kubernetes clusters.

Quelle

#

• System Upgrade Controller GitHub Repository
• Rancher Dokumentation zum System Upgrade Controller

Dokumentation

#

Die Dokumentation für den Controller ist auf GitHub zu finden.

Funktion

#

Dieser Controller automatisiert die Aktualisierung des zugrundeliegenden Kubernetes-Systems (k3s). Er funktioniert, indem er Plan-Custom-Ressourcen überwacht. Ein Plan definiert, wie ein Upgrade durchgeführt werden soll, einschließlich:

• Version: Die Zielversion von k3s.
• Concurrency: Wie viele Nodes gleichzeitig aktualisiert werden dürfen.
• Node Selector: Welche Nodes aktualisiert werden sollen (z.B. zuerst die Control-Plane, dann die Worker).
• Upgrade-Befehl: Das Skript, das auf dem Node ausgeführt wird, um das Upgrade durchzuführen.

Wenn ein Plan im Cluster erstellt oder geändert wird, erstellt der Controller für jeden ausgewählten Node einen Job, der den Node sperrt (cordon), die Workloads darauf beendet (drain), das Upgrade-Skript ausführt und den Node anschließend wieder freigibt (uncordon).

Lokale Anpassungen

#

Es gibt kein Helm-Chart und keine values.yaml. Der Controller selbst wird über die CRDs und das Deployment-Manifest des Upstream-Releases installiert; angepasst wird nur plan.yaml.

Wichtige Einstellungen

#

• plan.yaml: Enthält zwei Pläne — server-plan für die Control-Plane-Knoten und agent-plan für die Worker. Beide laufen mit concurrency: 1, es wird also immer nur ein Knoten zugleich aktualisiert.
• Kanal statt Version: Die Zielversion kommt aus dem k3s-Release-Kanal stable, nicht aus einer festen Versionsangabe. Der Cluster folgt damit automatisch neuen stabilen Releases — bequem, aber auch ohne Zwischenschritt, an dem jemand zustimmt.
• Reihenfolge: Die Control-Plane muss vor den Workern aktualisiert werden. Die Trennung in zwei Pläne mit unterschiedlichen nodeSelector-Angaben ist genau dafür da.
• Aktualisierung des Controllers: kustomization.yaml bezieht CRDs und Deployment über .../releases/latest/download/... — also den jeweils neuesten Upstream-Stand, nicht eine gepinnte Version. Ein Kustomize-Lauf kann dadurch eine andere Controller-Version bringen als der vorherige.
• Tolerations: Der Controller-Pod hat Tolerations für CriticalAddonsOnly, um sicherzustellen, dass er auch auf dedizierten Control-Plane-Nodes laufen kann.

Installation

#

Die Anwendung wird mittels Kustomize und Helm durch ArgoCD im Kubernetes-Cluster bereitgestellt. Die Konfiguration befindet sich im apps/system-upgrade-controller-Verzeichnis. Eine manuelle Installation kann mit folgendem Befehl durchgeführt werden:

1kubectl kustomize --enable-helm apps/system-upgrade-controller | kubectl apply -n system-upgrade -f -

Abhängigkeiten

#

Der Controller ist eine eigenständige Anwendung, die tief in die Verwaltung des Kubernetes-Clusters eingreift. Er hat keine externen Anwendungsabhängigkeiten.