Oracle Cloud Infrastructure - Dokumentation

Upgrade verwalteter Knoten auf Kubernetes-Version 1.35 (oder höher)

Erfahren Sie, wie Sie verwaltete Knoten upgraden, die derzeit ein OKE-OL7-Image, ein OL7-Plattformimage oder ein benutzerdefiniertes Image basierend auf einem OL7-Image verwenden, um Kubernetes-Version 1.35 (oder höher) und OL8 mit Kubernetes Engine (OKE) auszuführen.

Hinweis

Dieser Abschnitt gilt nur für verwaltete Knoten. Informationen zum Upgraden von selbstverwalteten Knoten finden Sie unter Upgrade von selbstverwalteten Knoten auf eine neuere Kubernetes-Version durch Ersetzen eines vorhandenen selbstverwalteten Knotens.

Ab Kubernetes-Version 1.35 benötigt Kubernetes die cgroups v2 für die Verwaltung von Containerressourcen.

Control Groups (cgroups) ist ein Linux-Kernelfeature, das einen Mechanismus zum Verwalten und Steuern der Ressourcenzuweisung für Prozesse oder Prozessgruppen bietet. Gruppen der Kontrollgruppen Version 2 (cgroups v2) stellen eine einzelne Kontrollgruppenhierarchie bereit, für die alle Ressourcencontroller gemountet sind. In dieser Hierarchie können Sie die Ressourcennutzung über verschiedene Resource Controller hinweg koordinieren.

Oracle Linux 7 (OL7) unterstützt die cgroups v1, unterstützt jedoch die cgroups v2 nicht. Oracle Linux 8 (OL8) und höhere Versionen unterstützen sowohl die cgroups v1 als auch die cgroups v2, aber cgroups v2 ist nicht immer standardmäßig in OL8 aktiviert.

Zusammenfassend lässt sich sagen, dass Kubernetes-Version 1.35 daher OL8 (oder höher) erfordert, wobei cgroups v2 aktiviert ist.

Cgroups v2 ist standardmäßig in OKE-OL8-Images aktiviert, die eine Build-Nummer von 1367 oder höher haben. In OKE-OL8-Images, die eine Build-Nummer kleiner als 1367 (und in OL8-Plattformimages) aufweisen, ist cgroups v1 standardmäßig aktiviert.

Für Worker-Knoten auf Clustern, auf denen Kubernetes-Version 1.35 (und höher) ausgeführt wird, unterstützt Kubernetes Engine die folgenden Images:

In Clustern, die Kubernetes-Version 1.35 (und höher) ausführen, wird die Verwendung von Plattformimages (sowohl OL7-Plattformimages als auch OL8-Plattformimages) nicht empfohlen. Es wird dringend empfohlen, OKE-Images für alle neuen Deployments und Upgrades zu verwenden. Wenn Sie weiterhin ein Plattformimage verwenden möchten, erstellen Sie ein benutzerdefiniertes Image basierend auf dem Plattformimage, und geben Sie die OCID des benutzerdefinierten Images an, wenn Sie einen Knotenpool erstellen oder aktualisieren (beachten Sie, dass dieser Ansatz nicht empfohlen wird).

Beachten Sie beim Upgrade verwalteter Knoten, die derzeit ein OL8-Image auf Kubernetes-Version 1.35 (und höher) verwenden, Folgendes:

  • Sie können verwaltete Knoten, die derzeit ein OKE-OL8-Image (oder ein benutzerdefiniertes Image basierend auf einem OKE-OL8-Image) mit einer Build-Nummer unter 1367 verwenden, upgraden, indem Sie ein In-Place-Upgrade durchführen und ein OKE-OL8-Image mit einer Build-Nummer größer/gleich 1367 angeben.
  • Sie können verwaltete Knoten upgraden, die derzeit ein OL8-Plattformimage verwenden, indem Sie ein In-Place-Upgrade durchführen und ein OKE-OL8-Image mit einer Build-Nummer von 1367 oder höher angeben.
  • Sie können In-Place-Upgrades von verwalteten Knoten durchführen, die derzeit ein OL8-Image verwenden, unabhängig davon, ob für die Linux-Kernels von Compute-Instanzen, auf denen die Knoten gehostet werden, bereits Cgroups v2 aktiviert sind.
  • Anweisungen zum Durchführen von In-Place-Upgrades finden Sie unter Verwaltete Knoten auf eine neuere Kubernetes-Version upgraden.
  • Weitere Informationen zur Einführung der Unterstützung für Kubernetes-Version 1.35 finden Sie unter OKE begrüßt Kubernetes 1.35: Neue Features, Änderungen und weitere Schritte.

