Si të migroni larg nga Dockershim në Kubernetes v1.24 dhe më vonë

Kubernetes v1.24 dhe më vonë lëshohet pa Dockershim pas zhvlerësimit të tij në versionin 1.20 të dhjetorit 2020. Dockershim nuk disponohet më si një kohëzgjatje e integruar e kontejnerit. Në vend të kësaj, duhet të përdorni një kohë ekzekutimi të mbështetur të ndryshme, si p.sh. Containerd, CRI-O ose Docker Engine me përshtatësin cri-dockerd.

Në këtë artikull, ne do të tregojmë se si të kontrolloni nëse jeni prekur, më pas do të shpjegojmë se si mund të migroni në një kohë tjetër ekzekutimi. Duhet t'i ndërmerrni këto hapa para që të përmirësoni në Kubernetes v1.24 ose një version të mëvonshëm në mënyrë që ngarkesat e punës së grupit tuaj të mos ndikohen.

Çfarë ishte Dockershim?

Dockershim u zhvillua si një komponent i domosdoshëm në mënyrë që Kubernetes të mund të mbështeste më shumë kohë pune të kontejnerëve. Në fillim të projektit, Kubernetes punoi vetëm me Docker Engine. Ky kufizim u hoq me futjen e standardit CRI. Çdo ekzekutim i pajtueshëm me CRI tani mund të përdoret me Kubernetes, duke përfshirë kontejnerin dhe CRI-O, një zbatim OCI i standardit.

Ndërsa CRI solli fleksibilitet të ri në Kubernetes, ai paraqiti një problem për grupimet ekzistuese. Docker-it i mungonte mbështetja për standardin CRI, kështu që Dockershim u ndërtua për të lejuar pajtueshmërinë e shtresave të ekipit Kubernetes në krye. Dockershim ishte një integrim i drejtpërdrejtë me Docker Engine që synohej gjithmonë të ishte një masë e përkohshme.

Lëvizja e kontejnerëve tani është shumë më tepër se Docker, siç demonstron shtytja origjinale e Kubernetes në CRI. Vetë Docker është ndarë në komponentë individualë me kohën e tij të ekzekutimit të nxjerrë si kontejnerë, i diplomuar në Cloud Native Computing Foundation (CNCF).

containerd mbështetet plotësisht nga Kubernetes dhe më i përshtatshëm për përdorim të pavarur në mjediset cloud. Kubernetes nuk kërkon Docker CLI dhe grupin e veçorive të tij për të ekzekutuar Pods-et tuaja; gjithçka që i nevojitet është aftësia për të nisur dhe drejtuar kontejnerët në një nivel relativisht të ulët. Dockershim është hequr sepse ishte e vështirë për t'u mirëmbajtur. Përdorimi i tij krijoi kod të brishtë që ishte i lidhur ngushtë me zbatimin e Docker Engine.

Kontrolloni nëse po përdorni Dockershim

Grupet e krijuara së fundmi në platformat moderne nuk kanë gjasa të përdorin Dockershim. Kjo përfshin grupimet e menaxhuara nga ofruesit e njohur të reve kompjuterike si Amazon EKS, Azure AKS, Google GKE dhe DigitalOcean DOKS.

Ka shumë të ngjarë që ju të duhet të ndërmerrni veprime nëse mbani grupin tuaj dhe e konfiguroni fillimisht disa vite më parë. Ju mund të kontrolloni nëse po përdorni Dockershim si kohën e ekzekutimit për ndonjë nga Nyjet tuaja duke ekzekutuar këtë komandë Kubectl:

$ 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

Në këtë shembull, një nga nyjet po përdor kontejner dhe mund të lihet ashtu siç është. Nyja tjetër është konfiguruar duke përdorur Docker dhe mund të ndikohet nga heqja e Dockershim. Mund ta kontrolloni duke ekzekutuar këtë komandë në Nyjen:

$ tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline | grep "\-\-container\-runtime"

Nyja juaj po përdor Dockershim për të drejtuar kontejnerët nëse nuk shfaqet asnjë dalje. Nëse merrni ndonjë rezultat, inspektoni vlerën e flamurit të shfaqur --container-runtime-endpoint për të përcaktuar nëse Dockershim është aktiv. Përdoret një pikë fundore e kohës së ekzekutimit të kontejnerit të sinjaleve unix:///run/containerd/containerd.sock, kështu që nuk është i nevojshëm migrimi.

Ndryshimi i kohës së funksionimit të një nyje

Nyjet që përdorin Dockershim duhet të përditësohen për të përdorur një kohë të ndryshme ekzekutimi. Zbrazni fillimisht ngarkesat e punës të Nyjes duke përdorur Kubectl, në mënyrë që Pods tuaja të riplanifikohen në Nyje të tjera në grupin tuaj. Ju duhet të rrethoni edhe Nyjen për të ndaluar planifikimin e çdo Pods të ri.

$ kubectl cordon node-1
$ kubectl drain node-1 --ignore-daemonsets

Më pas ekzekutoni komandat e mëposhtme në vetë Nyjen. Filloni duke ndaluar demonin Docker dhe procesin e punonjësit të Kubelet të Node:

$ systemctl stop kubelet
$ systemctl disable docker.service --now

Tani mund të instaloni kohën tuaj të re të funksionimit.

Përdorimi i kontejnerit

