Kubernetes v1.24 und spätere Versionen werden ohne Dockershim ausgeliefert, nachdem es im Dezember 2020 in der Version v1.20 eingestellt wurde. Dockershim ist nicht mehr als integrierte Containerlaufzeit verfügbar. Sie müssen stattdessen eine andere unterstützte Laufzeit verwenden, z. B. containerd, CRI-O oder Docker Engine mit dem cri-dockerd-Adapter.
In diesem Artikel zeigen wir, wie Sie überprüfen können, ob Sie betroffen sind, und erläutern dann, wie Sie zu einer anderen Laufzeitumgebung migrieren können. Sie sollten diese Schritte ausführen, bevor Sie ein Upgrade auf Kubernetes v1.24 oder eine neuere Version durchführen, damit die Workloads Ihres Clusters nicht beeinträchtigt werden.
Was war Dockershim?
Dockershim wurde als notwendige Komponente entwickelt, damit Kubernetes mehr Containerlaufzeiten unterstützen kann. Zu Beginn des Projekts arbeitete Kubernetes nur mit Docker Engine. Diese Einschränkung wurde durch die Einführung des CRI-Standards aufgehoben. Jede CRI-kompatible Laufzeit kann jetzt mit Kubernetes verwendet werden, einschließlich containerd und CRI-O, einer OCI-Implementierung des Standards.
Während CRI Kubernetes neue Flexibilität brachte, stellte es ein Problem für bestehende Cluster dar. Docker fehlte die Unterstützung für den CRI-Standard, also wurde Dockershim entwickelt, damit das Kubernetes-Team die Kompatibilität oben drauflegt. Dockershim war eine direkte Integration mit Docker Engine, die immer als vorübergehende Maßnahme gedacht war.
Die Containerbewegung ist jetzt viel mehr als nur Docker, wie der ursprüngliche Kubernetes-Push auf CRI zeigt. Docker selbst hat sich in einzelne Komponenten aufgeteilt, wobei seine Laufzeit als containerd extrahiert wurde, ein Absolvent der Cloud Native Computing Foundation (CNCF).
containerd wird von Kubernetes vollständig unterstützt und eignet sich eher für die eigenständige Verwendung in Cloud-Umgebungen. Kubernetes erfordert nicht die Docker-CLI und ihre zahlreichen Funktionen, um Ihre Pods auszuführen. alles, was es braucht, ist die Fähigkeit, Container auf relativ niedrigem Niveau zu starten und auszuführen. Dockershim wurde entfernt, da es schwierig zu warten war. Seine Verwendung erzeugte fragilen Code, der eng mit der Implementierung der Docker-Engine gekoppelt war.
Überprüfen, ob Sie Dockershim verwenden
Es ist sehr unwahrscheinlich, dass kürzlich erstellte Cluster auf modernen Plattformen Dockershim verwenden. Dazu gehören Cluster, die von beliebten Cloud-Anbietern wie Amazon EKS, Azure AKS, Google GKE und DigitalOcean DOKS verwaltet werden.
Am ehesten müssen Sie Maßnahmen ergreifen, wenn Sie Ihren eigenen Cluster verwalten und zuerst vor einigen Jahren eingerichtet. Sie können überprüfen, ob Sie Dockershim als Laufzeitumgebung für einen Ihrer Knoten verwenden, indem Sie diesen Kubectl-Befehl ausführen:
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker ://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
In diesem Beispiel verwendet einer der Knoten containerd und kann unverändert gelassen werden. Der andere Knoten wird mit Docker konfiguriert und könnte von der Dockershim-Entfernung betroffen sein. Sie können dies überprüfen, indem Sie diesen Befehl auf dem Knoten ausführen:
$ tr \0 ' ' < /proc/”$(pgrep kubelet)”/cmdline | grep “–container-runtime”
Ihr Knoten verwendet Dockershim, um Container auszuführen, wenn keine Ausgabe angezeigt wird. Wenn Sie eine Ausgabe erhalten, überprüfen Sie den angezeigten Wert des Flags –container-runtime-endpoint, um festzustellen, ob Dockershim aktiv ist. Ein Laufzeitendpunkt von unix:///run/containerd/containerd.sock signalisiert, dass containerd verwendet wird, sodass keine Migration erforderlich ist.
Ändern eines Knotens’ ;s Runtime
Knoten, die Dockershim verwenden, müssen aktualisiert werden, um eine andere Laufzeit zu verwenden. Entladen Sie zuerst die Arbeitslasten des Knotens mit Kubectl, damit Ihre Pods auf andere Knoten in Ihrem Cluster umgeplant werden. Sie sollten auch den Node absperren, um zu verhindern, dass neue Pods geplant werden.
$ kubectl cordon node-1 $ kubectl drain node-1 –ignore-daemonsets
Führen Sie als nächstes die folgenden Befehle auf dem Knoten selbst aus. Beginnen Sie, indem Sie den Docker-Daemon und den Kubelet-Arbeitsprozess des Knotens stoppen:
$ systemctl stop kubelet $ systemctl disable docker.service –now
Jetzt können Sie Ihre neue Laufzeit installieren.
< h3 id="using-containerd">Benutze containerd
containerd ist im Allgemeinen die bevorzugte Lösung für aktuelle Cluster. Sie sollten in der Lage sein, zu containerd zu migrieren, wenn Sie sich nicht auf bestimmte Funktionen von Docker Engine verlassen. Wenn ja, gehen Sie zum folgenden Abschnitt und installieren Sie stattdessen cri-dockerd.
Fügen Sie das Docker-Repository zu Ihrem System hinzu, wenn Ihre Paketlisten es nicht bereits enthalten. containerd wird im Docker-Repository verteilt.
$ sudo apt-get update $ sudo apt-get install ca-certificates curl gnupg lsb-release $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg –dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg $ echo “deb [arch=$(dpkg –print-architecture) signed-by=/usr/share/keyrings/docker -archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable” | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Installieren Sie containerd:
$ sudo apt update $ sudo apt install containerd
Aktualisieren Sie nun die Kubelet-Konfigurationsdatei des Knotens, um die neue Laufzeitumgebung zu verwenden. Öffnen Sie /var/lib/kubelet/kubeadm-flags.env. Suchen Sie nach den Flags –container-runtime und –container-runtime-endpoint oder fügen Sie sie mit den folgenden Werten hinzu:
- –container-runtime=remote
- –container-runtime-endpoint=unix:///run/containerd/containerd.sock
Ändern Sie als Nächstes die Socket-Annotation, die für das Node-Objekt in der Kubernetes-Steuerungsebene gespeichert wurde:
$ kubectl edit node node-1
Suchen Sie in der sich öffnenden Datei die Annotation kubeadm.alpha.kubernetes.io/cri-socket und ändern Sie sie in unix:///run/containerd/containerd.sock . Speichern und schließen Sie die Datei, um das Objekt des Knotens zu aktualisieren.
Starten Sie Kubelet jetzt neu:
$ systemctl start kubelet
Geben Sie dem Knoten einen Moment Zeit, um zu starten und sich mit der Kubernetes-Steuerungsebene zu verbinden. Sie sollten in der Lage sein, den Befehl get nodes zu wiederholen und zu sehen, dass containerd jetzt verwendet wird.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 containerd://1.4.13 node-2 Ready v1.22.8 containerd://1.4.13
Entfernen Sie schließlich die Schnur, die Sie um den Node gelegt haben, damit er anfangen kann, Pods zu empfangen:
$ kubectl uncordon node-1
Cri-dockerd verwenden
cri-dockerd ist eine von Docker und Mirantis gemeinsam entwickelte Laufzeitumgebung. Es ist praktisch eine eigenständige Version von Dockershim, die unabhängig gewartet wird. Sie können vertraute Funktionen weiterhin verwenden, ohne das Kubernetes-Projekt mit den Wartungsanforderungen von Dockershim zu belasten.
Stellen Sie sicher, dass Docker Engine bereits installiert ist. Installieren Sie dann cri-dockerd, indem Sie die neueste Binärdatei von den GitHub-Versionen herunterladen:
$ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.0/cri-dockerd-v0.2.0-linux-amd64.tar.gz $ tar xvf cri-dockerd-v0.2.0- linux-amd64.tar.gz $ mv cri-dockerd /usr/local/bin/
Nächstes Herunterladen, Installieren und Aktivieren der systemd-Dienstkonfigurationen von cri-dockerd:
wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.service wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd /cri-docker.socket sudo mv cri-docker.socket cri-docker.service /etc/systemd/system/sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service sudo systemctl daemon-reload sudo systemctl enable cri-docker.service sudo systemctl enable –now cri-docker.socket
Jetzt können Sie Ihren Knoten ändern& #8217;s Kubelet-Konfiguration zur Verwendung von cri-dockerd. Dies ähnelt der Konfiguration eines Knotens zur Verwendung von containerd.
Öffnen Sie /var/lib/kubelet/kubeadm-flags.env. Suchen Sie nach den Flags –container-runtime und –container-runtime-endpoint oder fügen Sie sie mit den folgenden Werten hinzu:
- –container-runtime=remote
- — container-runtime-endpoint=unix:///var/run/cri-dockerd.sock
Ändern Sie als Nächstes die Socket-Annotation des Node-Objekts:
$ kubectl edit node node-1
Suchen Sie in der sich öffnenden Datei die Annotation kubeadm.alpha.kubernetes.io/cri-socket und ändern Sie sie in unix:///var/run/cri-dockerd.sock. Speichern und schließen Sie die Datei, um das Objekt des Knotens zu aktualisieren.
Starten Sie Kubelet jetzt neu:
$ systemctl start kubelet
Warten Sie einen Moment und verwenden Sie dann Kubectl, um zu überprüfen, ob der Knoten aktiv ist. Es zeigt weiterhin die Docker-Laufzeit an, basiert aber jetzt auf dem eigenständigen cri-dockerd und nicht auf Dockershim, das in Kubernetes integriert ist.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER -RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
Sie können jetzt die Kette entfernen, die Sie um den Node gelegt haben. Es nimmt wieder Pod-Planungsanfragen an.
$ kubectl uncordon node-1
Schlussfolgerung
Kubernetes v1.24 hat die Dockershim-Komponente entfernt, die zuvor CRI-Kompatibilität für Docker Engine integriert hatte. Obwohl die neuesten Cluster nicht betroffen sind, sollten Sie vor dem Upgrade auf die neue Version prüfen, ob Sie Dockershim verwenden.
Die Laufzeit, zu der gewechselt werden muss, hängt davon ab, wie Sie Ihren Cluster derzeit verwenden. containerd ist normalerweise eine gute Wahl, wenn Sie keine Docker-Funktionen verwenden. Sie können cri-dockerd verwenden, um die Dockershim-ähnliche Integration wiederherzustellen, wenn Sie die Kompatibilität mit vorhandenen Tools aufrechterhalten müssen, die auf Docker Engine angewiesen sind. Dies hilft auch, wenn Sie den Docker-Daemon-Socket (/var/run/docker.sock) in Ihre Container einhängen, um Docker-in-Docker-Workflows zu unterstützen.
Die Entfernung von Dockershim funktioniert nicht. #8217;hat keinen Einfluss darauf, wie Sie Container-Images erstellen und verwenden. Kubernetes kann weiterhin Images ausführen, die mit Docker Build erstellt wurden, und sie sind mit allen unterstützten Laufzeiten kompatibel. CRI-Laufzeiten funktionieren mit jedem Bild im OCI-Format, wie es von Docker und anderen Bilderstellern ausgegeben wird.
WEITER LESEN
- › So importieren Sie Daten mit Google Sheets-Funktionen
- › Framework hat gerade das coolste Chromebook aller Zeiten auf den Markt gebracht
- › Holen Sie sich einen günstigen Surface Laptop Go 2 für noch weniger und noch mehr Angebote
- › Microsoft bringt am 12. Oktober neue Surface PCs auf den Markt
- › Die besten iPhone 14 Pro-Hüllen des Jahres 2022
- › Wie man Arrays in Excel kombiniert, umformt und in der Größe ändert