1.36 Versionsinformationen und Aktualisierungsmaßnahmen

Lesen Sie die Informationen zur Version „ 1.36 “ von „ IBM Cloud® Kubernetes Service “. Weitere Informationen zur Projektversion „ Kubernetes “ ( 1.36) finden Sie unter Kubernetes Änderungsprotokoll.

Dieses Abzeichen steht für die Zertifizierung von „ Kubernetes “ in der Version 1.36 für „ IBM Cloud Kubernetes Service “,
, Kubernetes in der Version 1.36.

IBM Cloud Kubernetes Service ist ein zertifiziertes „ Kubernetes “-Produkt für die Version 1.36 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 „ 1.36 “ von „ IBM Cloud® Kubernetes Service “. 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.

Zeitplan für die Veröffentlichung der Version „ IBM Cloud Kubernetes Service “ 1.36
Version Unterstützt? Freigabedatum Nicht unterstütztes Datum
1.36 Ja
  1. Juni 2026
  1. August 2027 †

Aktualisierung vorbereiten

Eine vollständige Liste der Änderungen, die sich bei einer Aktualisierung Ihres Clusters auf Ihre bereitgestellten Anwendungen auswirken könnten, finden Sie im Änderungsprotokoll der Community unter Kubernetes sowie im Versionsänderungsprotokoll unter IBM für die Version 1.36. Sie können sich auch die hilfreichen Warnhinweise unter „ Kubernetes “ ansehen.

Kubernetes API-Server und Konnectivity-Tunnel werden über Port 443 bereitgestellt

Der API-Server von „ Kubernetes “ und der Konnectivity-Tunnel werden nun über den Standard- HTTPS-Port 443 bereitgestellt, anstatt über einen dynamisch zugewiesenen Knotenport (beispielsweise einen Port im Bereich 20000–32767 ). Der Datenverkehr wird mithilfe von hostnamenbasiertem Routing an den richtigen Backend-Dienst weitergeleitet. Aus diesem Grund verfügt jede Funktion über einen eigenen Hostnamen, obwohl alle Dienste den Port 443 gemeinsam nutzen. Diese Änderung erleichtert die Verbindung zu Ihrem Cluster aus restriktiven Netzwerkumgebungen heraus, da Sie keinen nicht standardmäßigen Port mehr durch Ihre Firewalls und ausgehende Datenkontrollen zulassen müssen. Ihr Cluster stellt über seine privaten und öffentlichen Service-Endpunkte zwei speziell dafür vorgesehene Hostnamen bereit:

  • <cluster>.api.<region-domain> — der Endpunkt des „ Kubernetes “-API-Servers
  • <cluster>.tunnel.<region-domain> — der Konnectivity-Tunnel-Endpunkt, der für die Kommunikation zwischen der Steuerungsebene und dem Worker-Knoten verwendet wird

Diese Funktion ist ab der IKS-Version „ 1.36 “ 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.

Wenn Sie einen Cluster aktualisiert haben, der den öffentlichen Service-Endpunkt verwendet, greift eine kubeconfig-Datei, die weiterhin auf den öffentlichen Service-Endpunkt URL verweist, weiterhin auf den alten Port zurück, was dazu führt, dass Befehle mit dem Parameter kubectl aufgrund von Verbindungszeitüberschreitungen fehlschlagen. Um dies zu vermeiden, laden Sie entweder eine neue kubeconfig-Datei herunter, indem Sie den Befehl „ ibmcloud ks cluster config “ ausführen, oder ändern Sie den Port in Ihrer bestehenden kubeconfig-Datei manuell auf 443.

  • Neue Cluster: Es sind keine Maßnahmen erforderlich. Neue Cluster werden mit Endpunkten auf Port 443 erstellt, und die von Ihnen heruntergeladene kubeconfig-Datei verwendet bereits Port 443.
  • Aktualisierte Cluster, die ausschließlich den privaten Service-Endpunkt verwenden: Es sind keine sofortigen Maßnahmen erforderlich. Bestehende Verbindungen, die auf die bisherige Adresse NodePort verweisen, funktionieren auch nach dem Upgrade weiterhin. Die neue kubeconfig-Datei, die Sie herunterladen, nutzt den Endpunkt auf Port 443.
  • Benutzerdefinierte Netzwerkregeln: Aktualisieren Sie alle Regeln für Firewalls, Sicherheitsgruppen oder Ausgangs-Allowlists, die explizit auf den alten Port mit hoher Nummer in der Steuerungsebene verweisen, damit stattdessen ausgehender HTTPS-Verkehr über Port 443 zugelassen wird. Alle Regeln, die den vorherigen Port mit der höchsten Nummer fixiert haben, können entfernt werden.
  • IP-basierte Zulassungslisten: Die DNS-Einträge für den Endpunkt des öffentlichen Dienstes verweisen nun auf die Frontend-IP-Adressen von Akamai IP Protect (IPP) anstelle der bisherigen IP-Adressen des Lastenausgleichs (NLB). Falls Ihre Firewall- oder Egress-Regeln den Datenverkehr zu Ihrem Cluster anhand der Ziel-IP-Adresse zulassen, passen Sie diese bitte an die aktuellen IP-Bereiche von Akamai IPP an.
