Les solutions de calcul dans le cloud

Une machine virtuelle (VM) est un ordinateur défini par logiciel. Elle possède des processeurs virtuels, de la mémoire, des disques, une connexion réseau et son propre système d’exploitation. Un hyperviseur répartit un serveur physique entre plusieurs machines virtuelles et les isole les unes des autres. Une machine virtuelle cloud en fonctionnement est aussi appelée une instance.

Choisir les ressources

Les services principaux sont Amazon EC2, Azure Virtual Machines et Google Compute Engine. Chacun te loue une infrastructure ; tu gères le système d’exploitation et l’application. C’est l’infrastructure en tant que service (IaaS).

Le lancement d’une machine virtuelle implique plusieurs choix liés :

• Emplacement : une région et, lorsqu’elle est proposée, une zone de disponibilité.
• Image : un modèle contenant le système d’exploitation et les logiciels préinstallés. AWS l’appelle Amazon Machine Image (AMI) ; Azure et Google proposent des images publiques et personnalisées.
• Taille : les vCPU, la mémoire et la capacité associée. Un vCPU est l’unité de traitement attribuée à la machine virtuelle.
• Disque : le stockage persistant à partir duquel le système d’exploitation démarre.
• Réseau : une interface dans un sous-réseau, ainsi que des règles de trafic. Une adresse IP publique est facultative.

AWS utilise des volumes EBS, des sous-réseaux VPC et des groupes de sécurité. Azure utilise des disques managés, des sous-réseaux VNet et des groupes de sécurité réseau. Google utilise des disques persistants, des sous-réseaux VPC et des règles de pare-feu. Les noms diffèrent, mais les ressources remplissent des rôles comparables.

Suivre les choix de lancement

Une équipe a besoin d’un serveur web Linux à Francfort. Elle choisit la région Europe (Frankfurt), une AMI Ubuntu et m7g.large, avec 2 vCPU et 8 Gio de mémoire. Elle ajoute un volume de démarrage EBS de 30 Gio et connecte la machine virtuelle à un sous-réseau VPC. Son groupe de sécurité autorise HTTPS sur le port 443 depuis Internet et SSH sur le port 22 uniquement depuis le réseau du bureau. L’image fournit le point de départ logiciel ; la taille fournit la capacité de calcul ; les règles de trafic déterminent qui peut se connecter.

Suivre le cycle de vie et la facture

Une machine virtuelle est créée, s’exécute, peut être arrêtée et redémarrée, puis finit par être supprimée. Les frais de calcul s’accumulent tant qu’elle est allouée pour fonctionner, même si l’utilisation du CPU est proche de zéro. L’arrêt met normalement fin aux frais de calcul, mais les disques conservés et les adresses IP publiques réservées peuvent continuer à coûter de l’argent. Sur Azure, vérifie que l’état est « Stopped (deallocated) » : un arrêt depuis le système d’exploitation invité peut laisser la machine virtuelle à l’état « Stopped », avec des frais de calcul toujours facturés.

Les disques locaux temporaires diffèrent des disques de démarrage persistants. AWS instance store, les disques temporaires Azure et Google Local SSD conservent les données sur l’hôte physique ; l’arrêt, le déplacement ou la désallocation d’une machine virtuelle peut entraîner leur perte. Place les fichiers à conserver dans un stockage persistant. Après avoir supprimé une machine virtuelle, examine les ressources facturables conservées. Un groupe de sécurité seul ne fait l’objet d’aucuns frais propres, tandis qu’un disque non supprimé peut continuer à en générer.

Savoir qui assure la maintenance

Le fournisseur entretient le centre de données, le matériel physique et l’hyperviseur. Tu appliques les correctifs au système d’exploitation invité, mets à jour les logiciels installés, protèges les données et gères les accès et les paramètres du pare-feu. Louer une machine virtuelle ne transfère pas au fournisseur l’application des correctifs à son système invité.

Un hôte dédié réserve un serveur physique à ton usage, ce qui est utile pour les licences liées aux cœurs physiques. Une instance sur serveur physique donne accès au matériel sans couche d’hyperviseur. Azure Virtual Desktop et Amazon WorkSpaces transmettent quant à eux des postes de travail hébergés dans le cloud aux appareils des utilisateurs.

La famille d’une instance détermine l’équilibre entre traitement, mémoire, stockage et accélérateurs. Sa taille détermine la quantité de ces ressources dont tu disposes. Choisis la famille selon le besoin principal de la charge de travail, puis une taille qui répond à toutes ses exigences.

Reconnaître les principales familles

Un stockage local rapide ne rend pas les données persistantes. Une charge de travail qui utilise des instances optimisées pour le stockage a toujours besoin d’une solution pour les données à conserver en cas de perte de l’hôte.

Lire le nom

Dans m7g.large, m signifie polyvalent, 7 désigne la génération, g indique AWS Graviton et large est la taille. La même famille passe de 2 vCPU et 8 Gio pour large à 4 vCPU et 16 Gio pour xlarge, puis à 8 vCPU et 32 Gio pour 2xlarge.

Dans le nom Azure Standard_D4s_v5, D désigne la famille, 4 le nombre de vCPU, s la prise en charge des SSD premium et v5 la version. Le nom Google e2-standard-4 désigne la série E2, le rapport de mémoire standard et 4 vCPU. Un vCPU est souvent un fil d’exécution matériel ; sur Graviton, c’est un cœur entier. Ne considère pas les vCPU de tous les fournisseurs comme des cœurs physiques identiques.

