1.34 versionsinformationen und Aktualisierungsaktionen
Informationen zur Version 1.34 von IBM Cloud® Kubernetes Service überprüfen. Weitere Informationen zur Kubernetes Projektversion finden Sie im Kubernetes 1.34 Änderungsprotokoll.
IBM Cloud Kubernetes Service ist ein zertifiziertes Kubernetes Produkt für die Version 1.34 im Rahmen des CNCF Kubernetes Software Conformance Certification Programms. 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.34 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.
| Version | Unterstützt? | Freigabedatum | Nicht unterstütztes Datum |
|---|---|---|---|
| 1.34 | Ja |
|
|
Aktualisierung vorbereiten
Diese Informationen fassen die Updates zusammen, die wahrscheinlich Auswirkungen auf bereitgestellte Anwendungen haben, wenn Sie einen Cluster auf die Version 1.34 aktualisieren. Eine vollständige Liste der Änderungen finden Sie im Änderungsprotokoll Kubernetes der Community und im IBM Versionsänderungsprotokoll für Version 1.34. Sie können auch die Kubernetes hilfreichen Warnhinweise lesen.
Portworx unterstützt die Version noch 1.34 nicht. Aktualisieren Sie Ihren Cluster nicht auf Version, 1.34 wenn Ihre Anwendungen verwenden Portworx.
CoreDNS Die Standard-DNS-Cache-Zeit in den DNS-Konfigurationen von CoreDNS und NodeLocal wurde von 30 Sekunden auf 120 Sekunden erhöht.
Vor Master aktualisieren
In der folgenden Tabelle sind die Aktionen aufgeführt, die Sie ausführen müssen, bevor Sie den Kubernetes-Master aktualisieren.
| Typ | Beschreibung |
|---|---|
| Cluster-Autoscaler: In Version 1.34 wird nur die Version 2.0.0 und höher des Cluster-Autoscalers unterstützt. | Aktualisieren Sie Ihren Cluster-Autoscaler auf mindestens Version 2.0.0, bevor Sie Ihren Cluster auf Version 1.34 aktualisieren. |
Pod-Topologie-Verbreitung: Die Implementierung von matchLabelKeys in wird topologySpreadConstraints nun in labelSelector zusammengeführt. |
Führen Sie kein direktes Upgrade von v1.32 auf v1.34 durch, wenn Sie diese Funktion verwenden. Führen Sie zunächst ein Upgrade auf v1.33 durch. Stellen Sie sicher, dass Pods, die unter v1.32 mit erstellt wurden, vor dem Upgrade auf v1.34matchLabelKeys geplant oder entfernt werden. |
Pod-Sicherheit Zulassung: Die baseline Richtlinien restricted und blockieren nun das .host Feld in Probes und Lifecycle-Handlern (z. B. livenessProbe, httpGet). |
Entfernen Sie diese Richtlinien .host aus Ihren Pod-Konfigurationen, wenn Sie sie verwenden. |
AppArmor: Die Profile „ AppArmor “ in SecurityContext werden nicht mehr mit den veralteten container.apparmor.security.beta.kubernetes.io/ Anmerkungen synchronisiert. |
Tools aktualisieren, um aus SecurityContext. zu lesen. |
Wahl der Anführer: Die endpoint-controller und workload-leader-election FlowSchemas wurden entfernt. |
Workloads, die sich auf configmapsleases oder endpointsleases für die Leader-Wahl stützen, müssen auf den leases Lock-Typ migriert werden. |
Metriken: apiserver_cache_list_fetched_objects_total, apiserver_cache_list_returned_objects_total, apiserver_cache_list_total |
Ersetzen Sie resource_prefix label durch API group und resource labels. |
Metriken: apiserver_selfrequest_total |
Fügen Sie eine group API-Kennzeichnung hinzu. |
Metriken: apiserver_watch_events_sizes und apiserver_watch_events_total |
Ersetzen Sie API-Bezeichnung kind durch resource Bezeichnung. |
Metriken: apiserver_request_body_size_bytes, apiserver_storage_events_received_total, apiserver_storage_list_evaluated_objects_total apiserver_storage_list_fetched_objects_total,
apiserver_storage_list_returned_objects_total, apiserver_storage_list_total, apiserver_watch_cache_events_dispatched_total, apiserver_watch_cache_events_received_total, apiserver_watch_cache_initializations_total,
apiserver_watch_cache_resource_version, watch_cache_capacity, apiserver_init_events_total, apiserver_terminated_watchers_total,, watch_cache_capacity_increase_total,
watch_cache_capacity_decrease_total, apiserver_watch_cache_read_wait_seconds, apiserver_watch_cache_consistent_read_total, apiserver_storage_consistency_checks_total, etcd_bookmark_counts,
storage_decode_errors_total |
Extrahieren Sie die API-Gruppe aus resource label und fügen Sie sie in das neue group label ein. Weitere Informationen finden Sie unter #131845 SIG API Machinery, Etcd, Instrumentation and Testing. |
| Containerd- 2.0 Docker Schema 1: Docker Das Schema-1-Bildformat ( application/vnd.docker.distribution.manifest.v1+prettyjws ) wird standardmäßig nicht mehr unterstützt. | Stellen Sie sicher, dass Ihre Bilder mit Schema 2 oder OCI kompatibel sind ( Docker ). |
| Containerd- 2.0- CRI-API: Die CRI- v1alpha2-API wurde entfernt. | Stellen Sie sicher, dass die Komponenten und Tools von „ Kubernetes “, die mit „containerd“ interagieren, die CRI- v1-API verwenden. |
| Containerd- 2.0- Laufzeiten: Die Shims „Runtime V1 ” und „Runc V1 ” wurden entfernt. | Überprüfen Sie, ob Ihre Workloads mit den Runtime-Shims von containerd kompatibel sind: V2. |
| Containerd- 2.0 Nicht privilegierte Ports und ICMP: Nicht privilegierte Ports und ICMP sind jetzt standardmäßig aktiviert. | Überprüfen Sie Ihre Anwendungssicherheitskontexte und entfernen Sie zusätzliche Funktionen oder sysctls (wie NET_BIND_SERVICE oder net.ipv4.ping_group_range), die zuvor für diese Funktionen erforderlich waren.
Weitere Informationen finden Sie in den Upstream-Änderungsprotokollen. |
Nach Master aktualisieren
Keine Aktionen erforderlich.