Objectifs du chapitre et prérequis

Jusqu’à maintenant, les applications déployées étaient démarrées avec un seul pod et le passage à plusieurs se faisait manuellement à l’aide de la commande kubectl scale. Les mécanismes d’anti-affinité ont été également abordés lors de la mise en place des contrôleurs Ingress (Nginx et Traefik) afin d’augmenter la résilience du système.

Pour la gestion de la redondance d’une application ou pour un petit nombre de services, ces mécanismes sont suffisants. En revanche, dans un contexte un peu plus dynamique, cette gestion peut vite devenir problématique.

Ce chapitre a pour vocation de présenter la montée en charge horizontale (Horizontal Pod Autoscaler) et les prérequis nécessaires pour sa bonne mise en œuvre (metrics-server et attribution des ressources). Montée en charge

Autre aspect qui sera abordé : la mise en place de groupes de machines avec des fonctions différentes : présence de GPU, ratio mémoire/CPU différent. Le lecteur abordera également la notion d’instances dites « Spots » afin de réaliser des économies là où c’est possible.

Pour consulter la suite, découvrez le livre suivant :
couv_EI2KUB.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Protection de l’application WordPress
Suivant
Le serveur de métriques