Migrieren von dockershim zu containerd - Amazon EKS
Testen Sie die Amazon Linux 2-Migration von Docker zu containerd

Helfen Sie mit, diese Seite zu verbessern

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migrieren von dockershim zu containerd

Kubernetes unterstützt nicht mehrdockershim. Das Tool Kubernetes Das Team hat die Laufzeit entfernt in Kubernetes Version1.24. Weitere Informationen finden Sie unter Kubernetes is Moving on From Dockersheim: Commitments and Next Steps auf der Kubernetes Blog.

Amazon beendete EKS auch den Support für dockershim beginnend mit dem Kubernetes 1.24Versionsveröffentlichung. Amazon EKSAMIs, die offiziell veröffentlicht wurden, haben containerd als einzige Laufzeit ab Version1.24. Dieses Thema behandelt einige Details, aber weitere Informationen finden Sie unter Alles, was Sie über den Umstieg auf Containerd bei Amazon EKS wissen müssen.

Es gibt ein kubectl Plugin, mit dem Sie sehen können, welches Ihrer Kubernetes Workloads mounten die Docker Lautstärke des Sockels. Weitere Informationen finden Sie unter Detector for Docker Socket (DDS) on GitHub. Amazon EKSAMIs, die laufen Kubernetes Versionen, die älter sind als 1.24 ich 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 testen können. containerd Weitere Informationen finden Sie unter Testen Sie die Amazon Linux 2-Migration von Docker zu containerd.

Wir werden weiterhin für bestehende veröffentlichen AMIs Kubernetes Versionen bis zum Ende ihres Support-Datums. Weitere Informationen finden Sie unter Amazon EKS Kubernetes Veröffentlichungskalender. 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 das offizielle Amazon EKS AMIs auf Version 1.24 oder höher aktualisieren möchten, stellen Sie sicher, dass Ihre Workloads darauf containerd ausgeführt werden.

Die containerd Runtime bietet eine zuverlässigere Leistung und Sicherheit. containerdist die Laufzeit, die bei Amazon standardisiert wirdEKS. Fargate und Bottlerocket benutze schon containerd nur. containerdträgt dazu bei, die Anzahl der EKS AMI Amazon-Releases zu minimieren, die zur Behebung dockershim häufiger Sicherheitslücken und Risiken (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 das mounten Docker Buchse. Beispielsweise sind Container-Images, die mit einem Container entwickelt werden, davon betroffen. Viele Überwachungstools montieren auch die Docker Buchse. 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. 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 im Docker Dokumentation.

  • Wenn Sie den Amazon ECR Credential Helper zum Abrufen von Bildern verwenden, müssen Sie zum kubelet Image Credential Provider wechseln. Weitere Informationen finden Sie unter Konfigurieren eines Kubelet-Image-Anmeldeinformationsanbieters im Kubernetes -Dokumentation.

  • Weil Amazon EKS 1.24 nicht mehr unterstützt Docker, einige Flags, die das EKSAmazon-Bootstrap-Skript zuvor unterstützt hat, werden nicht mehr unterstützt. Bevor Sie zu Amazon EKS 1.24 oder später 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 Sie das bereits getan haben Fluentd konfiguriert für Container Insights, dann müssen Sie migrieren Fluentd to Fluent Bit bevor Sie zu wechselncontainerd. Das Tool Fluentd Parser sind so konfiguriert, dass sie Protokollnachrichten nur im JSON Format analysieren. Im dockerd Gegensatz dazu enthält die containerd Container-Laufzeit Protokollnachrichten, die nicht formatiert JSON sind. Wenn Sie nicht migrieren zu Fluent Bit, einige der konfigurierten Fluentd’s Parser werden eine große Anzahl von Fehlern innerhalb des erzeugen Fluentd Behälter. Weitere Informationen zur Migration finden Sie unter Fluent Bit einrichten, um Logs an Logs DaemonSet zu CloudWatch senden.

  • Wenn Sie eine benutzerdefinierte Option verwenden AMI und ein Upgrade auf Amazon durchführen EKS1.24, müssen Sie sicherstellen, dass die IP-Weiterleitung für Ihre Worker-Knoten aktiviert ist. Diese Einstellung wurde nicht benötigt bei Docker ist aber erforderlich fürcontainerd. Es wird zur Fehlerbehebung benötigt Pod-bis-Pod, Pod-to-extern, oder Pod-zu-apiserver Netzwerkkonnektivität.

    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 für Amazon Linux 2 während der containerd Laufzeit finden Sie install-worker.sh unter GitHub.

Testen Sie die Amazon Linux 2-Migration von Docker zu containerd

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Kubernetes Version1.23, Sie können ein optionales Bootstrap-Flag verwenden, um die containerd Runtime for Amazon EKS Optimized AL2 AMIs zu aktivieren. Mit diesem Feature erhalten Sie einen klaren Pfad für die Migration zu containerd, wenn Sie auf Version 1.24 oder höher aktualisieren. Amazon EKS hat den Support für eingestellt Docker beginnend mit dem Kubernetes 1.24Versionsstart. Die containerd Laufzeit ist weit verbreitet in Kubernetes Community und ist ein Abschlussprojekt mit derCNCF. Sie können es testen, indem Sie zu einem neuen oder vorhandenen Cluster eine Knotengruppe hinzufügen.

Sie können das Boostrap-Flag aktivieren, indem Sie eine der folgenden Arten von Knotengruppen erstellen.

Selbstverwaltet

Erstellen Sie die Knotengruppe anhand der Anweisungen unter Selbstverwaltete Amazon Linux-Knoten erstellen. Geben Sie einen für Amazon EKS optimierten Wert AMI und den folgenden Text für den BootstrapArguments Parameter an.

--container-runtime containerd
Verwaltet

Wenn Sie eksctl verwenden, erstellen Sie eine Datei namens my-nodegroup.yaml mit folgendem Inhalt. Ersetzen Sie jede example value durch Ihre eigenen Werte. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Informationen zum Abrufen einer optimierten AMI ID für ami-1234567890abcdef0 finden Sie unterRufen Sie das empfohlene Amazon Linux ab AMI IDs.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
Anmerkung

Wenn Sie viele Knoten gleichzeitig starten, ist es sinnvoll, ebenfalls Werte für die Bootstrap-Argumente --apiserver-endpoint, --b64-cluster-ca und --dns-cluster-ip anzugeben, um Fehler zu vermeiden. Weitere Informationen finden Sie unter Angabe eines AMI.

Führen Sie den folgenden Befehl aus, um die Benutzergruppe zu erstellen.

eksctl create nodegroup -f my-nodegroup.yaml

Wenn Sie die verwaltete Knotengruppe lieber mit einem anderen Werkzeug erstellen möchten, müssen Sie die Knotengruppe mithilfe einer Startvorlage bereitstellen. Geben Sie in Ihrer Startvorlage eine EKSfür Amazon optimierte AMI ID an, stellen Sie dann die Knotengruppe mithilfe einer Startvorlage bereit und geben Sie die folgenden Benutzerdaten an. Diese Benutzerdaten übergeben Argumente an die bootstrap.sh-Datei. Weitere Informationen zur Bootstrap-Datei finden Sie in bootstrap.sh unter GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

📝 Bearbeiten Sie diese Seite auf GitHub