Kubernetes v1.24 och senare utgåvor skickas utan Dockershim efter dess utfasning i december 2020’s version 1.20. Dockershim’s inte längre tillgänglig som en inbyggd containerkörning. Du måste använda en annan körtid som stöds istället, som containerd, CRI-O eller Docker Engine med cri-dockerd-adaptern.
I den här artikeln visar vi hur du kontrollerar om du påverkas, och förklarar sedan hur du kan migrera till en annan körning. Du bör vidta dessa steg innan du uppgraderar till Kubernetes v1.24 eller en senare version så att klustrets arbetsbelastningar inte påverkas.
Vad var Dockershim?
Dockershim utvecklades som en nödvändig komponent så att Kubernetes kunde stödja fler containerkörningstider. I början av projektet arbetade Kubernetes endast med Docker Engine. Denna begränsning togs bort genom införandet av CRI-standarden. Vilken CRI-kompatibel körtid som helst kunde nu användas med Kubernetes, inklusive containerd och CRI-O, en OCI-implementering av standarden.
Medan CRI gav Kubernetes ny flexibilitet, presenterade det ett problem för befintliga kluster. Docker saknade stöd för CRI-standarden så Dockershim byggdes för att låta Kubernetes laglagskompatibilitet överst. Dockershim var en direkt integration med Docker Engine som alltid var tänkt att vara en tillfällig åtgärd.
Containerrörelsen är nu mycket mer än Docker, vilket den ursprungliga Kubernetes push till CRI visar. Docker själv har delat upp sig i enskilda komponenter med sin körtid extraherad som containerd, en examen från Cloud Native Computing Foundation (CNCF).
containerd stöds fullt ut av Kubernetes och är mer lämpad för fristående användning i molnmiljöer. Kubernetes kräver inte Docker CLI och dess mängd funktioner för att köra dina Pods; allt den behöver är förmågan att starta och köra containrar på en relativt låg nivå. Dockershim har tagits bort eftersom det var svårt att underhålla. Dess användning skapade bräcklig kod som var tätt kopplad till Docker Engine’s implementering.
Kontrollera om du använder Dockershim
Nyligen skapade kluster på moderna plattformar är högst osannolikt att använda Dockershim. Detta inkluderar kluster som hanteras av populära molnleverantörer som Amazon EKS, Azure AKS, Google GKE och DigitalOcean DOKS.
Det är mest sannolikt att du behöver vidta åtgärder om du underhåller ditt eget kluster och första satte upp det för flera år sedan. Du kan kontrollera om du använder Dockershim som körtid för någon av dina noder genom att köra detta Kubectl-kommando:
$ kubectl get nodes -o wide NAMN STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker ://19.3.1 nod-2 Ready v1.22.8 containerd://1.4.13
I det här exemplet använder en av noderna containerd och kan lämnas som den är. Den andra noden är konfigurerad med Docker och kan påverkas av Dockershim-borttagningen. Du kan kontrollera genom att köra detta kommando på noden:
$ tr \0 ' ' < /proc/”$(pgrep kubelet)”/cmdline | grep “–container-runtime”
Din nod använder Dockershim för att köra behållare om ingen utdata visas. Om du får lite utdata, inspektera det visade flaggvärdet –container-runtime-endpoint för att avgöra om Dockershim är aktivt. En runtime endpoint av unix:///run/containerd/containerd.sock signals containerd används, så ingen migrering är nödvändig.
Ändra en nod’ ;s Runtime
Noder som använder Dockershim måste uppdateras för att använda en annan körtid. Töm först nodens arbetsbelastningar med Kubectl, så att dina Pods schemaläggs om till andra noder i ditt kluster. Du bör spärra av noden också för att stoppa eventuella nya Pods som schemaläggs.
$ kubectl cordon node-1 $ kubectl drain node-1 –ignore-daemonsets
Kör sedan följande kommandon på själva noden. Börja med att stoppa Docker-demonen och Nodens Kubelet-arbetarprocess:
$ systemctl stop kubelet $ systemctl disable docker.service –now
Nu kan du installera din nya runtime.
< h3 id="using-containerd">Använda containerd
containerd är i allmänhet den föredragna lösningen för nuvarande kluster. Du bör kunna migrera till containerd om du inte förlitar dig på specifika funktioner i Docker Engine. Om du är det, gå till följande avsnitt och installera cri-dockerd istället.
Lägg till Dockers repository till ditt system om dina paketlistor inte redan innehåller det. containerd distribueras i Dockers repository.
$ sudo apt-get update $ sudo apt-get install ca-certifikat 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) stabil” | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Installera containerd:
$ sudo apt update $ sudo apt install containerd
Uppdatera nu nodens Kubelet-konfigurationsfil för att använda den nya körtiden. Öppna /var/lib/kubelet/kubeadm-flags.env. Leta efter eller lägg till flaggorna –container-runtime och –container-runtime-endpoint med följande värden:
- –container-runtime=remote
- –container-runtime-endpoint=unix:///run/containerd/containerd.sock
Ändra sedan socketanteckningen som sparats mot Node-objektet i Kubernetes kontrollplan:
$ kubectl edit node node-1
I filen som öppnas, leta reda på kubeadm.alpha.kubernetes.io/cri-socket-anteckningen och ändra den till unix:///run/containerd/containerd.sock . Spara och stäng filen för att uppdatera nodens objekt.
Starta nu om Kubelet:
$ systemctl start kubelet
Låt noden starta en stund och ansluta till Kubernetes kontrollplan. Du bör kunna upprepa kommandot get nodes och se att containerd nu används.
$ kubectl get nodes -o wide NAMN STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 containerd://1.4.13 node-2 Ready v1.22.8 containerd://1.4.13
Ta slutligen bort spärren som du placerade runt noden så att den kan börja ta emot Pods:
$ kubectl uncordon node-1
Använda cri-dockerd
cri-dockerd är en runtime som utvecklats gemensamt av Docker och Mirantis. Det är faktiskt en fristående version av Dockershim som underhålls oberoende. Det låter dig fortsätta använda välbekant funktionalitet utan att belasta Kubernetes-projektet med Dockershim’s underhållskrav.
Se till att du redan har installerat Docker Engine. Installera sedan cri-dockerd genom att ladda ner den senaste binära versionen från GitHub:
$ 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ästa nedladdning, installera och aktivera cri-dockerds systemtjänstkonfigurationer:
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
Nu kan du modifiera din nod& #8217;s Kubelet-konfiguration för att använda cri-dockerd. Detta liknar att konfigurera en nod för att använda containerd.
Öppna /var/lib/kubelet/kubeadm-flags.env. Leta efter eller lägg till flaggorna –container-runtime och –container-runtime-endpoint med följande värden:
- –container-runtime=remote
- — container-runtime-endpoint=unix:///var/run/cri-dockerd.sock
Ändra sedan nodobjektets socketanteckning:
$ kubectl edit nod node-1
I filen som öppnas, hitta kubeadm.alpha.kubernetes.io/cri-socket-anteckningen och ändra den till unix:///var/run/cri-dockerd.sock. Spara och stäng filen för att uppdatera nodens objekt.
Starta nu om Kubelet:
$ systemctl start kubelet
Vänta ett par ögonblick och använd sedan Kubectl för att kontrollera att noden är uppe. Den kommer fortfarande att visa Docker-körtiden men den är nu baserad på den fristående cri-dockerden, istället för Dockershim som är integrerad med Kubernetes.
$ kubectl få noder -o wide NAMN STATUS VERSION CONTAINER -RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
Du kan nu ta bort spärren du placerade runt noden. Den kommer att börja acceptera Pod-schemaläggningsförfrågningar igen.
$ kubectl uncordon node-1
Slutsats
Kubernetes v1.24 tog bort Dockershim-komponenten som tidigare integrerade CRI-kompatibilitet för Docker Engine. Även om de senaste klustren inte kommer att påverkas, bör du kontrollera om du använder Dockershim innan du uppgraderar till den nya versionen.
Körtiden att byta till beror på hur du för närvarande använder ditt kluster. containerd är vanligtvis ett bra val om du inte använder Docker-funktioner. Du kan använda cri-dockerd för att få tillbaka Dockershim-liknande integration om du behöver bibehålla kompatibilitet med befintliga verktyg som är beroende av Docker Engine. Detta hjälper också om du monterar Docker-demonsocket (/var/run/docker.sock) i dina behållare för att driva Docker-in-Docker-arbetsflöden.
Dockershims borttagning görs inte& #8217;inte påverkar hur du bygger och använder behållarbilder. Kubernetes kan fortfarande köra bilder skapade med docker build och de är kompatibla med alla körtider som stöds. CRI-körtider fungerar med alla bilder i OCI-format, som utmatas av Docker och andra bildbyggare.
LÄS NÄSTA
- › Så här importerar du data med Google Sheets-funktioner
- › Skaffa en Budget Surface Laptop Go 2 för ännu mindre, plus fler erbjudanden
- › Hur man kombinerar, omformar och ändrar storlek på matriser i Excel
- › Framework har precis lanserat den coolaste Chromebook någonsin
- › Microsoft kommer att lansera nya Surface-datorer den 12 oktober
- › De bästa iPhone 14 Pro-skalen från 2022