**Help improve this page** To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page. # Understand the Kubernetes version lifecycle on EKS Kubernetes versions **Tip** [Register](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) for upcoming Amazon EKS workshops. Kubernetes rapidly evolves with new features, design updates, and bug fixes. The community releases new Kubernetes minor versions (such as `1.35`) on average once every four months. Amazon EKS follows the upstream release and deprecation cycle for minor versions. As new Kubernetes versions become available in Amazon EKS, we recommend that you proactively update your clusters to use the latest available version. A minor version is under standard support in Amazon EKS for the first 14 months after it’s released. Once a version is past the end of standard support date, it enters extended support for the next 12 months. Extended support allows you to stay at a specific Kubernetes version for longer at an additional cost per cluster hour. If you haven’t updated your cluster before the extended support period ends, your cluster is auto-upgraded to the oldest currently supported extended version. Extended support is enabled by default. To disable, see [Disable EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html). We recommend that you create your cluster with the latest available Kubernetes version supported by Amazon EKS. If your application requires a specific version of Kubernetes, you can select older versions. You can create new Amazon EKS clusters on any version offered in standard or extended support. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/_dJdAZ_J_jw?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/_dJdAZ_J_jw?rel=0) ## Available versions on standard support The following Kubernetes versions are currently available in Amazon EKS standard support: + `1.35` + `1.34` + `1.33` For important changes to be aware of for each version in standard support, see [Kubernetes versions standard support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html). ## Available versions on extended support The following Kubernetes versions are currently available in Amazon EKS extended support: + `1.32` + `1.31` + `1.30` For important changes to be aware of for each version in extended support, see [Kubernetes versions extended support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-extended.html). ## Amazon EKS Kubernetes release calendar The following table shows important release and support dates to consider for each Kubernetes version. Billing for extended support starts at the beginning of the day that the version reaches end of standard support, in the UTC\$10 timezone. The dates in the following table use the UTC\$10 timezone. **Note** Dates with only a month and a year are approximate and are updated with an exact date when it’s known. To receive notifications of all source file changes to this specific documentation page, you can subscribe to the following URL with an RSS reader: ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/versioning/kubernetes-versions.adoc.atom ``` | Kubernetes version | Upstream release | Amazon EKS release | End of standard support | End of extended support | | --- | --- | --- | --- | --- | | `1.35` | December 17, 2025 | January 27, 2026 | March 27, 2027 | March 27, 2028 | | `1.34` | August 27, 2025 | October 2, 2025 | December 2, 2026 | December 2, 2027 | | `1.33` | April 23, 2025 | May 29, 2025 | July 29, 2026 | July 29, 2027 | | `1.32` | December 11, 2024 | January 23, 2025 | March 23, 2026 | March 23, 2027 | | `1.31` | August 13, 2024 | September 26, 2024 | November 26, 2025 | November 26, 2026 | | `1.30` | April 17, 2024 | May 23, 2024 | July 23, 2025 | July 23, 2026 | ## Get version information with AWS CLI You can use the AWS CLI to get information about Kubernetes versions available on EKS, such as the end date of Standard Support. ### To retrieve information about available Kubernetes versions on EKS using the AWS CLI 1. Open your terminal. 1. Ensure you have the AWS CLI installed and configured. For more information, see [Installing or updating to the latest version of the CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). 1. Run the following command: ``` aws eks describe-cluster-versions ``` 1. The command will return a JSON output with details about the available cluster versions. Here’s an example of the output: ``` { "clusterVersions": [ { "clusterVersion": "1.31", "clusterType": "eks", "defaultPlatformVersion": "eks.21", "defaultVersion": true, "releaseDate": "2024-09-25T17:00:00-07:00", "endOfStandardSupportDate": "2025-11-25T16:00:00-08:00", "endOfExtendedSupportDate": "2026-11-25T16:00:00-08:00", "status": "STANDARD_SUPPORT", "kubernetesPatchVersion": "1.31.3" } ] } ``` **The output provides the following information for each cluster version:** + `clusterVersion`: The Kubernetes version of the EKS cluster + `clusterType`: The type of cluster (e.g., "eks") + `defaultPlatformVersion`: The default EKS platform version + `defaultVersion`: Whether this is the default version + `releaseDate`: The date when this version was released + `endOfStandardSupportDate`: The date when standard support ends + `endOfExtendedSupportDate`: The date when extended support ends + `status`: The current support status of the version, such as `STANDARD_SUPPORT` or `EXTENDED_SUPPORT` + `kubernetesPatchVersion`: The specific Kubernetes patch version ## Amazon EKS version FAQs **How many Kubernetes versions are available in standard support?** In line with the Kubernetes community support for Kubernetes versions, Amazon EKS is committed to offering support for at least three Kubernetes versions at any given time. We will announce the end of standard support date of a given Kubernetes minor version at least 60 days in advance. Because of the Amazon EKS qualification and release process for new Kubernetes versions, the end of standard support date of a Kubernetes version on Amazon EKS will be after the date that the Kubernetes project stops supporting the version upstream. **How long does a Kubernetes receive standard support by Amazon EKS?** A Kubernetes version received standard support for 14 months after first being available on Amazon EKS. This is true even if upstream Kubernetes no longer support a version that’s available on Amazon EKS. We backport security patches that are applicable to the Kubernetes versions that are supported on Amazon EKS. **Am I notified when standard support is ending for a Kubernetes version on Amazon EKS?** Yes. If any clusters in your account are running the version nearing the end of support, Amazon EKS sends out a notice through the AWS Health Dashboard approximately 12 months after the Kubernetes version was released on Amazon EKS. The notice includes the end of support date. This is at least 60 days from the date of the notice. **Which Kubernetes features are supported by Amazon EKS?** Amazon EKS supports all generally available (GA) features of the Kubernetes API. New beta APIs aren’t enabled in clusters by default. However, previously existing beta APIs and new versions of existing beta APIs continue to be enabled by default. Alpha features aren’t supported. **Are Amazon EKS managed node groups automatically updated along with the cluster control plane version?** No. A managed node group creates Amazon EC2 instances in your account. These instances aren’t automatically upgraded when you or Amazon EKS update your control plane. For more information, see [Update a managed node group for your cluster](update-managed-node-group.md). We recommend maintaining the same Kubernetes version on your control plane and nodes. **Are self-managed node groups automatically updated along with the cluster control plane version?** No. A self-managed node group includes Amazon EC2 instances in your account. These instances aren’t automatically upgraded when you or Amazon EKS update the control plane version on your behalf. A self-managed node group doesn’t have any indication in the console that it needs updating. You can view the `kubelet` version installed on a node by selecting the node in the **Nodes** list on the **Overview** tab of your cluster to determine which nodes need updating. You must manually update the nodes. For more information, see [Update self-managed nodes for your cluster](update-workers.md). The Kubernetes project tests compatibility between the control plane and nodes for up to three minor versions. For example, `1.32` nodes continue to operate when orchestrated by a `1.35` control plane. However, running a cluster with nodes that are persistently three minor versions behind the control plane isn’t recommended. For more information, see [Kubernetes version and version skew support policy](https://kubernetes.io/docs/setup/version-skew-policy/) in the Kubernetes documentation. We recommend maintaining the same Kubernetes version on your control plane and nodes. **Are Pods running on Fargate automatically upgraded with an automatic cluster control plane version upgrade?** No. We strongly recommend running Fargate Pods as part of a replication controller, such as a Kubernetes deployment. Then do a rolling restart of all Fargate Pods. The new version of the Fargate Pod is deployed with a `kubelet` version that’s the same version as your updated cluster control plane version. For more information, see [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) in the Kubernetes documentation. If you update the control plane, you must still update the Fargate nodes yourself. To update Fargate nodes, delete the Fargate Pod represented by the node and redeploy the Pod. The new Pod is deployed with a `kubelet` version that’s the same version as your cluster. **What Kubernetes versions are supported for hybrid nodes?** Amazon EKS Hybrid Nodes supports the same Kubernetes versions as Amazon EKS clusters with other node compute types, including standard and extended Kubernetes version support. Hybrid nodes are not automatically upgraded when you upgrade your control plane version and you are responsible for upgrading your hybrid nodes. For more information, see [Upgrade hybrid nodes for your cluster](hybrid-nodes-upgrade.md). ## Amazon EKS extended support FAQs **The standard support and extended support terminology is new to me. What do those terms mean?** Standard support for a Kubernetes version in Amazon EKS begins when a Kubernetes version is released on Amazon EKS, and will end 14 months after the release date. Extended support for a Kubernetes version will begin immediately after the end of standard support, and will end after the next 12 months. For example, standard support for version `1.23` in Amazon EKS ended on October 11, 2023. Extended support for version `1.23` began on October 12, 2023 and ended on October 11, 2024. **What do I need to do to get extended support for Amazon EKS clusters?** You will need to enable extended support (see [EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/enable-extended-support.html)) for your cluster by changing the cluster upgrade policy to EXTENDED. By default, for all new and existing clusters, the upgrade policy is set to EXTENDED, unless specified otherwise. See [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html) to view the upgrade policy for your cluster. Standard support will begin when a Kubernetes version is released on Amazon EKS, and will end 14 months after the release date. Extended support for a Kubernetes version will begin immediately after the end of standard support, and will end after the next 12 months. **For which Kubernetes versions can I get extended support?** You can run clusters on any version for up to 12 months after the end of standard support for that version. This means that each version will be supported for 26 months in Amazon EKS (14 months of standard support plus 12 months of extended support). **What if I don’t want to use extended support?** If you don’t want to be automatically enrolled in extended support, you can upgrade your cluster to a Kubernetes version that’s in standard Amazon EKS support. To disable extended support, see [Disable EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html). Note: If you disable extended support, your cluster will be auto upgraded at the end of standard support. **What will happen at the end of 12 months of extended support?** Clusters running on a Kubernetes version that has completed its 26-month lifecycle (14 months of standard support plus 12 months of extended support) will be auto-upgraded to the next version. The auto-upgrade includes only the Kubernetes control plane. If you have EKS Auto Mode nodes, they may automatically update. Self managed nodes and EKS Managed Node Groups will remain on the previous version. On the end of extended support date, you can no longer create new Amazon EKS clusters with the unsupported version. Existing control planes are automatically updated by Amazon EKS to the earliest supported version through a gradual deployment process after the end of support date. After the automatic control plane update, make sure to manually update cluster add-ons and Amazon EC2 nodes. For more information, see [Update existing cluster to new Kubernetes version](update-cluster.md). **When exactly is my control plane automatically updated after the end of extended support date?** Amazon EKS can’t provide specific time frames. Automatic updates can happen at any time after the end of extended support date. You won’t receive any notification before the update. We recommend that you proactively update your control plane without relying on the Amazon EKS automatic update process. For more information, see [Update existing cluster to new Kubernetes version](update-cluster.md). **Can I leave my control plane on a Kubernetes version indefinitely?** No. Cloud security at AWS is the highest priority. Past a certain point (usually one year), the Kubernetes community stops releasing common vulnerabilities and exposures (CVE) patches and discourages CVE submission for unsupported versions. This means that vulnerabilities specific to an older version of Kubernetes might not even be reported. This leaves clusters exposed with no notice and no remediation options in the event of a vulnerability. Given this, Amazon EKS doesn’t allow control planes to stay on a version that reached end of extended support. **Is there additional cost to get extended support?** Yes, there is additional cost for Amazon EKS clusters running in extended support. For pricing details, see [Amazon EKS extended support for Kubernetes version pricing](https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing) on the AWS blog or our [pricing page](https://aws.amazon.com/eks/pricing/). **What is included in extended support?** Amazon EKS clusters in Extended Support receive ongoing security patches for the Kubernetes control plane. Additionally, Amazon EKS will release patches for the Amazon VPC CNI, `kube-proxy`, and CoreDNS add-ons for Extended Support versions. Amazon EKS will also release patches for AWS-published Amazon EKS optimized AMIs for Amazon Linux, Bottlerocket, and Windows, as well as Amazon EKS Fargate nodes for those versions. All clusters in Extended Support will continue to get access to technical support from AWS. **Are there any limitations to patches for non-Kubernetes components in extended support?** While Extended Support covers all of the Kubernetes specific components from AWS, it will only provide support for AWS-published Amazon EKS optimized AMIs for Amazon Linux, Bottlerocket, and Windows at all times. This means, you will potentially have newer components (such as OS or kernel) on your Amazon EKS optimized AMI while using Extended Support. For example, once Amazon Linux 2 reaches the [end of its lifecycle in 2025](https://aws.amazon.com/amazon-linux-2/faqs/), the Amazon EKS optimized Amazon Linux AMIs will be built using a newer Amazon Linux OS. Amazon EKS will announce and document important support lifecycle discrepancies such as this for each Kubernetes version. **Can I create new clusters using a version on extended support?** Yes. # Review release notes for Kubernetes versions on standard support Standard support versions **Tip** [Register](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) for upcoming Amazon EKS workshops. This topic gives important changes to be aware of for each Kubernetes version in standard support. When upgrading, carefully review the changes that have occurred between the old and new versions for your cluster. ## Kubernetes 1.35 Kubernetes `1.35` is now available in Amazon EKS. For more information about Kubernetes `1.35`, see the [official release announcement](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/). **Important** Cgroup v1 Support Removed: Kubernetes 1.35 deprecates cgroup v1 support, meaning the kubelet will refuse to start by default on nodes using cgroup v1. AL2023: AL2023 uses cgroup v2 by default and aligns with Kubernetes upstream behavior. Action required: Customers who manually configured AL2023 to use cgroup v1 must either [migrate to cgroups v2](https://kubernetes.io/docs/concepts/architecture/cgroups/) or manually set `failCgroupV1: false` in kubelet configuration. Bottlerocket: Bottlerocket 1.35 uses cgroup v2 by default, however sets `failCgroupV1: false` in the kubelet configuration, maintaining backward compatibility. Fargate: Fargate continues to use cgroup v1. Containerd 1.x End of Support: Kubernetes 1.35 is the last release supporting containerd 1.x. You must switch to containerd 2.0 or later before upgrading to the next Kubernetes version. In March 2026, the upstream Kubernetes project will retire Ingress NGINX, a critical infrastructure component for many Kubernetes environments. Action required: EKS customers should evaluate whether they rely on Ingress NGINX and begin planning migration to alternatives such as Gateway API or third-party Ingress controllers, as there will be no further releases for bug fixes, security patches, or updates after retirement. Existing deployments will continue to work, but remaining with Ingress NGINX after retirement leaves your environment vulnerable to security risks, as none of the available alternatives are direct drop-in replacements and will require planning and engineering time. For more information about this Kubernetes announcement, see the official statement from the Kubernetes Steering and Security Response Committees [Ingress NGINX retirement](https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/). + **In-Place Pod Resource Updates (Stable):** In-Place Pod Resource Updates allows users to adjust CPU and memory resources without restarting Pods or containers. Previously, such modifications required recreating Pods, which could disrupt workloads, particularly for stateful or batch applications. The new in-place functionality allows for smoother, non-disruptive vertical scaling, improves efficiency, and can also simplify development. + For more information, see [Kubernetes 1.35: In-Place Pod Resize Graduates to Stable](https://kubernetes.io/blog/2025/12/19/kubernetes-v1-35-in-place-pod-resize-ga/) on the *Kubernetes Blog*. + **PreferSameNode Traffic Distribution (Stable):** The `trafficDistribution` field for Services has been updated to provide more explicit control over traffic routing. A new option, `PreferSameNode`, has been introduced to allow services to strictly prioritize endpoints on the local node when available, falling back to remote endpoints otherwise. This change makes the API more explicit about preferring traffic within the current node. + **StatefulSet MaxUnavailable (Beta):** This feature enables parallel Pod updates by setting `maxUnavailable` (e.g., 3 or 10%), allowing stateful applications like database clusters to update up to 60% faster than sequential one-at-a-time updates, significantly reducing maintenance windows. + **Windows Server 2025 Support:** EKS 1.35 adds support for [Windows Server 2025](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html). + **Kubelet Flag Removal:** The `--pod-infra-container-image` flag has been removed from kubelet. Custom AMI users must remove this flag from kubelet configuration before upgrading to 1.35. + **Deprecation Notice - IPVS Mode:** IPVS mode in kube-proxy is deprecated and will be removed in Kubernetes 1.36. For the complete Kubernetes `1.35` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md ## Kubernetes 1.34 Kubernetes `1.34` is now available in Amazon EKS. For more information about Kubernetes `1.34`, see the [official release announcement](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/). **Important** Containerd updated to 2.1 in Version 1.34 for launch. If you experience any issues after upgrade, check the [containerd 2.1 release notes](https://github.com/containerd/containerd/releases/tag/v2.1.0). AWS is not releasing an EKS-optimized Amazon Linux 2 AMI for Kubernetes 1.34. AWS encourages you to migrate to Amazon Linux 2023. Learn how to [Upgrade from Amazon Linux 2 to Amazon Linux 2023](al2023.md). For more information, see [Amazon Linux 2 AMI deprecation](kubernetes-versions-extended.md#al2-ami-deprecation). AppArmor is deprecated in Kubernetes 1.34. We recommend migrating to alternative container security solutions like [seccomp](https://kubernetes.io/docs/tutorials/security/seccomp/) or [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/). VolumeAttributesClass (VAC) graduates to GA in Kubernetes 1.34, migrating from the beta API (`storage.k8s.io/v1beta1`) to the stable API (`storage.k8s.io/v1`). If you use the EBS CSI driver with AWS-managed sidecar containers (from [CSI Components](https://gallery.ecr.aws/csi-components) on the ECR Gallery), volume modification will continue to work seamlessly on EKS 1.31-1.33 clusters. AWS will patch the sidecars to support beta VAC APIs until the end of EKS 1.33 standard support (July 29, 2026). If you self-manage your CSI sidecar containers, you may need to pin to older sidecar versions on pre-1.34 clusters to maintain VAC functionality. To use GA VolumeAttributesClass features (such as modification rollback), upgrade to EKS 1.34 or later. External JWT Signer for Service Account Tokens is promoted to Beta. When using external signers, the --service-account-extend-token-expiration flag is no longer fully respected. The API server enforces the minimum expiration between the desired extension (1 year) and the external signer’s limit (24 hours). We recommend using [bound service account tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens), which are automatically mounted and rotated by Kubernetes. + **Dynamic Resource Allocation (DRA) Core APIs (GA):** Dynamic Resource Allocation has graduated to stable, enabling efficient management of specialized hardware like GPUs through standardized allocation interfaces - simplifying resource management for hardware accelerators and improving utilization of specialized resources. + **Projected ServiceAccount Tokens for Kubelet (Beta):** This enhancement improves security by using short-lived credentials for container image pulls instead of long-lived secrets - reducing the risk of credential exposure and strengthening the overall security posture of your clusters. + **Pod-level Resource Requests and Limits (Beta):** This feature simplifies resource management by allowing shared resource pools for multi-container pods - enabling more efficient resource allocation and utilization for complex applications with multiple containers. + **Mutable CSI Node Allocatable Count (Beta):** The `MutableCSINodeAllocatableCount` feature gate is enabled by default in EKS 1.34, making the CSINode max attachable volume count attribute mutable and introducing a mechanism to update it dynamically based on user configuration at the CSI driver level. These updates can be triggered either by periodic intervals or by failure detection, enhancing the reliability of stateful pod scheduling by addressing mismatches between reported and actual attachment capacity on nodes. + For more information, see [Kubernetes v1.34: Mutable CSI Node Allocatable Count](https://kubernetes.io/blog/2025/09/11/kubernetes-v1-34-mutable-csi-node-allocatable-count/) on the *Kubernetes Blog*. + **Deprecation Notice - cgroup driver configuration:** Manual cgroup driver configuration is being deprecated in favor of automatic detection. + **Customer impact:** If you currently set the `--cgroup-driver` flag manually in your kubelet configuration, you should prepare to remove this configuration. + **Required action:** Plan to update node bootstrap scripts and custom AMI configurations to remove manual cgroup driver settings before the feature is removed in a future Kubernetes release. + For more information, see the [cgroup driver documentation](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). For the complete Kubernetes `1.34` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md ## Kubernetes 1.33 Kubernetes `1.33` is now available in Amazon EKS. For more information about Kubernetes `1.33`, see the [official release announcement](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/). **Important** The Dynamic Resource Allocation *beta* Kubernetes API is enabled. This beta API improves the experience of scheduling and monitoring workloads that require resources such as GPUs. The beta API is defined by the Kubernetes community, and might change in future versions of Kubernetes. Carefully review [Feature stages](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages) in the Kubernetes documentation to understand the implications of using beta APIs. AWS is not releasing an EKS-optimized Amazon Linux 2 AMI for Kubernetes 1.33. AWS encourages you to migrate to Amazon Linux 2023. Learn how to [Upgrade from Amazon Linux 2 to Amazon Linux 2023](al2023.md). For more information, see [Amazon Linux 2 AMI deprecation](kubernetes-versions-extended.md#al2-ami-deprecation). + **In-Place Pod Resource Resize (Beta):** In-place resource resize has been promoted to beta, allowing dynamic updates to CPU and memory resources for existing Pods without restarts - enabling vertical scaling of stateful workloads with zero downtime and seamless resource adjustments based on traffic patterns. + **Sidecar Containers Now Stable:** Sidecar containers have graduated to stable, implementing sidecars as special init containers with `restartPolicy: Always` that start before application containers, run throughout the pod lifecycle, and support probes for operational state signaling. + For more information, see [Sidecar Containers](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) in the *Kubernetes Documentation*. + **Endpoints API Deprecation:** The Endpoints API is now officially deprecated and will return warnings when accessed - migrate workloads and scripts to use the EndpointSlices API instead, which supports modern features like dual-stack networking and handles multiple EndpointSlices per Service. + For more information, see [Kubernetes v1.33: Continuing the transition from Endpoints to EndpointSlice](https://kubernetes.io/blog/2025/04/24/endpoints-deprecation/) on the *Kubernetes Blog*. + **Elastic Fabric Adapter Support:** The default security group for Amazon EKS clusters now supports Elastic Fabric Adapter (EFA) traffic. The default security group has a new outbound rule that allows EFA traffic with the destination of the same security group. This allows EFA traffic within the cluster. + For more information, see [Elastic Fabric Adapter for AI/ML and HPC workloads on Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) in the Amazon Elastic Compute Cloud User Guide. For the complete Kubernetes `1.33` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.33.md # Review release notes for Kubernetes versions on extended support Extended support versions Amazon EKS supports Kubernetes versions longer than they are supported upstream, with standard support for Kubernetes minor versions for 14 months from the time they are released in Amazon EKS, and extended support for Kubernetes minor versions for an additional 12 months of support (26 total months per version). This topic gives important changes to be aware of for each Kubernetes version in extended support. When upgrading, carefully review the changes that have occurred between the old and new versions for your cluster. ## Kubernetes 1.32 Kubernetes `1.32` is now available in Amazon EKS. For more information about Kubernetes `1.32`, see the [official release announcement](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/). **Important** The `flowcontrol.apiserver.k8s.io/v1beta3` API version of FlowSchema and PriorityLevelConfiguration has been removed in version `1.32`. If you are using these APIs, you must update your configurations to use the latest supported version before upgrading. ServiceAccount `metadata.annotations[kubernetes.io/enforce-mountable-secrets]` has been deprecated in version `1.32` and will be removed in a future Kubernetes minor version release. It is recommended to use separate namespaces to isolate access to mounted secrets. Kubernetes version `1.32` is the last version for which Amazon EKS will release Amazon Linux 2 (AL2) AMIs. From version `1.33` onwards, Amazon EKS will continue to release Amazon Linux 2023 (AL2023) and Bottlerocket based AMIs. + The Memory Manager feature has graduated to Generally Available (GA) status in Kubernetes version `1.32`. This enhancement provides more efficient and predictable memory allocation for containerized applications, particularly beneficial for workloads with specific memory requirements. + PersistentVolumeClaims (PVCs) created by StatefulSets now include automatic cleanup functionality. When PVCs are no longer needed, they will be automatically deleted while maintaining data persistence during StatefulSet updates and node maintenance operations. This feature simplifies storage management and helps prevent orphaned PVCs in your cluster. + Custom Resource Field Selector functionality has been introduced, allowing developers to add field selectors to custom resources. This feature provides the same filtering capabilities available for built-in Kubernetes objects to custom resources, enabling more precise and efficient resource filtering and promoting better API design practices. For the complete Kubernetes `1.32` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md ### Anonymous authentication changes Starting with Amazon EKS `1.32`, anonymous authentication is restricted to the following API server health check endpoints: + `/healthz` + `/livez` + `/readyz` Requests to any other endpoint using the `system:unauthenticated` user will receive a `401 Unauthorized` HTTP response. This security enhancement helps prevent unintended cluster access that could occur due to misconfigured RBAC policies. **Note** The `public-info-viewer` RBAC role continues to apply for the health check endpoints listed above. ### Amazon Linux 2 AMI deprecation Kubernetes version `1.32` is the last version for which Amazon EKS released AL2 AMIs. From version `1.33` onwards, Amazon EKS will continue to release AL2023 and Bottlerocket based AMIs. For more information, see [Guide to EKS AL2 & AL2-Accelerated AMIs transition features](eks-ami-deprecation-faqs.md). ## Kubernetes 1.31 Kubernetes `1.31` is now available in Amazon EKS. For more information about Kubernetes `1.31`, see the [official release announcement](https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/). **Important** The kubelet flag `--keep-terminated-pod-volumes` deprecated since 2017 has been removed as part of the version `1.31` release. This change impacts how terminated pod volumes are handled by the kubelet. If you are using this flag in your node configurations, you must update your bootstrap scripts and launch templates to remove it before upgrading. + The beta `VolumeAttributesClass` feature gate and API resource is enabled in Amazon EKS version `1.31`. This feature allows cluster operators to modify mutable properties of Persistent Volumes (PVs) managed by compatible CSI Drivers, including the Amazon EBS CSI Driver. To leverage this feature, ensure that your CSI Driver supports the `VolumeAttributesClass` feature (for the Amazon EBS CSI Driver, upgrade to version `1.35.0` or later to automatically enable the feature). You will be able to create `VolumeAttributesClass` objects to define the desired volume attributes, such as volume type and throughput, and associate them with your Persistent Volume Claims (PVCs). See the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) as well as the documentation of your CSI driver for more information. + For more information about the Amazon EBS CSI Driver, see [Use Kubernetes volume storage with Amazon EBS](ebs-csi.md). + Kubernetes support for [AppArmor](https://apparmor.net/) has graduated to stable and is now generally available for public use. This feature allows you to protect your containers with AppArmor by setting the `appArmorProfile.type` field in the container’s `securityContext`. Prior to Kubernetes version `1.30`, AppArmor was controlled by annotations. Starting with version `1.30`, it is controlled using fields. To leverage this feature, we recommend migrating away from annotations and using the `appArmorProfile.type` field to ensure that your workloads are compatible. + The PersistentVolume last phase transition time feature has graduated to stable and is now generally available for public use in Kubernetes version `1.31`. This feature introduces a new field, `.status.lastTransitionTime`, in the PersistentVolumeStatus, which provides a timestamp of when a PersistentVolume last transitioned to a different phase. This enhancement allows for better tracking and management of PersistentVolumes, particularly in scenarios where understanding the lifecycle of volumes is important. For the complete Kubernetes `1.31` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md ## Kubernetes 1.30 Kubernetes `1.30` is now available in Amazon EKS. For more information about Kubernetes `1.30`, see the [official release announcement](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/). + Starting with Amazon EKS version `1.30` or newer, any newly created managed node groups will automatically default to using Amazon Linux 2023 (AL2023) as the node operating system. For more information about specifying the operating system for a managed node group, see [Create a managed node group for your cluster](create-managed-node-group.md). + With Amazon EKS `1.30`, the `topology.k8s.aws/zone-id` label is added to worker nodes. You can use Availability Zone IDs (AZ IDs) to determine the location of resources in one account relative to the resources in another account. For more information, see [Availability Zone IDs for your AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) in the * AWS RAM User Guide*. + Starting with `1.30`, Amazon EKS no longer includes the `default` annotation on the `gp2 StorageClass` resource applied to newly created clusters. This has no impact if you are referencing this storage class by name. You must take action if you were relying on having a default `StorageClass` in the cluster. You should reference the `StorageClass` by the name `gp2`. Alternatively, you can deploy the Amazon EBS recommended default storage class by setting the `defaultStorageClass.enabled` parameter to true when installing version `1.31.0` or later of the `aws-ebs-csi-driver add-on`. + The minimum required IAM policy for the Amazon EKS cluster IAM role has changed. The action `ec2:DescribeAvailabilityZones` is required. For more information, see [Amazon EKS cluster IAM role](cluster-iam-role.md). For the complete Kubernetes `1.30` changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md. # View current cluster support period View support period The **cluster support period** section of the AWS console indicates if your cluster is *currently* on standard or extended support. If your cluster support period is **Extended support**, you are being charged for EKS extended support. For more information about standard and extended support, see [Understand the Kubernetes version lifecycle on EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). 1. Navigate to the **Clusters** page in the EKS section of the AWS Console. Confirm the console is set to the same AWS region as the cluster you want to review. 1. Review the **Support Period** column. If the value is **Standard support until…​**, you are not currently being charged for extended support. You are within the standard support period. If the value is **Extended support…​** this cluster is currently being charged for extended support. **Note** The **Support Period** cannot be retrieved with the AWS API or CLI. # View current cluster upgrade policy View upgrade policy The **cluster upgrade policy** determines what happens to your cluster when it leaves the standard support period. If your upgrade policy is `EXTENDED`, the cluster will not be automatically upgraded, and will enter extended support. If your upgrade policy is `STANDARD`, it will be automatically upgraded. Amazon EKS controls for Kubernetes version policy allows you to choose the end of standard support behavior for your EKS clusters. With these controls you can decide which clusters should enter extended support and which clusters should be automatically upgraded at the end of standard support for a Kubernetes version. A minor version is under standard support in Amazon EKS for the first 14 months after it’s released. Once a version is past the end of standard support date, it enters extended support for the next 12 months. Extended support allows you to stay at a specific Kubernetes version for longer at an additional cost per cluster hour. You can enable or disable extended support for an EKS Cluster. If you disable extended support, AWS will automatically upgrade your cluster to the next version at the end of standard support. If you enable extended support, you can stay at the current version for an additional cost for a limited period of time. Plan to regularly upgrade your Kubernetes cluster, even if you use extended support. You can set the version policy for both new and existing clusters, using the `supportType` property. There are two options that can be used to set the version support policy: + ` STANDARD ` — Your EKS cluster eligible for automatic upgrade at the end of standard support. You will not incur extended support charges with this setting but your EKS cluster will automatically upgrade to the next supported Kubernetes version in standard support. + ` EXTENDED ` — Your EKS cluster will enter into extended support once the Kubernetes version reaches end of standard support. You will incur extended support charges with this setting. You can upgrade your cluster to a standard supported Kubernetes version to stop incurring extended support charges. Clusters running on extended support will be eligible for automatic upgrade at the end of extended support. Extended support is enabled by default for new clusters, and existing clusters. You can view if extended support is enabled for a cluster in the AWS Management Console, or by using the AWS CLI. **Important** If you want your cluster to stay on its current Kubernetes version to take advantage of the extended support period, you must enable the extended support upgrade policy before the end of standard support period. You can only set the version support policy for your clusters while its running on Kubernetes version in standard support. Once the version enters extended support, you will not be able to change this setting until you are running on a version in standard support. For example, if you have set your version support policy as `standard` then you will not be able to change this setting after the Kubernetes version running on your cluster reaches the end of standard support. If you have set your version support policy as `extended` then you will not be able to change this setting after the Kubernetes version running on your cluster reaches end of standard support. In order to change the version support policy setting, your cluster must be running on a standard supported Kubernetes version. ## View cluster upgrade policy (AWS Console) 1. Navigate to the **Clusters** page in the EKS section of the AWS Console. Confirm the console is set to the same AWS region as the cluster you want to review. 1. Review the **Upgrade Policy** column. If the value is **Standard Support**, your cluster will not enter extended support. If the value is **Extended Support**, your cluster will enter extended support. ## View cluster upgrade policy (AWS CLI) 1. Verify the AWS CLI is installed and you are logged in. [Learn how to update and install the AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 1. Determine the name of your EKS cluster. Set the CLI to the same AWS region as your EKS cluster. 1. Run the following command: ``` aws eks describe-cluster \ --name \ --query "cluster.upgradePolicy.supportType" ``` 1. If the value is `STANDARD`, your cluster will not enter extended support. If the value is `EXTENDED`, your cluster will enter extended support. # Add flexibility to plan Kubernetes version upgrades by enabling EKS extended support Enable extended support This topic describes how to set the *upgrade policy* of an EKS cluster to enable extended support. The upgrade policy of an EKS cluster determines what happens when a cluster reaches the end of the standard *support period*. If a cluster upgrade policy has extended support enabled, it will enter the extended support period at the end of the standard support period. The cluster will not be automatically upgraded at the end of the standard support period. Clusters actually in the *extended support period* incur higher costs. If a cluster merely has the upgrade policy set to enable extended support, and is otherwise in the *standard support period*, it incurs standard costs. If you create a cluster in the AWS console, it will have the upgrade policy set to disable extended support. If you create a cluster in another way, it will have the upgrade policy set to enable extended support. For example, clusters created with the AWS API have extended support enabled. For more information about upgrade policies, see [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html). **Important** If you want your cluster to stay on its current Kubernetes version to take advantage of the extended support period, you must enable the extended support upgrade policy before the end of standard support period. If you do not enable extended support, your cluster will be automatically upgraded. ## Enable EKS extended support (AWS Console) 1. Navigate to your EKS cluster in the AWS Console. Select the **Overview** tab on the **Cluster Info** page. 1. In the **Kubernetes version settings** section, select **Manage**. 1. Select **Extended support** and then **Save changes**. ## Enable EKS extended support (AWS CLI) 1. Verify the AWS CLI is installed and you are logged in. [Learn how to update and install the AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 1. Determine the name of your EKS cluster. 1. Run the following command: ``` aws eks update-cluster-config \ --name \ --upgrade-policy supportType=EXTENDED ``` # Prevent increased cluster costs by disabling EKS extended support Disable extended support This topic describes how to set the *upgrade policy* of an EKS cluster to disable extended support. The upgrade policy of an EKS cluster determines what happens when a cluster reaches the end of the standard *support period*. If a cluster upgrade policy has extended support disabled, it will be automatically upgraded to the next Kubernetes version. For more information about upgrade policies, see [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html). **Important** You cannot disable extended support once your cluster has entered it. You can only disable extended support for clusters on standard support. AWS recommends upgrading your cluster to a version in the standard support period. ## Disable EKS extended support (AWS Console) 1. Navigate to your EKS cluster in the AWS Console. Select the **Overview** tab on the **Cluster Info** page. 1. In the **Kubernetes version setting** section, select **Manage**. 1. Select **Standard support** and then **Save changes**. ## Disable EKS extended support (AWS CLI) 1. Verify the AWS CLI is installed and you are logged in. [Learn how to update and install the AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 1. Determine the name of your EKS cluster. 1. Run the following command: ``` aws eks update-cluster-config \ --name \ --upgrade-policy supportType=STANDARD ```