Amazon EKS Kubernetes versions - Amazon EKS
Available Amazon EKS Kubernetes versionsKubernetes 1.17Kubernetes 1.16Kubernetes 1.15Kubernetes 1.14Amazon EKS Kubernetes release calendarAmazon EKS version deprecation and FAQ

Amazon EKS Kubernetes versions

The Kubernetes project is rapidly evolving with new features, design updates, and bug fixes. The community releases new Kubernetes minor versions, such as 1.17, as generally available approximately every three months, and each minor version is supported for approximately twelve months after it is first released.

Available Amazon EKS Kubernetes versions

The following Kubernetes versions are currently available for new clusters in Amazon EKS:

  • 1.17.9

  • 1.16.13

  • 1.15.11

  • 1.14.9

Unless your application requires a specific version of Kubernetes, we recommend that you choose the latest available Kubernetes version 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 more information, see Updating an Amazon EKS cluster Kubernetes version. For more information, see Amazon EKS Kubernetes release calendar and Amazon EKS version deprecation and FAQ.

Kubernetes 1.17

Kubernetes 1.17 is now available in Amazon EKS. For more information about Kubernetes 1.17, see the official release announcement.

Important

  • EKS has not enabled the CSIMigrationAWS feature flag. This will be enabled in a future release, along with detailed migration instructions. For more info on CSI migration, see the Kubernetes blog.

  • Upgrading a cluster from 1.16 to 1.17 will fail if any of your AWS Fargate pods have a kubelet minor version earlier than 1.16. Before upgrading your cluster from 1.16 to 1.17, you need to recycle your Fargate pods so that their kubelet is 1.16 before attempting to upgrade the cluster to 1.17. To recycle a Kubernetes deployment on a 1.15 or later cluster, use the following command. 

    kubectl rollout restart deployment deployment-name

The following Kubernetes features are now supported in Kubernetes 1.17 Amazon EKS clusters:

  • Cloud Provider Labels have reached general availability. If you are using the beta labels in your pod specs for features such as node affinity, or in any custom controllers, then we recommend that you start migrating them to the new GA labels. For information about the new labels, see the following Kubernetes documentation:

  • The ResourceQuotaScopeSelectors feature has graduated to generally available. This feature allows you to limit the number of resources a quota supports to only those that pertain to the scope.

  • The TaintNodesByCondition feature has graduated to generally available. This feature allows you to taint nodes that have conditions such as high disk or memory pressure.

  • The CSI Topology feature has graduated to generally available, and is fully supported by the EBS CSI driver. You can use topology to restrict the Availability Zone where a volume is provisioned.

  • Finalizer protection for services of type LoadBalancer has graduated to generally available. This feature ensures that a service resource is not fully deleted until the correlating load balancer is also deleted.

  • Custom resources now support default values. You specify values in an OpenAPI v3 validation schema.

  • The Windows containers RunAsUsername feature is now in beta, allowing you to run Windows applications in a container as a different username than the default.

For the complete Kubernetes 1.17 changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md.

Kubernetes 1.16

Kubernetes 1.16 is now available in Amazon EKS. For more information about Kubernetes 1.16, see the official release announcement.

Important

  • Kubernetes 1.16 removes a number of deprecated APIs. Changes to your applications may be required before upgrading your cluster to 1.16. Carefully follow the 1.16 upgrade prerequisites before upgrading.

  • Starting with 1.16, the Amazon EKS certificate authority will honor certificate signing requests with SAN X.509 extensions, which resolves the EKS CA should honor SAN x509 extension feature request from GitHub.

The following Kubernetes features are now supported in Kubernetes 1.16 Amazon EKS clusters:

  • Volume expansion in the CSI specification has moved to beta, which allows for any CSI spec volume plugin to be resizeable. For more information, see Volume Expansion in the Kubernetes CSI documentation. The latest version of the EBS CSI driver supports volume expansion when running on an Amazon EKS 1.16 cluster.

  • Windows GMSA support has graduated from alpha to beta, and is now supported by Amazon EKS. For more information, see Configure GMSA for Windows Pods and containers in the Kubernetes documentation.

  • A new annotation: service.beta.kubernetes.io/aws-load-balancer-eip-allocations is available on service type LoadBalancer to assign an elastic IP address to Network Load Balancers. For more information, see the Support EIP Allocations with AWS NLB GitHub issue.

  • Finalizer protection for service load balancers is now in beta and enabled by default. Service load balancer finalizer protection ensures that any load balancer resources allocated for a Kubernetes Service object, such as the AWS Network Load Balancer, will be destroyed or released when the service is deleted. For more information, see Garbage Collecting Load Balancers in the Kubernetes documentation.

  • The Kubernetes custom resource definitions and admission webhooks extensibility mechanisms have both reached general availability. For more information, see Custom Resources and Dynamic Admission Control in the Kubernetes documentation.

  • The server-side apply feature has reached beta status and is enabled by default. For more information, see Server Side Apply in the Kubernetes documentation.

  • The CustomResourceDefaulting feature is promoted to beta and enabled by default. Defaults may be specified in structural schemas through the apiextensions.k8s.io/v1 API. For more information, see Specifying a structural schema in the Kubernetes documentation.

