Concepts liés à la scalabilité
Avant de trouver une solution de mise à l’échelle, vous devez comprendre la scalabilité et la manière dont elle s’applique aux applications Kubernetes.
Dans cette unité, nous passons en revue certains concepts de la scalabilité.
Évolutivité
La scalabilité est le terme utilisé pour décrire la capacité d’une application ou d’un système à gérer une plus grande quantité de travail grâce à l’ajout de ressources supplémentaires.
Dans notre exemple de scénario, le nombre de requêtes client correspondant à la quantité de travail faisant l’objet d’une augmentation. Vous pouvez représenter la quantité de ressources ajoutées de deux manières différentes : scalabilité verticale et scalabilité horizontale.
Scale-up
La scalabilité verticale ou scale-up fait référence à la mise à l’échelle d’un système en ajoutant des ressources physiques, par exemple la puissance de processeur et de mémoire. Par exemple, si le site web de votre société consomme trop de mémoire, vous pouvez mettre à jour votre instance de machine virtuelle en y ajoutant de la mémoire tout en conservant la même application sous-jacente.
En résumé, la mise à l’échelle verticale concerne l’augmentation de la taille de la machine virtuelle tout en conservant le même nombre d’applications. Cette approche est utile avec des applications monolithiques qui demandent une puissance de calcul très importante, mais sont trop coûteuses à diviser en parties plus petites. Ces applications sont principalement hébergées sur des machines virtuelles plutôt que sur des systèmes distribués.
Malgré un coût plus gérable, les machines virtuelles très volumineuses peuvent devenir très onéreuses. Le coût d’ajout de puissance de calcul est plus élevé que le coût de duplication de petites machines virtuelles. Il existe une limite supérieure au nombre de ressources que vous pouvez ajouter à une seule machine virtuelle. Cela signifie que vous devez dupliquer la machine virtuelle une fois que vous avez atteint la limite supérieure.
L'extensibilité horizontale
L’extensibilité horizontale ou scale-out fait référence à la mise à l’échelle d’un système en dupliquant l’application et en équilibrant la charge entre les instances d’application.
La mise à l’échelle horizontale est utile pour des applications distribuées, telles que celles déployées dans AKS et des systèmes sans état, car vous pouvez faire tourner plusieurs conteneurs avec la même application dans une seule machine virtuelle. La mise à l’échelle vous permet d’extraire le plus de ressources tout en continuant à payer pour une seule machine virtuelle.
Dans notre exemple de scénario, le site de votre entreprise est sans état. Cela signifie que la mise à l’échelle out est le meilleur plan d’action. Kubernetes fournit une ressource prête à l’emploi appelée HorizontalPodAutoscaler (HPA) qui vous permet d’effectuer un scale-out de vos déploiements.
Scalabilité manuelle sur Kubernetes
Avant de couvrir le HPA, examinons comment mettre à l’échelle une application Kubernetes de façon manuelle.
Chaque déploiement est lié à une autre ressource appelée ReplicaSet. Un ReplicaSet est chargé du maintien d’un « état de réplica souhaité » et de la mise à l’échelle de l’application réelle pour que l’état souhaité reste identique à l’état réel. Vous pouvez contrôler le nombre de réplicas dans un déploiement via la clé spec.replicas dans la spécification de déploiement. Cette clé définit le nombre de réplicas souhaités dans le ReplicaSet sous-jacent et force le contrôleur de réplica à conserver le nombre de réplicas à tout moment.
Vous pouvez également contrôler le nombre de réplicas d’un déploiement avec la commande kubectl scale deploy/contoso-website --replicas <number>. Elle change de manière dynamique le nombre de réplicas souhaité dans un déploiement et effectue un scale-in ou un scale-out de l’application.
HorizontalPodAutoscaler (HPA)
Le HPA est la ressource native de la version 1.8 de Kubernetes et des versions suivantes, qui permet un scale-out des pods du cluster. Elle surveille toutes les 30 secondes les modifications apportées au nombre de réplicas souhaité dans l’API des métriques. Si le nombre de réplicas souhaité est différent du nombre de réplicas actuel, le gestionnaire de contrôleur gérant les objets HPA effectue un scale-in ou un scale-out du déploiement.
Les HPA fonctionnent avec le groupe d’API autoscaling dans Kubernetes. Il existe deux versions de ce groupe d’API : v1 et v2. La version v1 permet au déploiement de se mettre à l’échelle en fonction des mesures du processeur uniquement. La version v2 permet le monitoring natif du processeur et de la mémoire. Dans ce module, nous utilisons la version v2.
Chaque HPA est attaché à une référence de mise à l’échelle, définie dans la clé spec.scaleTargetRef du manifeste HPA. Cette référence de mise à l’échelle doit comporter des pods sous-jacents à mettre à l’échelle. Dans le cas contraire, le HPA ne fonctionne pas, car il n’est pas possible d’appliquer une mise à l’échelle à des objets qui ne peuvent pas être mis à l’échelle, comme les DaemonSet.
Il est important qu’une demande de ressource soit définie dans les spécifications de chaque pod. L’algorithme HPA ne peut pas correctement calculer les métriques et déterminer l’utilisation des ressources sans ce paramètre. Vous pouvez définir cette limitation via la clé spec.template.spec.containers[].resources dans le manifeste de déploiement, comme illustré dans l’exemple suivant :
spec:
template:
spec:
containers:
- resources:
requests:
cpu: 250m
memory: 256M
limits:
cpu: 500m
memory: 512M
Exemple de manifeste HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50