Amazon EKS Kubernetes versions
The Kubernetes project is continually integrating new features, design updates, and bug fixes.
The community releases new Kubernetes minor versions, such as 1.27
. New version
updates are available on average every three months. Each minor version is supported for
approximately twelve months after it's first released.
Available Amazon EKS Kubernetes versions
The following Kubernetes versions are currently available for new Amazon EKS clusters:
-
1.27
-
1.26
-
1.25
-
1.24
-
1.23
-
1.22
If your application doesn't require a specific version of Kubernetes, we recommend that you use the latest available Kubernetes version that's supported by Amazon EKS for your clusters. As new Kubernetes versions become available in Amazon EKS, we recommend that you proactively update your clusters to use the latest available version. For instructions on how to update your cluster, see Updating an Amazon EKS cluster Kubernetes version. For more information about Kubernetes releases, see Amazon EKS Kubernetes release calendar and Amazon EKS version support and FAQ.
Note
For 1.24
and later clusters, officially published Amazon EKS AMIs include
containerd
as the only runtime. Kubernetes versions earlier than
1.24
use Docker as the default runtime. These
versions have a bootstrap flag option that you can use to test out your workloads on
any supported cluster with containerd
. For more information, see Amazon EKS ended support for
Dockershim.
Kubernetes 1.27
Kubernetes 1.27
is now available in Amazon EKS. For more information about Kubernetes
1.27
, see the official
release announcement
Important
The support for the alpha seccomp
annotations
seccomp.security.alpha.kubernetes.io/pod
and
container.seccomp.security.alpha.kubernetes.io
annotations was
removed. The alpha seccomp
annotations was deprecated in
1.19
, and with their removal in 1.27
,
seccomp
fields will no longer auto-populate for Pods
with seccomp
annotations. Instead, use the
securityContext.seccompProfile
field for Pods
or
containers to configure seccomp
profiles. To check whether you are
using the deprecated alpha seccomp
annotations in your cluster, run the
following command:
kubectl get pods --all-namespaces -o json | grep -E 'seccomp.security.alpha.kubernetes.io/pod|container.seccomp.security.alpha.kubernetes.io'
The --container-runtime
command line argument for the kubelet
was
removed. The default container runtime for Amazon EKS has been containerd since
1.24
, which eliminates the need to specify the container runtime.
From 1.27
onwards, Amazon EKS will ignore the
--container-runtime
argument passed to any bootstrap scripts. It is
important that you don't pass this argument to --kubelet-extra-args
in
order to prevent errors during the node bootstrap process. You must remove the
--container-runtime
argument from all of your node creation
workflows and build scripts.
-
The
kubelet
in Kubernetes1.27
increased the defaultkubeAPIQPS
to50
andkubeAPIBurst
to100
. These enhancements allow thekubelet
to handle a higher volume of API queries, improving response times and performance. When the demands forPods
increase, due to scaling requirements, the revised defaults ensure that thekubelet
can efficiently manage the increased workload. As a result,Pod
launches are quicker and cluster operations are more effective. -
You can use more fine grained
Pod
topology to spread policies such asminDomain
. This parameter gives you the ability to specify the minimum number of domains yourPods
should be spread across.nodeAffinityPolicy
andnodeTaintPolicy
allow for an extra level of granularity in governingPod
distribution. This is in accordance to node affinities, taints, and thematchLabelKeys
field in thetopologySpreadConstraints
of yourPod's
specification. This permits the selection ofPods
for spreading calculations following a rolling upgrade. -
Kubernetes
1.27
promoted to beta a new policy mechanism forStatefulSets
that controls the lifetime of theirPersistentVolumeClaims
(PVCs
). The newPVC
retention policy lets you specify if thePVCs
generated from theStatefulSet
spec template will be automatically deleted or retrained when theStatefulSet
is deleted or replicas in theStatefulSet
are scaled down.
For the complete Kubernetes 1.27
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md
Kubernetes 1.26
Kubernetes 1.26
is now available in Amazon EKS. For more information about Kubernetes
1.26
, see the official
release announcement
Important
Kubernetes 1.26
no longer supports CRI
v1alpha2
. This results in the kubelet
no longer registering the node
if the container runtime doesn't support CRI
v1
. This also means that Kubernetes 1.26
doesn't support
containerd minor version 1.5
and earlier. If you're using containerd,
you need to upgrade to containerd version 1.6.0
or later before you
upgrade any nodes to Kubernetes 1.26
. You also need to upgrade any other
container runtimes that only support the v1alpha2
. For more
information, defer to the container runtime vendor. By default, Amazon Linux
and Bottlerocket AMIs include containerd version
1.6.6
.
-
Before you upgrade to Kubernetes
1.26
, upgrade your Amazon VPC CNI plugin for Kubernetes to version1.12
or later. If you don't upgrade to Kubernetes1.26
, earlier versions of the Amazon VPC CNI plugin for Kubernetes crash. For more information, see Working with the Amazon VPC CNI plugin for Kubernetes for Kubernetes Amazon EKS add-on.
For the complete Kubernetes 1.26
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md
Kubernetes 1.25
Kubernetes 1.25
is now available in Amazon EKS. For more information about Kubernetes
1.25
, see the official
release announcement
Important
PodSecurityPolicy
(PSP) is removed in Kubernetes
1.25
. PSPs are replaced with Pod
Security Admission (PSA)1.25
and are enabled in Amazon EKS by default. If you have
PSPs in your cluster, make sure to migrate from
PSP to the built-in Kubernetes PSS or to a
policy-as-code solution before upgrading your cluster to version 1.25
.
If you don't migrate from PSP, you might encounter interruptions to your workloads.
For more information, see the Pod security policy (PSP) removal
FAQ.
Amazon EKS 1.25
includes enhancements to cluster authentication that
contain updated YAML libraries. If a YAML value in the
aws-auth
ConfigMap
found in the kube-system
namespace starts with a
macro, where the first character is a curly brace, you should add quotation marks
(“ ”
) before and after the curly braces ({ }
). This is
required to ensure that aws-iam-authenticator
version
v0.6.3
accurately parses the aws-auth
ConfigMap
in Amazon EKS 1.25
.
The beta API version (discovery.k8s.io/v1beta1
) of
EndpointSlice
was deprecated in Kubernetes 1.21
and is no
longer served as of Kubernetes 1.25
. This API has been updated to
discovery.k8s.io/v1
. For more information, see EndpointSlice
v2.4.6
and earlier used the v1beta1
endpoint to
communicate with EndpointSlices
. If you're using the
EndpointSlices
configuration for the Amazon Load Balancer Controller, you must upgrade to
Amazon Load Balancer Controller v2.4.7
before upgrading your Amazon EKS cluster to
1.25
. If you upgrade to 1.25
while using the
EndpointSlices
configuration for the Amazon Load Balancer Controller, the controller will
crash and result in interruptions to your workloads. To upgrade the controller, see
Installing the Amazon Load Balancer Controller add-on.
-
SeccompDefault
is promoted to beta in Kubernetes1.25
. By setting the--seccomp-default
flag when you configurekubelet
, the container runtime uses itsRuntimeDefault
seccomp
profile, rather than the unconfined (seccomp disabled
) mode. The default profiles provide a strong set of security defaults, while preserving the functionality of the workload. Although this flag is available, Amazon EKS doesn't enable this flag by default, so Amazon EKS behavior is effectively unchanged. If you want to, you can start enabling this on your nodes. For more details, see the tutorial Restrict a Container's Syscalls with seccompin the Kubernetes documentation. -
Support for the Container Runtime Interface (CRI) for Docker (also known as
Dockershim
) was removed from Kubernetes1.24
and later. The only container runtime in Amazon EKS official AMIs for Kubernetes1.24
and later clusters iscontainerd
. Before upgrading to Amazon EKS1.24
or later, remove any reference to bootstrap script flags that aren't supported anymore. For more information, see Amazon EKS ended support for Dockershim. -
The support for wildcard queries was deprecated in CoreDNS
1.8.7
and removed in CoreDNS1.9
. This was done as a security measure. Wildcard queries no longer work and returnNXDOMAIN
instead of an IP address.
For the complete Kubernetes 1.25
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#changelog-since-v1240
Kubernetes 1.24
Kubernetes 1.24
is now available in Amazon EKS. For more information about Kubernetes
1.24
, see the official release announcement
Important
Starting with Kubernetes 1.24
, new beta APIs aren't enabled in clusters by
default. By default, existing beta APIs and new versions of existing beta APIs
continue to be enabled. Amazon EKS follows the same behavior as upstream Kubernetes
1.24
. The feature gates that control new features for both new and
existing API operations are enabled by default. This is in alignment with upstream
Kubernetes. For more information, see KEP-3136: Beta APIs Are Off by Default
Support for Container Runtime Interface (CRI) for Docker (also
known as Dockershim) is removed from Kubernetes 1.24
. Amazon EKS
official AMIs have containerd as the only runtime. Before moving to
Amazon EKS 1.24
or higher, you must remove any reference to bootstrap script
flags that aren't supported anymore. For more information, see Amazon EKS ended support for
Dockershim.
In Kubernetes 1.23
and earlier, kubelet
serving certificates with
unverifiable IP and DNS Subject Alternative Names (SANs) are automatically issued
with unverifiable SANs. These unverifiable SANs are omitted from the provisioned
certificate. In version 1.24
and later clusters, kubelet
serving
certificates aren't issued if any SAN can't be verified. This prevents
kubectl
exec and kubectl
logs commands from working.
For more information, see Certificate signing considerations before upgrading
your cluster to Kubernetes 1.24.
Amazon EKS 1.24
or later, you must remove any reference to bootstrap
script flags that aren't supported anymore. For more information, see Amazon EKS ended support for
Dockershim.
When
upgrading an Amazon EKS 1.23
or earlier cluster that uses Fluent
Bit, you must make sure that it's running k8s/1.3.12
or
later. You can do this by reapplying the latest applicable Fluent Bit
YAML file from GitHub. For more information, see Setting up Fluent Bit in the Amazon CloudWatch User Guide.
In Kubernetes 1.23
and earlier, kubelet
serving certificates with
unverifiable IP and DNS Subject Alternative Names (SANs) are automatically issued
with unverifiable SANs. These unverifiable SANs are omitted from the provisioned
certificate. In version 1.24
and later clusters, kubelet
serving
certificates aren't issued if any SAN can't be verified. This prevents
kubectl
exec and kubectl
logs commands from working.
For more information, see Certificate signing considerations before upgrading
your cluster to Kubernetes 1.24.
-
You can use Topology Aware Hints to indicate your preference for keeping traffic in zone when cluster worker nodes are deployed across multiple availability zones. Routing traffic within a zone can help reduce costs and improve network performance. By default, Topology Aware Hints are enabled in Amazon EKS
1.24
. For more information, see Topology Aware Hintsin the Kubernetes documentation. -
The
PodSecurityPolicy
(PSP) is scheduled for removal in Kubernetes1.25
. PSPs are being replaced with Pod Security Admission (PSA). PSA is a built-in admission controller that uses the security controls that are outlined in the Pod Security Standards (PSS) . PSA and PSS are both beta features and are enabled in Amazon EKS by default. To address the removal of PSP in version 1.25
, we recommend that you implement PSS in Amazon EKS. For more information, see Implementing Pod Security Standards in Amazon EKSon the Amazon blog. -
The
client.authentication.k8s.io/v1alpha1
ExecCredential is removed in Kubernetes1.24
. The ExecCredential API was generally available in Kubernetes1.22
. If you use a client-go credential plugin that relies on thev1alpha1
API, contact the distributor of your plugin on how to migrate to thev1
API. -
For Kubernetes
1.24
, we contributed a feature to the upstream Cluster Autoscaler project that simplifies scaling Amazon EKS managed node groups to and from zero nodes. Previously, for the Cluster Autoscaler to understand the resources, labels, and taints of a managed node group that was scaled to zero nodes, you needed to tag the underlying Amazon EC2 Auto Scaling group with the details of the nodes that it was responsible for. Now, when there are no running nodes in the managed node group, the Cluster Autoscaler calls the Amazon EKSDescribeNodegroup
API operation. This API operation provides the information that the Cluster Autoscaler requires of the managed node group's resources, labels, and taints. This feature requires that you add theeks:DescribeNodegroup
permission to the Cluster Autoscaler service account IAM policy. When the value of a Cluster Autoscaler tag on the Auto Scaling group powering an Amazon EKS managed node group conflicts with the node group itself, the Cluster Autoscaler prefers the value of the Auto Scaling group tag. This is so that you can override values as needed. For more information, see Autoscaling. -
If you intend to use Inferentia or Trainium instance types with Amazon EKS
1.24
, you must upgrade to the Amazon Neuron device plugin version 1.9.3.0 or later. For more information, see Neuron K8 release [1.9.3.0]in the Amazon Neuron Documentation. -
Containerd
hasIPv6
enabled for Pods, by default. It applies node kernel settings to Pod network namespaces. Because of this, containers in a Pod bind to bothIPv4
(127.0.0.1
) andIPv6
(::1
) loopback addresses.IPv6
is the default protocol for communication. Before updating your cluster to version1.24
, we recommend that you test your multi-container Pods. Modify apps so that they can bind to all IP addresses on loopback interfaces. The majority of libraries enableIPv6
binding, which is backward compatible withIPv4
. When it’s not possible to modify your application code, you have two options:-
Run an
init
container and setdisable ipv6
totrue
(sysctl -w net.ipv6.conf.all.disable ipv6=1
). -
Configure a mutating admission webhook
to inject an init
container alongside your application Pods.
If you need to block
IPv6
for all Pods across all nodes, you might have to disableIPv6
on your instances. -
For the complete Kubernetes 1.24
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#changelog-since-v1230
Kubernetes 1.23
Kubernetes 1.23
is now available in Amazon EKS. For more information about Kubernetes
1.23
, see the official release announcement
Important
The Kubernetes in-tree to container storage interface (CSI) volume migration feature is
enabled. This feature enables the replacement of existing Kubernetes in-tree storage
plugins for Amazon EBS with a corresponding Amazon EBS CSI driver. For more information, see
Kubernetes 1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta
The feature translates in-tree APIs to equivalent CSI APIs and delegates
operations to a replacement CSI driver. With this feature, if you use existing
StorageClass
, PersistentVolume
, and
PersistentVolumeClaim
objects that belong to these workloads, there
likely won't be any noticeable change. The feature enables Kubernetes to delegate all
storage management operations from the in-tree plugin to the CSI driver. If you use
Amazon EBS volumes in an existing cluster, install the Amazon EBS CSI driver in your cluster
before you update your cluster to version 1.23
. If you don't install
the driver before updating an existing cluster, interruptions to your workloads
might occur. If you plan to deploy workloads that use Amazon EBS volumes in a new
1.23
cluster, install the Amazon EBS CSI driver in your cluster before
deploying the workloads your cluster. For instructions on how to install the Amazon EBS
CSI driver on your cluster, see Amazon EBS CSI driver.
For frequently asked questions about the migration feature, see Amazon EBS CSI migration frequently asked
questions.
-
Kubernetes stopped supporting
dockershim
in version1.20
and removeddockershim
in version1.24
. For more information, see Kubernetes is Moving on From Dockershim: Commitments and Next Stepsin the Kubernetes blog. Amazon EKS will end support for dockershim
starting in Amazon EKS version1.24
. Starting with Amazon EKS version1.24
, Amazon EKS official AMIs will havecontainerd
as the only runtime.Even though Amazon EKS version
1.23
continues to supportdockershim
, we recommend that you start testing your applications now to identify and remove any Docker dependencies. This way, you are prepared to update your cluster to version1.24
. For more information aboutdockershim
removal, see Amazon EKS ended support for Dockershim. -
Kubernetes graduated
IPv4
/IPv6
dual-stack networking for Pods, services, and nodes to general availability. However, Amazon EKS and the Amazon VPC CNI plugin for Kubernetes don't support dual-stack networking. Your clusters can assignIPv4
orIPv6
addresses to Pods and services, but can't assign both address types. -
Kubernetes graduated the Pod Security Admission (PSA) feature to beta. The feature is enabled by default. For more information, see Pod Security Admission
in the Kubernetes documentation. PSA replaces the Pod Security Policy (PSP) admission controller. The PSP admission controller isn't supported and is scheduled for removal in Kubernetes version 1.25
.The PSP admission controller enforces Pod security standards on Pods in a namespace based on specific namespace labels that set the enforcement level. For more information, see Pod Security Standards (PSS) and Pod Security Admission (PSA)
in the Amazon EKS best practices guide. -
The
kube-proxy
image deployed with clusters is now the minimal base imagemaintained by Amazon EKS Distro (EKS-D). The image contains minimal packages and doesn't have shells or package managers. -
Kubernetes graduated ephemeral containers to beta. Ephemeral containers are temporary containers that run in the same namespace as an existing Pod. You can use them to observe the state of Pods and containers for troubleshooting and debugging purposes. This is especially useful for interactive troubleshooting when
kubectl exec
is insufficient because either a container has crashed or a container image doesn't include debugging utilities. An example of a container that includes a debugging utility is distroless images. For more information, see Debugging with an ephemeral debug container in the Kubernetes documentation. -
Kubernetes graduated the
HorizontalPodAutoscaler
autoscaling/v2
stable API to general availability. TheHorizontalPodAutoscaler
autoscaling/v2beta2
API is deprecated. It will be unavailable in1.26
.
For the complete Kubernetes 1.23
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220
Kubernetes 1.22
Kubernetes 1.22
is now available in Amazon EKS. For more information about Kubernetes
1.22
, see the official release announcement
Important
BoundServiceAccountTokenVolume
1.22
. This feature improves
security of service account tokens. It allows workloads that are running on Kubernetes to
request JSON web tokens that are audience, time, and key bound. Service account
tokens now have an expiration of one hour. In previous Kubernetes versions, they didn't
have an expiration. This means that clients that rely on these tokens must refresh
the tokens within an hour. The following Kubernetes
client SDKs
Go version
0.15.7
and laterPython version
12.0.0
and laterJava version
9.0.0
and laterJavaScript version
0.10.3
and laterRuby
master
branchHaskell version
0.3.0.0
C# version
7.0.5
and later
If your workload is using an older client version, then you must update it. To
enable a smooth migration of clients to the newer time-bound service account tokens,
Kubernetes version 1.22
adds an extended expiry period to the service
account token over the default one hour. For Amazon EKS clusters, the extended expiry
period is 90 days. Your Amazon EKS cluster's Kubernetes API server rejects requests with
tokens older than 90 days. We recommend that you check your applications and their
dependencies. Make sure that the Kubernetes client SDKs are the same or later than
the versions listed previously. For instructions about how to identify
Pods that are using stale tokens, see Kubernetes service accounts.
-
Kubernetes
1.22
removes a number of APIs that are no longer available. You might need to make changes to your application before you upgrade to Amazon EKS version1.22
. Follow the Kubernetes version 1.22 prerequisites carefully before updating your cluster. -
The Ingress API versions
extensions/v1beta1
andnetworking.k8s.io/v1beta1
have been removed in Kubernetes1.22
. If you're using the Amazon Load Balancer Controller, you must upgrade to at least version 2.4.1
before you upgrade your Amazon EKS clusters to version 1.22
. Additionally, you must modify Ingress manifeststo use apiVersion
networking.k8s.io/v1
. This has been available since Kubernetes version1.19
. For more information about changes between Ingress v1beta1
andv1
, see the Kubernetes documentation. The Amazon Load Balancer Controller controller sample manifest uses the v1
spec. -
The Amazon EKS legacy Windows support controllers use the
admissionregistration.k8s.io/v1beta1
API that was removed in Kubernetes1.22
. If you're running Windows workloads, you must remove legacy Windows support and enable Windows support before upgrading to Amazon EKS version1.22
. -
The CertificateSigningRequest (CSR)
API version certificates.k8s.io/v1beta1
was removed in Kubernetes version1.22
. You must migrate manifests and API clients to use thecertificates.k8s.io/v1
CSR API. This API has been available since version1.19
. For instructions on how to use CSR in Amazon EKS, see Certificate signing. -
The
CustomResourceDefinition
API versionapiextensions.k8s.io/v1beta1
was removed in Kubernetes1.22
. Make sure that all custom resource definitions in your cluster are updated tov1
. API versionv1
custom resource definitions are required to have Open APIv3
schema validation defined. For more information, see the Kubernetes documentation. -
If you're using App Mesh, you must upgrade to at least App Mesh controller
v1.4.3
or later before you upgrade to Amazon EKS version1.22
. Older versions of the App Mesh controller usev1beta1
CustomResourceDefinition
API version and aren't compatible with Kubernetes version1.22
and later. -
Amazon EKS version
1.22
enables theEndpointSliceTerminatingCondition
feature by default, which includes Pods in terminating state withinEndpointSlices
. If you setenableEndpointSlices
toTrue
(disabled by default) in the Amazon Load Balancer Controller, you must upgrade to at least Amazon Load Balancer Controller version2.4.1+
before upgrading to Amazon EKS version1.22
. -
Starting with Amazon EKS version
1.22
,kube-proxy
is configured by default to expose Prometheus metrics outside the Pod. This behavior change addresses the request made in containers roadmap issue #657. -
The initial launch of Amazon EKS version
1.22
usesetcd
version3.4
as a backend, and is not affected by the possibility of data corruptionpresent in etcd
version3.5
. -
Starting with Amazon EKS
1.22
, Amazon EKS is decoupling Amazon cloud specific control logic from core control plane code to the out-of-treeAmazon Kubernetes Cloud Controller Manager . This is in line with the upstream Kubernetes recommendation. By decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, the cloud-controller-manager
component enables cloud providers to release features at a different pace compared to the main Kubernetes project. This change is transparent and requires no action. However, a new log stream namedcloud-controller-manager
now appears under theControllerManager
log type when enabled. For more information, see Amazon EKS control plane logging. -
Starting with Amazon EKS
1.22
, Amazon EKS is changing the default Amazon Security Token Service endpoint used by IAM roles for service accounts (IRSA) to be the regional endpoint instead of the global endpoint to reduce latency and improve reliability. You can optionally configure IRSA to use the global endpoint in Configuring the Amazon Security Token Service endpoint for a service account.
The following Kubernetes features are now supported in Kubernetes 1.22
Amazon EKS
clusters:
-
Server-side Apply graduates to GA
- Server-side Apply helps users and controllers manage their resources through declarative configurations. It allows them to create or modify objects declaratively by sending their fully specified intent. After being in beta for a couple releases, Server-side Apply is now generally available. -
Warning mechanism for use of unsupported APIs
- Use of unsupported APIs produces warnings visible to API consumers, and metrics visible to cluster administrators.
For the complete Kubernetes 1.22
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#changelog-since-v1210
Kubernetes 1.21
Kubernetes 1.21
is now available in Amazon EKS. For more information about Kubernetes
1.21
, see the official release announcement
Important
BoundServiceAccountTokenVolume
1.21
. This feature improves
security of service account tokens by allowing workloads running on Kubernetes to request
JSON web tokens that are audience, time, and key bound. Service account tokens now
have an expiration of one hour. In previous Kubernetes versions, they didn't have an
expiration. This means that clients that rely on these tokens must refresh the
tokens within an hour. The following Kubernetes
client SDKs
Go version
0.15.7
and laterPython version
12.0.0
and laterJava version
9.0.0
and laterJavaScript version
0.10.3
and laterRuby
master
branchHaskell version
0.3.0.0
C# version
7.0.5
and later
If your workload is using an older client version, then you must update it. To
enable a smooth migration of clients to the newer time-bound service account tokens,
Kubernetes version 1.21
adds an extended expiry period to the service
account token over the default one hour. For Amazon EKS clusters, the extended expiry
period is 90 days. Your Amazon EKS cluster's Kubernetes API server rejects requests with
tokens older than 90 days. We recommend that you check your applications and their
dependencies. Make sure that the Kubernetes client SDKs are the same or later than
the versions listed previously. For instructions about how to identify
Pods that are using stale tokens, see Kubernetes service accounts.
-
Dual-stack networking
support ( IPv4
andIPv6
addresses) on Pods, services, and nodes reached beta status. However, Amazon EKS and the Amazon VPC CNI plugin for Kubernetes don't currently support dual stack networking. -
The Amazon EKS Optimized Amazon Linux 2 AMI now contains a bootstrap flag to enable the
containerd
runtime as a Docker alternative. This flag allows preparation for the removal of Docker as a supported runtimein the next Kubernetes release. For more information, see Enable the containerd runtime bootstrap flag. This can be tracked through the container roadmap on Github . -
Managed node groups support for Cluster Autoscaler priority expander.
Newly created managed node groups on Amazon EKS version
1.21
clusters use the following format for the underlying Auto Scaling group name:eks-
managed-node-group-name
-uuid
This enables using the priority expander
feature of Cluster Autoscaler to scale node groups based on user defined priorities. A common use case is to prefer scaling spot node groups over on-demand groups. This behavior change solves the containers roadmap issue #1304 .
The following Kubernetes features are now supported in Amazon EKS 1.21
clusters:
-
CronJobs
(previously ScheduledJobs) have now graduated to stable status. With this change, users perform regularly scheduled actions such as backups and report generation. -
Immutable Secrets and ConfigMaps
have now graduated to stable status. A new, immutable field was added to these objects to reject changes. This rejection protects the cluster from updates that can unintentionally break the applications. Because these resources are immutable, kubelet
doesn't watch or poll for changes. This reduceskube-apiserver
load and improving scalability and performance. -
Graceful Node Shutdown
has now graduated to beta status. With this update, the kubelet
is aware of node shutdown and can gracefully terminate that node's Pods. Before this update, when a node shutdown, its Pods didn't follow the expected termination lifecycle. This caused workload problems. Now, thekubelet
can detect imminent system shutdown throughsystemd
, and inform running Pods so they terminate gracefully. -
Pods with multiple containers can now use the
kubectl.kubernetes.io/default-container
annotation to have a container preselected forkubectl
commands. -
PodSecurityPolicy
is being phased out.PodSecurityPolicy
will still be functional for several more releases according to Kubernetes deprecation guidelines. For more information, see PodSecurityPolicy Deprecation: Past, Present, and Futureand the Amazon blog .
For the complete Kubernetes 1.21
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md
Kubernetes 1.20
For more information about Kubernetes 1.20
, see the official release announcement
-
1.20
brings new Amazon EKS created default roles and users. You can find more information in Default Amazon EKS created Kubernetes roles and users. Ensure that you are using a supported cert-manager version.
The following Kubernetes features are now supported in Kubernetes 1.20
Amazon EKS
clusters:
-
API Priority and Fairness
has reached beta status and is enabled by default. This allows kube-apiserver
to categorize incoming requests by priority levels. -
RuntimeClass
has reached stable status. The RuntimeClass
resource provides a mechanism for supporting multiple runtimes in a cluster and surfaces information about that container runtime to the control plane. -
Process ID Limits
has now graduated to general availability. -
kubectl debug
has reached beta status. kubectl debug
supports common debugging workflows directly fromkubectl
. -
The Docker container runtime has been phased out. The Kubernetes community has written a blog post
about this in detail with a dedicated FAQ page . Docker-produced images can continue to be used and will work as they always have. You can safely ignore the dockershim
deprecation warning message printed inkubelet
startup logs. Amazon EKS will eventually move tocontainerd
as the runtime for the Amazon EKS optimized Amazon Linux 2 AMI. You can follow the containers roadmap issuefor more details. -
Pod Hostname as FQDN has graduated to beta status. This feature allows setting a Pod's hostname to its Fully Qualified Domain Name (FQDN). This way, you can set the hostname field of the kernel to the FQDN of a Pod.
-
The client-go credential plugins can now be passed in the current cluster information via the
KUBERNETES_EXEC_INFO
environment variable. This enhancement allows Go clients to authenticate using external credential providers, such as a key management system (KMS).
For the complete Kubernetes 1.20
changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md
Amazon EKS Kubernetes release calendar
Note
Dates with only a month and a year are approximate and are updated with an exact date when it's known.
Kubernetes version | Upstream release | Amazon EKS release | Amazon EKS end of support |
---|---|---|---|
1.27 |
April 11, 2023 | May 24, 2023 | July 2024 |
1.26 |
December 9, 2022 | April 11, 2023 | June 2024 |
1.25 |
August 23, 2022 | February 22, 2023 | May 2024 |
1.24 |
May 3, 2022 | November 15, 2022 | January 2024 |
1.23 |
December 7, 2021 | August 11, 2022 | October 11, 2023 |
1.22 |
August 4, 2021 | April 4, 2022 | June 4, 2023 |
1.21 |
April 8, 2021 | July 19, 2021 | February 15, 2023 |
1.20 |
December 8, 2020 | May 18, 2021 | November 1, 2022 |
Amazon EKS version support and FAQ
In line with the Kubernetes community support for Kubernetes versions, Amazon EKS is committed to supporting at least four production-ready versions of Kubernetes at any given time. We will announce the end of support date of a given Kubernetes minor version at least 60 days before the end of support date. Because of the Amazon EKS qualification and release process for new Kubernetes versions, the end of support date of a Kubernetes version on Amazon EKS will be on or after the date that the Kubernetes project stops supporting the version upstream.
Frequently asked questions
Q: How long is a Kubernetes version supported by Amazon EKS?
A: A Kubernetes version is supported 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.
Q: Am I notified when support is ending for a Kubernetes version on Amazon EKS?
A: Yes, if any clusters in your account are running the version nearing the end of support, Amazon EKS sends out a notice through the Amazon 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.
Q: What happens on the end of support date?
A: On the end of 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 the Kubernetes version for your Amazon EKS cluster .
Q: When exactly is my control plane automatically updated after the end of support date?
A: Amazon EKS can't provide specific time frames. Automatic updates can happen at any time after the end of 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 Updating an Amazon EKS cluster Kubernetes version.
Q: Can I leave my control plane on a Kubernetes version indefinitely?
A: No, cloud security at Amazon 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 support.
Q: Which Kubernetes features are supported by Amazon EKS?
A: Amazon EKS supports all general availability features of the Kubernetes API. It also supports all beta features, which are enabled by default. Alpha features aren't supported.
Q: Are Amazon EKS managed node groups automatically updated along with the cluster control plane version?
A: 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. Assume that Amazon EKS automatically updates your control plane. The Kubernetes version that's on your managed node group might be more than one version earlier than your control plane. Then, assume that a managed node group contains instances that are running a version of Kubernetes that's more than one version earlier than the control plane. The node group has a health issue in the Node groups section of the Compute tab of your cluster in the console. Last, if a node group has an available version update, Update now appears next to the node group in the console. For more information, see Updating a managed node group. We recommend maintaining the same Kubernetes version on your control plane and nodes.
Q: Are self-managed node groups automatically updated along with the cluster control plane version?
A: 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 Self-managed node updates.
The Kubernetes project tests compatibility between the control plane and nodes for up
to two minor versions. For example, 1.25
nodes continue to operate
when orchestrated by a 1.27
control plane. However, running a
cluster with nodes that are persistently two minor versions behind the control plane
isn't recommended. For more information, see Kubernetes version and
version skew support policy
Q: Are Pods running on Fargate automatically upgraded with an automatic cluster control plane version upgrade?
Yes, Fargate Pods run on infrastructure in Amazon owned
accounts on the Amazon EKS side of the shared responsibility
model. Amazon EKS uses the Kubernetes eviction API to attempt to gracefully
drain Pods that are running on Fargate. For more information,
see The Eviction APIdelete
Pod
command. We strongly recommend running
Fargate Pods as part of a replication controller such as a
Kubernetes deployment. This is so that a Pod is automatically
rescheduled after deletion. For more information, see Deploymentskubelet
version that's the
same version as your updated cluster control plane version.
Important
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.