Workloads für cgroups v2 validieren

Prüfen Sie vor dem Upgrade von Production Worker-Knoten, ob Anwendungen und unterstützende Agents mit cgroups v2 kompatibel sind.

cgroups v2 kann ändern, wie Containerspeicher berücksichtigt wird. Eine Erhöhung der gemeldeten Containerspeicherauslastung allein deutet nicht unbedingt auf eine Speichersättigung hin. Untersuchen Sie eine Erhöhung, wenn sie von einer oder mehreren der folgenden Bedingungen begleitet wird:

  • Außerhalb des Speichers befindliche Container (OOM) werden beendet.
  • Container- oder Podneustarts.
  • Podräumungen.
  • Die Knotenbedingung MemoryPressure.

Informationen zu cgroups v2-Anforderungen, Speicher-Accounting, Laufzeitkompatibilität und Bestimmung der von einem Knoten verwendeten cgroups-Version finden Sie unter Info zu cgroup v2 in der Kubernetes-Dokumentation.

Ältere Anwendungslaufzeiten können Containerressourcenlimits auf Systemen, die cgroups v2 verwenden, möglicherweise nicht korrekt erkennen. Beispiel: Eine Java-Anwendung berechnet Heap- oder andere Speichereinstellungen aus den Ressourcen des Worker-Knotens anstelle des Speicherlimits des Containers. Infolgedessen könnte der Container den konfigurierten Speichergrenzwert überschreiten und vom Linux OOM-Killer beendet werden.

Verwenden Sie für Java-Workloads eines der folgenden JDK-Releases oder ein höheres Release:

  • JDK 15
  • JDK 11.0.16
  • JDK 8,381

JDK 8u372 führte cgroups v2 Awareness ein. JDK 8u381 enthält weitere Verbesserungen bei der Erkennung von Ressourcenlimits für cgroups v1 und cgroups v2, Containermetriken und Anwendungsstabilität. Weitere JDK-Distributionen und Anwendungslaufzeiten finden Sie in der Dokumentation des Herstellers, um ein Release zu identifizieren, das cgroups v2 unterstützt.

Prüfen Sie auch die Kompatibilität von Monitoring, Sicherheit und anderen Agents, die direkt auf /sys/fs/cgroup zugreifen. Aktualisieren Sie inkompatible Agents auf Versionen, die cgroups v2 unterstützen.

Führen Sie vor dem Upgrade von Produktions-Worker-Knoten die folgende Validierung in einer Nicht-Produktionsumgebung durch:

  1. Testen Sie repräsentative Workloads und unterstützende Agents auf Knoten, die cgroups v2 verwenden.
  2. Vergleichen Sie die folgenden Informationen vor und nach der Aktivierung von cgroups v2:
    • Gemeldete Containerspeicherauslastung
    • Container-OM-Ereignisse
    • Container- und Pod-Neustarts
    • Podräumung
    • Die Knotenbedingung MemoryPressure
    • Die von der Anwendungslaufzeit erkannte Speichergrenze

  3. Für Java-Workloads:

    • Zeichnen Sie die JDK-Version auf, indem Sie Folgendes eingeben:

      java -version

    • Prüfen Sie die von der JVM ermittelten System- und Containereinstellungen, indem Sie Folgendes eingeben: 

      java -XshowSettings:system -version

    • Konfigurieren Sie bei Bedarf explizite Werte für -Xms und -Xmx für die Workload.

Von OL7 verwaltete Knoten upgraden, um Kubernetes-Version 1.35 (oder höher) auszuführen

