Oracle beendet OL7-ARM-Support für Kubernetes Engine – Migration zu OL8 erforderlich

Mit dem Ende des Supports für Oracle Linux 7 auf ARM-Prozessoren reagiert Oracle Cloud Infrastructure mit konkreten Änderungen bei der Kubernetes Engine. Administratoren von OKE-Clustern stehen vor der Aufgabe, ihre Infrastruktur zeitnah auf Oracle Linux 8 umzustellen. Die technischen Hintergründe und ein strukturierter Migrationspfad im Überblick.

Support-Ende macht Anpassungen notwendig

Seit Jahresbeginn 2025 erhält Oracle Linux 7 für die ARM-Architektur (aarch64) keine Sicherheitsupdates und Fehlerkorrekturen mehr. Anders als bei der x86-Variante gibt es für OL7 auf ARM keinen erweiterten Support. Oracle Cloud Infrastructure Kubernetes Engine zieht daraus Konsequenzen: Die Plattform stellt die Bereitstellung neuer OL7-ARM-Images ein und deaktiviert die Möglichkeit, entsprechende Worker-Knoten zu erstellen.

Die Maßnahme betrifft ausschließlich die Worker-Knoten-Ebene. Steuerungsebenen von OKE-Clustern bleiben unverändert funktionsfähig. Gleiches gilt für serverlose Dienste wie Oracle Functions, die von der Änderung nicht tangiert werden.

Betroffene Systeme und Auswirkungen

Die Einschränkung wirkt sich auf Kubernetes-Umgebungen aus, die Worker-Knoten mit OL7 auf ARM-Basis betreiben – unabhängig davon, ob diese über verwaltete Knotenpools oder als selbstverwaltete Instanzen laufen. Kunden, die bereits OL8 auf ARM einsetzen oder andere Prozessorarchitekturen nutzen, sind nicht betroffen.

Vorhandene Cluster mit OL7-ARM-Knoten laufen zunächst weiter. Die fehlenden Sicherheitspatches erhöhen jedoch kontinuierlich das Risiko ungepatchter Schwachstellen. Oracle empfiehlt daher eine zügige Migration auf OL8-basierte Images.

Strukturierter Migrationspfad

Die Umstellung folgt einem mehrstufigen Prozess, der mit einer Bestandsaufnahme beginnt. Administratoren sollten zunächst alle betroffenen Cluster, Knotenpools und benutzerdefinierten Images identifizieren. Besondere Aufmerksamkeit verdienen Autoscaling-Konfigurationen und CI/CD-Pipelines, die möglicherweise fest an OL7-Image-IDs gekoppelt sind.

Vorbereitung der OL8-Umgebung

Bei der Auswahl geeigneter OL8-ARM-Images müssen mehrere Kompatibilitätsfaktoren geprüft werden. Dazu zählt die Kubernetes-Versionskompatibilität zwischen Steuerungsebene und Worker-Knoten nach der aktuellen Skew-Richtlinie. Die Container-Laufzeitumgebung Containerd erfordert eine Überprüfung der Version und CRI-Konfiguration.

Kritisch sind außerdem die CNI- und CSI-Versionen für Block Volume und File Storage sowie die Aktivierung des Oracle Cloud Agent mit den erforderlichen Plugins für das Betriebssystem-Management.

Blue-Green-Deployment für verwaltete Knotenpools

Verwaltete Knotenpools lassen sich über einen Blue-Green-Ansatz migrieren. Dabei wird parallel zum bestehenden OL7-Pool ein neuer OL8-basierter Pool mit identischen Konfigurationsparametern erstellt – einschließlich Formen, Labels, Taints und Autoscaling-Richtlinien. Die Netzwerk- und Sicherheitskonfiguration mit VCN-Subnetzen, Network Security Groups und IAM-Berechtigungen muss übereinstimmen.

Der ursprüngliche OL7-Pool bleibt als Rollback-Option bestehen, bis die Service Level Objectives auf der neuen Umgebung validiert sind. Für größere Installationen empfiehlt sich die Bereitstellung von Zusatzkapazitäten oder ein rollierendes Migrationsmuster.

Selbstverwaltete Knoten erfordern manuelle Schritte

Bei selbstverwalteten Knoten außerhalb der OKE-Pools erfolgt die Bereitstellung neuer OL8-Compute-Instanzen manuell. Das Bootstrap-Verfahren zum Clusterbeitritt über kubelet oder kubeadm muss entsprechend konfiguriert werden. Die Knoten benötigen die korrekte Platzierung in VCN-Subnetzen mit passenden Security Lists und Routing-Konfigurationen für NAT oder Service Gateways.