Étudier un choix de dimensionnement

Une application interne de production de rapports a besoin de 2 vCPU et de 6 Gio au pic d’activité. Compare ces tailles AWS :

• c7g.large : 2 vCPU et 4 Gio ; la mémoire est insuffisante.
• m7g.large : 2 vCPU et 8 Gio ; les deux besoins sont satisfaits, avec 2 Gio de marge.
• r7g.large : 2 vCPU et 16 Gio ; cette taille fournit bien plus de mémoire que l’application n’en a besoin.

La taille polyvalente est le point de départ raisonnable. Sa mémoire par vCPU est de $8÷2=4$ Gio. Les solutions optimisées pour le calcul et pour la mémoire fournissent respectivement 2 et 8 Gio par vCPU. Les types Google E2 highcpu, standard et highmem à 4 vCPU présentent de même des quantités de mémoire différentes : 4 Go, 16 Go et 32 Go.

Le redimensionnement optimal consiste à mesurer l’utilisation réelle et à adapter le choix. Examine l’utilisation de la mémoire, du disque et du réseau en plus de celle du CPU avant de réduire la taille. AWS Compute Optimizer, Azure Advisor et les recommandations de types de machines Google peuvent t’aider. Le changement de taille d’une machine virtuelle existante nécessite un arrêt ou un redémarrage : prévois donc une interruption pour une application sur un serveur unique.

Distinguer les pics des interruptions

Les types à performances extensibles AWS T, Azure B et Google E2 à cœur partagé conviennent aux charges peu actives avec de courts pics. AWS T et Azure B accumulent des crédits CPU sous un niveau de base et les dépensent au-dessus. Lorsque les crédits sont épuisés, Azure B et AWS T en mode standard reviennent au niveau de base ; les types AWS T actuels utilisent par défaut le mode illimité et peuvent facturer le surplus de CPU.

Les machines virtuelles Spot utilisent une capacité inutilisée que le fournisseur peut reprendre avec un court préavis. Elles conviennent aux traitements par lots redémarrables dont la progression est sauvegardée. Une base de données de production unique convient mal à cette solution. Les anciennes machines virtuelles préemptibles de Google ont aussi une durée de vie maximale de 24 heures ; cette limite ne définit pas les machines virtuelles Spot actuelles.

Un service fait face à deux problèmes différents : l’arrivée de davantage de travail et les pannes de matériel. La mise à l’échelle modifie la capacité. La haute disponibilité maintient le service utilisable lorsque des composants tombent en panne. Une conception peut résoudre un problème tout en laissant l’autre sans solution.

Modifier la taille ou le nombre

La mise à l’échelle verticale modifie la taille d’une machine : par exemple, 2 vCPU et 8 Gio deviennent 8 vCPU et 32 Gio. Une augmentation ajoute des ressources ; une réduction en supprime. C’est un moyen direct de donner plus de capacité à une application existante, mais la machine doit généralement redémarrer, la taille maximale est limitée et la machine reste un point de défaillance.

La mise à l’échelle horizontale modifie le nombre de copies. Trois serveurs web peuvent passer à neuf, puis revenir à trois. Une augmentation ajoute des instances ; une réduction en supprime. Un répartiteur de charge partage les requêtes web, tandis que des processus en arrière-plan peuvent prendre des tâches dans une file d’attente partagée. L’application doit permettre à plusieurs copies de travailler utilement ensemble. Une base de données partagée peut toujours limiter le débit ou tomber en panne même si de nombreux serveurs web restent sains.

La scalabilité est la capacité à traiter davantage de travail en ajoutant des ressources. L’élasticité est l’augmentation et la réduction automatiques de la capacité au bon moment lorsque la demande change. Une boutique qui passe automatiquement de 4 serveurs la nuit à 20 pendant une vente est élastique. Un parc fixe doté d’une réserve de capacité peut être hautement disponible sans être élastique.

Rendre les copies remplaçables

Une instance d’application sans état ne conserve aucune donnée unique nécessaire à une requête ultérieure. Stocke les paniers, les sessions et les fichiers chargés dans une base de données partagée, un cache ou un service de stockage. Une requête peut alors atteindre n’importe quelle instance, et une réduction horizontale peut en supprimer une sans perdre les paniers de ses utilisateurs.

Par exemple, un panier conservé uniquement dans la mémoire d’un serveur web disparaît lorsque ce serveur est résilié. Maintenir l’utilisateur sur ce serveur grâce à l’affinité de session ne protège pas le panier contre une panne du serveur. Placer le panier dans un stockage partagé change ce qui peut être supprimé sans risque.

Conserver une capacité suffisante après la panne d’une zone

Les zones de disponibilité sont des sites distincts au sein d’une région, dotés d’une alimentation électrique, d’un refroidissement et d’un réseau indépendants. Répartir les instances entre les zones protège contre la panne d’une zone entière. Plusieurs instances dans une même zone partagent toujours le risque lié à cette zone.

Supposons qu’une application doive conserver la capacité de 4 instances après la perte de n’importe laquelle des 3 zones. Les deux zones restantes doivent chacune fournir 2 instances :

Exécute 2 instances dans chaque zone, soit 6 au total. La perte de n’importe quelle zone en laisse 4. Il s’agit d’une réserve de capacité en cas de panne, et non d’une augmentation du besoin normal de la charge de travail. Un répartiteur de charge dirige les requêtes vers les instances restantes ; tout service de données partagé doit aussi disposer d’une disponibilité adaptée.

Reconnaître les groupes à haute disponibilité Azure