Der anonyme Zugriff auf den API-Server von „ Kubernetes “ ist nun eingeschränkt

Der anonyme Zugriff auf den API-Server von „ Kubernetes “ ist nun auf Endpunkte für Zustandsprüfungen beschränkt (/healthz, /readyz, /livez, /livez/ping). Für alle anderen Endpunkte ist eine Authentifizierung erforderlich (zum Beispiel /version). Dadurch wird das Risiko verringert, dass versehentliche Fehlkonfigurationen des RBAC-Systems zu Berechtigungen für system:anonymous oder system:unauthenticated führen.

Kubernetes Das Dashboard ist veraltet

Das Open-Source-Dashboard „ Kubernetes “ ist veraltet und wurde archiviert. Das „ Kubernetes “-Dashboard wird auf neu bereitgestellten Clustern nicht mehr installiert und bei Clustern mit früheren Versionen entfernt, wenn Sie ein Upgrade auf „ 1.36 “ durchführen. Das Headlamp-Add-on ist als Ersatz- Kubernetes-Benutzeroberfläche erhältlich.

NVIDIA GPU-Treiber werden nicht mehr automatisch installiert

Ab der Version „ Kubernetes “ ( 1.36 ) installiert „ IBM Cloud Kubernetes Service “ die GPU-Treiber von „ NVIDIA “ nicht mehr automatisch auf den GPU-Worker-Knoten. Um GPU-Workloads auszuführen, müssen Sie die GPU-Treiber selbst installieren und verwalten. Weitere Informationen finden Sie unter „ Umstellung auf selbstverwaltete GPU-Treiber “.

Der Cluster-Autoscaler unterstützt die Version „ 1.36 “ noch nicht. Führen Sie kein Update Ihres Clusters auf die Version „ 1.36 “ durch, wenn der Autoscaler installiert ist.

Vor Master aktualisieren

Sehen Sie sich die folgenden Änderungen an, die Sie vor der Aktualisierung des „ Kubernetes “-Master-Servers vornehmen müssen.

