Face à la déferlante Kubernetes, une seule solution : Kubernetes lui-même !

L'hégémonie de Kubernetes est telle, qu'il entraîne avec lui une prolifération d'interfaces et d'abstractions, créant paradoxalement de plus en plus de confusion chez les utilisateurs.

Il arrive dans l'histoire de l'informatique que certaines technologies gagnent la bataille, faisant oublier qu'elles n'ont pas toujours existé et, surtout, qu'elles n'ont pas toujours été seules. C’est le cas, aujourd’hui, de Kubernetes (K8s). Ce système Open source est devenu la norme pour automatiser le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées. Seulement, son hégémonie est telle, qu’il entraîne avec lui une prolifération d’interfaces et d’abstractions, créant paradoxalement de plus en plus de confusion chez les utilisateurs.

Une technologie ouverte et agnostique, utilisée par tous

Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Services (AKS), Mirantis MKE, AWS EKS, ou encore Kubernetes générique : seul ou intégré à d’autres solutions, K8s s’est invité dans tous les écosystèmes. À l’intérieur comme à l’extérieur des entreprises, il pousse presque aussi vite que la mauvaise herbe. Non pas que cette technologie soit « mauvaise », bien au contraire. Si elle est utilisée aussi massivement, c’est qu’elle permet d’accélérer considérablement le déploiement et la gestion des applications conteneurisées, ces programmes devenus eux-aussi incontournables, puisqu’ils peuvent être déplacés d’un environnement à l’autre sans rien perdre de leurs fonctionnalités.

Comme ce fut le cas par le passé de TCP/IP+Ethernet ou de Linux, Kubernetes s’est aujourd’hui imposé en tant que norme absolue. Au départ, il s’agissait d'une solution cloud native réservée aux applications scale-out. Au fil du temps, il s’est adapté pour devenir suffisamment générique et être utilisé à la fois pour les applications héritées, la virtualisation et quasiment toute charge utile. Évitant le verrouillage des fournisseurs, Kubernetes peut fonctionner aussi bien sur un Raspberry Pi, Microsoft Windows, que sur des clusters HPC massifs, permettant de résoudre environ 90% des problèmes de conditionnement, de déploiement et d’exploitation des applications. De plus, son architecture intégrée permet des mises à jour en continu, tandis que son API est particulièrement conviviale pour les opérateurs et les développeurs.

Un écosystème Kubernetes qui se complexifie de jour en jour

Forts de ces multiples atouts, Kubernetes a rapidement conquis le marché, générant une énorme prolifération de clusters Kubernetes et tout autant d’interfaces, mais aussi d’abstractions pour en contrôler le trafic réseau, entrant et sortant. Au début, il n'existait qu'une seule ressource officielle de contrôle en amont. Elle était simple et comportait des fonctionnalités minimales. Aujourd’hui, on en dénombre une douzaine à laquelle s’ajoute une douzaine de passerelles API Kubernetes, mais aussi de nombreuses implémentations de maillage de services. Des passerelles dont le trafic doit, à son tour, être contrôlé par de nouvelles ressources entrées/sorties. 

Le système, ainsi, se duplique à l’infini. À mesure que de nouvelles solutions apparaissent dans l'écosystème, les fonctionnalités des différentes catégories se chevauchent de plus en plus, créant une immense confusion parmi les utilisateurs mais aussi les fournisseurs. Pour pouvoir s’y retrouver, ils sont contraints à parler plusieurs langues. Aujourd’hui, la situation est devenue si complexe qu’elle confère au chaos. 

Utiliser Kubernetes comme point de contrôle

Face à cette confusion, les acteurs n’ont pas un milliard de solutions. La seule, véritablement efficace, est d’utiliser Kubernetes lui-même comme point de contrôle naturel des multiples sous-couches de chaque système. Prenant en charge une large gamme de conteneurs, il est en effet le plus adapté pour s’auto-gérer, permettant d’améliorer l’évolutivité de l’écosystème, tout en séparant les différents enjeux. Par exemple, la mise à niveau du plan de contrôle sera traitée séparément du plan de données. Ainsi, l’organisation n’a plus à se soucier de l’endroit où résident les clusters puisqu’ils sont tous gérés à partir du même point, agnostique aux options d’infrastructure. Le Saint-Graal des informaticiens ou presque, avec un semblant de multicloud hybride ! 

Ces points de contrôle naturels existent d’ailleurs dans tout système. La plupart du temps, ils sont associés à une API, essentielle face à l’automatisation omniprésente. Ainsi, avec Amazon Web Services, le point de contrôle est l'API/UI AWS. Avec les applications Java : la JVM. Avec Kubernetes : Kubernetes lui-même, combiné à Cluster API (CAPI) qui inclut quant à lui des fournisseurs pour Amazon (CAP-A), Azure (CAP-Z) ou VMware (CAP-V). Un dispositif complet à portée de chaque acteur pour résoudre les problèmes liés à la prolifération de Kubernetes. 

Alors que les premiers efforts, tels que k0smotron, ont prouvé l’efficacité de cette combinaison, il est temps, aujourd’hui, de passer au niveau supérieur en tenant la promesse de Kubernetes jusqu'au bout !