Article écrit par Jean-Philippe Gouigoux, Kévin Lenglet et Yannig Perre initalement publié sur la newsletter Ctrl Tech : S’abonner sur LinkedIn

Un des inconvénients d’écrire un livre technique sur un sujet précis est que les auteurs sont alors immédiatement catalogués comme aficionados de cette technologie. Si l’auteur est également décideur dans une entreprise (tech lead, architecte, directeur technique), il n’est pas rare que ses équipes ressentent une pression pour mettre en œuvre le type de solution étudié. Pourtant, une technologie ne reste qu’un outil, utile dans certaines situations et potentiellement surdimensionné dans d’autres contextes.

À l’occasion de la sortie du coffret « Docker et Kubernetes », il nous a semblé utile de rappeler que Kubernetes n’échappe pas à cette règle et, malgré qu’il ait souvent été présenté comme l’orchestrateur qui a dépassé toute concurrence, cela ne veut pas dire qu’il couvre idéalement tous les cas d’usage.

Dimensionnement de l’infrastructure

La taille de l’infrastructure est le tout premier critère de choix du mécanisme d’orchestration, en lien avec le nombre de machines nécessaires pour supporter la totalité des conteneurs qui devront être démarrés au maximum de la charge. Le schéma suivant montre l’évolution possible des infrastructures à mettre en œuvre en fonction de la charge, ainsi que le coût estimatif associé aux différentes approches :

Au commencement, une simple augmentation des ressources de la machine hôte (② à ④) suffira lorsque les ressources initialement allouées en ① ne suffisent plus (②).

À un moment donné, il deviendra difficile ou trop coûteux de passer à un serveur plus puissant, et la solution logique sera de commencer à mettre en œuvre une scalabilité horizontale, en augmentant le nombre de serveurs.

En ⑤, on opère une répartition manuelle des conteneurs, c’est-à-dire qu’on coupe le système applicatif en deux en gérant chaque portion indépendamment : un service est fourni par une machine donnée, charge à l’administrateur de savoir laquelle.

En ⑥, les besoins deviennent tellement forts qu’on est obligé de mettre en place un répartiteur de charge, certains services étant rendus par plusieurs machines. La charge continue d’augmenter jusqu’en ⑦, où il faudra opérer une autre bascule de mécanisme d’infrastructure.

En ⑧ / ⑨, les besoins sont tels qu’il n’est plus envisageable de gérer machine par machine une répartition des conteneurs. Il devient nécessaire de découpler complètement la partie infrastructure de la gestion applicative qui s’appuie dessus. Les métiers sont alors séparés entre des administrateurs de ressources qui fournissent des nœuds au cluster, et des administrateurs logiciels qui utilisent ce cluster pour répartir des charges de travail. C’est ce modèle sophistiqué que Kubernetes met en œuvre.

Ce que nous observons

En tant que professionnels utilisant Kubernetes en production depuis ses premières versions, nous avons tous les trois observé la montée en puissance de cet orchestrateur et, il y a quelques années, sa « victoire » sur les autres orchestrateurs. Il est devenu incontestable, lorsque Docker Incorporated a annoncé son support, que Docker Swarm et les autres orchestrateurs avaient « perdu la bataille » et nombre d’articles sur internet ont constaté cet état de fait.

Bien que ceci soit pleinement justifié par la qualité du produit (nous n’écririons pas sur une technologie qui ne nous paraitrait pas pleinement fonctionnelle), nous notons le fait qu’énormément d’entreprises sautent directement le pas vers un orchestrateur complexe comme Kubernetes dès les étapes ⑤ ou ⑥ de la montée en charge, voire même dès l’étape ①, en prévision d’une augmentation de la complexité. Ceci peut avoir plusieurs causes, que nous avons observées dans différents contextes industriels :