Änderungen, die Sie vornehmen müssen, bevor Sie den Master auf „ Kubernetes “ aktualisieren 1.36
Typ Beschreibung
Entfernt: Das in den Kernel integrierte „ Portworx “-Volume-Plugin Das in-Tree-Plugin „ Portworx “ wurde in Kubernetes 1.36 entfernt, womit die Umstellung auf den CSI-Treiber „ Portworx “ abgeschlossen ist. Das Feature-Gate „ CSIMigrationPortworx “ (GA und gesperrt seit 1.33 ) sowie das Feature-Gate „alpha InTreePluginPortworxUnregister “ wurden ebenfalls entfernt, und alle im Mainline-Tree enthaltenen Portworx-Volume-Operationen werden nun auf CSI umgeleitet. Stellen Sie vor dem Update sicher, dass der CSI-Treiber „ Portworx “ installiert ist und dass Ihre Ressourcen „ StorageClass “, „ PersistentVolume “ und „ PersistentVolumeClaim “ auf den CSI-Treiber verweisen. Cluster, die weiterhin auf das „in-tree“-Plugin zurückgreifen, verlieren nach dem Update den Zugriff auf „ Portworx “-Volumes.
Geändert: Strengere IP- und CIDR-Validierung Die Funktion „ StrictIPCIDRValidation “ ist auf dem API-Server standardmäßig aktiviert. API-Felder, die IP- oder CIDR-Werte enthalten, akzeptieren keine Adressen mehr mit überflüssigen führenden Nullen (z. B. 010.000.000.005 statt 10.0.0.5) oder CIDR-Werte mit mehrdeutigen Host-Bits (z. B. 192.168.0.5/24 statt 192.168.0.0/24 oder 192.168.0.5/32). Überprüfen Sie Ihre Manifestdateien und Tools auf Ressourcen wie Service, NetworkPolicy und EndpointSlice und korrigieren Sie vor der Aktualisierung alle nicht kanonischen IP- oder CIDR-Werte. Nach der Aktualisierung des Masters werden Anfragen, die Objekte mit ungültigen Werten erstellen oder aktualisieren, abgelehnt.
Geändert: Metriken der Steuerungsebene umbenannt Die Metrik „ volume_operation_total_errors “ (kube-controller-manager) wird in „ volume_operation_errors_total “ umbenannt, und die Metrik „ etcd_bookmark_counts “ wird in „ etcd_bookmark_total “ umbenannt. Wenn Sie benutzerdefinierte Überwachungs-Dashboards oder Benachrichtigungsregeln verwenden, die auf die alten Metriknamen verweisen, passen Sie diese bitte an die neuen Namen an, damit Ihre Überwachung auch nach der Aktualisierung der Steuerungsebene weiterhin funktioniert.
Entfernt: „ git-repo “-Lautstärke-Plugin Das „ git-repo “-Volumen-Plugin ist standardmäßig deaktiviert, und es gibt keine Möglichkeit, es wieder zu aktivieren; das Feature-Gate „ GitRepoVolumeDriver “ hat keine Wirkung mehr. Dieser Volumetyp wird in „ IBM Cloud Kubernetes Service “ seit Version „ 1.33 “ nicht mehr unterstützt. Falls noch Workloads ein „ gitRepo “-Volume verwenden, migrieren Sie diese auf ein „ emptyDir “-Volume, das von einem „ init “-Container bestückt wird, der das Repository mithilfe von „ git “ klont. Weitere Informationen finden Sie unter „ Entfernung des integrierten „ gitRepo “-Volumetreibers “.

Nach Master aktualisieren

Sehen Sie sich die folgenden Änderungen an, die Sie nach der Aktualisierung des „ Kubernetes “-Master-Servers vornehmen müssen.

