Amazon EKS hat die Unterstützung für Dockershim eingestellt

Kubernetes unterstützt Dockershim nicht mehr. Das Kubernetes-Team hat die Laufzeit in der Kubernetes-Version 1.24 entfernt. Weitere Informationen finden Sie unter Kubernetes is Moving on From Dockershim: Commitments and Next Steps im Kubernetes-Blog.

Amazon EKS beendet auch den Support für Dockershim ab der Kubernetes-Version der 1.24-Freigabe. Offiziell veröffentlichte Amazon EKS AMIs verfügen über containerd als einzige Laufzeit, beginnend mit Version 1.24. In diesem Thema werden einige Details behandelt, aber weitere Informationen finden Sie unter Alles, was Sie über die Umstellung auf containerd in Amazon EKS wissen müssen.

Es gibt ein kubectl-Plugin, mit dem Sie anzeigen können, welche Ihrer Kubernetes-Workloads das Docker-Socket-Volume mounten. Weitere Informationen finden Sie unter Detector for Docker Socket (DDS) auf GitHub. Amazon-EKS-AMIs, auf denen Kubernetes-Versionen ausgeführt werden, die älter sind als 1.24 verwenden Docker als Standard-Laufzeit. Diese Amazon-EKS-AMIs verfügen jedoch über eine Bootstrap-Flag-Option, mit der Sie Ihre Workloads auf jedem unterstützten Cluster mit containerd verwenden können. Weitere Informationen finden Sie unter Testen der Migration von Docker zu containerd.

Wir werden bis zum Ende des Support-Datums weiterhin AMIs für bestehende Kubernetes-Versionen veröffentlichen. Weitere Informationen finden Sie unter Amazon-EKS-Kubernetes-Release-Kalender. Wenn Sie mehr Zeit benötigen, um Ihre Workloads auf containerd zu testen, verwenden Sie eine unterstützte Version vor 1.24. Wenn Sie jedoch offizielle Amazon-EKS-AMIs auf Version 1.24 oder höher aktualisieren möchten, stellen Sie sicher, dass Ihre Workloads auf containerd ausgeführt werden.

Die containerd-Laufzeit bietet eine zuverlässigere Leistung und Sicherheit. containerd ist die Laufzeit, auf die Amazon EKS standardisiert wird. Fargate und Bottlerocket verwenden bereits nur noch containerd. containerd trägt dazu bei, die Anzahl der Amazon EKS AMI-Versionen zu minimieren, die zur Behebung von Dockershim Common Vulnerabilities and Exposures (CVEs) erforderlich sind. Da Dockershim bereits containerd intern verwendet, müssen Sie möglicherweise keine Änderungen vornehmen. Es gibt jedoch einige Situationen, in denen Änderungen erforderlich sein können:

• Sie müssen Änderungen an Anwendungen vornehmen, die den Docker-Socket mounten. Beispielsweise sind Container-Images, die mit einem Container entwickelt werden, davon betroffen. Viele Überwachungstools montieren auch den Docker-Socket. Möglicherweise müssen Sie auf Updates warten oder Workloads für die Laufzeitüberwachung erneut bereitstellen.

• Möglicherweise müssen Sie Änderungen für Anwendungen vornehmen, die auf bestimmte Docker-Einstellungen angewiesen ist. Beispielsweise wird das HTTPS_PROXY-Protokoll nicht mehr unterstützt. Sie müssen die Anwendungen, die dieses Protokoll verwenden, aktualisieren. Weitere Informationen finden Sie unter dockerd und in Docker Docs.

• Wenn Sie die Amazon ECR-Anmeldeinformation zum Abrufen von Images verwenden, müssen Sie zum Anbieter von kubelet-Image-Anmeldeinformationen wechseln. Weitere Informationen finden Sie unter Konfigurieren eines Anbieters von kubelet-Image-Anmeldeinformationen in der Kubernetes-Dokumentation.

• Da Amazon EKS 1.24 Dockernicht mehr unterstützt, werden einige Flags, die zuvor vom Amazon EKS-Bootstrap-Skript unterstützt wurden, nicht mehr unterstützt. Bevor Sie zu Amazon EKS 1.24 oder höher wechseln, müssen Sie alle Verweise auf Flags entfernen, die jetzt nicht mehr unterstützt werden:

  • --container-runtime dockerd (containerd ist der einzige unterstützte Wert)

  • --enable-docker-bridge

  • --docker-config-json

• Wenn Fluentd bereits für Container Insights konfiguriert ist, müssen Sie Fluentd zu Fluent Bit migrieren, bevor Sie zu containerd wechseln. Die Fluentd-Parser sind so konfiguriert, dass sie nur Protokollnachrichten im JSON-Format analysieren. Im Gegensatz zu dockerd enthält die Container-Laufzeit containerd Protokollnachrichten, die sich nicht im JSON-Format befinden. Wenn Sie nicht zu Fluent Bit migrieren, erzeugen einige der konfigurierten Fluentd's-Parser eine große Anzahl von Fehlern im Container Fluentd. Weitere Informationen zur Migration finden Sie unter Einrichten von Fluent Bit als DaemonSet, um Protokolle an CloudWatch Logs zu senden.

• Wenn Sie ein benutzerdefiniertes AMI verwenden und ein Upgrade auf Amazon EKS 1.24 durchführen, müssen Sie sicherstellen, dass die IP-Weiterleitung für Ihre Worker-Knoten aktiviert ist. Diese Einstellung wurde bei Docker nicht benötigt, ist aber für containerd erforderlich. Sie ist erforderlich, um Probleme mit den Netzwerkkonnektivitäten Pod-zu-Pod, Pod-zu-extern und Pod-zu-apiserver zu lösen.

  Führen Sie einen der folgenden Befehle aus, um diese Einstellung auf einem Worker-Knoten zu überprüfen:

  • sysctl net.ipv4.ip_forward

  • cat /proc/sys/net/ipv4/ip_forward

  Wenn die Ausgabe 0 lautet, führen Sie einen der folgenden Befehle aus, um die Kernelvariable net.ipv4.ip_forward zu aktivieren:

  • sysctl -w net.ipv4.ip_forward=1

  • echo 1 > /proc/sys/net/ipv4/ip_forward

  Informationen zur Aktivierung der Einstellung auf Amazon-EKS-AMIs in der containerd-Laufzeit finden Sie unter install-worker.sh auf GitHub.