4.22 Versionsinformationen und Maßnahmen zur Aktualisierung
Lesen Sie die Informationen zur Versions 4.22 von Red Hat OpenShift on IBM Cloud. Diese Version basiert auf der Version Kubernetes ( 1.35 ).
Suchen Sie allgemeine Informationen zur Aktualisierung von Clustern oder Informationen zu einer anderen Version? Weitere Informationen zu Red Hat Red Hat OpenShift auf IBM Cloud sowie die Versionshinweise zu Version 4.22 finden Sie hier.
Red Hat OpenShift on IBM Cloud ist ein zertifiziertes Kubernetes-Produkt für die Version 1.35 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.22. 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.
| Unterstützt? | Red Hat OpenShift / Kubernetes-Version | Freigabedatum | Nicht unterstütztes Datum |
|---|---|---|---|
| Unterstützt | 4.22 / 1.35 |
|
|
Aktualisierung vorbereiten
Sehen Sie sich an, welche Änderungen Sie möglicherweise vornehmen müssen, wenn Sie einen Cluster auf die Version 4.22 aktualisieren. Diese Informationen fassen Aktualisierungen zusammen, die sich wahrscheinlich auf implementierte Apps auswirken, wenn Sie eine Aktualisierung durchführen.
Die Anforderungen an die Dimensionierung des Satellite für das Hosting Red Hat OpenShift on IBM Cloud Clustern der Version 4.22 sind nun unabhängig davon gleich, ob es sich um einen RHEL non-CoreOS oder einen RHEL- CoreOS basierten Standort handelt. Die Anforderungen an die Standortknoten sollten nun denen für CoreOS-enabled-Standorte entsprechen.
Portworx Red Hat OpenShift on IBM Cloud-Cluster der Version 4.22 werden noch nicht unterstützt. Aktualisieren Sie Ihren Cluster nicht auf die Version 4.22, wenn Portworx installiert ist.
Ab Version 4.22 wird die Cluster-Steuerungsebene über Port 443 bereitgestellt und nicht mehr über einen dynamisch zugewiesenen Knotenport (Bereich 20000–32767). Der Datenverkehr wird mithilfe des hostnamenbasierten Routings über vier speziell
dafür eingerichtete Hostnamen geleitet: <cluster>.api.<region-domain>, <cluster>.oauth.<region-domain>, <cluster>.tunnel.<region-domain>, und <cluster>.ignition.private.<region-domain>.
Die Hostnamen .oauth. und .api. sind sowohl über die öffentlichen als auch über die privaten Service-Endpunkte verfügbar; die Hostnamen .ignition.private. .tunnel. und sind ausschließlich
privat. Diese Änderung betrifft nicht nur den Datenverkehr zwischen Client und Server kubectl,oc sondern auch den Datenverkehr zwischen Worker und Control Plane (Kubelet-API, Konnectivity und RHCOS Ignition). Diese
Änderung ist ab sofort in den folgenden Regionen verfügbar: Montreal (ca-mon), Chennai (in-che) und Mumbai (in-mum). Die Unterstützung weiterer Regionen folgt in Kürze. Weitere Informationen finden Sie
unter Cluster-Control-Plane über Port 443 erreichbar.
Vor Master aktualisieren
Die folgende Tabelle zeigt die Aktionen, die Sie ausführen müssen, bevor Sie den Cluster-Master aktualisieren.
Bei Clustern, auf denen Version 4.22 oder höher ausgeführt wird, können Sie den Befehl oc adm upgrade status verwenden, um den Aktualisierungsstatus Ihres Cluster-Masters während einer Master-Versionsaktualisierung zu überprüfen.
Weitere Informationen finden Sie unter Anzeigen des Status eines Cluster-Upgrades mit dem Befehl oc adm upgrade status.
| Typ | Beschreibung |
|---|---|
| Port 443 für die Cluster-Steuerungsebene | Die Cluster-Steuerungsebene wird nun über Port 443 bereitgestellt statt über einen dynamisch zugewiesenen Knotenport (Bereich 20000–32767). Es werden vier Hostnamen verwendet: <cluster>.api.<region-domain>, <cluster>.oauth.<region-domain>,
<cluster>.tunnel.<region-domain>, und <cluster>.ignition.private.<region-domain>. Die Hostnamen .ignition.private. und .tunnel. sind ausschließlich für den
internen Gebrauch bestimmt. Dies betrifft kubectl/oc Kunden, oc login, die Webkonsole sowie den Datenverkehr zwischen Workern und der Control Plane (Kubelet, Konnectivity und RHCOS Ignition).
Erforderliche Maßnahme: Aktualisieren Sie alle Regeln für Firewalls, Sicherheitsgruppen oder Ausgangs-Allowlists, die auf den alten Control-Plane-Port mit hoher Nummer verweisen, um ausgehenden HTTPS auf Port 443 zu
allen vier Hostnamen zuzulassen. Wenn Sie den öffentlichen Service-Endpunkt verwenden, laden Sie eine neue kubeconfig herunter, indem Sie ausführen, oder ibmcloud ks cluster config ändern Sie den Port in Ihrer bestehenden
kubeconfig manuell auf 443. Wenn Sie IP-basierte Zulassungslisten verwenden, aktualisieren Sie diese bitte entsprechend den aktuellen IP-Bereichen von Akamai IPP, da die DNS-Einträge der öffentlichen Service-Endpunkte nun auf die Frontend-Adressen
von Akamai IP Protect verweisen. Weitere Informationen finden Sie unter Netzwerkgrundlagen für ROKS-Cluster und Cluster-Steuerungsebene über Port 443 erreichbar. |
| Vorbereitungen für die Aktualisierung von OpenShift | Weitere Informationen zu möglichen erforderlichen Maßnahmen finden Sie im Dokument Vorbereitung auf das Update auf OpenShift Container Platform unter 4.22. Die Vorbereitungsmaßnahmen für das Backup von etcd, die Versionsauswahl und das Entfernen von SDN gelten nicht für Red Hat OpenShift on IBM Cloud-Cluster, da die Backups von etcd sowie die Versionsauswahl automatisch für Sie durchgeführt werden und anstelle von SDN Calico verwendet wird. |
| Veraltete und entfernte Funktionen von OpenShift | Weitere Informationen finden Sie in der Liste der veralteten und entfernten Funktionen der Version OpenShift Container Platform unter 4.22, um zu erfahren, welche Maßnahmen möglicherweise erforderlich sind. |
| Für das Upgrade ist keine Bestätigung durch den Administrator erforderlich | In dieser Version werden keine APIs entfernt. |
| Bekannte Probleme mit OpenShift | Weitere Informationen finden Sie in der Version OpenShift Container Platform unter 4.22. Dort werden bekannte Probleme aufgeführt, für die möglicherweise Maßnahmen erforderlich sind. |
| Für das Upgrade muss die Cluster-Version von OpenShift auf dem neuesten Stand sein | Ein Cluster-Master-Upgrade wird abgebrochen, wenn der Versionsstatus des OpenShift-Clusters anzeigt, dass bereits ein Update durchgeführt wird. Weitere Informationen finden Sie unter Warum zeigt OpenShift an, dass die Cluster-Version nicht auf dem neuesten Stand ist?. |
| Für das Upgrade muss sichergestellt sein, dass die Bedingungen für ein Versions-Upgrade des OpenShift-Clusters erfüllt sind | Ein Cluster-Master-Upgrade wird abgebrochen, wenn der Status Upgradeable der Clusterversion unter OpenShift angibt, dass der Cluster nicht aktualisiert werden kann. Um festzustellen, ob der Cluster aktualisiert werden kann, lesen Sie den Abschnitt Überprüfen des Aktualisierungsstatus Ihres Clusters. |
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")'
Beispielausgabe, bei der der Status Upgradeable ist False.
{
"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 lautet False, enthalten die Statusinformationen Anweisungen, die vor dem Upgrade befolgt werden müssen.