Lesen Sie die Versionshinweise für Kubernetes-Versionen zum erweiterten Support

Das .status.kubeProxyVersion Feld für Knotenobjekte ist jetzt veraltet, und das Kubernetes-Projekt schlägt vor, dieses Feld in einer future Version zu entfernen. Das veraltete Feld ist nicht korrekt und wurde in der Vergangenheit von einer Organisation verwaltet, die weder kubelet die kube-proxy Version noch weiß, ob sie ausgeführt wird. kube-proxy Wenn Sie dieses Feld in der Client-Software verwendet haben, hören Sie auf. Die Informationen sind nicht zuverlässig und das Feld ist jetzt veraltet.

Um die potenzielle Angriffsfläche 1.29 zu reduzieren, kennzeichnet die LegacyServiceAccountTokenCleanUp Funktion in Kubernetes veraltete, automatisch generierte geheime Token als ungültig, wenn sie lange Zeit nicht verwendet wurden (standardmäßig 1 Jahr), und entfernt sie automatisch, wenn sie lange Zeit nicht verwendet wurden, nachdem sie als ungültig markiert wurden (standardmäßig 1 zusätzliches Jahr). Um solche Token zu identifizieren, können Sie Folgendes ausführen:

kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system

Kubernetes v1.28 erweiterte den unterstützten Unterschied zwischen den Komponenten des Kernknotens und der Steuerungsebene um eine Nebenversion, von n-2 bisn-3, sodass die Knotenkomponenten (kubeletundkube-proxy) für die älteste unterstützte Nebenversion mit den Komponenten der Steuerungsebene (kube-apiserver, kube-schedulerkube-controller-manager,cloud-controller-manager) für die neueste unterstützte Nebenversion zusammenarbeiten können.

Die Metriken force_delete_pods_total und force_delete_pod_errors_total im Pod GC Controller wurden dahingehend verbessert, dass alle erzwungen Löschungen von Pods berücksichtigt werden. Der Metrik wird ein Grund hinzugefügt, der angibt, ob der Pod gewaltsam gelöscht wurde, weil er beendet wurde, verwaist ist, mit dem out-of-service Makel endet oder weil er beendet wurde und nicht geplant wurde.

Der PersistentVolume (PV)-Controller wurde dahingehend geändert, dass allen ungebundenen PersistentVolumeClaim, bei denen der storageClassName nicht gesetzt ist, automatisch eine standardmäßige StorageClass zugewiesen wird. Darüber hinaus wurde der Mechanismus zur Überprüfung der PersistentVolumeClaim Zulassung innerhalb des API-Servers so angepasst, dass Werte von einem nicht festgelegten Status in einen tatsächlichen Namen geändert werden können. StorageClass

kubeletIn Kubernetes 1.27 wurde die Standardeinstellung auf und kubeAPIQPS auf 50 erhöht. kubeAPIBurst 100 Dank dieser Verbesserungen kann das kubelet eine größere Menge an API-Abfragen verarbeiten, wodurch die Antwortzeiten und die Leistung verbessert werden. Wenn der Bedarf an Pods aufgrund von Skalierungsanforderungen steigt, stellen die überarbeiteten Standardwerte sicher, dass das kubelet die höhere Workload effizient bewältigen kann. Infolgedessen sind Pod-Starts schneller und Clustervorgänge effektiver.

Zur Verteilung von Richtlinien wie minDomain können Sie eine detailliertere Pod-Topologie verwenden. Mit diesem Parameter können Sie die Mindestanzahl von Domains angeben, auf die die Pods verteilt werden sollen. nodeAffinityPolicy und nodeTaintPolicy ermöglichen ein zusätzliches Maß an Granularität bei der Steuerung der Pod-Verteilung. Dies entspricht den Knotenaffinitäten, den Taints und dem Feld matchLabelKeys in den topologySpreadConstraints der Spezifikation Ihres Pod’s. Das ermöglicht die Auswahl von Pods für Verteilungsberechnungen nach einem fortlaufenden Upgrade.

Kubernetes hat einen neuen Richtlinienmechanismus zur Beta-Version 1.27 befördert, der StatefulSets die Lebensdauer ihrer () steuert. PersistentVolumeClaims PVCs Mit der neuen PVC-Aufbewahrungsrichtlinie können Sie angeben, ob die anhand der Spezifikationsvorlage StatefulSet generierten PVCs automatisch gelöscht oder beibehalten werden, wenn das StatefulSet gelöscht wird oder die Replikate im StatefulSet herunterskaliert werden.

Die Goaway-Chance-Option im Kubernetes-API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Serverinstanz hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.27 hat das goaway-chance-Flag aktiviert. Wenn Ihr Workload, der auf dem Amazon EKS-Cluster ausgeführt wird, einen Client verwendet, der nicht mit HTTP GOAWAY kompatibel ist, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er bei Verbindungsabbruch erneut eine Verbindung herstellt. GOAWAY