• Une entreprise dans laquelle travaille l’un d’entre nous a une forte tradition d’innovation et de maitrise complète des technologies. Démarrer du Kubernetes en production à la fin des années 2010 était certes un pas complexe, et qui a coûté cher en formation et mise en œuvre, mais qui se révèle un choix judicieux au regard de la forte montée en puissance de l’infrastructure qui a suivi.
• Une autre entreprise, conseillée par un second auteur sur son architecture de Système d’Information, a souhaité – malgré les conseils fournis – gérer en interne un orchestrateur Kubernetes alors que des solutions gérées existaient. Après un peu plus d’un an et malgré la présence d’un Équivalent Temps Plein sur le sujet, il s’est avéré que la tâche était trop complexe et le cluster a été abandonné au profit d’un Azure Kubernetes Service.
• Armé de cette expérience, le même auteur, quelques années plus tard, devait placer sous Tierce Maintenance Applicative une solution web dont la montée en charge était limitée. Une solution légère a donc été demandée, utilisant simplement Docker Swarm. Le fournisseur a préféré fournir une solution plus complexe, à savoir Kubernetes, quitte à sacrifier une partie de sa marge financière, pour des raisons de pur affichage : proposer une offre d’orchestrateur géré qui ne serait pas basée sur Kubernetes n’aurait tout simplement pas fait sérieux pour les autres clients à venir !

D’une certaine manière, Kubernetes a démontré de manière tellement étincelante son adéquation aux grosses infrastructures complexes qu’il est considéré comme la solution pour tous les cas, y compris les plus simples. Dans cet article, nous souhaitons – bien que pleinement convaincus de la qualité de la solution – retracer les bonnes conditions de son utilisation.

Quand utiliser Docker seul ?

Si votre solution logicielle ne comporte que quelques services et peut être répartie sur deux ou trois serveurs, la simple mise en œuvre de services suffit amplement. En production, il y a peu d’avantages à déployer la base de données dans un conteneur Docker.

Pour ce qui est des serveurs web, le téléchargement d’une SPA utilise tellement peu de ressources qu’une exposition sur une seule machine suffira largement. Et pour les serveurs applicatifs sur lesquels une montée en charge peut le justifier, un simple passage à l’échelle pour lancer plusieurs conteneurs sur un hôte suffira éventuellement.

Tout ceci peut être mis en œuvre simplement en utilisant la notion de service Docker, que vous pouvez créer simplement grâce à la commande docker service create ou bien en utilisant une définition dans Docker Compose. Et la commande scale vous donnera dans un premier temps la possibilité d’augmenter le nombre de conteneurs Docker en réponse aux sollicitations.

Imaginons maintenant que cette mise à l’échelle ne suffise pas et que vous ayez besoin que le serveur applicatif soit déployé sur deux machines hôtes : un simple répartiteur de charge en amont et le lancement de deux services mis à l’échelle sur les deux machines peut, là encore, être tout à fait adapté. Après tout, toutes les infrastructures ne varient pas fortement. Nous connaissons ainsi une entreprise avec un site connaissant un pic saisonnier fort et qui rajoute simplement des machines quinze jours avant l’évènement anticipé, puis les recycle après ledit évènement, avec une économie intéressante par rapport à une élasticité automatique.

En termes de robustesse, la gestion des services Docker incorpore déjà le redémarrage automatique, ainsi que la mise à jour progressive. Ainsi, si un conteneur tombe, il sera remplacé par un autre pour respecter la mise à l’échelle attendue. Le tout en gérant l’occupation des conteneurs par une requête, la centralisation des logs, la parallélisation d’une mise à jour de l’image, etc. Bref, une sophistication déjà très importante et utile.

Quand mettre en œuvre Docker Swarm ?

Docker Swarm est clairement la victime du succès de Kubernetes, alors que les deux ne boxaient pourtant pas dans la même catégorie. Comme expliqué plus haut, la victoire de Kubernetes dans la catégorie poids lourds a, d’une certaine manière, fait penser qu’il devenait naturellement le champion des poids légers. C’est certainement vrai dans le sens où Kubernetes a l’avantage sur Docker Swarm en termes de fonctionnalités, de puissance, etc. mais nous pensons que Docker Swarm conserve un avantage sur des petits déploiements, en raison de son incroyable simplicité de mise en œuvre.

