Livrée en décembre, la dernière version 1.9 de Kubernetes, le framework d'orchestration de conteneur open source, généralise la disponibilité de l'API Workloads pour les charges de travail, comporte une version alpha d'une nouvelle API de stockage de conteneur et inclut le support en bêta de Windows Server.

L'API Workloads généralement disponible en version de production

Avec la mise à jour de Kubernetes, l'API Apps Workloads, arrivée en version bêta dans Kubernetes 1.8, passe en version de production. Cette API permet de définir les charges de travail en fonction de leurs comportements, ce qui peut s’avérer fort utile pour les applications ayant besoin de temps d’exécution importants, voire persistants.

Quatre API de la version 1 de l'API Apps Workloads accèdent à la disponibilité générale :

- Deployment : une méthode de base pour décrire l'état souhaité pour une application en cours d'exécution, dont les ReplicaSet.

- ReplicaSet : elle garantit, via une configuration de Deployment, qu'une application dispose de suffisamment d'instances de conteneur en cours d'exécution (les Replicas) pour répondre aux besoins définis.

- Daemonset : un déploiement pour une application qui tourne en continu, indépendamment des tâches exécutées par les autres applications, comme la journalisation ou la surveillance.

- StatefulSet : utilisée pour les charges de travail nécessitant un état persistant même si les conteneurs sont supprimés et redémarrés. StatefulSets assure également la persistance des données pour des opérations comme l'identification réseau pour les conteneurs ou l'ordre dans lequel les conteneurs démarrent et s'arrêtent.

Un autre set d'API de Workloads, Job et CronJob, regroupées sous la dénomination Batch Workloads API, est utilisé pour des charges de travail planifiées et à durée déterminée. Ces Batch Workloads API sont toujours en version bêta. 

Support de Windows Server en bêta

Après l’ajout par Microsoft du support natif des conteneurs Docker à Windows, il semblait logique que d'autres applications utilisant Docker, comme Kubernetes, suivent. Kubernetes 1.9 permet d’utiliser partiellement Kubernetes sur Windows Server. Pour tester Kubernetes sur Windows Server, il faut Windows Server 2016 et Docker 1.12. À l'heure actuelle, le panneau de contrôle de Kubernetes ne tourne que sous Linux. En d'autres termes, il est possible de planifier l'exécution de conteneurs sur Windows Server à partir d'un contrôleur Linux, mais il n’est pas possible d’utiliser Windows Server comme contrôleur à la place de Linux.

Première alpha de l'interface de stockage de conteneurs (CSI)

Dès le début, Kubernetes s’est distingué par sa capacité d’abstraction des ressources, stockage compris, à partir des applications. Malheureusement, le stockage de conteneurs n'est pas vraiment normalisé. Pratiquement chaque solution de conteneurs a une manière propre de gérer le stockage, et Kubernetes n’échappe pas à la règle. La bonne nouvelle est que le Groupe de travail sur le stockage, le CNCF Storage Working Group, un sous-groupe de la Cloud Native Computing Foundation (CNCF), a élaboré une norme de stockage appelée Container Storage Interface (CSI) pour les clusters de conteneurs. Kubernetes 1.9 comporte une version alpha d'un plug-in CSI, qui permet de développer des plug-ins de volume de stockage indépendamment de Kubernetes lui-même. Le projet n'en est encore qu'à ses débuts, mais les développeurs de Kubernetes sont confiants et pensent que l’initiative va dans le bon sens.

D’autres fonctionnalités de Kubernetes 1.9

Parmi les autres ajouts et modifications apportées au framework, on peut citer :

- Une version alpha d'une extension d'accélération matérielle à Kubernetes, permettant d’utiliser le GPU comme ressource. Kubernetes pourra mieux supporter ainsi les charges de travail d'apprentissage machine.

- Prise en charge en alpha de l'adressage IPv6.

 - Validation plus rapide des données de définition de ressources personnalisées (CRD). Ces Custom Ressource Definition (CRD) permettent aux administrateurs de personnaliser et d'étendre une installation Kubernete sans compromettre la compatibilité quand une nouvelle version de Kubernetes est disponible.