Un groupe à haute disponibilité répartit les machines virtuelles au sein d’un même centre de données entre des domaines de défaillance matériels et des domaines de mise à jour pour la maintenance. Un domaine de défaillance partage du matériel comme l’alimentation électrique et les commutateurs réseau. Les groupes prennent en charge jusqu’à 3 domaines de défaillance ; les domaines de mise à jour sont au nombre de 5 par défaut et peuvent atteindre 20. Ils réduisent les risques liés aux baies et aux redémarrages planifiés. Les zones répondent au risque plus large d’indisponibilité de tout un site de centre de données.

La mise à l’échelle automatique ajoute et supprime des instances lorsque la demande change. Amazon EC2 Auto Scaling utilise des groupes Auto Scaling, Azure utilise Virtual Machine Scale Sets avec des règles de mise à l’échelle automatique, et Google utilise des groupes d’instances managés avec un outil de mise à l’échelle automatique.

Partir d’un modèle reproductible

Une nouvelle instance a besoin de la même image, de la même taille, des mêmes paramètres réseau et des mêmes instructions de démarrage que les autres. AWS utilise un modèle de lancement, Azure un modèle de machine virtuelle du groupe et Google un modèle d’instance. Une modification manuelle dans une machine virtuelle en fonctionnement disparaîtra lors de son remplacement, sauf si elle est incluse dans la configuration reproductible.

Le groupe possède trois paramètres de capacité :

• Minimum : le plancher que le groupe maintient.
• Capacité souhaitée : le nombre d’instances qu’il cherche actuellement à exécuter.
• Maximum : le plafond qu’il ne doit pas dépasser.

Avec un minimum de 2, une capacité souhaitée de 4 et un maximum de 10, le groupe vise 4 instances. Les politiques peuvent faire varier la capacité souhaitée entre 2 et 10. Le maximum autorise la croissance ; le fixer à 10 ne lance ni ne facture en soi 10 machines virtuelles. Il plafonne le nombre d’instances, pas tous les frais de l’application.

Choisir ce qui déclenche un changement

Le suivi de cible cherche à maintenir une métrique proche d’une cible, comme une utilisation moyenne du CPU de 50 %. La mise à l’échelle par paliers ou fondée sur des règles modifie la capacité lorsqu’un seuil est franchi, par exemple en ajoutant 2 instances après que le CPU est resté au-dessus de 70 % pendant 5 minutes. La mise à l’échelle planifiée définit la capacité à des heures connues. La mise à l’échelle prédictive prévoit la demande à partir des tendances passées et prépare la capacité à l’avance.

Un pic quotidien à 08 h 00 incite à préparer les instances avant 08 h 00. Attendre une alerte de forte utilisation du CPU signifie que le pic est déjà arrivé alors que les machines virtuelles supplémentaires démarrent encore.

Calculer la capacité pour le suivi de cible

Quatre instances identiques ont une utilisation moyenne du CPU de 80 %, et la cible est de 50 %. Pour une estimation simplifiée à charge constante, additionne d’abord le travail en unités de pourcentage par instance :

Divise par la cible par instance :

Arrondis à 7 instances, car 6 laisseraient la moyenne au-dessus de la cible. Avec 7, l’estimation est de $320÷7\approx \mathrm{45,7}\mathrm{\%}$. Si le maximum du groupe est de 6, il s’arrête là et la moyenne est d’environ 53,3 %.

Distinguer la mise en disponibilité de la récupération après panne

Une machine virtuelle a besoin de temps pour démarrer, exécuter ses tâches de démarrage et réussir les contrôles d’état. Le préchauffage empêche les mesures incomplètes d’une nouvelle instance de fausser une décision de mise à l’échelle. Un délai de stabilisation limite les changements rapides dans les deux sens.

Les groupes de mise à l’échelle peuvent aussi remplacer les machines virtuelles défaillantes pour rétablir la capacité souhaitée. Les contrôles au niveau de l’application et les actions de réparation doivent être configurés : une machine virtuelle peut fonctionner alors que son application web est défaillante. Sur Azure, une action de réparation peut redémarrer une instance, réinstaller son image ou la remplacer ; Google appelle cette récupération autoréparation. Un répartiteur de charge peut détecter une application défaillante, mais le groupe de mise à l’échelle doit être configuré pour utiliser cette information à des fins de réparation.

La réduction horizontale supprime des instances. Conserve les journaux de manière centralisée et les données durables hors de leurs fichiers locaux pour que la suppression d’une copie saine ne supprime pas d’informations uniques.

Un répartiteur de charge donne aux clients une adresse d’entrée unique et transmet le trafic entrant aux serveurs sains. AWS appelle l’ensemble de serveurs un groupe cible ; Azure utilise un pool principal ; Google utilise un service de backend. Les clients n’ont pas besoin d’une nouvelle adresse chaque fois que l’ensemble change.

Acheminer le trafic et détecter les pannes

Un contrôle d’état teste régulièrement une cible, par exemple en envoyant une requête à /health toutes les 10 secondes. Après un nombre suffisant d’échecs, la cible est marquée comme défaillante et ne reçoit plus de nouveau trafic jusqu’à ce qu’elle réussisse à nouveau un contrôle. La détection prend du temps, car les contrôles sont effectués à intervalles réguliers.

L’acheminement et la réparation sont deux tâches différentes. Le répartiteur de charge cesse d’envoyer de nouvelles requêtes à une cible défaillante. Un groupe de mise à l’échelle ou un opérateur répare ou remplace ce serveur. Ajouter uniquement un répartiteur de charge n’ajoute aucune capacité de traitement à l’application.

