Kubernetes 1.24 a supprimé Dockershim et ne prend plus en charge Docker en tant que runtime de conteneurs intégré. ACK ne prend plus en charge Docker comme runtime de conteneurs dans les versions 1.24 et ultérieures. Pour mettre à niveau un cluster ACK vers Kubernetes 1.24 ou une version ultérieure, migrez d'abord le runtime de conteneurs des nœuds de Docker vers containerd.
Containerd est un runtime de conteneurs conforme aux normes du secteur, offrant des temps de démarrage plus rapides, une consommation de ressources réduite et une sécurité renforcée par rapport à Docker.
Avant de commencer
Dans la plupart des cas, les charges de travail ne dépendent pas directement du runtime de conteneurs : le backend de Docker appelle lui-même containerd. La migration devrait donc être transparente pour les applications en cours d'exécution.
Migrez d'abord votre environnement de préproduction, puis migrez votre environnement de production pendant les heures creuses.
Options de migration
Deux méthodes permettent de migrer le runtime de conteneurs des nœuds.
Option 1 : Mettre à niveau le pool de nœuds existant (recommandé)
Utilisez la fonctionnalité Kubelet Update disponible sur la page Node Pools. Cette méthode remplace automatiquement le disque système de chaque nœud.
Sauvegardez toutes les données présentes sur les disques système des nœuds avant de commencer. Les disques système sont remplacés lors de la mise à niveau. Les disques de données ne sont pas affectés.
Connectez-vous à la console de gestion Container Service. Dans le volet de navigation de gauche, cliquez sur Clusters.
Cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, choisissez Nodes > Node Pools.
Dans la colonne Actions du pool de nœuds cible, cliquez sur
> Kubelet Update.Vérifiez les détails de la mise à niveau du runtime et cliquez sur Precheck. Une fois la vérification préalable réussie, suivez les instructions à l'écran pour terminer la mise à niveau.
Pour plus de détails sur les paramètres, consultez la rubrique Mettre à niveau un pool de nœuds.
Option 2 : Créer un nouveau pool de nœuds et migrer les charges de travail (facultatif)
Créez un nouveau pool de nœuds avec le runtime containerd, puis transférez progressivement les charges de travail vers celui-ci avant de désactiver l'ancien pool.
Créer et gérer un pool de nœuds et définissez le runtime de conteneurs sur containerd.
Augmentez la capacité du nouveau pool de nœuds pour ajouter des nœuds.
Rendez l'ancien pool de nœuds non planifiable (cordon), ou utilisez des libellés de nœuds pour replanifier les charges de travail vers le nouveau pool.
Migrez toutes les charges de travail vers le nouveau pool de nœuds.
Désactivez l'ancien pool de nœuds.
Pour obtenir des instructions sur la mise en cordon des nœuds, consultez la rubrique Vider un nœud et gérer sa planifiabilité.
Fonctionnement des mises à niveau par remplacement de disque
Lorsque vous utilisez l'option 1, ACK effectue une mise à niveau par remplacement de disque pour chaque nœud, séquentiellement :
Videz le nœud et définissez-le comme non planifiable.
Arrêtez l'instance ECS.
Remplacez le disque système. L'ID du disque système change, mais le type de disque, l'adresse IP de l'instance et l'adresse MAC de l'interface réseau élastique (ENI) restent inchangés.
Réinitialisez le nœud et installez le runtime containerd.
Redémarrez le nœud et définissez-le comme planifiable une fois qu'il est prêt.
Considérations post-migration
Les commandes et API Docker ne sont plus disponibles sur les nœuds. Après la migration, Docker ne gère plus le cycle de vie des conteneurs. Utilisez plutôt les commandes containerd. Pour connaître les équivalents containerd des commandes Docker courantes, consultez la rubrique Comparaison des runtimes containerd, conteneurs sandboxés et Docker.
Docker Build n'est pas disponible sur les nœuds du cluster. Containerd n'inclut pas d'outil intégré de construction d'images. Le tirage (pull) d'images reste inchangé. Si vous construisiez précédemment des images sur les nœuds du cluster, utilisez l'une des alternatives suivantes :
Alibaba Cloud Container Registry (ACR) — recommandé : ACR construit des images à l'aide de BuildKit, l'outil officiel de construction d'images de Docker. Créez une instance ACR et configurez des règles de construction basées sur un Dockerfile pour déclencher des builds automatiques. L'image résultante est poussée directement vers votre référentiel d'images. Consultez la rubrique Construire des images à l'aide d'une instance Enterprise Edition.
Une instance ECS dédiée : Créez une instance ECS distincte, installez Docker dessus et exécutez les commandes Docker pour construire des images. Consultez la rubrique Installer et utiliser Docker et Docker Compose.
Vérifiez les configurations du Dockerfile. La syntaxe principale du Dockerfile reste inchangée. Vérifiez la compatibilité des images de base, les paramètres des variables d'environnement et les définitions des commandes d'exécution afin de garantir que les images se construisent et s'exécutent correctement dans l'environnement containerd.
FAQ
Combien de temps dure la mise à niveau de chaque nœud ?
Sans snapshot, la mise à niveau de chaque nœud prend généralement moins de 8 minutes. Si vous créez un snapshot pendant la mise à niveau, celle-ci commence après la création du snapshot ; ACK alloue jusqu'à 40 minutes pour la création du snapshot. Si le snapshot n'est pas prêt dans ce délai de 40 minutes, la mise à niveau du nœud expire et échoue (sans démarrer la mise à niveau sur ce nœud).
Si vous ne stockez pas de données métier sur les disques système, ignorez la création de snapshot pour maintenir des temps de mise à niveau courts.
Comment les nœuds sont-ils mis à niveau par lots ?
La taille des lots suit un schéma exponentiel : 1, 2, 4, 8, etc., jusqu'à atteindre le nombre maximal de mises à niveau concurrentes configuré. Ensuite, chaque lot met à niveau ce nombre de nœuds. Par exemple, avec un maximum de 4 mises à niveau concurrentes, les lots seront de 1, 2, 4, 4, 4.
Mes services seront-ils interrompus pendant la mise à niveau ?
Les nœuds sont vidés pendant la mise à niveau. Les services ne sont pas affectés si vos pods implémentent un arrêt gracieux et si vous disposez de plusieurs réplicas exécutés sur différents nœuds. Pour éviter que tous les réplicas d'une même application ne soient mis à niveau dans le même lot, définissez le nombre maximal de mises à niveau concurrentes à une valeur inférieure au nombre de réplicas de pod.
Puis-je revenir en arrière après la migration ?
Non. Le retour en arrière n'est pas pris en charge.
Les données sur les nœuds sont-elles perdues pendant la migration ?
Les disques système sont remplacés. Sauvegardez toutes les données importantes présentes sur les disques système avant de commencer. Les disques de données ne sont pas affectés.
L'adresse IP du nœud change-t-elle lors du remplacement du disque système ?
Non. L'ID du disque système change, mais le type de disque, l'adresse IP de l'instance et l'adresse MAC de l'ENI restent inchangés. Consultez la rubrique Remplacer le disque système d'une instance (changer le système d'exploitation).
Après la mise à niveau vers containerd, le répertoire Docker occupe toujours de l'espace disque. Comment le nettoyer ?
Le répertoire Docker sur le disque de données peut contenir des fichiers de conteneurs, des images, des journaux et des chemins de fichiers que vous avez créés. S'ils ne sont plus nécessaires, supprimez manuellement le répertoire Docker du disque de données après la migration.