Editions ENI Livres | Vidéos | e-Formations
Montée en charge automatique
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).
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.
Le serveur de métriques
1. Présentation de la brique metrics-server
Le serveur de métriques a pour rôle de collecter les consommations des différents éléments d’un cluster Kubernetes pour les mettre à disposition.
Ce serveur va scruter l’activité de deux types d’éléments : les pods et les nœuds du cluster. Les métriques récupérées concerneront la consommation CPU et mémoire.
2. Activation du serveur de métriques
a. Vérification de la présence du serveur de métriques
Le serveur de métriques porte le label k8s-app=metrics-server et est lancé dans l’espace de noms kube-system.
Vérifiez sa présence à l’aide de la commande suivante :
$ kubectl -n kube-system get pods -l k8s-app=metrics-server Dans certains cas, le label à vérifier sera app=metrics-server. Si la commande ne remonte rien avec le label k8s-app, faites le même test avec le label app=metrics-server.
Dans le cas où le serveur serait présent (ce qui sera sûrement le cas pour des clusters managés), la commande retournera le résultat suivant :
NAME READY STATUS RESTARTS AGE
metrics-server-77fddcc-95crc 1/1 ...Activation de la montée en charge automatique
1. Test avec l’application MailHog
Le serveur de métriques est en place et il permet de consulter la consommation des briques de base du cluster (nœuds et pods). Il ne s’agit toutefois pas du seul point important à remplir.
En effet, la montée en charge automatique nécessite de définir la capacité des pods. Outre le fait que cette limitation permet d’éviter un emballement de la consommation des ressources, elle va permettre d’indiquer à quel moment va se déclencher une augmentation ou une diminution du nombre de pods.
Les tests de charge se feront à l’aide de l’application MailHog. Afin de simplifier les choses au maximum, la persistance de données ne sera pas active. Au niveau de la capacité de chaque pod, ces derniers auront 10 millièmes de CPU (10m) réservés et la même quantité au maximum.
Afin de déterminer au mieux les valeurs à utiliser pour démarrer un pod, il est nécessaire de mettre en place un outil de suivi des consommations des ressources système. N’hésitez pas à consulter le chapitre sur la surveillance à l’aide de Prometheus.
Ci-dessous le fichier de déploiement qui sera utilisé pour les tests :
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mailhog
name: mailhog
spec:
selector:
matchLabels:
app: mailhog
template:
metadata:
labels:
app: mailhog
spec:
containers:
- image: mailhog/mailhog
name: mailhog
resources:
requests:
memory: "64Mi"
cpu: "10m"
limits:
memory: "64Mi"
cpu: "10m" Cette déclaration est présente dans le fichier deployment.yaml du répertoire mailhog à côté...
Scalabilité des nœuds d’un cluster
1. Contexte
La montée en charge automatique d’un déploiement a été abordée. En revanche, en cas de saturation d’un nœud, l’administrateur doit intervenir afin d’augmenter la capacité de traitement du cluster en ajoutant de nouvelles machines.
Dans le cas d’un cluster maison, il n’y a malheureusement pas de solutions miracles : il sera nécessaire de créer une nouvelle machine puis de l’intégrer à l’aide de Kubespray.
En revanche, pour un cluster managé, il est tout à fait possible de créer - ou supprimer - automatiquement des nœuds à la demande.
2. Présentation de l’autoscaler
L’autoscaler est un service Kubernetes qui scrute l’état des nouvelles demandes de pods afin de savoir s’il faut créer ou non de nouveaux nœuds. Les pods à l’état Pending (suite à un déficit de mémoire ou CPU) rentrent dans ces critères.
Ci-dessous un exemple d’événement associé à un pod indiquant un déficit de CPU :
0/3 nodes are available: 3 Insufficient cpu. 3. Activation de l’autoscaler avec Google Cloud
Pour récupérer les clusters existants, utilisez la commande suivante :
$ gcloud container clusters list La commande renverra les caractéristiques des clusters existants ainsi que leurs régions.
Sous Google, l’activation de l’autoscaler peut se faire depuis l’interface web ou en ligne de commande avec gcloud. Cette commande prend en paramètre les options suivantes :
-
Les instructions containers clusters update suivies du nom du cluster.
-
Les options d’activation de l’autoscaling (--enable-autoscaling).
-
Le nombre min/max de nœuds (--min-nodes et --max-nodes).
-
La région à utiliser pour le lancement des nœuds (--region).
Pour activer l’autoscaler du cluster eni-test afin qu’il dispose de 1 à 5 nœuds maximum dans la région europe-west3-c, lancez la commande suivante :
$ gcloud container clusters update eni-test \
--enable-autoscaling --min-nodes=1 --max-nodes=5 \
--region europe-west3-c 4. Activation de l’autoscaler...
Définition de groupes de machines
1. Contexte
Jusqu’à maintenant, l’utilisateur a toujours fait appel à des groupes de machines uniformes :
-
Même quantité de mémoire.
-
Même nombre de CPU
En plus de ces caractéristiques, d’autres critères peuvent entrer en jeu :
-
Souhait de séparer les types de charges applicatives (base de données, serveurs web).
-
Utilisation de machines avec des ratios CPU/mémoire différents.
-
Utilisation de GPU pour du calcul vectoriel.
-
Réduction de sa facture à l’aide de nœuds à disponibilité non garantie (instance Spot).
Toutes ces raisons peuvent mener l’administrateur à séparer les différents types de charge sur des groupes de machines différents.
2. Les différents types de machines
a. Les machines préemptives (Spot)
Une instance Spot désigne - dans le jargon des fournisseurs d’informatique dans les nuages - des machines disponibles à bas prix mais avec une disponibilité non garantie ou à coût variable.
La différence de coût peut être importante (typiquement d’un facteur trois ou quatre voire beaucoup plus, certains types de machines peuvent avoir des ristournes appliquées de 90 %). La contrepartie étant que ces machines peuvent être réquisitionnées très rapidement par le fournisseur cloud ou être soumises à un jeu d’enchères.
Cette différence de coûts s’explique très facilement : afin d’absorber les pics de charge, le fournisseur dispose d’une capacité de traitement très importante. En dehors de ces périodes, ces réserves de puissance sont sous-utilisées : il devient possible de les utiliser à bas coût.
Un cas typique d’utilisation de ce type de machines peut s’imaginer lors de gros traitements durant les périodes de faible activité (la nuit, durant les vacances d’été, en dehors des périodes de soldes, etc.). Reste à disposer d’une application compatible avec ce mode de fonctionnement. Il est par exemple préférable que les applications supportent les pannes, des arrêts non planifiés ou le décalage...