La répartition à tour de rôle sélectionne successivement les cibles saines. La méthode du plus petit nombre de connexions ou du plus petit nombre de requêtes en cours privilégie la cible qui a le moins de travail en cours. Le routage fondé sur le hachage associe à une cible les caractéristiques de la connexion, notamment les adresses et les ports. Une connexion reste sur la même cible, mais une nouvelle connexion du même utilisateur peut aboutir ailleurs.

L’affinité de session maintient les requêtes d’un utilisateur sur un même serveur. Elle peut aider une application qui conserve les sessions localement, mais rend le trafic moins régulier et expose les sessions à une panne de ce serveur. Un stockage partagé des sessions permet aux autres serveurs sains de poursuivre le travail de l’utilisateur.

Calculer l’effet de la perte d’un serveur

Trois serveurs sains se partagent également 900 requêtes par minute. Chacun en traite :

Un serveur échoue à ses contrôles d’état. Le même travail est désormais envoyé à deux serveurs :

Si chacun ne peut traiter que 400 requêtes par minute, le routage vers les serveurs sains laisse tout de même une surcharge. L’ensemble a besoin d’une réserve de capacité ou d’instances supplémentaires. La mise à l’échelle automatique modifie la capacité ; la répartition de charge la distribue.

Choisir la couche adaptée au routage

Un service de couche 7 peut aussi assurer la terminaison TLS, en déchiffrant HTTPS au point d’entrée, et fonctionner avec un pare-feu applicatif web. Un service de couche 4 n’inspecte pas le chemin HTTP pour choisir son serveur cible. Vérifie les protocoles de transport pris en charge par un produit donné.

AWS Elastic Load Balancing propose, au sein d’une région, des Application Load Balancers en couche 7, des Network Load Balancers en couche 4 et des Gateway Load Balancers pour les équipements réseau. Azure Load Balancer fonctionne en couche 4 ; Application Gateway est un service régional de couche 7 ; Front Door fournit un point d’entrée mondial de couche 7. Google Cloud Load Balancing propose des Application et Network Load Balancers sous des formes régionales et mondiales.

Relier le routage à la mise à l’échelle

Une fois l’intégration configurée, les nouvelles instances du groupe s’enregistrent comme cibles et reçoivent du trafic dès qu’elles sont saines. Lors de leur suppression, le drainage des connexions permet aux requêtes en cours de se terminer avant qu’une cible disparaisse. Un déploiement multizone achemine le trafic vers les zones saines pendant une panne, à condition que les zones restantes aient une capacité suffisante. Même deux serveurs bénéficient de ce point d’entrée partagé et du routage selon leur état.

Un conteneur exécute une application et ses dépendances sous forme de processus isolé sur un hôte. Le regroupement de ses bibliothèques et de son environnement d’exécution permet de reproduire en production le logiciel testé.

Image, registre et copie en cours d’exécution

Une image est le modèle en lecture seule ; un registre stocke et distribue les images ; un conteneur est une copie en cours d’exécution. Amazon ECR, Azure Container Registry et Google Artifact Registry fournissent des registres. L’Open Container Initiative définit des formats d’image standard ; Docker a contribué à populariser leur utilisation.

Par exemple, une équipe empaquette son API de commandes Python sous le nom orders-api:1.4, la teste, l’envoie à un registre et démarre 3 conteneurs de production à partir de cette image. Les paramètres d’environnement et l’accès aux services externes doivent encore être configurés.

Partager un noyau au lieu de démarrer un système d’exploitation invité

Chaque machine virtuelle possède un système d’exploitation invité complet derrière un hyperviseur. Les conteneurs partagent le noyau de l’hôte, le cœur du système d’exploitation qui gère les ressources et les processus. Ils ont moins de logiciels à emporter et à démarrer : les images occupent souvent des dizaines ou des centaines de mégaoctets, et le démarrage prend quelques secondes ou moins. Les images de machines virtuelles occupent généralement des gigaoctets et leur démarrage prend des minutes. Un hôte peut donc exécuter davantage de conteneurs que de machines virtuelles complètes.

Le partage a aussi une incidence sur l’isolation. Une faille dans le noyau de l’hôte peut affecter plusieurs conteneurs, tandis que des noyaux invités distincts assurent une isolation plus forte aux machines virtuelles. Les conteneurs Linux ont besoin d’un noyau Linux ; les conteneurs Windows ont besoin de Windows. L’image doit aussi correspondre à l’architecture du processeur, comme x86 ou Arm. Les conteneurs s’exécutent souvent sur des machines virtuelles dans le cloud.

Remplacer les logiciels et conserver les données

Mets à jour un conteneur en créant une image corrigée et en remplaçant les anciennes copies. Un correctif appliqué à la main disparaît lors du remplacement et laisse les autres répliques inchangées.

Il en va de même pour les fichiers créés pendant l’exécution dans la couche accessible en écriture. Une facture qui y est générée doit être enregistrée sur un volume persistant ou dans un service de stockage avant le remplacement. Le registre d’images conserve les ensembles applicatifs, pas les documents créés par les conteneurs en cours d’exécution.

Séparer les services lorsque cela aide

Une application monolithique se déploie comme une seule unité. Les microservices divisent une application en services connectés par réseau, qui se déploient et se mettent à l’échelle séparément. Une boutique peut ajouter des conteneurs au service de paiement sans ajouter de copies du service de catalogue.

