Kubernetes - Faut il trouver une alternative à Docker comme container runtime ?
Publié le : 9 janvier 2022 | Mis à jour le : 27 juin 2023
Annoncé lors de la sortie de la version 1.20 de Kubernetes, la fin du
support de DockerShim comme Runtime Container sera effective pour la
version 1.24.
Qu’est ce que DockerShim ?
Que fait le Container Runtime au sein de Kubernetes ? Il est chargé de récupérer les images (pull) et de gérer l’exécution des conteneurs. Pour rappel, c’est Kubelet, le service qui tourne sur les workers nodes, qui communique avec le Container Runtime pour réaliser ces opérations.
Mais pourquoi cette fin de support ? En fait Docker ne respectait pas
complètement la norme CRI et donc a eu jusqu’à la version 18.09 besoin d’une
interface. Cette interface s’appelle dockershim.
Pourquoi jusqu’à la version 18.09 ? Tout simplement parce que Docker a choisi
d’utiliser containerd qui lui respecte la norme.
Donc pas besoin d’avoir peur de cette fin de support, sauf si vous utilisez une
version antérieure à la 18.09 de Docker.
Remplacer Containerd par Cri-o
Utilisons la CKASandBox pour voir comment migrer de Docker à Cri-O. On doit se connecter au noeud worker1.
ssh worker1
ps -ef |grep dockerd
root 6497 1 0 17:27 ? 00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
C’est bien containerd qui tourne comme CRI. Lancons la migration. Depuis un autre terminal se connecter au controller :
ssh controller
kubectl cordon worker1
kubectl drain worker1 --ignore-daemonsets
Retour sur la session avec le noeud worker1 :
systemctl stop kubelet
apt purge docker-ce docker-ce-cli
apt-get autoremove --purge
export OS=xUbuntu_20.04
export VERSION=1.20
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
sudo apt update
sudo apt install cri-o cri-o-runc
sudo systemctl daemon-reload
sudo systemctl enable crio --now
Il faut modifier la conf de cri-o (tjs sur worker1) :
vi /etc/crio/crio.conf.d/02-cgroup-manager.conf
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
sudo systemctl daemon-reload
sudo systemctl enable crio --now
crictl info
{
"status": {
"conditions": [
{
"type": "RuntimeReady",
"status": true,
"reason": "",
"message": ""
},
{
"type": "NetworkReady",
"status": true,
"reason": "",
"message": ""
}
]
}
}
crictl ps
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
Ca tourne modifions la configuration de kubelet :
cat <<EOF > /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --container-runtime-endpoint='unix:///var/run/crio/crio.sock'
EOF
Depuis le controller on controle que le node est a nouveau Ready :
kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane,master 25m v1.22.5
worker1 Ready <none> 24m v1.22.5