Comment exploiter la puissance de Kubernetes pour optimiser vos coûts d'hébergement

Au cours des dernières années, l’industrie a évolué vers le développement d’applications plus petites et plus ciblées.

Il n’est pas surprenant que de plus en plus d’entreprises divisent leurs monolithes massifs et statiques en un ensemble de composants découplés et indépendants.

Et à juste titre.

Les services qui sont de petite taille sont:

  • plus rapide à déployer - parce que vous les créez et les publiez par petits morceaux
  • plus facile à parcourir - puisque l'ajout de fonctionnalités se fait indépendamment
  • résiliente - le service global peut toujours fonctionner même si l'un des composants n'est pas disponible

Les petits services sont excellents du point de vue des produits et du développement.

Mais comment ce changement culturel a-t-il un impact sur l'infrastructure?

Gestion des infrastructures à grande échelle

Il s'avère que les choses sont plutôt simples lorsque vous traitez avec quelques applications éparses.

Vous pouvez les compter avec vos mains et vous avez tout le temps nécessaire pour soutenir et libérer.

Dans une grande entreprise, la gestion de centaines d’applications est une tâche difficile mais qui reste réalisable. Vous avez plusieurs équipes dédiées au développement, à l’emballage et à la publication d’applications.

Le développement de services à partir de composants plus petits, en revanche, introduit un défi différent.

Lorsque, pour chaque application, vous pouvez reformer les mêmes applications dans un ensemble de quatre composants, vous avez au moins quatre fois plus d'applications à développer, à emballer et à publier.

Il n’est pas rare qu’un petit service soit constitué d’une douzaine de composants, tels qu’une application frontale, une API back-end, un serveur d’autorisation, une application admin, etc.

En effet, lorsque vous développez des services qui interagissent les uns avec les autres, vous assistez à une explosion de composants déployés sur votre infrastructure.

Cela devient plus difficile, cependant.

Vous gaspillez probablement votre argent en ressources informatiques

La plupart des services sont déployés sur des machines virtuelles telles que Amazon EC2, Digital Ocean Droplets ou Azure Virtual Machines.

Chaque machine virtuelle est livrée avec un système d’exploitation qui utilise une partie de la mémoire et des ressources de l’UC qui lui sont allouées.

Lorsque vous créez un droplet de 1 Go de mémoire et 1 gouttelette de vCPU sur Digital Ocean, vous vous retrouvez avec 700 Mo en mémoire et 0,8 vCPU après la suppression de la surcharge du système d'exploitation.

Ou, en d'autres termes, pour chaque cinquième machine virtuelle, la surcharge s'ajoute à une machine virtuelle complète.

Vous payez pour cinq mais vous ne pouvez en utiliser que quatre.

Vous ne pouvez pas y échapper, même si vous êtes sur du métal nu.

Vous devez toujours exécuter vos services à partir d'un système d'exploitation de base.

C’est bien, tout le monde doit utiliser un système d’exploitation - vous dites.

Et tu as raison.

Cependant, l'argent gaspillé sur les systèmes d'exploitation n'est que la partie visible de l'iceberg.

Vous gaspillez aussi BEAUCOUP d’argent dans l’utilisation des ressources

Vous vous êtes probablement rendu compte que lorsque vous divisez vos services en plusieurs composants plus petits, chacun d’eux nécessite des ressources différentes.

Certains composants, tels que les applications de traitement et d’exploration de données, utilisent beaucoup le processeur. D'autres, tels que les serveurs pour applications en temps réel, peuvent utiliser plus de mémoire que le processeur.

Amazon Web Services et les autres fournisseurs de cloud disposent en effet d’une longue liste de ressources de calcul qui répondent à tous les besoins: utilisation générale, optimisation de l’UC, optimisation de la mémoire, optimisation du stockage et calcul sur GPU.

Vous devez vous efforcer d'utiliser la bonne machine virtuelle pour votre composant. Idéalement, il devrait correspondre à la consommation de mémoire et à l'utilisation du processeur.

Travaillez-vous sur un composant Web critique écrit en Java?

Peut-être devriez-vous utiliser un c5.4xlarge optimisé pour les charges de travail intensives en calculs.