Un orchestrateur place les conteneurs sur les hôtes, redémarre les copies défaillantes, adapte leur nombre, déploie les versions et connecte les services. Kubernetes le fait, tout comme des services de conteneurs managés plus simples. Les conteneurs ne nécessitent pas Kubernetes.

Kubernetes déploie et gère des conteneurs sur un groupe de machines appelé cluster. Il est open source, a été créé chez Google et est maintenu au sein de la Cloud Native Computing Foundation. La même plateforme peut fonctionner sur plusieurs clouds et dans des centres de données privés.

Comprendre les composants du cluster

Le plan de contrôle conserve la configuration, planifie les tâches et coordonne le cluster. Les nœuds de travail, généralement des machines virtuelles, fournissent la puissance de traitement et la mémoire consommées par les conteneurs.

Un pod est la plus petite unité planifiée par Kubernetes. Il contient un ou plusieurs conteneurs qui partagent une adresse réseau et restent ensemble sur un même nœud. Un pod n’est pas une machine virtuelle distincte. Plusieurs pods peuvent partager le même nœud de travail si leurs besoins en ressources le permettent.

Tu déclares un état souhaité : par exemple, 3 répliques de orders-api:1.4. Kubernetes cherche à maintenir 3 pods en fonctionnement. Lorsqu’un pod tombe en panne, il crée un remplaçant ; après la panne d’un nœud, des pods de remplacement peuvent s’exécuter sur les nœuds restants disposant de capacité. Un Service Kubernetes fournit un nom et une adresse stables pour accéder aux pods, même lorsque leurs adresses individuelles changent.

Mettre les pods et les machines à l’échelle séparément

Un autoscaler horizontal de pods (HPA) modifie le nombre de pods à partir de métriques comme la demande de CPU. Un autoscaler de cluster modifie la capacité en nœuds lorsque les pods ne peuvent pas être placés ou que des nœuds deviennent inutiles. Ajouter des pods sans espace pour les exécuter crée du travail en attente, pas davantage de capacité de traitement.

Supposons que chaque pod demande 0,5 vCPU et que chaque nœud dispose de 2 vCPU pour les pods. Ignore les autres limites de ressources dans cet exemple. Un nœud peut accueillir :

Si le HPA porte le nombre souhaité à 10 pods, deux nœuds n’en accueillent que 8. Le besoin est de :

Arrondis à 3 nœuds. Le troisième nœud fournit de la place pour les 2 derniers pods. Utilise la capacité disponible pour les pods, car le système d’exploitation du nœud et les composants Kubernetes ont aussi besoin de ressources. Dans une planification réelle, la mémoire et les règles de placement comptent également, en plus du CPU.

Répartir les responsabilités de gestion

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) et Google Kubernetes Engine (GKE) exploitent des plans de contrôle managés. Le fournisseur maintient ce plan de contrôle, notamment sa disponibilité et ses mises à jour. Tu gères les images, les paramètres de l’application, les accès et les demandes de ressources des charges de travail. Dans de nombreux modes, tu gères aussi le choix et les mises à jour des nœuds de travail. Les frais de cluster peuvent être distincts de ceux des nœuds.

GKE Standard te laisse choisir les nœuds et facture leurs machines virtuelles. GKE Autopilot provisionne et gère les nœuds et facture généralement les ressources demandées par les pods. EKS peut exécuter les pods admissibles sur AWS Fargate pour que tu n’aies pas à gérer les machines virtuelles des nœuds. Ces modes réduisent le travail d’exploitation tout en limitant certains choix concernant les hôtes.

Déterminer si la complexité est utile

Kubernetes convient à de nombreux services déployés indépendamment et aux équipes qui ont besoin d’une plateforme commune à plusieurs fournisseurs. Ses outils et ses définitions de charges de travail améliorent la portabilité, même si les bases de données cloud associées, les systèmes d’identité et les réseaux peuvent encore nécessiter des modifications.

Pour une application web simple, une plateforme d’hébergement ou un service de conteneurs sans serveur peut demander moins de travail. Kubernetes managé ne corrige pas un bogue dans ton image et ne choisit pas la bonne quantité de mémoire à demander. Si une application manque régulièrement de mémoire, l’équipe doit examiner l’application et ses paramètres, même lorsque le plan de contrôle est entièrement managé.

Les services de conteneurs sans serveur exécutent tes images sur des hôtes gérés par le fournisseur. Tu choisis toujours les ressources, maintiens l’image et configures l’application. La mise à l’échelle et la facturation dépendent du service.

Distinguer l’orchestration du calcul

Amazon ECS orchestre les conteneurs sous forme de tâches. Un service ECS maintient un nombre souhaité de tâches, éventuellement derrière un répartiteur de charge. Les tâches s’exécutent sur des hôtes EC2 que tu gères ou sur la capacité de calcul Fargate.

Fargate prend aussi en charge les pods EKS admissibles. Tu choisis les vCPU et la mémoire de la tâche ou du pod et tu paies pendant que ces ressources fonctionnent ; tu ne choisis, ne corriges et ne mets pas à l’échelle les hôtes EC2 sous-jacents. La mise à l’échelle automatique d’un service ECS utilise les politiques que tu configures. Fargate fournit la capacité de calcul ; il ne détermine pas le nombre de tâches souhaité pour l’application. ECS sur EC2 laisse davantage de contrôle sur l’hôte et la famille d’instances, mais demande plus de gestion.

Comparer les services Azure et Google