For the complete Kubernetes 1.16 changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md.

Kubernetes 1.15

Kubernetes 1.15 is now available in Amazon EKS. For more information about Kubernetes 1.15, see the official release announcement.

Important

Starting with 1.15, Amazon EKS no longer tags the VPC containing your cluster.

  • Subnets within the VPC of your cluster are still tagged.

  • VPC tags will not be modified on existing cluster upgrades to 1.15.

Important

Amazon EKS has set the re-invocation policy for the Pod Identity Webhook to IfNeeded. This allows the webhook to be re-invoked if objects are changed by other mutating admission webhooks like the App Mesh sidecar injector. For more information about the App Mesh sidecar injector, see Install the sidecar injector.

The following features are now supported in Kubernetes 1.15 Amazon EKS clusters:

  • EKS now supports configuring transport layer security (TLS) termination, access logs, and source ranges for network load balancers. For more information, see Network Load Balancer support on AWS on GitHub.

  • Improved flexibility of Custom Resource Definitions (CRD), including the ability to convert between versions on the fly. For more information, see Extend the Kubernetes API with CustomResourceDefinitions on GitHub.

  • NodeLocal DNSCache is in beta for Kubernetes version 1.15 clusters. This feature can help improve cluster DNS performance by running a DNS caching agent on cluster nodes as a DaemonSet. For more information, see Using NodeLocal DNSCache in Kubernetes clusters on GitHub.

    Note

    When running CoreDNS on Amazon EC2, we recommend not using force_tcp in the configuration and ensuring that options use-vc is not set in /etc/resolv.conf.

For the complete Kubernetes 1.15 changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md.

Kubernetes 1.14

Kubernetes 1.14 is now available in Amazon EKS. For more information about Kubernetes 1.14, see the official release announcement.

Important

The -allow-privileged flag has been removed from kubelet on Amazon EKS 1.14 nodes. If you have modified or restricted the Amazon EKS default pod security policy on your cluster, you should verify that your applications have the permissions they need on 1.14 nodes.

The following features are now supported in Kubernetes 1.14 Amazon EKS clusters:

For the complete Kubernetes 1.14 changelog, see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.14.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 is known.

Kubernetes version Upstream release Amazon EKS release Amazon EKS end of support
1.14 March 25, 2019 September 4, 2019 November, 2020
1.15 June 19, 2019 March 10, 2020 May, 2021
1.16 Septermber 8, 2019 April 30, 2020 July, 2021
1.17 December 9, 2019 July 10, 2020 September, 2021
1.18 March 23, 2020 October, 2020 November, 2021
1.19 August 26, 2020 January, 2021 February, 2022

Amazon EKS version deprecation 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 deprecation 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 deprecation of a Kubernetes version on Amazon EKS will be on or after the date that the Kubernetes project stops supporting the version upstream.

Kubernetes supports compatibility between the control plane and nodes for up to two minor versions. For example, 1.15 nodes will continue to operate when orchestrated by a 1.17 control plane. For more information, see Kubernetes version and version skew support policy in the Kubernetes documentation.

Frequently asked questions

Q: How long is a Kubernetes version supported by Amazon EKS?

A: A Kubernetes version is fully supported for 14 months after first being available on Amazon EKS. This is true even if upstream Kubernetes is no longer supporting a version available on Amazon EKS. We backport security patches that are applicable to the Kubernetes versions supported on Amazon EKS.

Q: When does a Kubernetes version become deprecated on Amazon EKS?

A: Approximately 12 months after a version is released on Amazon EKS (usually with the release of a new version) Amazon EKS will send out a deprecation notice through the AWS Personal Health Dashboard if any clusters in your account are running the deprecated version. The deprecation notice will include the end of support date, which will be approximately 60 days from the date of the notice.

Q: Can I create new clusters on a version that is deprecated?

A: You can create new clusters with a deprecated version through the Amazon EKS API until the end of support date. You cannot create clusters using deprecated versions through the Amazon EKS console.

Q: What happens on the end of support date?

A: On the end of support date, you will no longer be able to create new Amazon EKS clusters with the unsupported version. Existing clusters will be automatically upgraded to the oldest supported version through a gradual deployment process after the end of support date.

Q: When exactly will my cluster be automatically upgraded after the end of support date?

A: Amazon EKS is unable to provide specific timeframes. Automatic upgrades can happen at any time after the end of support date. We recommend that you take proactive action and upgrade your clusters without relying on the Amazon EKS automatic upgrade process.

Q: Can I leave my cluster on a Kubernetes version indefinitely?

A: No. In the interest of security, Amazon EKS does not allow clusters to stay on a version that has reached end of support.