Plus vous répondez aux exigences, mieux vous utilisez vos ressources.

En pratique, cela reste cependant peu commun.

Devez-vous utiliser un c5.2xlarge ou un c5.4xlarge?

Le niveau suivant (8 vCPU et 16 Go de mémoire) fait-il une différence?

Il est beaucoup plus facile de sélectionner deux profils informatiques suffisamment performants dans 80% des cas et de les utiliser pour tous les composants.

En fait, qu’est-ce qui ne va pas avec l’utilisation de la même machine virtuelle pour chaque charge de travail?

Rien du tout, si vous êtes heureux d’envelopper chaque composant dans une mémoire de 2 Go et une capacité de calcul vCPU.

Même si votre composant ne peut fonctionner qu'avec 1 Go de mémoire.

Oui, vous pourriez optimiser dans le futur.

Mais soyons honnêtes: c’est comme changer de pneus en conduisant.

Vous avez déployé beaucoup d'efforts pour régler le système, mais vous vous êtes rendu compte que l'application avait encore changé et que vous deviez recommencer à zéro.

Vous finissez donc par prendre le seul choix judicieux: sélectionner un profil de taille petite, moyenne et grande pour les machines virtuelles et les utiliser pour toutes les charges de travail.

Vous savez que vous devez vivre avec le gaspillage de centaines de mégaoctets de RAM et de nombreux cycles de processeur.

Si cela vous aide à vous sentir mieux, de nombreuses entreprises souffrent de la même inefficacité.

Certains utilisent à peine 10% des ressources allouées.

Vous payez 1 000 USD en instances EC2 sur Amazon, vous n'en utilisez que 100 USD.

Cela ne semble pas être la meilleure façon de dépenser votre budget.

Vous devriez récupérer votre argent sur les ressources que vous n’utilisez pas.

Mais pourquoi ces exigences sont-elles si différentes?!

Choisir le bon outil fait plus de mal que de bien

Lorsque les développeurs ont la liberté d'utiliser le bon outil pour le travail, ils se déchaînent.

Node.js pour le serveur frontal, Spring Boot pour l'API backend, Flask et Celery pour le traitement des travaux en arrière-plan, React.js pour le côté client, vous l'appelez.

L'infrastructure devient un parc à thème, des centaines d'applications s'exécutant à des exécutions totalement différentes.

Disposer de la technologie adaptée à la tâche permet une plus grande vitesse d'itération, mais elle s'accompagne généralement de la charge supplémentaire que représente la gestion d'un autre langage de programmation.

Vous pouvez limiter la prolifération des outils et des langages, mais dans la pratique, c’est plus compliqué que cela.

Deux applications partageant le même environnement d'exécution JVM peuvent s'appuyer sur un ensemble différent de dépendances et de bibliothèques.

On peut peut-être compter sur ImageMagick pour redimensionner les images.

L'autre repose sur un binaire tel que PhantomJS ou ZeroMQ pour être disponible sur son chemin.

Vous devriez conditionner ces dépendances avec son application.

Vous vous retrouvez ainsi avec des dizaines de configurations identiques, mais différentes à leur manière.

Vous ne devez pas traiter l’infrastructure après coup. Vous devez vous occuper de vos dépendances et les empaqueter au fur et à mesure que vous développez l'application, dès le début.

Idéalement, vous devez archiver toutes les pièces nécessaires à l’exécution de votre composant sous la forme d’un ensemble.

Plus besoin de se perdre dans la chasse aux dépendances juste avant une publication.

Oui, plus facile à dire qu'à faire.

Ou peut être pas.

Emprunt de conteneurs de l'industrie du transport maritime

Les technologies de l'information ne sont pas le seul secteur confronté au même problème.

Il est difficile d’envoyer des marchandises dans le monde entier lorsque vous devez stocker des articles individuellement.

Imaginez avoir des milliers de boîtes de toutes formes et tailles à stocker dans la cale. Vous devez porter une attention particulière à la manière dont vous emballez les articles, car vous ne voulez pas en manquer un au moment du déchargement.

L'industrie du fret a proposé une solution: les conteneurs.

La compagnie de fret ne transporte pas de marchandises; il expédie des conteneurs.