Änderungen, die nach der Aktualisierung des Masters auf „ Kubernetes “ vorzunehmen sind 1.36
Typ Beschreibung
Veraltet: Dienst .spec.externalIPs Das Feld „ .spec.externalIPs “ bei „ Service “-Ressourcen ist veraltet, und der API-Server gibt nun eine Veraltungswarnung aus, wenn das Feld gesetzt ist. Planen Sie, die Nutzung von „ externalIPs “ einzustellen und externen Datenverkehr stattdessen über einen „ LoadBalancer “-Dienst oder einen „Ingress“ weiterzuleiten. Weitere Informationen finden Sie unter „ Externe IP-Adressen “.
Geändert: Standardprofil „ kubectl debug “ Das Standardprofil für „ kubectl debug “ ändert sich von „ legacy “ zu „ general “. Wenn Sie Skripte oder Runbooks haben, die vom Verhalten des Profils „ legacy “ abhängen, übergeben Sie „ --profile=legacy “ explizit. Das „ legacy “-Profil soll in „ Kubernetes “ entfernt werden 1.39. Weitere Informationen finden Sie unter „ Fehlerbehebung bei laufenden Pods “.
Geändert: Reihenfolge der Client-Go-Informer-Ereignisse (AtomicFIFO) Die Funktion „Client-Go- AtomicFIFO “ ist standardmäßig aktiviert. Informer-Speicher werden nun vollständig auf eine einheitliche Ressourcenversion aktualisiert, bevor die pro Element spezifischen Handler „ OnAdd “, „ OnUpdate “ und „ OnDelete “ aufgerufen werden. Außerdem hat sich die Verarbeitung der Informer-Neusynchronisierung geringfügig geändert, was zu erkennbaren Unterschieden beim Zeitpunkt des Handler-Aufrufs führen kann. Testen Sie benutzerdefinierte Controller und Operatoren, in die „client-go“ eingebettet ist. Sollten Sie Regressionen feststellen, können Sie das Feature-Gate „ AtomicFIFO “ für den Client vorübergehend in Ihrer eigenen Controller-Binärdatei auf „ false “ setzen, während Sie die Anpassungen vornehmen.
Geändert: Strengere numerische Validierung bei „ CustomResourceDefinition “ CustomResourceDefinition Bei der (CRD-)Validierung werden nun die Bereiche der numerischen Formate „ int32 “, „ int64 “, „ float “ und „ double “ strikt durchgesetzt, wenn diese in einem Schema festgelegt sind. Bestehende Objekte, die bereits Werte außerhalb des zulässigen Bereichs enthalten, bleiben durch die schrittweise Validierung erhalten, neue oder aktualisierte Werte müssen jedoch innerhalb des zulässigen Bereichs liegen. Überprüfen Sie benutzerdefinierte Ressourcen, die diese Zahlenformate verwenden.
Veraltet: Feld „Allowlist“ des Credential-Plugins In der Whitelist des Client-Anmeldeinformationen-Plugins wird das Feld „ AllowlistEntry.Name “ in „ AllowlistEntry.Command “ umbenannt. Wenn Sie eine Whitelist für das Credential-Plugin konfigurieren (beispielsweise über kuberc), passen Sie Ihre Konfiguration an, damit der neue Feldname verwendet wird.
Veraltet: Direkter Zugriff auf metav1.FieldsV1.Raw Der direkte Zugriff auf das Feld „ Raw “ von „ metav1.FieldsV1 “ ist veraltet. Code, der FieldsV1 erstellt oder ausliest (beispielsweise Controller oder Tools, die verwaltete Felder überprüfen), sollte auf die neuen Zugriffsmethoden NewFieldsV1(string), GetRawBytes(), GetRawString()`` und SetRawBytes() umgestellt werden.
Erforderliche Maßnahme: Benutzerdefinierte Scheduler- PreBind-Plugins Das Scheduler-Framework unterstützt nun die parallele Ausführung von „ PreBind “-Plugins. Wenn Sie benutzerdefinierte Scheduler-Plugins pflegen, aktualisieren Sie diese so, dass sie bei der Methode „ PreBindPreFlight “ den Wert „ PreBindPreFlightResult “ zurückgeben; die Rückgabe von „ nil “ behält das bestehende sequenzielle Verhalten bei, und Plugins aktivieren die parallele Ausführung, indem sie „ AllowParallel: true “ zurückgeben. Diese Maßnahme gilt nur für Cluster, auf denen benutzerdefinierte Scheduler-Plugins ausgeführt werden.
Erforderliche Maßnahme: Detailliertes RBAC für DRA-Treiber Wenn die Funktion „ DRAResourceClaimGranularStatusAuthorization “ aktiviert ist (Beta-Version unter 1.36 ), benötigen Treiber und Controller für die dynamische Ressourcenzuweisung (DRA) detaillierte RBAC-Berechtigungen, um den Status von „ ResourceClaim “ zu aktualisieren. Scheduler und Controller benötigen update oder patch auf resourceclaims/binding, und DRA-Treiber benötigen associated-node:update oder arbitrary-node:update auf resourceclaims/driver, eingeschränkt durch ihre spezifischen resourceNames. Wenn Sie DRA-Treiber verwenden, aktualisieren Sie deren RBAC. Diese Maßnahme gilt nur für Cluster, die DRA verwenden.