Azure Container Instances (ACI) démarre un conteneur ou un petit groupe sans cluster et facture à la seconde. Il convient aux tests et aux tâches simples de durée limitée, mais ne possède pas de mise à l’échelle automatique intégrée.

Azure Container Apps masque sa plateforme Kubernetes sous-jacente. Des règles configurées adaptent la capacité des applications conteneurisées selon le trafic HTTP ou les événements, jusqu’à zéro pour les charges de travail adaptées.

Google Cloud Run propose des services pour les requêtes entrantes et des tâches qui s’exécutent jusqu’à leur terme. Les services peuvent passer de zéro à plusieurs instances, puis réduire à nouveau leur nombre. La facturation du calcul fondée sur les requêtes couvre leur traitement ainsi que le démarrage et l’arrêt. Sans nombre minimal d’instances et sans instance en fonctionnement, le calcul inactif ne coûte rien ; les bases de données et les images stockées peuvent toutefois entraîner des frais. Cloud Run héberge aussi Cloud Run functions, qui part du code d’une fonction plutôt que d’une image d’application fournie par le client.

Échanger les économies pendant l’inactivité contre une attente au démarrage

Une API interne de réservation est très sollicitée de 08 h 00 à 18 h 00 les jours ouvrés : 10 heures sur 5 jours, soit 50 des 168 heures de la semaine. Des requêtes occasionnelles arrivent aussi la nuit. Cloud Run ou Container Apps peut exécuter plusieurs copies au pic et atteindre zéro entre les requêtes pendant les périodes calmes.

Une requête après une période d’inactivité peut attendre un démarrage à froid. Maintenir au moins une instance prête réduit l’attente dans la limite de sa capacité et ajoute un coût continu. Un pic dépassant cette capacité peut toujours entraîner le démarrage à froid d’instances supplémentaires.

Choisir le contrôle nécessaire sur l’hôte

Ces services limitent l’accès à l’hôte et imposent des limites de ressources et de durée. Tu ne peux pas installer d’agents sur l’hôte ni modifier son noyau. Des machines virtuelles ou des nœuds Kubernetes adaptés répondent à ces besoins. Pour des API conteneurisées standard, des services plus simples peuvent éviter le travail d’exploitation de Kubernetes ; ACI est une solution directe pour un groupe simple de conteneurs.

Une fonction sans serveur est un code qui s’exécute à l’arrivée d’un événement correspondant. Le fournisseur gère les serveurs et l’environnement d’exécution managé. AWS Lambda, Azure Functions et Google Cloud Run functions proposent ce modèle de fonction en tant que service (FaaS).

Relier un déclencheur à une invocation

Un déclencheur lance une exécution, appelée invocation. Les déclencheurs comprennent les requêtes HTTP, les fichiers chargés, les messages dans une file d’attente, les modifications de base de données et les minuteries. Le chargement d’une photo peut déclencher une fonction qui crée une miniature de 200 pixels et l’enregistre dans un stockage. Sans chargement, un déploiement à la demande peut n’exécuter aucun calcul de fonction.

Le fournisseur adapte le nombre d’exécutions à l’arrivée des événements, dans les limites de simultanéité et du service. De nombreuses fonctions simultanées peuvent ouvrir de nombreuses connexions à une base de données. La couche de fonctions peut encore avoir de la marge pour monter en charge alors que la base de données n’en a plus. Limite la simultanéité à ce que les systèmes connectés peuvent supporter.

Les fonctions sont sans état entre les invocations. Une invocation ultérieure peut utiliser un nouvel environnement et ne peut donc pas dépendre de la mémoire ou des fichiers temporaires d’un appel précédent. Stocke les compteurs, les sessions et les résultats durables dans une base de données, un cache ou un stockage en mode objet. Un environnement prêt peut être réutilisé, mais cette réutilisation ne garantit pas la persistance.

Calculer l’utilisation facturée à l’usage

La facturation standard à la demande de Lambda combine le nombre d’invocations et les Go-secondes (Go-s) : la mémoire allouée en Go multipliée par les secondes d’exécution. Pour illustrer le calcul, supposons que chacune des 3 000 000 d’invocations dure 0,2 seconde avec 0,5 Go de mémoire. Ignore les franchises gratuites et tous les autres services.

Avec des prix supposés de 0,0000167 dollar américain par Go-s et de 0,20 dollar américain par million de requêtes, le calcul coûte 5,01 dollars américains et les requêtes 0,60 dollar américain, soit 5,61 dollars américains au total. Ces prix sont supposés pour apprendre le modèle. Cloud Run functions mesure aussi le CPU ; les offres Azure peuvent facturer les instances prêtes ou allouées.

Pour 100 000 000 d’invocations par ailleurs identiques, l’utilisation est de 10 000 000 Go-s : 167 dollars américains pour le calcul et 20 dollars américains pour les requêtes à ces tarifs supposés. Une machine virtuelle à un prix supposé de 0,04 dollar américain par heure coûte 29,20 dollars américains pour 730 heures, mais une comparaison équitable vérifie aussi si elle peut traiter le même travail et tient compte de son effort d’exploitation. Une demande irrégulière favorise les solutions qui évitent la capacité inactive ; une charge stable peut favoriser une capacité de calcul toujours active.

Vérifier les limites d’exécution et l’attente au démarrage

Le calcul par défaut de Lambda autorise au maximum 15 minutes par invocation et jusqu’à 10 240 Mo de mémoire. Une conversion de 40 minutes ne tient pas dans cette invocation. Une tâche conteneurisée, une machine virtuelle ou des étapes plus courtes peuvent convenir ; les règles de délai diffèrent pour les autres offres et modes de calcul.