Voulez-vous expédier tous vos biens en toute sécurité? Placez-les dans un récipient. Lorsque le conteneur est déchargé, vous êtes assuré d’avoir tout.

Vous pouvez appliquer le même principe à vos applications.

Voulez-vous déployer votre application et toutes ses dépendances en toute sécurité?

Enveloppez-les dans un conteneur Linux.

Un conteneur Linux est comme un conteneur de fret, mais il encapsule tous les fichiers, fichiers binaires et bibliothèques nécessaires à l'exécution de votre processus.

Cela ne ressemble-t-il pas beaucoup à des machines virtuelles?

Machines virtuelles au régime

En effet, si vous plissez les yeux et regardez de loin les machines virtuelles, elles ressemblent à des conteneurs.

Ils encapsulent l'application et ses dépendances comme des conteneurs.

Cependant, les machines virtuelles sont lentes à démarrer, généralement plus grandes et - comme vous l’avez appris - un gaspillage de ressources.

En fait, vous devez allouer un nombre fixe de processeurs et de mémoire pour exécuter votre application.

Ils doivent également émuler le matériel et sont livrés avec le bagage supplémentaire d’un système d’exploitation.

Les conteneurs Linux, en revanche, ne sont que des processus en cours d'exécution sur votre hôte.

En effet, pour le même système d'exploitation et le même serveur, des dizaines de conteneurs pourraient s'exécuter sur cet hôte.

Et bien qu’ils vivent sur le même ordinateur, les processus exécutés dans des conteneurs ne peuvent pas se voir.

Les applications exécutées dans des conteneurs sont entièrement isolées et ne peuvent pas faire la différence entre une machine virtuelle et un conteneur.

Ce sont de bonnes nouvelles!

Les conteneurs Linux sont comme des machines virtuelles, mais plus efficaces.

Mais de quoi sont faits ces conteneurs Linux?

Les conteneurs Linux sont des processus isolés avec des avantages

La magie des conteneurs provient de deux fonctionnalités du noyau Linux: les groupes de contrôle et les espaces de noms.

Les groupes de contrôle constituent un moyen pratique de limiter le processeur ou la mémoire qu'un processus particulier peut utiliser.

Par exemple, vous pouvez dire que votre composant ne doit utiliser que 2 Go de mémoire et l’un de vos quatre cœurs de processeur.

Les espaces de noms, en revanche, sont chargés d’isoler le processus et de limiter ce qu’il peut voir.

Le composant ne peut voir que les paquets réseau qui lui sont directement liés. Il ne sera pas en mesure de voir tous les paquets réseau transitant par la carte réseau. Les groupes de contrôle et les espaces de noms sont des primitives de bas niveau.

Avec le temps, les développeurs ont créé de plus en plus de couches d'abstractions pour faciliter le contrôle de ces fonctionnalités du noyau.

LXC a été l'une des premières abstractions, mais le véritable contrat a été Docker, sorti en 2013.

Docker non seulement résume les caractéristiques du noyau ci-dessus, mais il est agréable de travailler avec.

L'exécution d'un conteneur Docker est aussi simple que:

docker run 

Et comme tous les conteneurs implémentent une interface standard, vous pouvez exécuter n'importe quel autre conteneur avec la même commande:

docker run mysql

Et vous avez une base de données MySQL.

La portabilité de l'application et une interface standard pour la création et l'exécution de processus sont ce qui rend les conteneurs si populaires.

Les conteneurs sont super!

  • Vous avez économisé de l'argent sur l'exécution de dizaines de systèmes d'exploitation
  • Vous avez emballé des applications sous forme d'unités portables
  • Vous avez une prolifération de conteneurs

On dirait que les conteneurs n’ont pas résolu tous les problèmes après tout.

Vous avez besoin d'un moyen de gérer les conteneurs.

Gérer les conteneurs à l'échelle

Lorsque vous avez des centaines, voire des milliers de conteneurs, vous devez trouver un moyen d’exécuter plusieurs conteneurs sur le même serveur. Et vous devez également planifier la répartition des conteneurs sur plusieurs serveurs.

Ainsi, vous pouvez répartir la charge sur plusieurs nœuds et empêcher qu’une seule défaillance ne compromette l’ensemble du service.

