Il est partout ! On ne peut pas parcourir un site d’information, lire les nouvelles sur son réseau social favori, consulter les Meetups du jour sans en entendre parler : Kubernetes par-ci, Kubernetes par-là, mais qu’est-ce qu’ils ont tous avec Kubernetes !
Et puis d’ailleurs, c’est quoi « Kubernetes » ? Profitons de la récente release 1.14 pour faire le point sur cette technologie qui fait couler tellement d’encre numérique.
—
Je ne vous ferai pas l’affront de vous expliquer les bénéfices de l’utilisation de docker. Le plus populaire mécanisme de conteneurisation s’est imposé en 6 ans comme la solution idéale pour maquetter et tester toute forme d’application. Pourtant, même affublé de son pendant docker-compose, il était hors de question de l’utiliser pour publier sur un environnement de production sans un élément contrôlant…
Plusieurs solutions d’orchestration telles que Swarm (réalisé par Docker) ou MESOS remplissent la fonction avec brio, mais celle qui s’est peu à peu imposée comme le standard du marché se nomme Kubernetes, et ce n’est pas le fruit du hasard.
La coqueluche !
Pour comprendre comment cet orchestrateur est devenu la coqueluche de toute une industrie, il faut revenir à l’origine de sa création. Google, créateur du projet, utilisait pour ses besoins propres la notion de conteneur. Depuis le début des années 2000, le moteur de recherche avait besoin de monter en charge bien plus rapidement que ne le lui permettait des machines virtuelles, encore à leurs balbutiements à cette époque. En 2003, le projet visant à obtenir une telle flexibilité s’appelle Borg et il est uniquement interne à la société. Le produit App Engine, disponible sur Google Cloud, utilise en coulisses la technologie Borg pour assurer la montée en charge.
Plus tard, en 2013, l’évolution de Borg se nomme Omega. Elle apporte son lot de concepts, améliorations et mises à jour relatives aux technologies disponibles. Là encore, il s’agit d’un projet interne.
Finalement, c’est en 2014 que l’onde de choc retentit lorsque Google annonce « Kubernetes », une version OpenSource de Borg. Très rapidement, des noms tels que RedHat, IBM, Cisco et même Docker rejoignent la communauté qui se forme autour de l’orchestrateur. Quand on y réfléchit, c’est tactiquement un coup de maître que joue alors Google. À la traine derrière AWS sur le sujet Cloud, Google ouvre avec cette brique logicielle tout un juteux business d’hybridation. Et l’enjeu va bien plus loin qu’une simple interconnexion entre le on premise et son infrastructure Cloud.
De quoi parle-t-on exactement ? Ni plus ni moins que de surcharger l’infrastructure traditionnelle par une abstraction qui a le bon goût d’être totalement compatible quel que soit le matériel sur lequel elle est installée. Un acteur de l’hébergement ayant raté sa « cloudification » peut revenir sur le devant de la scène en proposant des plateformes Kubernetes. On comprend l’engouement de sociétés comme RedHat (désormais IBM) ou Cisco qui voient la la possibilité de rentrer en concurrence avec Amazon qui mettait en péril leur business models ancestraux.
Comment fonctionne Kubernetes ?
On reproche souvent aux articles génériques pro-Kubernetes d’empiler les mots clés vides de sens. Nous allons tâcher de ne pas reproduire ce schéma et expliquer concrètement les atouts techniques de la solution. Sans rentrer dans le détail de l’implémentation, nous allons voir quelques-uns des mécanismes clés d’un Cluster Kubernetes.
Imaginons une application simple : un serveur web qui reçoit une requète, lit une valeur dans une base de données puis répond au client HTTP. Imaginons maintenant que cette application soit cloisonnée dans un conteneur docker qui fonctionne sur une machine, virtuelle ou pas. Si cette machine venait à crasher, l’application ne répondrait plus. Cela lèverait probablement une alarme dans le système de monitoring de l’hébergeur de l’application. Ce dernier devra alors investiguer. Il devra probablement redémarrer la machine virtuelle et le conteneur. Il devra enfin tenter de comprendre post-mortem ce qui a pu se produire.
Kubernetes, mais ce n’est pas la seule solution à adopter cette philosophie, propose une approche différente. Il s’agit d’une approche déclarative, à opposer à l’ancestrale approche impérative. Dans l’univers Kubernetes (et de façon générale dans les environnements Cloud) on décrit l’état dans lequel doit se trouver la plateforme. A contrario, le modèle impératif impose d’opérer des changements de façon itérative. Il faut alors réajuster des paramètres de diverses natures en permanence. C’est peu ou prou le travail d’un administrateur système.
Pourquoi l’approche déclarative est-elle particulièrement séduisante ? Car le système est dès lors programmé pour trouver une solution afin de répondre aux exigences de la déclaration de la plateforme. Dans notre exemple précédent, le Cluster Kubernetes devra trouver le moyen de remettre notre application dans son état nominal. Par exemple, il démarrera, seul, le conteneur dans lequel s’exécutait le service web sur une autre ressource, physique ou virtuelle, qu’il est en mesure de piloter.
Les composantes de Kubernetes
Comme toujours en informatique, il n’y a pas de magie, la brique responsable de cette orchestration est composée d’une somme de logiciels qui forment le Kubernetes Master. Sans rentrer dans le détail de chacun de ses composants, retenez qu’un Master est composé d’un :
- Système de stockage clé / valeur (etcd)
- Serveur d’API qui recevra les instructions à passer au Cluster
- Controller Manager, qui maintient les ressources dans l’état souhaité
- Ordonnanceur ( scheduler ), qui démarrera les conteneurs sur les environnements matériels ou virtuels les plus adaptés à leurs besoins
Nous utilisons ici abusivement le terme de « conteneur ». Pour parvenir à un degré satisfaisant d’abstraction, Kubernetes introduit la notion de pod. Il s’agit d’un élément qui peut contenir un ou plusieurs conteneurs. Mais ce sucre technique va au-delà du périmètre de cet article.
En poussant le raisonnement, on en conclut que le Master est finalement l’administrateur système de notre plateforme. Le nouveau travail des OPs se convertit au déclaratif, modèle dont le chemin était pavé par des outils d’orchestration tels que Chef, Puppet, Ansible ou encore Salt, bien connu des équipes de NBS System.
Finalement, derrière ce Master, on trouvera des workers, ou plus simplement les noeuds / machines qui seront utilisés pour réellement faire fonctionner notre application de façon totalement contrôlée. C’est sur ces noeuds que seront lancés les conteneurs qui cloisonnent notre petit serveur web.
Suis-je concerné ?
Devant cette débauche de puissance, on est en droit de se demander si notre petite application est réellement une cible judicieuse. Et effectivement, s’il vous revenait la tâche de gérer ce fameux Cluster, l’effort serait totalement disproportionné. Mais fort heureusement, tous les fournisseurs de Cloud sont aujourd’hui munis de solutions de Clusters Kubernetes opérés pour vous. Ainsi, il ne vous incombe que la responsabilité de correctement déployer votre charge de travail sur l’environnement mis à votre disposition. Citons en particulier AWS EKS, Azure AKS ou encore, à tout seigneur tout honneur, Google Cloud GKE. Dans ces 3 offres, vous n’aurez aucunement à intervenir de quelque façon que ce soit sur le Master, car de toutes façons, cela vous est impossible.
Mais basculer votre environnement sur Kubernetes est-ce aussi simple ?
Comme nous l’avons exposé précédemment, le modèle K8s (c’est le petit nom de Kubernetes) est déclaratif; cela suppose une certaine habitude des outils modernes chers aux DevOps et également une bonne compréhension de l’abstraction de plateformes. Typiquement, des équipes ayant préalablement travaillé dans des environnements Cloud et en particulier avec des techniques comme l’auto-scaling ou encore les plateformes éphémères s’adapteront naturellement à la méthode Kubernetes.
Pour quels bénéfices ?
Les plus évidents et immédiats :
- Indépendance totale au regard de l’infrastructure
Votre hébergeur ne vous convient plus ? vous souhaitez voler de vos propres ailes ? La migration de votre application se fera de façon totalement standard.
- Uniformité des objets réseau
Conséquence du point précédent, la standardisation dont bénéficie Kubernetes vous permettra de mettre en place des mécanismes réseau avancés reproductibles, et transférables de votre environnement de développement à la plateforme de test, validation ou production sans modification.
- Meilleure résilience
Nous l’avons vu, le travail de maintien en condition de la plateforme est à la charge du Master. C’est lui qui va contrôler que cette dernière fonctionne comme prévu, aidé de multiples capacités de monitoring.
- Montée en charge transparente avec les mécanismes d’ autoscaling
- Intégration à de multiples solutions de métrologie
- Basé sur des standards connus
En effet, les équipes rompues à l’utilisation de docker trouveront dans Kubernetes une machine capable d’industrialiser leur travail en prenant la place de leurs anciens mécanismes articulés autour de docker-compose.
Par où commencer ?
L’approche la plus efficace et surtout paradoxalement la moins onéreuse consiste à se faire accompagner dans sa transformation. Car si les outils que nous venons d’exposer se prennent en main en quelques heures, leur intégration dans votre workflow demande connaissance et expertise pour ne pas tomber dans les pièges classiques que tend malgré lui ce type de plateformes.
De plus, monter un environnement Kubernetes sans prendre en compte les éléments de sécurité peut se révéler dangereux. Les bonnes pratiques et la connaissance des impératifs inhérentes à l’hébergement d’une application exposée sur Internet n’ont pas pris une ride : un processus n’est pas sûr parce qu’il est conteneurisé ! Il en va de même pour une infrastructure complète, fusse-t-elle abstraite.
Depuis plus de 20 ans, nos équipes ont évolué et se sont sans cesse renouvelées avec la technologie. Ce tournant qui s’amorce et s’annonce comme un bouleversement dans la façon de concevoir et administrer des plateformes, nous l’avons adopté, embrassé, et y avons apporté notre savoir-faire dans la construction d’environnements sécurisés. Nos équipes sont formées et disposent des connaissances et de l’expertise pour vous accompagner sur ces questions. N’hésitez pas à nous contacter. Nous pourrons vous donner plus d’informations sur le sujet ou pour vous aider à monter un environnement Kubernetes sécurisé !