Un démarrage à froid se produit lorsqu’un nouvel environnement d’exécution doit être préparé, après une période d’inactivité ou lors d’une augmentation horizontale. Les environnements prêts réutilisés démarrent plus vite. La simultanéité provisionnée de Lambda, les instances toujours prêtes d’Azure Premium ou Flex Consumption et les instances minimales de Cloud Run réduisent les attentes au démarrage moyennant un coût supplémentaire.

Le fournisseur maintient les serveurs et l’environnement d’exécution managé. Tu dois toujours corriger ton code et les bibliothèques incluses, protéger les secrets, configurer les permissions et sécuriser les données. Le sans serveur supprime l’administration des serveurs, mais tu restes responsable de l’application.

Une plateforme d’hébergement d’applications prend ton code ou ton image de conteneur et fournit l’infrastructure nécessaire à son exécution. C’est une plateforme en tant que service (PaaS) : la plateforme fournit le déploiement, la surveillance de l’état, l’exploitation des serveurs et la mise à l’échelle, tandis que tu construis l’application.

Comparer les principales plateformes

AWS Elastic Beanstalk crée des ressources AWS ordinaires pour ton application, généralement des instances EC2 dans un groupe Auto Scaling derrière un Elastic Load Balancer. Il prend en charge les déploiements et la surveillance de l’état. Beanstalk lui-même ne facture pas de frais de service supplémentaires ; tu paies les ressources qu’il crée. Ces ressources restent visibles dans ton compte et tu peux personnaliser leur configuration.

Azure App Service héberge des applications web, des API et des backends mobiles à partir de code ou de conteneurs. Un plan App Service définit la région, la taille et le nombre d’instances. Les applications de ce plan partagent ces instances. Les niveaux dédiés facturent le plan même lorsque les applications sont peu sollicitées. Les fonctionnalités comme la mise à l’échelle automatique et les emplacements de déploiement dépendent du niveau choisi.

Google App Engine possède des environnements standard et flexible. L’environnement standard utilise les environnements d’exécution pris en charge dans un bac à sable et peut passer à zéro avec une mise à l’échelle automatique adaptée. L’environnement flexible exécute des conteneurs sur des machines virtuelles Compute Engine, permet davantage de personnalisation et maintient au moins une instance en fonctionnement. Cloud Run est une autre solution pour héberger une application déjà empaquetée dans un conteneur.

Mettre une nouvelle version en service en toute sécurité

Une équipe de deux personnes qui gère une boutique utilise un niveau App Service avec des emplacements de déploiement. Elle exécute 2 instances et déploie une nouvelle version dans un emplacement de préproduction, un espace distinct pour tester la version avant que les clients l’utilisent. Après les tests, elle échange la préproduction et la production. L’ancienne version reste disponible dans l’autre emplacement pour un éventuel retour en arrière.

Pendant une vente, la règle de mise à l’échelle automatique configurée porte le plan à 5 instances après que l’utilisation moyenne du CPU est restée supérieure à 70 %, puis le ramène à 2 lorsque la demande baisse. La plateforme effectue la mise à l’échelle, mais l’équipe choisit toujours le plan, les règles et les limites. Elle n’installe jamais le système d’exploitation de l’hôte ni le serveur web.

Conserver les bonnes responsabilités

Sur chaque plateforme, tu maintiens le code, les bibliothèques incluses, les paramètres, les secrets, les données et les accès. App Service et App Engine maintiennent le système d’exploitation de leur hôte et l’environnement d’exécution managé. Beanstalk permet davantage de personnalisation d’EC2 ; AWS publie des mises à jour de plateforme que tu appliques ou pour lesquelles tu actives les mises à jour managées. Les logiciels supplémentaires que tu installes nécessitent aussi une maintenance.

Une plateforme diffère du SaaS. Avec le PaaS, tu déploies l’application que tu construis ; avec le SaaS, tu utilises l’application achevée de quelqu’un d’autre, comme une suite de messagerie. Les paramètres propres à la plateforme et les intégrations avec ses services peuvent aussi rendre plus difficile un changement ultérieur de fournisseur.

Répondre aux besoins d’hébergement plus simples

Amazon Lightsail regroupe un serveur privé virtuel, du stockage et du transfert de données dans un forfait mensuel prévisible. Il convient aux petits sites web, mais implique toujours les responsabilités liées à une machine virtuelle. Un site statique est composé de fichiers comme du HTML, du CSS, du JavaScript et des images. AWS Amplify Hosting, Azure Static Web Apps et Firebase Hosting peuvent diffuser ces fichiers dans le monde entier sans serveur web à maintenir. Une application qui nécessite le contrôle complet du système d’exploitation de l’hôte doit être placée sur des machines virtuelles.

Compare les modèles de calcul pour une même charge de travail. Examine le contrôle, l’effort d’exploitation, le démarrage, la facturation, les limites et la portabilité.

Qui maintient quoi ?

Les données et les accès restent dans tous les cas sous la responsabilité du client. Elastic Beanstalk nécessite aussi de choisir comment appliquer les mises à jour de plateforme.

Comparer le trafic et la capacité utilisable

Une machine virtuelle a généralement besoin d’au moins une minute pour démarrer et réussir les contrôles ; un conteneur démarre souvent en quelques secondes ; une fonction dont l’environnement est prêt peut commencer à travailler en quelques millisecondes. Un nouvel environnement peut ajouter une attente liée au démarrage à froid. Une capacité maintenue prête réduit cette attente moyennant un coût continu.