Garder une trace de l’emplacement de chaque conteneur dans votre infrastructure ne semble pas être la meilleure utilisation de votre temps.

Peut-être qu’il ya un moyen de l’automatiser?

Et si vous pouviez avoir un algorithme décidant où placer également ces conteneurs?

Peut-être serait-il si judicieux d’emballer efficacement les conteneurs afin de maximiser la densité du serveur. Peut-être même garder une liste des conteneurs déployés et de leur hôte.

Il s'avère que quelqu'un a eu précisément cette idée et a proposé une solution.

Kubernetes, le puissant orchestrateur de conteneurs

Kubernetes était à l'origine une création de Google.

Google utilisait une technologie similaire aux conteneurs et devait trouver un moyen efficace de planifier les charges de travail.

Ils ne voulaient pas conserver et mettre à jour manuellement une longue liste de conteneurs et de serveurs. Ils ont donc décidé d'écrire une plate-forme capable d'analyser automatiquement l'utilisation des ressources, de planifier et de déployer des conteneurs.

Mais c'était source fermée.

Quelques Googlers ont décidé de réécrire la plate-forme en tant qu'effort open source. Et le reste est de l'histoire.

Alors, quel est Kubernetes?

Vous pouvez considérer Kubernetes comme un planificateur.

Kubernetes inspecte votre infrastructure (nu-metal ou cloud, public ou privé) et mesure le processeur et la mémoire de chaque ordinateur.

Lorsque vous demandez le déploiement d'un conteneur, Kubernetes identifie les besoins en mémoire de votre conteneur et trouve le meilleur serveur répondant à votre demande.

Vous ne décidez pas où l'application est déployée. Le centre de données est extrait de vous.

En d'autres termes, Kubernetes jouera sur Tetris avec votre infrastructure.

Les conteneurs Docker sont les blocs, les serveurs sont les tableaux et Kubernetes est le joueur.

Si Kubernetes compresse efficacement votre infrastructure, vous obtenez plus d’informatique pour votre argent. Vous pouvez faire beaucoup plus avec beaucoup moins.

Et votre utilisation globale de la facture devrait diminuer en conséquence.

Rappelez-vous que les entreprises n'utilisent que 10% des ressources allouées.

Eh bien, Kubernetes vient de sauver votre journée.

Mais il y a plus.

Kubernetes a une fonctionnalité tueur qui est généralement oubliée ou rejetée.

Kubernetes en tant que couche API sur votre centre de données

Tout ce que vous faites dans Kubernetes est à un appel d'API de vous.

Avez-vous besoin de déployer un conteneur? Il existe un point de terminaison REST pour cela.

Peut-être souhaitez-vous configurer un équilibreur de charge? Pas de problème. Il suffit d'appeler cette API.

Souhaitez-vous prévoir un stockage? Veuillez envoyer une demande POST à ​​cette URL.

Tout ce que vous faites dans Kubernetes appelle des API.

Et il y a beaucoup de bonnes raisons d'être excité à ce sujet:

  • Vous pouvez créer des scripts et des démons qui interagissent avec l'API par programmation
  • L'API est versionnée. lorsque vous mettez à niveau votre cluster, vous pouvez continuer à utiliser l'ancienne API et migrer progressivement
  • Vous pouvez installer Kubernetes dans n’importe quel fournisseur de cloud ou centre de données, et vous pouvez utiliser la même API.

Vous pouvez considérer Kubernetes comme une couche au-dessus de votre infrastructure.

Et puisque cette couche est générique et qu’elle peut être installée n’importe où, vous pouvez toujours la prendre avec vous.

Amazon Web Services est trop cher?

Pas de problème.

Vous pouvez installer Kubernetes sur Google Cloud Platform et y déplacer vos charges de travail.

Ou peut-être pouvez-vous conserver les deux, car une stratégie de haute disponibilité est toujours utile.

Mais peut-être que tu ne me crois pas.

C’est trop beau pour être vrai et je vends de la fumée et des miroirs.

Laisse moi te montrer.

Économisez sur votre facture cloud avec Kubernetes

Netlify est une plate-forme de création, de déploiement et de gestion de sites Web statiques.

