Petit guide pour passer de la virtualisation à Kubernetes

Introduction

Des instances plus légères, des déploiements plus élastiques et beaucoup plus d’automatisation. L’orchestrateur Kubernetes s’impose en entreprise pour mettre en production les applications, non plus sous la forme de machines virtuelles, mais sous celle de containers. Ce guide est conçu pour donner les clés d’un système qui a de plus en plus vocation à remplacer l’hyperviseur dans les options d’achat du datacenter. 

Initialement assimilé à une solution d’architecture plutôt conçue pour les développeurs, avec la promesse jamais tenue qu’ils n’auraient plus jamais besoin de solliciter la DSI pour réserver des serveurs, Kubernetes est finalement redevenu un produit d’infrastructure. Il s’administre par les ingénieurs système, fait la jonction entre la technique et les besoins métier, et sert de fondation pour bâtir des projets de transformation, notamment ceux basés sur l’informatique en Edge. 

Kubernetes permet effectivement aux développeurs de déployer leurs applications sans tenir compte de l’infrastructure ; une couche d’abstraction abolit pour eux les différences entre serveurs sur site et ressources en cloud public, entre cluster de test et cluster de production. Mais encore faut-il savoir déployer et maintenir Kubernetes lui-même. Et pour qu’il fonctionne, il faut lui fournir de vrais serveurs, avec de vrais systèmes d’exploitation. Ce travail est celui des informaticiens. 

Lorsque Google a imaginé le concept de Kubernetes, il devait s’agir d’une technologie essentiellement exécutée en cloud public, c’est-à-dire maintenue par les seules équipes des hyperscalers. Mais la réalité du marché est que les entreprises veulent pouvoir exécuter des clusters Kubernetes chez elles. Dès lors, Kubernetes devient un système informatique au même titre que VMware vSphere. Et il se pilote par les mêmes équipes internes, celles de la DSI. 

Le principe : réduire l’empreinte des instances applicatives pour mieux les déployer

Les containers sont nés en 2004 sur le système Solaris de Sun, comme une technologie de virtualisation non pas d’une machine entière, mais juste de l’environnement d’exécution du système d’exploitation. L’idée était simplement d’économiser l’empreinte mémoire et les ressources processeur. Dans une machine virtuelle, il faut embarquer un système Linux ou Windows complet pour exécuter une application. Mais si l’application est développée avec des langages d’assez haut niveau (Java…), finalement, qu’importe le système sous-jacent. Et si l’OS importe peu, autant mettre le même dans chaque VM. Et quitte à mettre le même, autant n’en faire fonctionner qu’une seule copie par machine physique. 

Au-delà des ressources matérielles économisées, les équipes IT y voient un intérêt : pouvoir redémarrer très rapidement une application quand elle plante. On la relance juste en container, sans avoir à recharger tout un OS. 

La communauté Linux a décliné le concept en 2008, en intégrant dans le noyau 2.6.24 de son système une sorte d’hyperviseur de containers baptisé LXC. Cela fonctionne un peu comme du multitâche, mais en mieux cloisonné : chaque application est persuadée d’être la seule à fonctionner en mémoire et elle pense que l’OS qui l’exécute lui est dédié. 

L’arrivée de Docker en 2013 a permis d’apporter un peu de méthodologie au concept, à commencer par le fait de packager les containers sur disque, avec des paramètres, pour avoir une image prête à l’emploi, qu’on peut lancer automatiquement quand le moment est opportun (pic d’activité…) sur n’importe quelle machine. 

Kubernetes est arrivé en 2015 pour passer de l’exécution de containers sur une machine à leur répartition sur un cluster, au même titre que VMware vSphere. La raison d’être de Kubernetes est de repenser les applications en microservices : on les découpe en petits bouts fonctionnels individuellement plus simples à mettre à jour. Quand une fonction évolue, on actualise seulement son container, sans risquer de casser le reste des fonctions. 

Ce morcellement permet d’exécuter les applications n’importe où, Kubernetes se chargeant de leur attribuer puissance de calcul, stockage et canaux de communications. Les possibilités de l’orchestrateur sont telles qu’il est capable de déployer des applicatifs aussi bien sur de grands clusters que sur de toutes petites machines d’appoint. C’est ainsi que la couche système Kubernetes sait faire le grand écart entre cloud privé et informatique en Edge.

1Administration-

Comprendre comment Kubernetes fonctionne

2Datacenter-

Les principales solutions pour les déploiements métier

3Edge-

Les solutions pour concrétiser la nouvelle informatique de terrain