kontejneri është përgjithësisht zgjidhja e preferuar për grupimet aktuale. Ju duhet të jeni në gjendje të migroni në kontejnerë nëse nuk po mbështeteni në veçori specifike të Docker Engine. Nëse jeni, shkoni te seksioni i mëposhtëm dhe instaloni cri-dockerd në vend.

Shtoni depon e Docker në sistemin tuaj nëse listat e paketave tuaja nuk e përfshijnë tashmë atë. kontejneri shpërndahet në depon e Docker.

$ 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

Instaloni kontejnerin:

$ sudo apt update
$ sudo apt install containerd

Tani përditësoni skedarin e konfigurimit Kubelet të Node për të përdorur kohën e re të ekzekutimit. Hapni /var/lib/kubelet/kubeadm-flags.env. Kërkoni ose shtoni flamujt --container-runtime dhe --container-runtime-endpoint me vlerat e mëposhtme:

• --container-runtime=remote
• --container-runtime-endpoint=unix:///run/containerd/containerd.sock

Më pas ndryshoni shënimin e folesë të ruajtur ndaj objektit Node në rrafshin e kontrollit Kubernetes:

$ kubectl edit node node-1

Në skedarin që hapet, gjeni shënimin kubeadm.alpha.kubernetes.io/cri-socket dhe ndryshojeni në unix:///run/containerd/containerd.sock . Ruani dhe mbyllni skedarin për të përditësuar objektin e Nyjes.

Tani rinisni Kubelet:

$ systemctl start kubelet

Lejo që Nyja të fillojë disa momente dhe të lidhet me planin e kontrollit Kubernetes. Ju duhet të jeni në gjendje të përsërisni komandën merr nyjet dhe të shihni që kontejneri tani po përdoret.

$ 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

Në fund hiqni kordonin që keni vendosur rreth Nyjes në mënyrë që ajo të fillojë të marrë Pods:

$ kubectl uncordon node-1

Duke përdorur cri-dockerd

cri-dockerd është një kohë ekzekutimi e zhvilluar bashkërisht nga Docker dhe Mirantis. Është efektivisht një version i pavarur i Dockershim që mirëmbahet në mënyrë të pavarur. Kjo ju lejon të vazhdoni të përdorni funksionalitetin e njohur pa e ngarkuar projektin Kubernetes me kërkesat e mirëmbajtjes së Dockershim.

Sigurohuni që e keni instaluar tashmë Docker Engine. Pastaj instaloni cri-dockerd duke shkarkuar binarin më të fundit nga lëshimet e 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/

Shkarkoni, instaloni dhe aktivizoni më pas konfigurimet e shërbimit systemd të 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

Tani mund të modifikoni konfigurimin Kubelet të Node tuaj për të përdorur cri-dockerd. Kjo është e ngjashme me konfigurimin e një Node për të përdorur kontejnerin.

Hapni /var/lib/kubelet/kubeadm-flags.env. Kërkoni ose shtoni flamujt --container-runtime dhe --container-runtime-endpoint me vlerat e mëposhtme:

• --container-runtime=remote
• --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock

Më pas ndryshoni shënimin e folesë së objektit Node:

$ kubectl edit node node-1

Në skedarin që hapet, gjeni shënimin kubeadm.alpha.kubernetes.io/cri-socket dhe ndryshojeni në unix:///var/run/cri-dockerd.sock. Ruani dhe mbyllni skedarin për të përditësuar objektin e Nyjes.

Tani rinisni Kubelet:

$ systemctl start kubelet

Prisni disa çaste dhe më pas përdorni Kubectl për të kontrolluar se Nyja është ngritur. Do të tregojë ende kohën e ekzekutimit të Docker, por tani bazohet në cri-dockerd-in e pavarur, në vend të Dockershim që është i integruar me Kubernetes.

$ 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

Tani mund të hiqni kordonin që keni vendosur rreth Nyjes. Do të fillojë të pranojë përsëri kërkesat e planifikimit të Pod.

$ kubectl uncordon node-1

konkluzioni

Kubernetes v1.24 hoqi komponentin Dockershim që më parë kishte integruar përputhshmërinë CRI për Docker Engine. Ndërsa grupimet më të fundit nuk do të ndikohen, duhet të kontrolloni nëse po përdorni Dockershim përpara se të përmirësoni në versionin e ri.

Koha e ekzekutimit në të cilën duhet të kaloni varet nga mënyra se si e përdorni aktualisht grupin tuaj. kontejneri është zakonisht një zgjedhje e mirë nëse nuk po përdorni veçoritë e Docker. Ju mund të përdorni cri-dockerd për të rikthyer integrimin e ngjashëm me Dockershim nëse keni nevojë të ruani përputhshmërinë me veglat ekzistuese që varen nga Docker Engine. Kjo ndihmon gjithashtu nëse po montoni folenë Daemon Docker (/var/run/docker.sock) në kontejnerët tuaj për të fuqizuar rrjedhat e punës Docker-in-Docker.

Heqja e Dockershim nuk ndikon në mënyrën se si ndërtoni dhe përdorni imazhet e kontejnerëve. Kubernetes mund të ekzekutojë ende imazhe të krijuara me docker build dhe ato janë të pajtueshme me të gjitha kohëzgjatjet e mbështetura. Kohët e ekzekutimit të CRI funksionojnë me çdo imazh të formatit OCI, si rezultat i Docker dhe ndërtuesve të tjerë të imazheve.