Version Kubernetes 1.24, système de gestion de clusters de conteneurs isolés

La version de la plateforme d'orchestration de conteneurs Kubernetes 1.24 est disponible, permettant de gérer un cluster de conteneurs isolés comme une entité unique, et offrant des mécanismes pour le déploiement, la maintenance et l'échelle des applications exécutées dans des conteneurs. Le projet a été initialement créé par Google, mais a ensuite été transféré sur une plateforme indépendante gérée par la Linux Foundation. La plateforme se positionne comme une solution universelle développée par la communauté, non attachée à des systèmes spécifiques et capable de fonctionner avec n'importe quelle application dans n'importe quel environnement cloud. Le code de Kubernetes est écrit en langage Go et est distribué sous la licence Apache 2.0.

Des fonctionnalités sont fournies pour le déploiement et la gestion de l'infrastructure, telles que la gestion de la base DNS, l'équilibrage de charge, la distribution des conteneurs sur les nœuds du cluster (migration des conteneurs en fonction des variations de charge et des besoins en services), la vérification de la disponibilité au niveau des applications, la gestion des comptes, la mise à jour et l'échelonnement dynamique du cluster opérationnel, sans interruption. Il est possible de déployer des groupes de conteneurs avec des opérations de mise à jour et d'annulation de modifications pouvant être appliquées simultanément à tout le groupe, ainsi que de segmenter logiquement le cluster en parties avec une séparation des ressources. Un support pour la migration dynamique des applications est disponible, pour lesquelles des solutions de stockage locales ou des systèmes de stockage en réseau peuvent être utilisés.

Principaux changements dans cette nouvelle version :

• Les outils de suivi de la capacité de stockage (Storage Capacity Tracking) ont été stabilisés, fournissant une surveillance de l'espace libre dans les partitions et transmettant les données au nœud de contrôle pour empêcher le lancement de pod sur des nœuds avec un espace libre insuffisant.
• La possibilité d'étendre les partitions de stockage a été stabilisée. L'utilisateur peut modifier la taille des partitions existantes et Kubernetes étendra automatiquement la partition et le système de fichiers associé sans interruption.
• La livraison du runtime Dockershim, qui était présenté comme une solution temporaire pour utiliser Docker dans Kubernetes, a été interrompue. Cela n’est pas compatible avec l'interface CRI (container runtime interface) et complique davantage le kubelet. Pour gérer des conteneurs isolés, il convient d'utiliser un runtime prenant en charge l'interface CRI, tel que containerd et CRI-O, ou d'utiliser le wrapper cri-dockerd qui implémente l'interface CRI sur l'API Docker Engine.
• Un support expérimental pour la vérification des images de conteneurs par des signatures numériques a été fourni à l'aide du service Sigstore, qui maintient un journal public pour confirmer l'authenticité (transparency log). Pour prévenir les attaques de la chaîne d'approvisionnement et la substitution de composants, le service assure également l'attestation par des signatures numériques des artefacts associés aux versions, y compris tous les fichiers exécutables Kubernetes installés.
• Par défaut, l'activation des API qui sont en beta pour les clusters a été arrêtée (les API de test ajoutées dans les versions précédentes sont conservées, ce changement ne concerne que les nouvelles API).
• Un support de test pour le format OpenAPI v3 a été mis en œuvre.
• Une initiative visant à migrer les plugins pour le stockage vers une interface unifiée CSI (Container Storage Interface) a été présentée, tout en maintenant la compatibilité au niveau de l'API. Les plugins Azure Disk et OpenStack Cinder ont été transférés vers CSI.
• Le Kubelet Credential Provider a été mis en beta, permettant d'extraire dynamiquement des identifiants pour le dépôt d'images de conteneurs via le lancement de plugins, sans stocker d'identifiants dans le système de fichiers du nœud.
• Une option pour réserver des plages d'adresses IP pour l'attribution aux services a été fournie. Lorsque cette option est activée, le cluster n'attribuera aux services que adresses IP à partir d'un pool préalablement alloué à chaque service, ce qui permet d'éviter les collisions lors de l'attribution d'adresses libres à partir d'un ensemble commun.

Source : opennet.ru