Containers

Amazon EKS 1.20 Released

The Amazon Elastic Kubernetes Service (Amazon EKS) team is pleased to announce support for Kubernetes 1.20. I had the privilege of serving on the upstream release team for this release from September to December of 2020 and am excited for Amazon EKS customers to experience “The Raddest Release” in all its glory.

Bringing you new releases quicker has been a priority for the EKS team and with this release, we’re diving right into working on the next. The upstream Kubernetes project has recently switched to a cadence of three releases a year from four. This change coupled with the continued maturation of the project is going to lead to much larger feature packed releases. We’ll continue to make sure that all the new and shiny features will be easy for you to use with EKS.

This release also marks the end of support for EKS 1.15. Kubernetes 1.16 is a notably challenging version to upgrade to due to many deprecated APIs being removed. Be sure to check out our blog post on 1.16 upgrade prep and the Amazon EKS release calendar for future dates.

Kubernetes 1.20 highlights

For all the furry details check out the upstream blog post and release notes. In this post, I’ll share some highlights.

Features in Kubernetes are gated with release phases. Alpha features are bleeding edge and only recommended for short-lived testing. They are usually disabled by default and may change or be removed at any point. Beta features are often enabled by default and considered safe to use. The structure of resources may change but this is the best time to provide feedback and help shape the feature. Stable features are generally available and safe to rely on. They shouldn’t see any breaking changes for the current major version. Since its launch, EKS has supported stable and enabled-by-default beta features.

TTL controller

A Job in Kubernetes is a workload for running shorter-lived tasks that run until completion as opposed to a Deployment which is meant for a long-running service or application. Jobs are often used for tasks like generating reports or doing extract, transform, and load (ETL) operations on data. By default, the Pods that a Job creates will stick around in your cluster after completion. This has the intended purpose of allowing you to observe their logs and results but the onus is on operators to clean them up or build tooling to do so.

The TTL controller was first introduced in Kubernetes 1.12 and helps to solve this pain point. It provides a time-to-live (TTL) mechanism to clean up completed Jobs. When a Job is marked Completed or Failed it (along with any created Pods) will be deleted after the time in .spec.ttlSecondsAfterFinished.

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 # <-- TTL controller

Though the TTL controller moved to beta in 1.21, it has seen no significant changes over the past few releases. As one of our most requested features and with thorough testing, we have decided to enable this alpha feature for EKS 1.20. This is an especially useful feature to take advantage of with Amazon EKS on AWS Fargate where completed tasks still incur costs until they are cleaned up.

PID Limits moves to GA

Process IDs (PIDs) represent the processes that are running on your servers. Different Linux installations have different PID limits and they depend directly on the amount of compute resources available. The PID Limits feature provides per-node and per-pod limits that can be set as flags for the kubelet (requiring the same node caveats as above). These limits allow you to reserve a certain number of PIDs for the operating system which can prevent your Kubernetes workloads from starving system operations.

Volume Snapshots moves to GA

The Container Storage Interface (CSI) is how you provision persistent storage in your clusters. When you’re using the Amazon Elastic Block Store (Amazon EBS) CSI driver and create a Persistent Volume, the controller is able to provision EBS volumes on your behalf. The EBS CSI driver has also recently moved to GA.

EBS snapshots are point-in-time backups of the data on an EBS volume. New EBS volumes can be created from snapshots as a way to create a clone or rollback a disk. Kubernetes Volume Snapshots bring this functionality to your clusters with native Kubernetes resources. Check out this blog post for more information on creating and using EBS Snapshots.

API Priority and Fairness moves to beta

API Priority and Fairness (APF) provides a way to sort and weigh traffic from busy controllers and other applications that make requests to the Kubernetes API Server like observability tools. Previous solutions required flags to be set on the Kubernetes API server and EKS does not support customer defined flags. It’s a more advanced feature that can be used to address various issues like bursty traffic that can flood the API server causing failed requests.

Cluster operators can tune the fine-grained controls of APF if you’re seeing dropped or delayed requests. There’s also a mechanism if you want to disable API rate limiting for certain endpoints or services like health and readiness checks. Check out the documentation for more.

RootCAConfigMap moves to beta

Starting with 1.20 you may notice a new default ConfigMap in all of your namespaces.

$ kubectl create namespace dontpageme
namespace/dontpageme created

$ kubectl -n dontpageme get configmaps
NAME               DATA   AGE
kube-root-ca.crt   1      7s

$ kubectl -n dontpageme get configmaps kube-root-ca.crt -o yaml
apiVersion: v1
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
    notarealcertiamgoingtowalkmydogintheparbecauseheisagoodboyLUJefD
    [snip]
    IXK0CtsLWTuafWK9YU7NYyfMD6DHVEV3dwMeLnlMoK28YTwdKVrF20qUDUSmsEO0
    Xvd/tqXWqNMqDXkyCUbnqXYe3A/N6iaGHJjK
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  creationTimestamp: "2021-04-30T22:01:08Z"
  name: kube-root-ca.crt
  namespace: dontpageme
  resourceVersion: "775"
  uid: f672079e-cd60-4a02-86ba-426a295b2393

This ConfigMap contains the Certificate Authority bundle for your Kubernetes API server allowing your controllers and services to verify their connections when making API requests. This is part of ongoing work to improve the security of Service Account Tokens.

Dockershim deprecation

You may remember discussion from Kubernetes users a few months ago when this first showed up in the release notes. Don’t Panic: Kubernetes and Docker co-authored by our own AWS Developer Advocate Justin Garrison on the Kubernetes Blog covers this in great detail. In short, don’t worry. The container runtime used in your cluster may change in the future but your Docker containers will still work and you shouldn’t notice it. You can safely ignore the dockershim deprecation warning message printed in kubelet startup logs. EKS will eventually move to containerd as the runtime for the EKS optimized Amazon Linux 2 AMI. You can follow the containers roadmap issue for more details.

Amazon EKS 1.20 specific changes

With each Kubernetes version release there may be some number of EKS specific changes. These will usually focus on interoperability with other AWS services. Starting with EKS 1.20 there are a few new default Service Accounts and Roles created to provide RBAC permissions to the different Kubernetes components.

Bottlerocket (a Linux-based open-source operating built by AWS for running containers) has been updated to kernel version 5.10 for EKS 1.20. You can use the EKS optimized Bottlerocket AMI to launch self-managed nodes for you cluster, and we are hard at work bringing native support for Bottlerocket to EKS managed node groups.

See the changelog since 1.19 and the EKS 1.20 docs for more.

Next Steps

Upgrade from 1.19

The upgrade from 1.19 to 1.20 should be pretty painless as there are little to no breaking changes. As always, check the upgrade notes first. Keeping your clusters up to date is an important aspect of using Kubernetes. EKS has integrated automation for upgrading but teams should still plan ahead. To get started with upgrading your clusters please see this blog post and the Amazon EKS documentation.

Plan for upgrades

If you’re still on Kubernetes 1.15, it’s time to upgrade. The support cycle ended May 3, 2021 and your control plane will eventually be automatically upgraded. We recommend that you take proactive action and update your control plane without relying on the Amazon EKS automatic update process. See the Version Deprecation FAQ for more info. Support for Kubernetes 1.16 ends July 25th, 2021. Best to get ahead of it and upgrade now. See the EKS Release Calendar for more.