Um verwaltete Knoten, die derzeit ein OKE-OL7-Image, ein OL7-Plattformimage oder ein benutzerdefiniertes Image basierend auf einem OL7-Image verwenden, upzugraden, um Kubernetes-Version 1.35 (oder höher) auszuführen, führen Sie ein Out-of-Place-Upgrade aus, um den vorhandenen Knotenpool durch einen neuen Knotenpool zu ersetzen:

  1. Identifizieren Sie vorhandene Knotenpools, die OL7 verwenden, mit der Konsole oder der CLI wie folgt:

    • Konsole verwenden:

      1. Wählen Sie auf der Listenseite Cluster den Namen des Clusters mit den Knotenpools aus, die Sie anzeigen möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
      2. Wählen Sie die Registerkarte Knotenpools.
      3. Verwenden Sie die Spalte Imagename, um Knotenpools zu identifizieren, die Oracle-Linux-7.9.x-Images verwenden.

    • CLI verwenden: Identifizieren Sie vorhandene Knotenpools, die OL7 verwenden, indem Sie einen Befehl wie den folgenden eingeben:

      oci ce node-pool list --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --query 'data[*].{name:"name", image:"node-source"."image-id"}'

  2. Erstellen Sie einen Ersatzknotenpool, der ein OL8-Image verwendet, mit der Konsole oder der CLI wie folgt:

    • Konsole verwenden:

      1. Wählen Sie in der Registerkarte Knotenpools die Option Knotenpool hinzufügen aus, und geben Sie Details für den neuen Knotenpool ein.
      2. Wählen Sie ein OKE-Worker-Knotenimage basierend auf einem Oracle Linux 8.x-Image aus.
      3. Konfigurieren Sie den neuen Knotenpool mit derselben Ausprägung, Größe und Platzierung wie der Knotenpool OL7.
      4. Wählen Sie Erstellen.

    • CLI verwenden: Erstellen Sie einen Ersatzknotenpool, der ein OL8-Abbild verwendet, indem Sie einen Befehl wie den folgenden eingeben:

      oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name "nodepool-ol8-workers" --node-shape "VM.Standard.E4.Flex" --kubernetes-version "v1.35.0" --node-image-id <ol8-image-ocid> --size 3 --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"<subnet-ocid>"}]'

  3. Cordon der OL7-Knoten:

    1. Rufen Sie die Namen der OL7-Knoten ab, indem Sie Folgendes eingeben:

      kubectl get nodes -l node.kubernetes.io/os=ol7

    2. Cordonieren Sie jeden Knoten, indem Sie Folgendes eingeben:

      kubectl cordon <node-name>

  4. Ziehen Sie die OL7-Knoten, um Workloads ordnungsgemäß zu migrieren:

    1. Entwässern Sie jeden OL7-Knoten, indem Sie Folgendes eingeben:
      kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
    2. Prüfen Sie, ob Workloads auf den neuen Knoten neu geplant wurden, indem Sie Folgendes eingeben:
      kubectl get pods -A -o wide | grep <node-name>

  5. Löschen Sie den Knotenpool OL7 wie folgt mit der Konsole oder der CLI:

    • Konsole verwenden:

      1. Wählen Sie auf der Registerkarte Knotenpools im Menü Aktionen (drei Punkte) neben dem Knotenpool OL7 die Option Knotenpool löschen aus.
      2. Klicken Sie auf Löschen.
      3. Bestätigen Sie, dass Sie den Knotenpool löschen möchten, und wählen Sie Löschen aus.

    • CLI verwenden: Löschen Sie den Knotenpool OL7:

      oci ce node-pool delete --node-pool-id <ol7-nodepool-ocid>

  6. Führen Sie ein Upgrade des Clusters aus (Beispiel: auf Kubernetes-Version 1.35):

    oci ce cluster update --cluster-id <cluster-ocid> --kubernetes-version "v1.35.0"

Weitere Informationen finden Sie unter Out-of-Place-Kubernetes-Upgrade von verwalteten Knoten durch Ersetzen eines vorhandenen Knotenpools mit einem neuen Knotenpool durchsetzen.