La version Kubernetes 1.24 Stargazer inaugure deux changements majeurs

La version Kubernetes 1.24 Stargazer inaugure deux changements majeurs

L’orchestrateur de conteneurs Kubernetes vient d’apporter deux changements majeurs dans sa dernière version, Kubernetes 1.24 Stargazer. Avec cette version, les développeurs devront abandonner la prise en charge du moteur d’exécution de conteneur Docker Engine, mais gagneront en contrepartie un renforcement de la sécurité de la chaîne logistique via Sigstore.

La dépréciation de Dockershim n’est pas aussi dramatique qu’elle en a l’air. Si Dockershim vous permettait d’utiliser le moteur d’exécution Docker containerd dans Kubernetes, il n’a jamais été conçu pour être intégré à Kubernetes. De plus, Dockershim est incompatible avec la Container Runtime Interface (CRI) de Kubernetes et – surtout – sa maintenance était une véritable corvée.

Si les utilisateurs de Kubernetes ont élargi leur palette de choix de runtime avec CRI, le moteur Docker n’était pas compatible avec ce dernier. La solution, Dockershim, a comblé les lacunes entre Docker Engine et CRI. Pour autant, “cette petite cale logicielle n’a jamais été conçue comme une solution permanente. Au fil des années, son existence a introduit beaucoup de complexité inutile”, fait valoir Kat Cosgrove, défenseur des développeurs de Pulumi et ambassadeur de la Cloud Native Computing Foundation (CNCF), au début de Kubernetes. “À l’époque, il n’y avait pas vraiment beaucoup d’autres options et Docker était l’outil dominant pour travailler avec des conteneurs, donc ce choix n’était pas controversé.”

publicité

Un abandon contesté

Reste que la communauté des développeurs Kubernetes n’a pas su expliquer les raisons de l’abandon de Dockershim, ce qui a pu susciter de l’incompréhension, regrette ce dernier. “Docker ne disparaît pas, ni en tant qu’outil ni en tant qu’entreprise”. Pourtant, “retirer dockershim de kubelet est finalement une bonne chose pour la communauté, l’écosystème, le projet et l’open source en général”, fait valoir le développeur.

Et de rappeler que si vous souhaiter vraiment rester fidèle au moteur Docker, vous pouvez le faire même si Kubernetes ne le prend plus en charge de manière native. Mirantis, qui possède désormais le programme Docker, continuera à prendre en charge Dockershim dans Docker Engine et Mirantis Container Runtime avec Kubernetes. Ce nouveau programme Dockershim, cri-dockerd, fournit une shim pour Docker Engine, qui vous permet de contrôler Docker via le CRI de Kubernetes. Vous pouvez aussi, bien sûr, passer à l’un des runtimes Kubernetes pris en charge, tels que containerd v1.6.4 et ultérieur, v1.5.11 et ultérieur, ou CRI-O 1.24 et ultérieur.

Autre évolution majeure, Kubernetes prend désormais en charge la signature chiffrée des artefacts logiciels afin d’améliorer la sécurité de sa chaîne d’approvisionnement en logiciels. Selon le développeur fondateur de Sigstore, Dan Lorenc, les certificats Sigstore permettent aux utilisateurs de Kubernetes de vérifier l’authenticité et l’intégrité de la distribution qu’ils utilisent en “donnant aux utilisateurs la possibilité de vérifier les signatures et d’avoir une plus grande confiance dans l’origine de chaque binaire Kubernetes déployé, de chaque bundle de code source et de chaque image de conteneur”.

Des tas d’améliorations

Kubernetes 1.24 apporte également d’autres améliorations. Par exemple, les nouvelles interfaces de programmation d’applications (API) bêta ne seront plus activées par défaut dans les clusters. Toutefois, les API bêta existantes et leurs nouvelles versions continueront d’être activées par défaut. Dans un autre changement d’API, Kubernetes 1.24 offre une prise en charge bêta pour la publication de ses API au format OpenAPI v3.

Des modifications ont également été apportées au stockage et aux volumes. Le suivi de la capacité de stockage prend désormais en charge l’exposition de la capacité de stockage actuellement disponible via les objets CSIStorageCapacity et améliore la planification des pods qui utilisent les volumes de l’interface de stockage des conteneurs (CSI) avec une liaison tardive. En attendant, vous pouvez redimensionner un volume persistant existant avec l’expansion de volume. Des travaux sont également en cours pour migrer les éléments internes des plugins de stockage en arborescence afin de faire appel aux plugins CSI tout en conservant l’API d’origine. Jusqu’à présent, les plugins Azure Disk et OpenStack Cinder ont tous deux été migrés.

Enfin, bien qu’il y ait de nombreux autres changements et améliorations, gardez en mémoire que la nouvelle fonctionnalité de mise en réseau facultative de Kubernetes 1.24, qui vous permet de réserver une plage pour l’attribution d’adresses IP statiques aux services a été modifiée. Avec l’activation manuelle de cette fonctionnalité, le cluster préférera l’attribution automatique à partir du pool d’adresses IP des Services, réduisant ainsi le risque de collision. J’aime beaucoup cette fonctionnalité.

Source : ZDNet.com

Leave a Reply

Your email address will not be published. Required fields are marked *