Il possède son propre pipeline de CI. Ainsi, chaque fois que vous appliquez une modification à un référentiel, votre site Web est reconstruit.

Netlify a réussi à migrer vers Kubernetes, doublant ainsi sa base d'utilisateurs, tout en maintenant les coûts inchangés.

Ce sont de bonnes nouvelles!

Imaginez économiser 50% de votre facture Google Cloud Platform!

Mais Netlify n’est pas le seul.

Qbox - une entreprise spécialisée dans l'hébergement hébergé Elastic Search - a réussi à économiser encore 50% par mois sur les factures AWS!

Ce faisant, ils ont également fait appel à des sources ouvertes dans le cadre d’opérations multi-cloud.

Si vous n'êtes toujours pas impressionné, vous devriez jeter un coup d'œil à la presse réalisée par OpenAI.

OpenAI est une société de recherche à but non lucratif qui se concentre sur l'intelligence artificielle et l'apprentissage automatique. Ils ont écrit un algorithme pour jouer au jeu en ligne multi-joueurs Dota comme le ferait tout joueur humain.

Mais ils ont fait un pas de plus et ont formé une équipe de machines à jouer ensemble.

Et ils ont utilisé Kubernetes pour faire évoluer leur modèle d'apprentissage automatique dans le cloud.

Vous vous demandez les détails de leur cluster?

128000 vCPU

C’est environ 16000 MacBook Pro.

256 Nvidia Tesla P100

C’est 2100 Teraflops 16 bits en performances à virgule flottante.

De la même manière que si vous utilisiez la PlayStation 4 525.

Pouvez-vous deviner le coût par heure?

Non?

Seulement 1280 $ / heure pour 128 000 vCPU et 400 $ pour le 256 Nvidia P100.

Ce n’est pas grand-chose compte tenu du fait que gagner des tournois Dota pourrait vous rapporter des prix de l’ordre de plusieurs millions de dollars.

Alors qu'est-ce que tu attends?

Préparez-vous à adopter Kubernetes et à économiser sur votre facture cloud!

Notes finales

Kubernetes et les conteneurs sont là pour rester.

Avec le soutien de sociétés telles que Google, Microsoft, Red Hat, Pivotal, Oracle, IBM et bien d’autres encore, il est difficile de croire qu’elle ne comprendra pas.

De nombreuses entreprises commencent à prendre l’avance sur Kubernetes et rejoignent la révolution.

Pas seulement les startups et les PME, mais les grandes entreprises telles que les banques, les institutions financières et les compagnies d’assurances misent sur les conteneurs et sur Kubernetes pour être le futur.

Même les entreprises ont investi dans l'Internet des objets et les systèmes embarqués.

Il n’en est qu’à ses débuts et la communauté a le temps de mûrir, mais vous devez surveiller de près l’innovation dans cet espace.

C'est tout le monde!

Un grand merci à Andy Griffiths, John Topley et Walter Miani d’avoir lu le brouillon de cet article et d’avoir fait des suggestions inestimables.

Si vous avez apprécié cet article, vous pourriez trouver une lecture intéressante:

  • Prise en main de Docker et Kubernetes sous Windows 10, où vous aurez les mains sales et où vous installerez Docker et Kubernetes dans votre environnement Windows.
  • 3 astuces simples pour des images plus petites de Docker. Les images de Docker ne doivent pas nécessairement être grandes. Apprenez à mettre vos images Docker au régime!

Devenez un expert du déploiement et de la mise à l'échelle d'applications dans Kubernetes

Prenez une longueur d'avance avec nos cours pratiques et apprenez à maîtriser l'évolutivité dans le cloud.

Apprendre à:

  • Gérez les sites Web les plus fréquentés sans vous faire transpirer
  • Faites évoluer vos tâches vers des milliers de serveurs et réduisez le temps d'attente de quelques jours à quelques minutes
  • Ayez l'esprit tranquille en sachant que vos applications sont hautement disponibles avec une configuration multi-cloud
  • Économisez beaucoup d'argent sur votre facture cloud en n'utilisant que les ressources dont vous avez besoin
  • Renforcez votre pipeline de livraison et déployez l'application 24 heures sur 24

Devenir un expert de Kubernetes →

L'article a été publié à l'origine à learnk8s.io