L’histoire des conteneurs modernes est longue et compliquée, revenant à l’époque du mainframe et après cela à travers des innovations telles que Solaris Zones jusqu’à l’adoption par Linux des cgroups comme structure de ses fonctionnalités de virtualisation au niveau du système d’exploitation. Ces conteneurs Linux (LXC) étaient un élément clé de la première plate-forme Docker, offrant un espace utilisateur isolé pour héberger et exécuter des conteneurs Docker.
Alors que les conteneurs continuaient à se développer, Docker a développé son propre environnement d’exécution, qui a été adopté par de nombreuses plateformes de microservices open source telles que Kubernetes. Cela a en fait fait de Docker le moyen le plus courant de développer, regrouper et publier des conteneurs. Néanmoins, cela a également incité les premières versions de Kubernetes à prendre en charge plusieurs interfaces d’exécution de conteneurs, ce qui vous permet de déployer des conteneurs à l’aide de différents environnements d’exécution dans exactement la même application.
Transfert de Kubernetes vers l’utilisation d’OCI et de Dockershim
Avec le temps, Docker et Kubernetes ont évolué. Le format d’image de conteneur de Docker a été adopté comme base pour la définition d’environnement d’exécution de l’Open Container Initiative (OCI) aux côtés d’un CRI (interface d’exécution de conteneur) Kubernetes de base exécuté dans l’environnement d’exécution de conteneur standard OCI runc. Cela a entraîné le développement des exigences de conteneur ouvert, qui fournissent des outils pour gérer le processus de vie complet d’un conteneur à peu près de la même manière que Docker, mais avec une combinaison profonde dans la communauté Kubernetes.
Le passage de Kubernetes à l’utilisation OCI pour gérer les conteneurs de pod utilisant le CRI a nécessité l’exécution d’un shim qui a transformé les contacts OCI en appels Docker, ajoutant une couche supplémentaire à la gestion des conteneurs de Kubernetes dont d’autres conteneurs totalement conformes à OCI n’ont pas besoin. La gestion de tous les conteneurs de Kubelets passant désormais par le CRI, le groupe Kubernetes a décidé que ce Dockershim ne serait qu’un substitut, permettant aux configurations de Kubernetes de passer aux plates-formes de conteneurs prêtes pour le CRI, d’autant plus qu’il n’y avait pas d’hôte de conteneur prêt pour le CRI. pour les conteneurs Windows – une exigence essentielle pour Azure.
Un problème supplémentaire était que l’assistance Dockershim codée en dur était utilisée par d’autres parties de Kubernetes et par d’autres projets construits au-dessus de la plate-forme. Le résultat était un code qui pouvait être délicat et bogué. L’équipe Kubernetes a finalement déconseillé Dockershim, laissant aux concepteurs le temps de s’en éloigner avant qu’il ne soit supprimé. L’annonce initiale indiquait qu’elle irait à un moment donné après la sortie de Kubernetes 1.23.
Ce jour arrive bientôt. Avec la version d’avril 2022 de Kubernetes 1.24, la prise en charge de Dockershim sera complètement supprimée. Microsoft prend en charge les toutes nouvelles versions de Kubernetes qui sont sur le point d’être introduites, il est donc temps d’examiner si cette modification radicale aura un impact sur votre code.
Comment Azure utilise Dockershim aujourd’hui
Actuellement, le nœud Azure Kubernetes Linux les pools créés avec Kubernetes 1.19 ou version ultérieure exécutent actuellement containerd. Cela indique que vous n’avez pas besoin d’utiliser Dockershim, AKS utilisant l’interface d’exécution du conteneur Kubernetes pour lier vos Kubelets directement à containerd. Cela élimine un ensemble d’actions de gestion et d’interfaces utilisateur d’AKS, de sorte que vos applications doivent être plus réactives, évoluer plus rapidement et utiliser moins de ressources. Avec l’assistance de Docker, vos Kubelets devraient d’abord se connecter à Dockershim avant de se lier au moteur Docker sous-jacent avant de se lier à l’implémentation sous-jacente du conteneur Docker.
Ces deux points sont essentiels, en particulier si vous utilisez Kubernetes en conjonction avec KEDA (Kubernetes-based Event-Driven Autoscaling) ou d’autres outils événementiels. Le développement de nouveaux pods selon les besoins sera plus rapide, permettant à votre application de réagir plus rapidement à une demande accrue. Cela peut également entraîner des économies à long terme, en vous permettant de réduire à zéro dans davantage de cas où la tolérance de votre application à la latence peut prendre en charge le temps nécessaire pour lancer une instance de conteneur.
Basé sur Windows les conteneurs pourraient être plus préoccupants. Microsoft n’a commencé à proposer un aperçu de la prise en charge de Windows pour containerd qu’en 2021, nécessitant des en-têtes spécifiques dans la configuration de votre cluster. La disponibilité générale inclura la sortie de Kubernetes 1.23 par AKS, à un moment donné en février 2022.
Il est très important de comprendre que la suppression de Dockershim de Kubernetes n’empêche pas l’exécution des images Docker dans votre environnement AKS. Ces conteneurs ne fonctionneront pas sur Docker, car Docker ne prend pas en charge le Kubernetes CRI. En pratique, ils s’exécuteront sur d’autres environnements d’exécution compatibles OCI, car Docker exécute la spécification d’image de conteneur OCI.
Mettre à niveau les pools de nœuds AKS pour utiliser containerd
Bien que certaines instances plus anciennes de Kubernetes continuer à fonctionner, ils ne seront pas pris en charge. Au fur et à mesure que Microsoft met à jour les outils Kubernetes d’Azure, il finira par se débarrasser de la prise en charge des anciennes variantes, vous devrez donc mettre à jour les clusters basés sur Docker si nécessaire. Le propre cycle de vie de l’assistance de Kubernetes consiste à prendre en charge chaque variation mineure pendant 12 mois (un coup de pouce par rapport aux neuf premiers mois d’assistance). Avec une toute nouvelle version mineure qui arrive environ tous les trois à quatre mois, Microsoft s’engage à prendre en charge les 3 dernières variantes mineures de Kubernetes. Cela vous offre environ un an pour mettre à niveau vos applications AKS lorsque Kubernetes 1.22 présentera une assistance avec la version de base de Kubernetes 1.25, probablement en janvier ou février 2023.
Heureusement, le processus de mise à niveau des applications Kubernetes fonctionnant sur AKS est assez basique. Si vous utilisez Linux, vous utilisez déjà un environnement basé sur containerd. Si vous utilisez toujours une version plus ancienne et non prise en charge, la mise à niveau de votre situation vous mettra automatiquement à niveau vers l’utilisation de containerd. Aucune modification n’est nécessaire à vos registres d’ordinateurs ou à vos conteneurs, et vous pouvez continuer à utiliser Docker pour développer et tester sur vos propres systèmes. Il ne devrait pas y avoir de problèmes, mais c’est un bon concept d’établir un système de test utilisant la dernière version d’AKS Kubernetes pour garantir que votre application fonctionne dans l’environnement actuel.
Les choses sont un peu plus complexes si vous ‘utilisez des conteneurs Windows. Le choix le plus pratique consiste à inclure tout d’abord un pool de nœuds conteneurs dans votre cluster AKS existant. Vous devez inclure explicitement un en-tête personnalisé dans le pool de nœuds, ce qui définit la valeur de WindowsContainerRuntime sur containerd. Vous pouvez ensuite essayer de déplacer des conteneurs ou d’inclure de nouveaux conteneurs dans le tout nouveau pool de nœuds. Il est également possible de mettre à niveau un pool de nœuds unique ou un cluster entier vers containerd, à l’aide d’Azure CLI. Cela permet à votre code de s’exécuter sur containerd, mais à moins que vous ne vous souveniez de créer explicitement de nouveaux pools de nœuds containerd, ils seront basés sur Docker.
Avec la version d’accessibilité de base de Kubernetes 1.23 sur AKS, containerd sera la valeur par défaut pour les nouveaux conteneurs Windows ainsi que pour Linux. Cela facilitera la réalisation de votre migration avant que Kubernetes 1.24 ne soit disponible plus tard en 2022.
Il existe quelques recommandations supplémentaires. Comme la CLI Docker n’est pas prise en charge dans Kubernetes, vous devrez utiliser une CLI différente pour dépanner les pods en cours d’exécution. Microsoft conseille d’utiliser crictl, qui a une méthode de travail centrée sur Kubernetes. Cela a un peu une courbe de connaissance, mais ce n’est pas trop onéreux. Il y a des changements dans la composition des journaux de conteneur et vous devrez peut-être changer votre plate-forme de journalisation pour une plate-forme prenant en charge les formats de journal Kubernetes CRI. Les propres outils de surveillance d’Azure prennent déjà en charge ce format. Ils sont conseillés en remplacement du travail avec le moteur Docker, qui n’est plus disponible.
Les développeurs de Kubernetes et le groupe Azure de Microsoft ont parcouru un long chemin pour se débarrasser de la menace de la transition Dockershim . Si vous utilisez Dockershim dans AKS, il est maintenant temps de passer à containerd. Il ne devrait pas y avoir de problèmes autres que le passage à un nouveau format de journal et la découverte de l’utilisation des nouveaux outils de dépannage. Bien que cela nécessite quelques modifications sur la façon dont vous avez pu gérer AKS, elles sont assez mineures. Le résultat est un bon exemple de la façon dont des équipes de développement telles que Kubernetes et des plates-formes telles qu’Azure peuvent gérer les changements d’innovation de base, en limitant le travail de votre part à vos applications.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
