Tester Kubernetes sans Docker avec minikube

À l’occasion de la release 1.20 de Kubernetes, Docker a été déprécié en tant que container runtime. J’ai donc voulu voir si l’utilisation de minikube (distribution Kubernetes pour faire des tests en local) était impactée ou non.

On peut utiliser minikube de plusieurs manières différentes : 

• minikube avec un driver hyperviseur (virtualbox, hyperkit, etc.)
• minikube avec un driver Docker
• minikube sans driver (driver=none)

Minikube en mode hyperviseur ou Docker

Ces deux manières permettent directement de pouvoir tester Kubernetes avec containerd comme container-runtime sans aucun changement à part la ligne de commande pour initialiser votre cluster : il faut rajouter le switch “–container-runtime=containerd” : 

minikube start --driver=virtualbox --container-runtime=containerd
😄  minikube v1.16.0 on Darwin 11.1
✨  Using the virtualbox driver based on user configuration
👍  Starting control plane node minikube in cluster minikube
🔥  Creating virtualbox VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...
📦  Preparing Kubernetes v1.20.0 on containerd 1.4.3 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Et pour vérifier que containerd est bien utilisé : 

kubectl describe node minikube
(...)
System Info:
  Machine ID:                 7c96c7ea9bc9406e93aa1bfd1b3c5abf
  System UUID:                b9979f80-f17f-c242-a4d9-1b82a8981f41
  Boot ID:                    d029f9a7-6eae-4661-92e0-bc68c5392caa
  Kernel Version:             4.19.157
  OS Image:                   Buildroot 2020.02.8
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.4.3
  Kubelet Version:            v1.20.0
  Kube-Proxy Version:         v1.20.0
(...)

Pour le driver Docker c’est exactement la même chose que précédemment !

Minikube sans driver

Dans ce mode d’utilisation, minikube va s’appuyer directement sur l’host pour initialiser le cluster. Il faut donc être sur un Linux. Pour faire fonctionner minikube avec du containerd sans driver, il y a un peu plus de choses à faire.

Premièrement, il y a actuellement un bug avec minikube: minikube va chercher l’executable docker même si vous ne voulez pas vous en servir ! On peut donc soit installer Docker… soit mettre n’importe quel binaire à la place : 

sudo cp /bin/true /usr/local/bin/docker

Ensuite il va falloir installer containerd : dans la documentation de Kubernetes se trouve une procédure d’installation de containerd.

Si vous initiez votre cluster tout de suite il n’y aura pas d’erreur, mais vous aurez l’erreur suivante lors de la création de votre premier pod : 

Warning  FailedCreatePodSandBox  4m47s                kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "5a52413ae1aa874b3da63f84e02d36ba296209188d0db074eb0b0f9ff94502cc": failed to find plugin "loopback" in path [/opt/cni/bin]

Il faut aussi installer un plugin CNI pour que votre containerd puisse créer une interface réseau pour votre pod. Cela peut se faire facilement avec les lignes suivantes : 

sudo mkdir -p /opt/cni/bin
wget https://github.com/containernetworking/plugins/releases/download/v0.9.0/cni-plugins-linux-amd64-v0.9.0.tgz
sudo tar -xvf cni-plugins-linux-amd64-v0.9.0.tgz -C /opt/cni/bin/

Maintenant, tout est prêt pour votre cluster : 

minikube start --driver=none --container-runtime=containerd
😄  minikube v1.16.0 on Debian 10.7 (vbox/amd64)
✨  Using the none driver based on user configuration
❗  Using the 'containerd' runtime with the 'none' driver is an untested configuration!

👍  Starting control plane node minikube in cluster minikube
🤹  Running on localhost (CPUs=2, Memory=1995MB, Disk=126099MB) ...
ℹ️  OS release is Debian GNU/Linux 10 (buster)
📦  Preparing Kubernetes v1.20.0 on containerd 1.4.3 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔗  Configuring bridge CNI (Container Networking Interface) ...
🤹  Configuring local host environment ...

❗  The 'none' driver is designed for experts who need to integrate with an existing VM
💡  Most users should use the newer 'docker' driver instead, which does not require root!
📘  For more information, see: https://minikube.sigs.k8s.io/docs/reference/drivers/none/

🔎  Verifying Kubernetes components...
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Notez par contre le warning ❗ Using the 'containerd' runtime with the 'none' driver is an untested configuration! !

Et pour vérifier que containerd est bien utilisé : 

kubectl describe node minikube
(...)
System Info:
  Machine ID:                 9b147abee4444b26a3afa57cc7aa99be
  System UUID:                5348c864-7de1-44fa-9157-c335105a5ce1
  Boot ID:                    9c7aefc8-a966-4e20-a066-262f03bf3fd0
  Kernel Version:             4.19.0-13-amd64
  OS Image:                   Debian GNU/Linux 10 (buster)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.4.3
  Kubelet Version:            v1.20.0
  Kube-Proxy Version:         v1.20.0
(...)

Conclusion

C’est bien possible de tester Kubernetes sans Docker directement avec minikube de manière (plus ou moins) simple. Une fois le setup passé… En tant qu’utilisateur du cluster, cela ne change rien ! Le changement va surtout s’opérer côté administration du cluster car il faut maintenant s’habituer à l’outillage sans Docker (crictl par exemple)

Avez-vous déjà testé Kubernetes sans Docker ? Avez-vous eu d’autres surprises ? 

Nos formations Kubernetes