Blog technique
Moderator Moderator , Moderator Moderator Moderator
Blog technique
Kubernetes : le noyau des temps modernes
Dec 10, 2019

 

1Blog1.jpg

 

À la veille du KubeCon + CloudNativeCon North America 2019, nous consacrons une série d’articles aux sujets brûlants qui devraient y être abordés. Notre premier article invite le lecteur à retracer le parcours d'une application monolithique vers une architecture de microservices. Nous y évoquons les avantages des microservices en matière de vitesse et d’évolutivité, avec Kubernetes pour orchestrer l’ensemble.

 

Pour beaucoup, Kubernetes peut apparaître comme la nouvelle panacée, au même titre que le SDN, incarnée par notre célèbre JKitty, petit chaton-licorne arc-en-ciel aux ailes de papillon. L’effet papillon, vous connaissez ? Un simple battement d’ailes du chaton Kubernetes, et c’est la tempête. C'est vrai, Kubernetes fait souffler un vent de nouveauté. Mais question simplicité, on est encore loin du compte. À l'heure où les entreprises migrent vers des architectures de microservices, Kubernetes peut engendrer autant de problèmes qu’il n'en résout.

 

Lorsqu’on décompose une application en microservices, les maîtres-mots sont sécurité et réseau. Pourquoi réseau ? Parce que c'est lui qui permet aux microservices de communiquer entre eux pour former une application fonctionnelle. Une seule erreur et c’est une véritable tempête qui se déchaîne.

 

Juniper va donc profiter de sa présence au KubeCon pour présenter ses solutions dans des domaines qui ont fait sa réputation : le réseau et la sécurité à grande échelle.

 

Et le hasard fait parfois bien les choses puisque ces solutions viennent à bout des problèmes créés par Kubernetes. Examinons de plus près certains d'entre eux.

 

Microservices et Kubernetes : des opportunités, mais aussi des défis


Dès lors qu'elle est bien conçue, une application à base de microservices ne devrait pas pâtir de la perte d’un container ou d'un nœud de serveur. Tant que la plateforme d’orchestration prévoit suffisamment d’instances actives, l'application doit pouvoir répondre à la demande. Après tout, les applications en microservices sont conçues pour ajouter et supprimer des instances de services individuelles selon les besoins.

 

Une orchestration évolutive et tolérante aux pannes, voilà exactement ce que propose Kubernetes avec de nombreuses fonctionnalités de paramétrage supplémentaires basées sur des contraintes. C’est pour cette raison que l’on compare souvent Kubernetes à un noyau de système d’exploitation pour le cloud. Il s’agit à bien des égards d’un puissant planificateur de processus pour un cluster d’applications distribuées en microservices. Mais pour qu’une application fonctionne correctement, un simple noyau ne suffit pas.

 

Fidèle à notre devise "Engineering Simplicity", nous nous sommes fixés pour mission de régler les problèmes de stockage, de sécurité, de réseau et de surveillance. Si l’on en croit notre propre expérience et celle de nos clients, mieux vaut mener tous ces combats de front si l'on gère soi-même sa propre plateforme Kubernetes.

 

Un des moyens de régler les problèmes, c'est parfois de les externaliser. Kubernetes-as-a-Service a l’avantage d’être simple, mais pèche aussi par son coût et ses lacunes dans l’uniformité et la portabilité multicloud. Pour la plupart des entreprises, impossible donc d’échapper à Kubernetes et ses clusters... mais Juniper est là pour les aider.

 

Face aux difficultés, repoussez vos limites

 

Pour se faciliter la tâche, certains opérateurs Kubernetes limitent la taille des clusters.

 

Qui dit clusters plus petits, dit effet de souffle (blast radius) limité en termes de fiabilité et de sécurité. Côté surveillance, stockage et réseau, ces mini-clusters paraissent plus faciles à gérer qu’un gros cluster partagé. Dans certains cas, chaque équipe applicative déploie son propre cluster. Dans d’autres, chaque phase du cycle de développement (développement, test, préproduction et production) a son propre cluster Kubernetes. Quoi qu'il en soit, beaucoup d'opérateurs Kubernetes déploient des clusters peu volumineux, composés de dix à vingt nœuds et de quelques applications. Pourtant, Kubernetes peut supporter des clusters plus larges, beaucoup plus larges.

 

La création d'une multitude de petits clusters peut mener à une véritable prolifération, le fameux "Kube sprawl".

 

Malgré certains avantages, le foisonnement de mini-clusters ne fait que contourner les difficultés, et peut rapidement engendrer de nouvelles problématiques. Il faut jongler entre plusieurs versions de Kubernetes, gérer les mises à niveau et les correctifs, sans parler des techniciens informatiques à mobiliser. À moins d’automatiser soi-même le processus, mais cela représente une autre tâche considérable.

 

