Aller au contenu principal

Kubernetes plus compatible avec Docker ?

· 3 minutes de lecture
Stéphane ROBERT
Consultant DevOps

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 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