Alors que la version 1.6 de Kubernetes a surtout servi à stabiliser et à apporter une touche finale à des modifications de long terme, par exemple l’usage de la version 3 du magasin de stockage clé-valeur distribué ETCD, la mouture 1.7 du système d'administration et de gestion de conteneurs s’enrichit de fonctions de sécurité, de stockage et devient plus extensible. Et même si plusieurs fonctionnalités de Kubernetes 1.7 sont encore en version alpha, elles donnent une idée de la direction que prend la solution pour répondre à une gamme plus étendue de scénarios. D’autres fonctions mettent aussi en avant des capacités jusque-là réservées à des pans moins connus de l'écosystème conteneur.

Stockage et état : maintien en local et à jour

Plusieurs fonctionnalités mises à jour dans Kubernetes 1.7 tournent autour de la gestion du stockage persistant. Cette gestion consiste le plus souvent à associer des groupes de conteneurs (des pods dans le langage de Kubernetes) avec différents types de volumes de stockage : NFS, cibles iSCSI ou stockage dans des services cloud comme Amazon Web Services ou Azure. Kubernetes 1.7 offre également la possibilité de mapper un périphérique de stockage local, une solution pratique pour permettre à la charge de travail d’un « pod » d’accéder aux données sur le même système que celui sur lequel sont exécutées les API natives de Kubernetes.

Reste que, dans un grand nombre de scénarios Kubernetes, l'utilisation du stockage local n’est semble-t-il pas la solution la plus avisée. La méthode sera sans doute très utile pour les applications « vite fait mal fait », ou les nœuds de développement à système unique, comme c’est le cas avec Minikube, un outil qui sert à mettre en place rapidement un cluster opérationnel sur une machine. De plus, pour l’instant, de nombreux aspects du stockage local de Kubernetes 1.7 sont assez rudimentaires et fragiles. Par exemple, Kubernetes ne peut pas encore reconnaître les périphériques bloc locaux comme volume source. Mais il semble néanmoins que, à long terme, Kubernetes donnera plus d’importance au stockage local, par rapport à toutes les autres solutions.

Un autre changement dans la façon de gérer l'état de Kubernetes concerne les applications avec un état persistant. StatefulSets, utilisé pour gérer l'état d’un pod d'applications, dispose maintenant d’une fonction qui permet aux applications d’état - dont le propre ETCD de Kubernetes - d'être mises à jour automatiquement sans affecter leur état.

Sécurité : des secrets bien gardés

Les applications doivent souvent garder des secrets, c’est à dire des données associées à l'application qui ne doivent pas être transmises ou stockées en texte clair. Les clés API ou les mots de passe de service sont souvent considérés comme secrets. Kubernetes 1.7 peut maintenant stocker des informations confidentielles dans des espaces de noms, cryptés, au repos. Les pods peuvent également accéder à ces informations confidentielles pour communiquer entre eux grâce à l'ajout d'un administrateur de nœuds. Cette fonction, très prometteuse, est encore en version alpha. Il est probable que tous les secrets qui lui seront confiés dans la version actuelle devront être déchiffrés et recryptés avant le passage à une version ultérieure de Kubernetes.

D'autres produits, comme Docker Datacenter, sont capables de stocker les informations confidentielles utilisées par les conteneurs. Il est possible de préférer le système de secrets de Kubernetes 1.7 à la place, mais à long terme, il n’est pas sûr que la technologie puisse se substituer à d’autres solutions. Mais elle peut être considérée comme complémentaire. Kubernetes s’emploie à créer ou à améliorer les intégrations de son système avec des produits coffre-fort tiers comme Hashicorp Vault et Cyberark pour le stockage des secrets. Dans Kubernetes 1.7, certaines fonctions de sécurité antérieures en version bêta sont désormais stabilisées. Par exemple, l'API Network Policy permet maintenant de définir des règles pour contrôler la façon dont les pods peuvent communiquer entre eux, via des plug-ins pour le sous-système de réseau de Kubernetes.

Extensibilité : la personnalisation d’API par plug-ins

Kubernetes utilise depuis longtemps un système appelé « Third Party Resource » (TPR) qui permet aux développeurs d'ajouter leurs propres API. La version 1.7 s’enrichit d’une implémentation basée le même principe, la définition de ressource personnalisée ou Custom Resource Definition (CRD), l’idée étant d’alléger le processus de définition des API personnalisées. À noter que les TPR existants ne sont pas modifiés lors de la migration vers Kubernetes 1.7. Mais étant donné que ces TPR seront obsolètes dans la version 1.9 de Kubernetes, il est préférable de migrer dès maintenant les TPR existants vers les CRD.

Un autre changement majeur dans l’extensibilité de Kubernetes 1.7 concerne l'agrégation d’API. Celle-ci permet aux développeurs avancés de Kubernetes d'ajouter leurs propres API au cluster, de manière plus profonde et plus normative que les CRD. Éric Chiang, ingénieur logiciel chez CoreOS, explique la différence entre les deux fonctions : « Les CRD apportent une solution plus légère pour demander à Kubernetes d’allouer un espace aux ressources personnalisées pour l'API existante. L'agrégation permet de personnaliser complètement la gestion d’API par Kubernetes avec des plug-ins, par exemple pour la validation spécialisée des ressources ou le filtrage ACL, non disponible pour les ressources de base ». Il pense par ailleurs que la majorité des projets natifs de Kubernetes continueront à utiliser les CRD et que l'agrégation sera réservée à quelques grands projets « bien arrêtés ».

Kubernetes 1.7 bénéficie également de plusieurs améliorations. C’est le cas notamment de l'interface Container Runtime. Cette API permet à des runtimes de conteneurs comme Docker de communiquer avec Kubelet, l'application utilisée par Kubernetes pour exécuter chaque nœud dans un cluster, ce qui permet d’éviter l’intégration manuelle de chaque runtime avec Kubernetes. Docker pourrait demeurer le standard de fait pour les runtimes de conteneurs, mais les auteurs de Docker et d'autres ont travaillé dur pour désolidariser le runtime de l'écosystème conteneur. L’ajout de fonctions comme celle-ci dans Kubernetes 1.7 montre qu’il reste encore des choses à faire.