Une perte d’efficacité paraît en outre évidente, dans la mesure où chaque nœud de serveur ou VM n’appartient qu’à un seul cluster Kubernetes. L’utilisation d’un cluster partagé plus large serait plus efficace. Une plus grande variété d'applications, d'équipes, de batchs et de pics d’utilisation optimise l'utilisation des ressources et génère des économies d’échelle.

 

Si un petit cluster exécute quelques applications seulement, elles ne seront pas suffisamment variées pour pouvoir utiliser l’ensemble du pool de ressources de manière constante, d'où certains gaspillage. Les opérateurs peuvent tenter de jouer sur l'élasticité du nombre de nœuds de cluster comme sur celle des applications containerisées, mais l’orchestration sera difficile à déployer et automatiser du fait des exigences très spécifiques des applications au sein de chaque petit cluster. Sachant que chaque cluster Kubernetes nécessite au moins trois nœuds de serveur pour assurer une haute disponibilité, le niveau de gaspillage est proportionnel au nombre de clusters maintenus.

 

Pour les développeurs, la surabondance de clusters pose également problème. Des outils cloud existent, tels que le traçage de microservices, mais il s'agit généralement de solutions intra- et non inter-clusters. D'autres outils, notamment le maillage de services (service mesh), peuvent s’avérer plus complexes lorsque fédérés sur plusieurs clusters.

 

Tout comme les applications, l’infrastructure cloud-native doit s'étendre aux Edge Clouds et au multicloud

 

Quand il s’agit de gérer un seul cluster de serveurs avec leurs containers, Kubernetes fait très bien le job. Là où les choses se compliquent, c'est lorsque des applications doivent s’exécuter sur plusieurs clusters pour couvrir plusieurs domaines d’erreur ou zones de disponibilité. On ne parle pas ici de déployer plusieurs petits clusters au sein de la zone de disponibilité d'un même datacenter, mais sur plusieurs datacenters pour gagner en disponibilité et en couverture, tout en réduisant la latence côté utilisateur.

 

Résoudre les problématiques de sécurité, de réseau, de surveillance et de stockage pour chaque cluster est un bon début. Mais des solutions plus puissantes doivent être mises en œuvre pour parvenir à fédérer plusieurs clusters sur plusieurs zones de disponibilité, régions, Edge Clouds et environnements multicloud. Là encore, Juniper a de quoi illustrer ses capacités en la matière lors de KubeCon.

 

La sécurité et le réseau deviennent plus complexes dans ce scénario, car ils jouent un rôle bien plus important dans une architecture applicative globalement distribuée. Le réseau doit relier à la fois les microservices et les environnements multicloud. Côté sécurité, la défense en profondeur (DiD, Defense in Depth) de chaque cluster doit s'accompagner d'une défense en largeur (DiB, Defense in Breadth) pour une application uniforme des politiques sur tous les clusters.

 

On ne peut pas toujours faire table rase de l'existant

 

Dans le monde réel de l’entreprise, certains services utilisés par des applications cloud-native s’exécutent sur un mainframe, alors que d'autres s’apparentent davantage à de vrais microservices. Comment les entreprises peuvent-elles fournir une infrastructure software-defined sécurisée, performante et évolutive quand une application est composée de services si radicalement différents, exécutés sur des infrastructures si variées, ces dernières étant la plupart du temps hébergées chez des fournisseurs cloud situés aux quatre coins du globe ?

 

Là encore, gérer la sécurité, le réseau, la surveillance et le stockage pour Kubernetes est une bonne chose. Mais qu’en est-il de la gestion de l'existant sur les VM et les serveurs physiques ? Les outils dernier cri conçus pour Kubernetes s'arrêtent à Kubernetes. Mais les applications et les opérations IT, elles, dépassent largement le périmètre de Kubernetes. De même, un énième outil à déployer et prendre en main ne fait que surcharger les équipes opérationnelles au lieu de les soulager. Les outils et technologies modernes doivent résoudre les nouvelles problématiques liées au cloud. Mais seuls les meilleurs outils pourront résoudre le problème le plus ardu du moment : la simplicité opérationnelle. Cela ne sera possible qu’en conciliant le nouveau et l'ancien, tout en prévoyant une certaine évolutivité à terme.

 

Des solutions pour simplifier les opérations

 

À présent, vous devinez certainement de quoi traitera notre prochain article. Depuis longtemps, Juniper excelle dans le développement de systèmes évolutifs et ultra-performants.

 

Ne manquez pas notre prochain article pour découvrir comment Juniper fait désormais rimer Kubernetes et simplicité opérationnelle. Pour en savoir plus sur les solutions cloud-native de Juniper, visitez la page juniper.net/cloud-native

0 Compliments
Feedback