Ein wichtiger Unterschied: Während der Cluster Autoscaler verwaltete Knotenpools automatisch skaliert, müssen für selbstverwaltete Knoten externe Mechanismen wie Instanzkonfigurationen oder eigene Automatisierungslösungen zum Einsatz kommen.

Workload-Migration mit minimalen Ausfallzeiten

Die eigentliche Workload-Migration erfordert das kontrollierte Entleeren der OL7-Knoten unter Berücksichtigung von PodDisruptionBudgets. DaemonSets, Ingress-Controller, Speicher-Mounts über CSI sowie Admission-Richtlinien müssen auf den OL8-Knoten überprüft werden.

Surge-Kapazitäten helfen dabei, Service Level Objectives während der Umstellung einzuhalten. Die Neuplanung von Pods sollte kontinuierlich überwacht werden, um Probleme mit Container-Laufzeit, Sidecars oder Speicher-Volumes frühzeitig zu erkennen.

Validierung und Sicherheitsprüfungen

Nach der technischen Migration stehen Smoke-Tests und Performance-Validierungen an. Protokolle, Metriken und das Autoscaler-Verhalten liefern Hinweise auf mögliche Probleme.

Die Sicherheitsprüfung umfasst mehrere Komponenten: Image-Herkunft und Signaturen sollten verifiziert, Knoten-Image-Quellen über IAM-Richtlinien eingeschränkt werden. Der OCI Vulnerability Scanning Service ermöglicht die Überprüfung neuer Images und Knoten. Cloud Guard bietet zusätzliche Erkennungen für Konfigurationsdrift und Compliance-Status.

Operative Hinweise für die Umsetzung

Bewährte Vorgehensweise ist der Start in Nicht-Produktionsumgebungen. Nach erfolgreicher Validierung lässt sich das Muster auf produktive Systeme übertragen. Wartungsfenster sollten geplant und Snapshots vor Änderungen erstellt werden.

Infrastructure-as-Code-Definitionen in Terraform oder Resource Manager sowie CI/CD-Pipelines erfordern Aktualisierungen auf OL8-Image-OCIDs. Die Verwendung von „latest“-Tags sollte vermieden werden.

Während der Parallelphase beider Knotenpools entstehen temporäre Mehrkosten. Skalierungsrichtlinien können entsprechend angepasst werden, um die Zusatzbelastung zu begrenzen.

Compliance-Aspekte

Ungepatchte OL7-ARM-Systeme bergen Risiken durch bekannte Schwachstellen. Die Migration auf OL8 stellt die Grundlage für aktuelle Kernel- und Userspace-Updates dar. Nach der Umstellung empfiehlt sich eine Überprüfung mit VSS und Cloud Guard.

Im Rahmen des Upgrades lohnt die Prüfung weiterer Sicherheitsaspekte: KMS- und Vault-Nutzung für Secrets, Konfiguration privater Cluster, WAF-Einstellungen sowie IAM-Berechtigungen nach dem Least-Privilege-Prinzip.

Häufige Fragen zur Umstellung

Sind Ampere A1-Shapes unter OL8 verfügbar?
Die aktuellen OL8-ARM-Images für OKE unterstützen Ampere A1-Shapes vollständig.

Lassen sich bestehende OL7-Knoten in-place aktualisieren?
Ein direktes Betriebssystem-Upgrade wird nicht unterstützt. Die Migration erfolgt über neue OL8-Knotenpools mit anschließender Workload-Verlagerung.

Wie verfahren Nutzer benutzerdefinierter Images?
Benutzerdefinierte Images müssen auf OL8-Basis neu erstellt werden. Erforderliche Treiber und Module sind zu überprüfen, anschließend erfolgt die Registrierung bei OKE.

Gelten die Einschränkungen auch für x86-Systeme?
Die aktuelle Mitteilung bezieht sich ausschließlich auf OL7 für ARM-Architekturen. Für x86-Systeme gelten separate Oracle-Linux-Richtlinien.

Die vollständigen technischen Dokumentationen zu OKE-unterstützten Images, Netzwerkkonfiguration und Best Practices für Upgrades stehen in der Oracle Cloud Infrastructure-Dokumentation zur Verfügung.

Unsere Empfehlungen zum Weiterlesen:

---

Bild/Quelle: https://depositphotos.com/de/home.html