L’estimation fournie plus haut sur le personnel nécessaire pour gérer une instance Kubernetes est confirmée par plusieurs autres entreprises: un Équivalent Temps Plein est indispensable pour établir, maintenir et surveiller un cluster Kubernetes.

Mettons face à cela les manipulations nécessaires pour mettre en œuvre un Docker Swarm :

1. S’assurer que les machines hôtes puissent échanger sur les ports 2376 / 2377 (c’est en général déjà le cas, car elles seront dans 99% des cas sur le même réseau).
2. Lancer la commande docker swarm init sur la machine élue comme manager par défaut.
3. Lancer la commande docker swarm join sur les autres machines.

C’est tout ! Votre cluster Docker Swarm est prêt, et il vous permet de gérer vos services Docker sans n’avoir plus à connaitre les machines sous-jacentes, déplacer des conteneurs sur telle ou telle machine moins utilisée, changer la répartition en risquant des interruptions de service, gérer la répartition de charge par vous-même.

En mode Docker Swarm, les échanges entre les démons se chargent de toute la gestion du cluster : si un nœud disparaît, les autres se débrouillent sans lui, y compris s’il y a besoin d’élire un autre manager pour que le cluster continue à fonctionner. Quant aux services que vous aurez créés avec Docker Compose, ils continuent à fonctionner, mais sur une base beaucoup plus simple, en ayant à leur disposition ce qui apparait comme un seul et même serveur Docker avec toutes les ressources des nœuds sous-jacents.

La répartition des conteneurs sur les différentes machines est ainsi complètement automatique (avec support des préférences de placement, ce qui permet déjà de belles optimisations), ainsi que la mise à l’échelle avec adoption immédiate par le répartiteur de charges intégré. La mise à jour progressive reste toujours de mise, mais elle s’étend alors à la totalité du cluster, ainsi que les capacités de retour en arrière en cas de problème. Bref, avec un coût très modéré, on accède déjà à la grande majorité des fonctionnalités dont ont besoin les administrateurs d’application en mode conteneurs.

Quand adopter Kubernetes ?

Bien sûr, Kubernetes apporte de nombreuses fonctionnalités supplémentaires, mais tout l’argument du présent article est d’essayer de définir clairement le moment où mettre en œuvre un cluster Kubernetes – avec toute la complexité associée – est réellement nécessaire. Nous insisterons donc sur les fonctionnalités qui sont l’apanage de Kubernetes et qui sont des marqueurs différenciants par rapport aux autres approches :

• Kubernetes apporte la notion de pod, qui est un niveau d’indirection supérieur au simple conteneur Docker. Il permet ainsi d’embarquer plusieurs conteneurs dans une même unité de passage à l’échelle. Bien qu’également possible simplement avec Docker, il est beaucoup plus simple de mettre en œuvre une approche de type « Sidecar » avec Kubernetes, chaque conteneur étant alors accompagné d’un conteneur satellite pour des fonctions secondaires (monitoring, typiquement), dans son propre hôte conteneurisé.
• Kubernetes supporte la notion de conteneur étendu et peut fonctionner avec n’importe quel moteur compatible OCI. Le support de CRI-O permet également d’aller plus loin dans les changements de runtime. Enfin, WASM commence à être supporté dans Kubernetes, ce qui va amener à des changements assez radicaux dans la chaîne de développement / intégration / déploiement.
• L’écosystème Kubernetes fournit de nombreux outils comme Helm ou les Actors qui dépassent ce qu’il est possible de faire en termes de composition d’application avec Docker Compose, en incorporant une variabilisation plus forte et un support plus structuré des formats.
• Kubernetes fournit un mécanisme d’Ingress, mais aussi de support du stockage ou de support du réseau, bien plus sophistiqué que celui trouvé dans Docker Swarm. Il est ainsi possible d’adapter plus fortement ces fonctionnalités, voire même de changer leur implémentation par des versions sur mesure pour les cas les plus avancés.