Un annuaire peu sollicité pendant la nuit peut bénéficier de la mise à l’échelle à zéro ; une demande stable peut favoriser une capacité de calcul allouée. Compare un débit, une mémoire et une simultanéité équivalents avant les totaux mensuels : une machine virtuelle peu chère peut ne pas traiter le même travail que de nombreuses invocations de fonctions simultanées. Tiens aussi compte de l’effort d’exploitation.

Les machines virtuelles et les plans d’hébergement dédiés facturent le temps d’allocation, qu’ils soient sollicités ou inactifs. La facturation standard à la demande de Lambda combine les requêtes et les Go-secondes ; d’autres offres de fonctions utilisent des unités de mesure différentes. Zéro instance supprime les frais de calcul pendant l’inactivité uniquement lorsqu’aucun minimum payant ne subsiste. Le stockage et les bases de données peuvent rester facturés.

Vérifier les limites et le passage entre plateformes

Les processus de longue durée conviennent aux machines virtuelles ou aux conteneurs adaptés. Une invocation avec le calcul par défaut de Lambda est limitée à 15 minutes ; une tâche ininterrompue de deux heures nécessite donc une autre solution d’exécution compatible. Les fonctions ne peuvent pas compter sur la persistance de l’état local entre les appels ; les conteneurs remplaçables et les machines virtuelles des groupes de mise à l’échelle ont aussi besoin de données durables externes.

Le contrôle complet du système d’exploitation invité, les modifications du noyau et les logiciels spécialisés sous licence favorisent les machines virtuelles. De nombreux services déployés indépendamment peuvent justifier Kubernetes. Les applications web standard conviennent souvent aux plateformes d’hébergement ; les tâches courtes déclenchées par des événements conviennent aux fonctions.

Les images de conteneurs passent d’un hôte compatible à l’autre, et Kubernetes offre des outils de déploiement communs aux différents clouds. Les bases de données, les systèmes d’identité et les réseaux peuvent encore nécessiter des modifications. La migration de machines virtuelles dépend des formats et outils des fournisseurs ; les fonctions et les plateformes sont plus étroitement liées aux paramètres et déclencheurs du fournisseur. Différents composants peuvent utiliser différents modèles.

Vérifie d’abord les exigences qui pourraient exclure une solution. Compare ensuite le trafic, le coût et les compétences de l’équipe.

Trouver la contrainte décisive

1. Vérifie l’accès au système d’exploitation invité, les logiciels particuliers, le matériel et les licences.
2. Pour un traitement court déclenché par un événement, vérifie la durée, l’état et la simultanéité des fonctions.
3. Pour les applications conteneurisées, compare le contrôle de Kubernetes à des services managés plus simples.
4. Pour les applications web standard déployées sous forme de code, envisage une plateforme d’hébergement.
5. Vérifie l’attente au démarrage, les profils de trafic, les limites de ressources et le coût total d’exploitation.

Associer les solutions aux cas d’entreprise

Un éditeur ne prend en charge une application de comptabilité que sur Windows Server, avec une licence fondée sur les cœurs. Les machines virtuelles conservent cet environnement ; utilise un hôte dédié si la licence exige des cœurs physiques. Des copies sur plusieurs zones nécessitent une conception compatible de l’application et des données. Le déplacement avec très peu de modifications est un réhébergement, ou lift and shift, et conserve la maintenance du système invité.

Les chargements de photos passent de quelques-uns la nuit à des milliers par minute. Les tâches courtes et indépendantes de création de miniatures conviennent aux fonctions déclenchées par les chargements. Leur nombre s’adapte aux arrivées ; vérifie les démarrages à froid, les limites de durée et la capacité des services en aval.

Un commerce possède 30 microservices, 6 équipes et exige une plateforme sur deux clouds. Kubernetes managé fournit des outils d’orchestration communs. Une jeune entreprise disposant de 3 services et sans expérience de Kubernetes peut utiliser Cloud Run, Container Apps ou ECS avec Fargate : elle reste responsable des images et des applications sans gérer les hôtes.

L’agence d’un musée construit un site de billetterie mais ne possède pas de personnel d’exploitation. Une plateforme d’hébergement fournit les outils de déploiement et la mise à l’échelle pour les jours d’ouverture. App Service et App Engine maintiennent les hôtes ; Beanstalk nécessite un choix pour les mises à jour de plateforme, comme les mises à jour managées.

Un rapport nocturne de deux heures convient à une tâche conteneurisée ou à une machine virtuelle dont la limite d’exécution est adaptée, mais pas à une seule invocation avec le calcul par défaut de Lambda. La capacité Spot peut réduire le coût si la tâche enregistre sa progression et reprend après une interruption.

Un entraînement sur GPU de plusieurs jours nécessite des machines virtuelles accélérées ou des nœuds GPU Kubernetes adaptés. Des points de contrôle persistants rendent Spot utilisable en limitant la progression perdue.

Expliquer un choix par étapes

Une entreprise peut d’abord réhéberger ses applications pour quitter rapidement son centre de données, puis moderniser certains composants avec des conteneurs, des plateformes d’hébergement ou des fonctions. Le réhébergement seul conserve l’ancien modèle d’exploitation.

Par exemple : « Utilise Cloud Run parce que l’API est déjà conteneurisée, que le trafic s’arrête la nuit et que l’équipe n’a pas d’administrateur de serveurs ; prévois un démarrage à froid après une période d’inactivité. »