Versionshinweise für Kubernetes-Versionen mit erweitertem Support anzeigen

Das Beta-Feature Gate VolumeAttributesClass und die API-Ressource sind in der Amazon-EKS-Version 1.31 aktiviert. Mit dieser Funktion können Cluster-Betreiber veränderbare Eigenschaften von Persistent Volumes (PVs) ändern, die von kompatiblen CSI-Treibern verwaltet werden, einschließlich des Amazon EBS CSI-Treibers. Um dieses Feature nutzen zu können, stellen Sie sicher, dass Ihr CSI-Treiber das VolumeAttributesClass-Feature unterstützt (für den Amazon-EBS-CSI-Treiber führen Sie ein Upgrade auf Version 1.35.0 oder höher durch, um das Feature automatisch zu aktivieren). Sie können VolumeAttributesClass Objekte erstellen, um die gewünschten Volumenattribute wie Volume-Typ und Durchsatz zu definieren und sie Ihren Persistent Volume Claims () PVCs zuzuordnen. Weitere Informationen finden Sie in der offiziellen Kubernetes-Dokumentation sowie in der Dokumentation Ihres CSI-Treibers.

Die Kubernetes-Unterstützung für AppArmorwurde auf Stable umgestellt und ist nun allgemein für die öffentliche Nutzung verfügbar. Mit dieser Funktion können Sie Ihre Container schützen, AppArmor indem Sie das appArmorProfile.type Feld in den Containern festlegen. securityContext Vor der Kubernetes-Version AppArmor wurde 1.30 es durch Anmerkungen gesteuert. Ab Version 1.30 erfolgt die Steuerung über Felder. Um dieses Feature optimal zu nutzen, empfehlen wir, Annotationen zu migrieren und das appArmorProfile.type-Feld zu verwenden, um die Kompatibilität Ihrer Workloads sicherzustellen.

Die Funktion zur Übergangszeit in der PersistentVolume letzten Phase wurde auf Stable umgestellt und ist nun in der Kubernetes-Version allgemein für den öffentlichen Gebrauch verfügbar. 1.31 Mit dieser Funktion wird ein neues Feld eingeführt,.status.lastTransitionTime, in dem ein Zeitstempel angegeben wird PersistentVolumeStatus, wann das PersistentVolume letzte Mal in eine andere Phase übergegangen ist. Diese Erweiterung ermöglicht eine bessere Nachverfolgung und Verwaltung von PersistentVolumes, insbesondere in Szenarien, in denen es wichtig ist, den Lebenszyklus von Volumen zu verstehen.

Ab der Amazon EKS-Version 1.30 oder neuer verwenden alle neu erstellten verwalteten Knotengruppen automatisch standardmäßig Amazon Linux 2023 (AL2023) als Knotenbetriebssystem. Weitere Informationen zum Festlegen des Betriebssystems für eine verwaltete Knotengruppe finden Sie unter Eine verwaltete Knotengruppe für Ihren Cluster erstellen.

Mit Amazon EKS 1.30 wird das topology.k8s.aws/zone-id-Label den Worker-Knoten hinzugefügt. Sie können die Availability Zone IDs (AZ IDs) verwenden, um den Standort von Ressourcen in einem Konto im Verhältnis zu den Ressourcen in einem anderen Konto zu bestimmen. Weitere Informationen finden Sie im AWS RAM-Benutzerhandbuch unter Availability Zone IDs für Ihre AWS Ressourcen.

Ab Version 1.30 enthält Amazon EKS keine default-Annotation mehr zu den gp2 StorageClass-Ressourcen, die auf neu erstellte Cluster angewendet werden. Dies hat keine Auswirkungen, wenn Sie namentlich auf diese Speicherklasse verweisen. Sie müssen Maßnahmen ergreifen, wenn Sie sich darauf verlassen, dass im Cluster ein Standard-StorageClass vorhanden ist. Sie sollten auf StorageClass mit dem Namen gp2 verweisen. Alternativ können Sie die von Amazon EBS empfohlene Standardspeicherklasse bereitstellen, indem Sie den defaultStorageClass.enabled-Parameter bei der Installation von Version 1.31.0 oder höher von aws-ebs-csi-driver add-on auf „true“ setzen.

Die erforderliche Mindest-IAM-Richtlinie für die IAM-Rolle des Amazon-EKS-Clusters wurde geändert. Die Aktion ec2:DescribeAvailabilityZones ist erforderlich. Weitere Informationen finden Sie unter Amazon-EKS-Cluster-IAM-Rolle.

Das .status.kubeProxyVersion-Feld für Knotenobjekte ist nun veraltet, und das Kubernetes-Projekt schlägt vor, dieses Feld in einer zukünftigen Version zu entfernen. Das veraltete Feld ist nicht korrekt und wurde in der Vergangenheit von kubelet verwaltet, das weder die kube-proxy-Version kennt noch weiß, ob kube-proxy ausgeführt wird. Wenn Sie dieses Feld in Ihrer Clientsoftware verwendet haben, sollten Sie dies unterlassen, da die Informationen nicht zuverlässig sind und das Feld nun veraltet ist.

Um die potenzielle Angriffsfläche in Kubernetes 1.29 zu reduzieren, kennzeichnet das LegacyServiceAccountTokenCleanUp-Feature automatisch generierte geheime Tokens als ungültig, wenn sie längere Zeit (standardmäßig 1 Jahr) nicht verwendet wurden, und entfernt sie automatisch, wenn nach der Kennzeichnung als ungültig (standardmäßig 1 weiteres Jahr) längere Zeit keine Verwendung erfolgt. Um solche Tokens zu identifizieren, können Sie folgenden Befehl ausführen:

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