Si l’un de ces points est une contrainte pour vous, ou si vos déploiements se comptent en milliers de conteneurs, alors Kubernetes sera effectivement un incontournable pour vous. Mais, encore une fois, ceci se fera avec un coût d’exploitation élevé. Mettre en place un cluster Kubernetes est complexe, le maintenir et le superviser l’est encore plus… et réparer un cluster Kubernetes en production, dans les – très – rares cas où il tombe est un cauchemar d’administrateur. Par contre, toutes les fonctionnalités citées, disponibles sur étagère et surtout avec un mécanisme de package très mature font qu’à un moment donné, le gain en intégration dépasse le surcoût de mise en œuvre d’une infrastructure Kubernetes.

Kubernetes As A Service

Serait-il possible d’avoir le beurre (la sophistication de Kubernetes) et l’argent du beurre (ne pas avoir à payer le coût de gestion) ? Bien sûr, et c’est tout l’intérêt du mode « as a service », quelle que soit la fonctionnalité que vous placiez avant ce terme magique ! Le mode « as a service » vous permet, moyennement le paiement d’une gestion réalisée par un tiers, de bénéficier des fonctionnalités fournies par une ressource sans avoir à gérer celle-ci.

Le choix d’une approche Kubernetes As A Service est d’autant plus logique que les solutions foisonnent (Azure Kubernetes Service, Amazon Elastic Kubernetes, Google Kubernetes Engine et OVH etc.), sont extrêmement simples d’accès et imbattables sur l’aspectapport / coût de gestion, de par la parallélisation massive du service dans les clouds.

Ceci pourrait vous pousser à sauter le pas directement pour du Kubernetes. Mais, encore une fois, n’oubliez pas que des approches intermédiaires et plus légères peuvent être mieux adaptées. Même si la gestion du cluster est réalisée par un tiers, il reste plus complexe de déployer une application basée sur des conteneurs Docker dans Kubernetes que sur un Docker Swarm (et a fortiori sur un simple démon Docker si cela vous suffit). De plus, faire ainsi ne vous prive pas d’une opportunité future de passer à Kubernetes. En effet, les images Docker resteront absolument les mêmes ; c’est d’ailleurs tout l’intérêt de Docker de permettre des « boîtes noires » applicatives. Et le peu de travail nécessaire à la migration consistera à transformer les définitions Docker Compose en fichiers YAML ou Helm, ce qui est très aisé.

Si vous êtes un concepteur d’infrastructure, c’est cette notion de mutualisation qui sera l’enjeu majeur d’efficacité du choix Kubernetes. Héberger un certain nombre d’applications sur une même infrastructure en permettant de les cloisonner, de les sécuriser les unes indépendamment des autres et de leur donner des propriétés différentes (en termes de déploiement et de disponibilité) permet de partager les coûts d’infrastructure sur de nombreuses applications et – in fine – de réduire la facture pour les clients consommateurs de ces applications ou d’augmenter vos gains en tant que fournisseur, au prix il est vrai d’une augmentation de la complexité d’exploitation et potentiellement aussi de la surface d’attaque.

En conclusion, n’oubliez pas d’utiliser toujours l’outil le plus adapté pour l’usage. Ce qui est vrai pour les langages de programmation l’est également pour les orchestrateurs. Et même si une visseuse peut enfoncer une petite vis, un simple tournevis vous coûtera moins cher, vous laissera plus en contrôle du serrage et vous évitera de casser du bois…

Si vous voulez en savoir plus sur le sujet et profiter de l’expertise de nos auteurs sur la conteneurisation, lecoffret « Docker et Kubernetes – Maîtrisez le déploiement d’applications conteneurisées »qui réunit les ouvrages de nos trois experts est un indispensable tout comme le tout dernier livre de Jean-Philippe Gouigoux et Kévin Lenglet “Kubernetes – Mise en œuvre d’un cluster et déploiement de microservices” ! Vous pourrez bien sûr également les retrouver dans la plus grande Bibliothèque numérique IT, pour les particuliers comme pour les professionnels.

Livre

Docker
Concepts fondamentaux et déploiement d’applications conçues en services