Kubernetes v1.22 est une nouvelle version de fonctionnalité qui ajoute plus de 50 améliorations à la plate-forme d'orchestration de conteneurs. Il désapprouve également certaines fonctionnalités et supprime plusieurs API qui ont été remplacées par des versions de remplacement.
Voici la liste des changements les plus importants, à commencer par les ajouts de fonctionnalités.
Application côté serveur
L'application côté serveur n'est plus en version bêta et est généralement disponible pour tous les utilisateurs. Il s'agit d'un nouveau mécanisme destiné à faciliter la gestion déclarative des ressources par les utilisateurs et les contrôleurs de cluster.
L'utilisation de Server-side Apply permet aux développeurs d'initier des modifications de ressources en décrivant leurs intentions. Le serveur d'API Kubernetes suit les modifications apportées aux objets champ par champ. Cette “gestion de terrain” Le système crée un modèle de propriété dans lequel les modifications apportées à un champ ajouté par un autre responsable sont automatiquement rejetées. Cela évite d'annuler involontairement une opération lancée par un autre administrateur.
Avant l'application côté serveur, la logique d'identification des champs de ressources nécessitant une mise à jour faisait partie de la commande kubectl apply côté client. Maintenant, cela est élevé sur le serveur, ce qui permet aux contrôleurs d'appliquer plus facilement leurs propres modifications de configuration et facilite les nouvelles capacités de contrôle d'accès. Les modifications apportées aux champs individuels sont enregistrées, pas seulement le dernier état appliqué par chaque utilisateur.
Publicité
Les ressources acquièrent une nouvelle propriété managedFields lorsque l'application côté serveur avec gestion des champs est active. Il enregistre chaque champ, les données qui lui sont associées et l'heure de sa dernière mise à jour. L'édition manuelle de managedFields est possible mais fortement déconseillée ; il est prévu que seul le serveur d'API Kubernetes écrive ces valeurs.
La gestion sur le terrain s'accompagne d'une prise en charge de la résolution des conflits et de quatre stratégies de fusion différentes. Ceux-ci vous permettent de personnaliser ce qui se passe lorsque vous essayez de modifier un champ qui a déjà été modifié par un autre utilisateur. Vous pouvez forcer l'application des modifications si nécessaire, en transférant la propriété à l'utilisateur entrant.
Fournisseurs d'identifiants externes
Les fournisseurs d'identifiants externes ont également fait le saut à stable. Ceux-ci vous permettent d'utiliser des plugins pour obtenir des informations d'identification telles que des jetons d'authentification et des certificats TLS en dehors de votre cluster.
La fonctionnalité vous permet d'intégrer le contrôle d'accès Kubernetes aux fournisseurs d'authentification existants. Les fournisseurs peuvent vous authentifier à l'aide des systèmes OAuth2, LDAP et SAML, afin que vous puissiez vous connecter à l'aide de vos informations d'identification existantes pour les services courants.
Les fournisseurs sont implémentés sous forme de plug-ins avec un composant côté serveur exécuté dans le cluster. Cela utilise un webhook spécial pour convertir les jetons spécifiques au client dans un format que le serveur d'API Kubernetes peut interpréter.
Exécution sans racine
Les environnements de haute sécurité peuvent bénéficier de protections accrues en exécutant le plan de contrôle Kubernetes en tant qu'utilisateur non root. Il s'agit d'une fonctionnalité alpha disponible pour les nouveaux déploiements de cluster. Cela permet d'atténuer les risques d'une compromission réussie du plan de contrôle en fournissant un accès illimité à votre hôte.
Publicité
Le lancement d'un cluster en tant qu'utilisateur non root nécessite que vous activiez la porte de fonctionnalité RootlessControlPlane. Le plan de contrôle devrait alors démarrer sans utiliser sudo.
Il existe une prise en charge similaire pour l'exécution de composants individuels au niveau du nœud dans un environnement non racine. Kubelet, kube-proxy et l'environnement d'exécution du conteneur ont désormais cette capacité, vous aidant à renforcer la sécurité de votre installation.
Suppressions d'API
Comme une nouvelle version mineure, v1.22 désapprouve certaines fonctionnalités existantes dans divers composants Kubernetes. Il s'agit principalement de commandes, d'indicateurs et de quelques plugins d'authentification et de stockage. Les fonctionnalités affectées restent disponibles mais pourraient être supprimées à l'avenir.
v1.22 supprime également 12 API précédemment obsolètes. Les API supprimées sont toutes des versions bêta qui ont été remplacées par des alternatives stables plus récentes.
La liste comprend les ressources Ingress et IngressClass utilisées pour exposer les services avec des règles de routage. Les versions networking.k8s.io/v1beta1 de ces objets doivent être remplacées par leurs équivalents networking.k8s.io/v1 qui restent pris en charge.
Les autres API supprimées incluent les versions bêta d'APIService, CertificateSigningRequest, CustomResourceDefinition et Lease, ainsi que plusieurs objets liés au contrôle d'accès, au stockage et à la planification. Consultez le guide de migration avant d'appliquer la mise à niveau à votre cluster. Vous devrez modifier toutes les ressources à l'aide des API supprimées afin qu'elles fassent plutôt référence aux nouvelles versions stables.
La prochaine version de Kubernetes pour inclure les suppressions sera la v1.25. Il est actuellement prévu de supprimer quatre API bêta : CronJob, EndpointSlice, Event et PodDisruptionBudget.
Autres modifications
Cette version apporte de nombreux autres ajouts et améliorations mineurs, notamment la prise en charge alpha de la mémoire d'échange, une expérience améliorée lors de l'exécution de Kubernetes sous Windows et la possibilité d'utiliser des groupes de contrôle v2 pour définir des contraintes d'allocation de mémoire et d'isolement sur les pods.
Publicité
Etcd, le magasin de configuration utilisé par le serveur d'API Kubernetes, a été déplacé vers la version 3.5.0. Cela améliore les capacités de journalisation avec un nouveau format structuré et une rotation de fichier intégrée. Le projet a également permis d'améliorer considérablement les performances pour accélérer certaines opérations Kubernetes courantes.
Plusieurs API bêta sont désormais marquées comme stables, y compris les jetons de compte de service liés et l'objet PodDisruptionBudget pour spécifier le nombre minimum de réplicas simultanés. Kubernetes a également acquis la capacité de vous avertir lorsque vous utilisez une API obsolète, ce qui vous permet de rester plus facilement sur le chemin stable. Vous verrez ces messages lorsque vous appliquerez des ressources à votre cluster.
New Release Cadence
La v1.22 marque le début d'une nouvelle cadence de publication régulière pour les mises à jour de Kubernetes. Les fonctionnalités arriveront désormais quatre fois par an au lieu de trois, créant un cycle de développement légèrement plus long qui offre plus de chances d'optimiser et de maintenir la qualité de la version. Il offre également plus de marge de manœuvre aux administrateurs de cluster qui disposent désormais d'un mois supplémentaire entre les migrations.
Conformément à ce calendrier, Kubernetes v1.23 devrait arriver début décembre 2021. Chaque cycle a un temps de développement estimé à 15 semaines. Des mises à jour de correctifs régulières seront toujours publiées sur leur cadence mensuelle existante, avec des corrections de bogues critiques plus tôt si nécessaire.
Résumé
Kubernetes v1.22 est une mise à jour importante qui voit le projet passer à une nouvelle cadence de publication. Cela aidera les administrateurs de cluster à planifier les futures mises à niveau, offrant plus de temps de migration avant la prochaine.
Publicité
En termes de nouvelles fonctionnalités, l'ajout le plus important est sans doute l'application côté serveur. Cela simplifie l'utilisation de configurations de ressources déclaratives, en soulevant la logique de kubectl dans votre cluster. Cela devrait éventuellement remplacer l'implémentation d'origine de kubectl apply.
La mise à niveau vers la v1.22 peut nécessiter une action si vous utilisez toujours l'une des API bêta supprimées. Vous devriez pouvoir les remplacer par leurs versions stables, bien que cela puisse signifier modifier vos ressources dans certains cas. Prendre le temps maintenant de traiter les nouvelles dépréciations de la v1.22 vous aidera à vous préparer à l'arrivée de la v1.23, ce qui facilitera le processus de migration de cette version.