Au deuxième jour de la KubeCon 2022, la keynote démarre par l'annonce des nouveautés du projet Kubernetes v1.24.
En voici les principales:

Suppression de Dockershim

Rappelez-vous, Kubernetes v1.20 avait annoncé que Dockershim serait bientôt supprimé, c’est chose faite dans Kubernetes v1.24!

Pour rappel, les premières versions de Kubernetes ne fonctionnaient qu'avec un seul runtime de conteneurs: Docker Engine. Pourtant il en existe plein d'autres: containerd, CRI-O, Mirantis Container Runtime, etc.
Plus tard, Kubernetes a ajouté la prise en charge de l'utilisation d'autres runtimes de conteneurs, au travers de la norme CRI. La norme CRI a été créée pour permettre l'interopérabilité entre des orchestrateurs (comme Kubernetes) et de nombreux runtimes de conteneurs différents.
Or, Docker Engine n'implémente pas cette interface (CRI), donc le projet Kubernetes a dû créer un code spécifique pour continuer à supporter Docker Engine le temps de la transition et a intégré ce code dockershim à Kubernetes lui-même.

Le code dockershim a toujours été destiné à être une solution temporaire (d'où le nom : shim). En fait, la maintenance de dockershim était même devenue un lourd fardeau pour les mainteneurs de Kubernetes: des fonctionnalités qui sont maintenant implémentées dans les nouveaux runtimes CRI étaient largement incompatibles avec le dockershim, telles que cgroups v2 et les espaces de noms utilisateurs. La suppression du dockershim de Kubernetes permet de poursuivre le développement dans ces domaines.

Pour en savoir plus sur ce que cela signifie vraiment, consultez le billet de blog "Don't Panic: Kubernetes and Docker".

Pour déterminer l'impact que la suppression de dockershim peut avoir sur vos projets, vous pouvez lire "Check whether dockershim removal affects you".

Kubernetes Cluster API

Cluster API v1.0 est sortie!

Cluster API est un sous-projet Kubernetes axé sur la fourniture d'API déclaratives et d'outils pour simplifier le provisionnement, la mise à niveau et l'exploitation de clusters Kubernetes.

Lancé par le Special Interest Group (SIG) Kubernetes "Cluster Lifecycle", le projet Cluster API utilise des APIs et des modèles de style Kubernetes pour automatiser la gestion du cycle de vie des clusters pour les opérateurs de plates-formes. Cela signifie que l'infrastructure de votre cluster Kubernetes, c'est-à-dire les machines virtuelles, les réseaux, les load balancers et les VPCs, ainsi que la configuration du cluster lui-même sont définis de la même manière que les charges de travail qui y sont déployées: au travers d'objets Kubernetes définis dans des fichiers de configuration au format yaml. Cela permet des déploiements de cluster cohérents et reproductibles dans différents environnements d'infrastructure.

Storage

Volume Expansion

L'"expansion de volume" a été introduite en tant que fonctionnalité alpha dans Kubernetes 1.8, passée en bêta dans 1.11, et finalement GA avec Kubernetes 1.24.

Cette fonctionnalité permet de spécifier simplement une nouvelle taille dans la Spec des objets PersistentVolumeClaim et Kubernetes étendra automatiquement le volume à l'aide du backend de stockage et étendra également à chaud (quand cela est possible) le système de fichiers sous-jacent utilisé par le pod.

Storage Capacity Tracking

Kubernetes v1.24 inclut la prise en charge de l'API (cluster-level) pour le suivi de la capacité de stockage.
Pour l'utiliser, vous devez également utiliser un driver CSI prenant en charge le suivi de la capacité.

Kubernetes garde une trace de la capacité de stockage pour permettre au scheduler de placer des pods sur des noeuds avec une capacité de stockage suffisante pour les volumes manquants restants. Sans suivi de la capacité de stockage, le scheduler peut choisir un noeud qui n'a pas assez de capacité pour provisionner un volume et plusieurs tentatives de scheduling seront alors nécessaires.

Security - Pod Security Admission

Dans Kubernetes v1.24, la fonctionnalité en bêta PodSecurity est activée par défaut.

Pour rappel, la fonctionnalité "Pod Security Admission" permet de définir différents niveaux d'isolation pour les pods, pour restreindre le comportement des pods de manière claire et cohérente. Plus d'infos ici.

Performances

Les performances du scheduler sont accrues dans Kubernetes 1.24: notamment la latence est réduite et le débit de placement atteint maintenant 300 pods/sec (avez-vous besoin d'autant dans votre projet?)

D'autre part, le SIG "Batch Working Group" a été créé pour discuter et améliorer la prise en charge des workloads de type batch (HPC, AI/ML, analyse de données, CI, etc.) dans Kubernetes. Le but est d'unifier la façon dont les utilisateurs déploient ce type de charges de travail pour améliorer la portabilité et simplifier la prise en charge pour les providers Kubernetes.

Le travail se poursuit également au sein du SIG Scheduling avec le support d'une dizaine de plugins, pour notamment faire du co-scheduling avec les PodGroups (analogue au gang scheduling de Volcano?).