Amazon EKS is ending support for
Dockershim
Kubernetes no longer supports Dockershim
. Additionally, the Kubernetes team plans to
completely remove the runtime in Kubernetes version 1.24
. Amazon EKS will be ending
support for Dockershim
starting with the Kubernetes version 1.24
launch. Amazon EKS AMIs that are officially published will have containerd
as the
only runtime starting with version 1.24
.
There's a kubectl
plugin you can use to see which of your Kubernetes workloads are mounting
the Docker socket volume. For more information, see Detector for
Docker Socket (DDS)1.18
through 1.23
use Docker as
the default runtime, but have a bootstrap flag option that you can use to test out your
workloads on any supported cluster today with containerd
. For more information,
see Enable the
containerd runtime bootstrap
flag.
We will continue to publish AMIs for existing Kubernetes versions until the end of their
support date. For more information, see Amazon EKS Kubernetes release calendar. If you require more time to test your
workloads on containerd
, you can stay on a supported version before
1.24
and still be fully supported. But, when version 1.24
is
made available and you want to upgrade official Amazon EKS AMIs to that version or higher, make
sure to validate that your workloads run on containerd
.
If you will be upgrading to version 1.24
or higher but you still want to use
Dockershim
, build your own AMI with Docker installed.
However, when Kubernetes removes Dockershim
support, make sure that you migrate to
containerd
to remain on a supported version. For more information, see
Kubernetes is Moving on From Dockershim: Commitments and Next Steps
The containerd
runtime provides more reliable performance and
security, and it's the runtime we're standardizing on across Amazon EKS (Fargate
and Bottlerocket already use containerd
only).
containerd
helps to minimize the number of Amazon EKS AMI
releases that are required to address Dockershim
Common Vulnerabilities and
ExposuresDockershim
already uses
containerd
internally, you might not need to make any
changes. However, there are some situations where changes might or must be
required:
-
You must make changes for any application that mounts the Docker socket. For example, building container images using a container are impacted. Many monitoring tools also mount the Docker socket. You may have to wait for updates or re-deploy workloads for runtime monitoring.
-
You might need to make changes for any application that's reliant on specific Docker settings. For example, using
HTTPS_PROXY
can require changes. For more information, see dockerdin the Docker Docs. -
If you're using the Amazon ECR credential helper to pull images, you must switch to the
kubelet
image credential provider. For more information, see Configure a kubelet image credential providerin the Kubernetes documentation.