Quoi de neuf dans Kubernetes 1.8

Kubernetes 1.8, la dernière version du framework open source d'orchestration de conteneurs, arrive avec des améliorations attendues de longue date, comme le contrôle d'accès basé sur les rôles, l'audit et la journalisation ou encore la gestion de la charge de travail. Certaines fonctions en développement depuis longtemps accèdent au statut de production, d’autres sont livrées en bêta voire même en alpha.

Ajouts et évolutions

Voici la liste des ajouts et des évolutions dans la hiérarchie des versions :

• Des fonctions de sécurité basées sur les rôles.

• Des fonctions étendues d'audit et de journalisation.

• De méthodes, plus efficaces, pour exécuter à la fois des charges de travail interactives et en batch.

• Plusieurs fonctionnalités en alpha appelées à évoluer en versions de production dans les prochaines moutures.

Sécurité renforcée

Les fonctions de contrôle d'accès basé sur les rôles (RBAC pour « Role-Based Access Control ») sont déjà présentes en bêta dans les versions antérieures de Kubernetes. Le RBAC permet à un administrateur de définir des autorisations d'accès aux ressources de Kubernetes, comme les pods (unité de base de l’ordonnancement) ou les secrets (clés API ou mots de passe de service), puis de les rattacher (« relier » ou « bind ») à un ou plusieurs utilisateurs. Les autorisations sont accordées pour appliquer certaines modifications (« create » ou « créer », « update » ou « mettre à jour », « corriger » ou « patch ») ou simplement d’obtenir des informations (« obtenir » ou « get », « lister » ou « list », « voir » ou « watch »). Les rôles peuvent être appliqués sur un seul espace de noms ou sur un cluster entier, via deux API distinctes.

Kubernetes disposait déjà d'un système de contrôle des politiques pour le réseau, notamment le filtrage du trafic entrant vers les pods. Kubernetes 1.8 ajoute une fonction bêta pour filtrer aussi le trafic sortant. Pour l’instant, le filtrage dans les deux sens est limité à une liste de ports et de pairs de destination, de sorte que les limitations de débit ne sont pas encore disponibles via les interfaces de Kubernetes. (Il est possible d’effectuer ces opérations directement dans les conteneurs en passant par un pont réseau personnalisé.)

Une autre fonction réseau qui évolue en version bêta est celle de l’échange automatique des certificats TLS par Kubelet, l’agent logiciel qui tourne sur chaque nœud Kubernetes. Les certificats TLS utilisés dans Kubernetes ont une durée de vie d'une année et il arrive couramment d'oublier de les renouveler. La nouvelle fonctionnalité, quand elle est activée, génère automatiquement de nouveaux certificats pour Kubelet avant leur limite d’expiration.

Des fonctionnalités d'audit

Arrivée en alpha dans Kubernetes 1.7, la fonction d'audit passe en bêta dans Kubernetes 1.8. Les évolutions concernent le formatage des journaux d'audit, les politiques de contrôle des éléments accessibles au niveau d'un cluster et de ceux qui y ont accès, et les Webhooks utilisés pour relayer des événements vers des services externes. Cependant, malgré l’évolution de la fonction en bêta, toutes les modifications apportées au format d'événement sont rétrocompatibles. Cela signifie en d'autres termes que les développeurs Kubernetes peuvent commencer à utiliser la fonction dans des applications de production. L'outil audit2rbac qui peut générer des profils RBAC à partir d'événements d'audit offre un bon exemple de cette compatibilité ascendante du framework.

Mieux gérer les charges de travail

Kubernetes 1.8 fait également passer le set d’API de charge de travail du statut alpha en bêta. Ces API permettent d’orchestrer les applications en fonction de leurs comportements globaux, par exemple si la charge de travail est effectuée par lots ou en mode « cron » avec un début et une fin, différent d’un mode daemon qui tourne en permanence. Certaines des API de charge de travail devraient évoluer vers le statut de production plus rapidement que d'autres. Ce sera sans doute le cas de quatre des API les plus courantes - Deployment, DaemonSet, ReplicaSet et StatefulSet - dès la version 1.9 de Kubernetes. Les API par lots (Job et CronJob) évolueront vers ce statut un peu plus tard, mais les développeurs ont la possibilité de voir dès maintenant comment elles fonctionnent. Certaines applications peuvent déjà utiliser les API de charge de travail, mais seulement de façon provisoire. Il existe par exemple un fork de Apache Spark qui fonctionne directement sur Kubernetes, alors que ces fonctionnalités ne seront pas officiellement disponibles dans Spark ou dans Kubernetes avant un certain temps.

D’autres fonctionnalités alpha et bêta

Kubernetes 1.8 comporte aussi plusieurs fonctionnalités en alpha ou en bêta :

• Cri-containerd (en bêta) : permet d'utiliser Containerd alternativement au daemon Docker pour réduire les dépendances directes sur Docker.

• Les instantanés de volume (en alpha) : permettent de prendre des instantanés des volumes de Kubernetes à partir d’un appel d’API Kubernetes. Cette fonction n’est pas du tout prête pour une mise en production, car elle ne garantit même pas des instantanés cohérents.

• Le redimensionnement de volume (en alpha) : permet de modifier la taille des volumes, également à partir d’un appel d’API Kubernetes. À noter que le redimensionnement de volume permet uniquement de modifier la taille du volume sous-jacent et non son système de fichiers, qui peut avoir tous les formats possibles.