Comment Kubernetes perce les frontières du cloud
Historiquement, la disparité des hyperviseurs applicatifs empêchait l'émergence d'un cloud hybride universel. Amazon Web Services (AWS) s'est orienté vers Xen. Google Cloud vers KVM, tout comme le IaaS OpenStack. Quant à Microsoft, il a fait le choix du fait maison avec Hyper-V. Même logique pour VMware avec sa technologie ESXI. Mais depuis 2015, cette hétérogénéité s'est effacée. Docker s'est imposé à tous comme runtime standard. A ce socle est venu se greffer l'orchestrateur de containers Kubernetes. Désormais implémenté par tous ces providers, il représente le dernier étage de la fusée. Dotant les infrastructures cloud d'un gestionnaire de cluster universel, il ouvre la possibilité de déployer les applications, aussi complexe soit leur couche logicielle, quel que soit cloud.
Et ça marche. "Pour un client, nous avons réalisé un proof of concept visant à démontrer qu'une même application pouvait être mise en œuvre aussi bien sur le service Kubernetes managé de Google (GKE, ndlr), qu'en mode cloud privé sur les plateformes OpenShift et Rancher, ou sur la distribution Kubernetes officielle (Vanilla, ndlr)", explique Ludovic Logiou chez Objectif Libre, une ESN française experte en open source. Résultat : un déploiement rigoureusement équivalent sur GKE, Rancher et Vanilla. "OpenShift a nécessité quelques ajustements car nous souhaitions pouvoir mettre en avant ses fonctions d'automatisation", précise le consultant. Le logiciel utilisé dans le cadre de ce PooC était composé de quelques microservices, d'une passerelle Internet, d'un front end d'administration et d'un back end reposant sur la base de données PostgreSQL.
Le défi de la standardisation
Au fil des projets, des points de grippage peuvent cependant surgir. "Les fournisseurs implémentent les nouvelles versions de Kubernetes à des rythmes différents. Or, d'un opus à l'autre, des fonctions peuvent être dépréciées", prévient Cyril Becker, CTO d'Alterway Cloud Consulting. Du coup, en fonction des éditions implémentées par les providers, des ajustements plus ou moins importants sont à prévoir. "Il ne s'agit pas d'un point bloquant", souligne Ludovic Logiou. Et Thibaut Demaret, CTO de la SS2L Worteks, d'ajouter : "Les différences d'API impliqueront rarement une refonte complète des templates Kubernetes."
"Dans un cloud public, le recours à des services supplémentaires engendre un risque de vendor lock-in"
A l'heure de la publication de cet article, l'offre de Kubernetes as a Service de Microsoft (AKS) prend en charge la version 1.15 de l'orchestrateur alors que celle d'AWS (EKS) supporte la 1.16. Quant au père de Kubernetes, Google, il implémente la 1.17. C'est également le cas de Rancher.
En charge de piloter le projet Kubernetes, la Cloud Native Computing Foundation (CNCF) propose un programme de certification technologique. L'ensemble des acteurs cités dans l'infographie ci-dessus ont décroché ce label. Mais parmi eux, seuls les français OVHCloud et Scaleway sont certifiés Kubernetes 1.18, qui est à ce jour la dernière version de l'orchestrateur. A l'inverse certains fournisseurs sont moins enclins à suivre la voie de la standardisation. EKS d'AWS oblige par exemple à recourir au IAM (identity and access management) du cloud américain pour authentifier les clusters. "Ce n'est pas le cas des services AKS de Microsoft et GKE de Google qui permettent tous deux de recourir à Kubernetes pour la gestion d'identités, sans obliger à passer par une solution tierce", constate Cyril Becker.
Vers la gestion multi-clusters
Evidemment, les offres Kubernetes des clouds publics automatisent l'installation de toutes les briques périphériques nécessaires à l'architecture applicative : ressources machines, répartiteur de charges, stockage, base de données... Autant de composants qui devront être préalablement installés manuellement dans le cas d'une plateforme Kubernetes mise en œuvre sur site. "Dans un cloud public, le recours à des services supplémentaires engendre un risque de vendor lock-in et de dépendance au fournisseur si l'on ne fait pas attention", insiste Ludovic Logiou. Face à ce dilemme, Thibaut Demaret conseille d'éviter les excentricités.
En attendant, la CNCF poursuit ses travaux de développement en vue d'étendre Kubernetes à de nouveaux domaines de standardisation. Via le projet Linkerd, elle planche notamment sur l'intégration à l'orchestrateur du service mesh et de la gestion d'architecture Kubernetes multi-clusters.