4.18 Versionsinformationen und Maßnahmen zur Aktualisierung

Informationen zur Version 4.18 von Red Hat OpenShift on IBM Cloud überprüfen. Diese Version basiert auf der Version Kubernetes ( 1.31 ).

Suchen Sie allgemeine Informationen zur Aktualisierung von Clustern oder Informationen zu einer anderen Version? Siehe Red HatRed Hat OpenShift zu IBM Cloud Versionsinformationen und den 4.18 Versionshinweisen.

Diese Plakette zeigt die Kubernetes Version 1.31 Zertifizierung für Red Hat OpenShift on IBM Cloud
Kubernetes Version 1.31 Zertifizierungsplakette

Red Hat OpenShift on IBM Cloud ist ein zertifiziertes Kubernetes-Produkt für die Version 1.31 im Rahmen des CNCF-Programms zur Konformitätszertifizierung von Kubernetes-Software. Kubernetes® ist eine eingetragene Marke der Linux Foundation in den USA und/oder anderen Ländern und wird gemäß einer Lizenz der Linux Foundation verwendet.

Releasezeitachse

Die folgende Tabelle enthält den voraussichtlichen Zeitplan für die Veröffentlichung der Version 4.18. Sie können diese Informationen zu Planungszwecken verwenden, um beispielsweise die allgemeine Zeit zu schätzen, die die Version möglicherweise nicht mehr unterstützt wird.

Datumsangaben mit einem Kreuzzeichen () sind vorläufig und können sich ändern.

Versionsgeschichte für Red Hat OpenShift on IBM Cloud Version 4.18.
Unterstützt? Red Hat OpenShift / Kubernetes-Version Freigabedatum Nicht unterstütztes Datum
Unterstützt 4.18 / 1.31
  1. Mai 2025
  1. Mai 2027

Aktualisierung vorbereiten

Sehen Sie sich an, welche Änderungen Sie möglicherweise vornehmen müssen, wenn Sie einen Cluster auf die Version 4.18 aktualisieren. Diese Informationen fassen Aktualisierungen zusammen, die sich wahrscheinlich auf implementierte Apps auswirken, wenn Sie eine Aktualisierung durchführen.

Die Anforderungen Satellite an die Standortgröße für das Hosten Red Hat OpenShift on IBM Cloud von 4.18 Versionsclustern sind nun unabhängig davon, ob es sich um einen RHEL-Standort ( non-CoreOS ) oder einen CoreOS-enabled-Standort handelt, identisch. Die Anforderungen für Standortknoten entsprechen denen für „ CoreOS-enabled “-Standorte.

Vor Master aktualisieren

Die folgende Tabelle zeigt die Aktionen, die Sie ausführen müssen, bevor Sie den Cluster-Master aktualisieren.

Bei Clustern, die Version 4.18 oder höher ausführen, können Sie den oc adm upgrade status Befehl verwenden, um den Aktualisierungsstatus Ihres Cluster-Masters während einer Master-Versionsaktualisierung zu überprüfen. Weitere Informationen finden Sie unter Anzeigen des Cluster-Upgrade-Status mit dem Befehl oc adm upgrade status.

Änderungen, die Sie vornehmen müssen, bevor Sie den Master auf Red Hat OpenShift aktualisieren 4.18
Typ Beschreibung
Vorbereitungen für ein Update von OpenShift Weitere Informationen finden Sie im Abschnitt Vorbereitung der Aktualisierung auf OpenShift Container Platform 4.18. Die Aktionen etcd zur Vorbereitung von Backups, Versionsauswahl und SDN-Entfernung gelten nicht für Red Hat OpenShift on IBM Cloud-Cluster, da etcd-Backups und Versionsauswahlaktionen für Sie durchgeführt werden und Calico anstelle von SDN verwendet wird.
Veraltete und entfernte Funktionen v OpenShift Weitere Informationen finden Sie unter OpenShift Container Platform version 4.18 deprecated and removed features for possible actions required.
Bekannte Probleme OpenShift Weitere Informationen finden Sie unter OpenShift Container Platform Version 4.18 Bekannte Probleme und mögliche erforderliche Maßnahmen.
Upgrade erfordert OpenShift cluster version currency Ein Cluster-Master-Upgrade wird abgebrochen, wenn der Versionsstatus des Clusters OpenShift anzeigt, dass bereits eine Aktualisierung im Gange ist. Weitere Informationen finden Sie unter Warum zeigt OpenShift an, dass die Clusterversion nicht auf dem neuesten Stand ist?
Das Upgrade erfordert eine Lösung für die OpenShift cluster version upgradeable conditions Ein Cluster-Master-Upgrade wird abgebrochen, wenn die Statusbedingung OpenShift cluster version Upgradeable anzeigt, dass der Cluster nicht upgradefähig ist. Um festzustellen, ob der Cluster upgradefähig ist, siehe Überprüfen des Upgrade-Status Ihres Clusters.
RHEL 8-Worker-Knoten werden nicht unterstützt RHEL 8-Worker-Knoten werden in Version 4.18 nicht unterstützt. Die Version 4.17 ist die letzte Version, die RHEL 8 unterstützt. Bevor Sie ein Upgrade auf 4.18 durchführen, müssen Sie alle RHEL 8-Worker-Knoten auf RHEL 9 oder RHCOS migrieren. Informationen zu den Migrationsschritten finden Sie unter Migration zu Red Hat Enterprise Linux 9 (Classic oder VPC) oder Migration von VPC-Worker-Knoten zu RHCOS (nur VPC).
RHEL-Worker-Knoten sind veraltet Ab der Clusterversion 4.18 ist Red Hat Enterprise Linux CoreOS (RHCOS) das Standardbetriebssystem in Classic- und VPC-Clustern und RHEL Worker Nodes sind veraltet. Beim Upgrade eines Clusters auf die Version 4.18 wird das Betriebssystem für einen bestehenden Worker-Pool nicht geändert. Weitere Informationen und mögliche Migrationsmaßnahmen finden Sie unter Red Hat Enterprise Linux(RHEL)deprecation.
Node etikett node-role.kubernetes.io/master entfernt 4.18 cluster setzen nicht mehr das node-role.kubernetes.io/master node label für die Version 4.18 worker nodes (RHEL oder RHCOS). Wenn Ihre Anwendungen auf diese Knotenbezeichnung angewiesen sind, aktualisieren Sie sie entsprechend.

Den Status Upgradeable Ihres Clusters überprüfen

Führen Sie den folgenden Befehl aus, um den Status Upgradeable Ihres Clusters zu überprüfen.

oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'

Beispiel für eine Ausgabe, bei der der Status von Upgradeable False lautet.

{
  "lastTransitionTime": "2024-11-17T19:29:34Z",
  "message": "Cluster operator operator-lifecycle-manager should not be upgraded between minor versions: ClusterServiceVersions blocking cluster upgrade: default/test is incompatible with OpenShift minor versions greater than 4.16",
  "reason": "IncompatibleOperatorsInstalled",
  "status": "False",
  "type": "Upgradeable"
}

Wenn der Status Upgradeable False lautet, enthält die Zustandsinformation Anweisungen, die vor der Aktualisierung befolgt werden müssen.