La prochaine version 1.24 de Kubernetes, dont la sortie est prévue pour le 3 mai, marque un changement substantiel pour le populaire système d’orchestration de conteneurs open source, car la prise en charge intégrée de dockershim sera enfin éliminée.
Docker a été le premier runtime de conteneur utilisé par Kubernetes. Alors que le projet Kubernetes évoluait vers sa propre Open Container Initiative (OCI), il fallait un palliatif pour rendre possible la portabilité avec différents autres runtimes de conteneurs. Ce substitut était dockershim.
Essentiellement, dockershim était initialement conçu comme une option de courte durée pour permettre au moteur d’exécution populaire du conteneur Docker de convertir les contacts OCI en appels Docker dans la propre interface utilisateur d’exécution du conteneur (CRI) de Kubernetes. ). Peu à peu, dockershim a fini par être fortement ancré dans les déploiements de Kubernetes, mais a ralenti les déploiements et placé un fardeau sur les mainteneurs. Il fallait que ça parte.
Comment se préparer à l’abandon de dockershim
La version v1.24 de Kubernetes, désormais prévue pour le 3 mai, nécessitera des utilisateurs qui souhaitent utiliser la dernière variante de le logiciel pour passer de dockershim à un autre environnement d’exécution compatible avec celui de Kubernetes, ou utiliser le remplacement externe de dockershim établi par Mirantis, connu sous le nom de cri-dockerd.
Alors que les nœuds Kubernetes n’utiliseront plus par défaut l’environnement d’exécution Docker , de nombreux concepteurs et administrateurs seront déjà passés à d’autres runtimes conformes au CRI, tels que containerd – dont Docker lui-même a fait don à la CNCF en 2017 – et le CRI-O natif. Cela implique généralement de s’assurer que le représentant de kubelet qui opère sur chaque nœud d’un cluster est configuré pour appeler les sockets containerd ou CRI-O.
De nombreux fournisseurs de Kubernetes gérés ont déjà procédé, tels que Red Hat OpenShift, qui a adopté CRI-O en 2019. Elastic Kubernetes Service (EKS) d’Amazon, Azure Kubernetes Service (AKS) de Microsoft et Kubernetes Engine (GKE) de Google sont actuellement par défaut conteneurd. Microsoft a également adopté containerd pour les piscines de nœuds Azure Kubernetes Linux produites avec la variante 1.19 ou ultérieure de Kubernetes.
Passez à un environnement d’exécution ou un buste conforme au CRI
Les concepteurs qui ne remplacent pas dockershim par un Menace d’exécution conforme au CRI brisant leurs clusters et retombant sur des points de sécurité, tout en passant à côté de toutes nouvelles fonctions.
« À ce stade, notre entreprise pense que la valeur que vous (et Kubernetes) tirez de l’élimination de dockershim compense l’effort de migration que vous aurez », a écrit le groupe de publication de Kubernetes dans un article de blog de janvier.
Les concepteurs peuvent toujours utiliser Docker dans votre région pour établir ou vérifier leurs conteneurs, quel que soit le runtime de conteneur qu’ils utilisent pour les clusters Kubernetes. Les images produites par Docker continueront de fonctionner dans des clusters avec tous les environnements d’exécution conformes à l’IRC, mais ne continueront pas à être prises en charge.
Toute l’actualité en temps réel, est sur L’Entrepreneur
