Cette rubrique décrit l'architecture technique, le modèle de ressources hybrides et la qualité de service (QoS) au niveau des nœuds pour la colocalisation des charges de travail en ligne et hors ligne, afin de vous aider à comprendre et à utiliser la colocalisation dans ACK.
Contexte
La colocalisation déploie différents types de charges de travail dans le même cluster et sur le même nœud afin d'améliorer l'utilisation des ressources. Les charges de travail sont classées selon les objectifs de niveau de service (SLO) : les charges de travail sensibles à la latence (LS) ont généralement des cibles en termes de requêtes par seconde (QPS) ou de temps de réponse (RT) et bénéficient d'une QoS haute priorité, tandis que les charges de travail best-effort (BE) sont intensives en calcul, tolérantes aux pannes et bénéficient d'une QoS basse priorité.
Les différents rôles se concentrent sur des aspects distincts de la colocalisation :
Administrateur des ressources du cluster : surveille les limites, l'allocation et l'utilisation des ressources par charge de travail afin d'améliorer l'utilisation et de réduire les coûts.
Administrateur des charges de travail LS : atténue les interférences entre conteneurs dues à la contention des ressources, qui peuvent entraîner une augmentation de la latence aux 90e et 99e percentiles et dégrader la qualité du service.
Administrateur des charges de travail BE : utilise la surconsommation classifiée des ressources pour respecter les SLO des charges de travail.
ACK fournit les mécanismes de colocalisation suivants :
Un modèle de QoS de colocalisation avec des priorités de ressources configurables.
Une surconsommation de ressources stable et fiable.
Une orchestration et une isolation fines des ressources Kubernetes.
Une planification améliorée des charges de travail.
Architecture
ACK utilise ack-koordinator pour respecter les SLO des charges de travail dans les scénarios de colocalisation. ack-koordinator est composé d'un contrôleur SLO (une extension Kubernetes, déployée en tant que Deployment) et d'un agent SLO (déployé en tant que DaemonSet) qui étend kubelet avec des capacités de colocalisation.
La solution de colocalisation consciente des SLO utilise des CRD pour enregistrer les métriques des nœuds, les configurations de QoS et l'application des politiques, et suit les ressources disponibles pour la surconsommation dynamique en tant que ressources étendues standard. Chaque composant offre les fonctionnalités suivantes :
Contrôleur SLO : surveille les charges des nœuds, gère la surconsommation des ressources et garantit les SLO en fonction des profils de ressources.
Recommender : établit des profils de ressources et estime la demande maximale de charge de travail pour simplifier la configuration des ressources des conteneurs.
Koordlet : surveille les charges des nœuds, détecte les anomalies et isole dynamiquement les ressources pour supprimer les interférences en boucle fermée.
Planificateur ACK : optimise la colocalisation consciente des SLO, par exemple en dispersant les pods lors de la surconsommation dynamique.
Koordinator Descheduler : déployé en tant que Deployment pour la replanification des pods.
Modèle de ressources
Kubernetes gère les ressources des conteneurs via des demandes (requests) et des limites (limits). Pour éviter la contention, les administrateurs surprovisionnent souvent les charges de travail LS, ce qui laisse les ressources demandées sous-utilisées.
Le bloc vert indique les ressources disponibles pour la surconsommation dynamique. Ces ressources sont allouées aux charges de travail BE pour respecter les SLO et améliorer l'utilisation globale.
ack-koordinator quantifie les ressources susceptibles d'être surconsommées, calcule les ressources récupérées en temps réel et les synchronise en tant que ressources étendues standard vers les métadonnées des nœuds Kubernetes.
Exemple de modèle YAML du nœud :
status:
allocatable:
# milli-core
kubernetes.io/batch-cpu: 50000
# bytes
kubernetes.io/batch-memory: 50000
capacity:
kubernetes.io/batch-cpu: 50000
kubernetes.io/batch-memory: 100000Les pods BE ont une priorité inférieure à celle des pods LS. Pour utiliser les ressources récupérées, ajoutez les champs qos et batch au fichier YAML du pod BE. qos: LS définit une priorité élevée ; qos: BE définit une priorité faible. batch-cpu et batch-memory spécifient les demandes de ressources du pod. Consultez Activer la surconsommation dynamique des ressources.
Exemple de modèle YAML du pod BE :
metadata:
labels:
koordinator.sh/qosClass: "BE" # Set the QoS class to BE or LS.
spec:
containers:
- resources:
limits:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048
requests:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048QoS au niveau des nœuds
QoS CPU
La QoS CPU, basée sur Alibaba Cloud Linux, réserve des ressources CPU pour les pods LS en configurant les priorités de planification Linux via la fonctionnalité d'identité de groupe d'ack-koordinator. Dans les environnements de colocalisation, les pods LS bénéficient d'une priorité élevée et les pods BE d'une priorité faible, ce qui empêche la contention des ressources et garantit la qualité du service LS.
Avantages de la QoS CPU :
Réduction minimale de la latence de réveil des tâches pour les charges de travail LS.
Les réveils des tâches BE n'affectent pas les performances des pods LS.
Les tâches BE ne peuvent pas utiliser le planificateur SMT pour partager les cœurs CPU, ce qui réduit encore davantage l'impact sur les performances des pods LS.
Suppression CPU (CPU Suppress)
La quantité de ressources susceptibles d'être surconsommées dynamiquement varie en fonction de l'utilisation des pods LS et peut être allouée aux pods BE. La suppression CPU limite l'utilisation du CPU par les pods BE afin de garantir que les pods LS sur le nœud disposent de ressources suffisantes.
Sur le schéma, le seuil CPU représente le seuil d'utilisation du CPU du nœud, Pod (LS).Usage correspond à l'utilisation du CPU par les pods LS, et la restriction CPU pour BE représente l'utilisation du CPU par les pods BE. L'allocation du CPU aux pods BE s'ajuste en fonction des fluctuations de l'utilisation des pods LS, permettant aux pods BE d'exploiter les ressources inactives tout en empêchant la contention lorsque les charges LS augmentent.
Explosion CPU (CPU Burst)
Les limites CPU de Kubernetes plafonnent l'utilisation du CPU par conteneur sur une période donnée. Par exemple, CPU Limit=2 limite un conteneur à 200 ms de temps CPU par période de 100 ms.
Le schéma illustre l'allocation des threads pour un conteneur d'application web sur un nœud à quatre vCores avec une limite CPU définie sur 2. Malgré une faible utilisation globale du CPU, le thread 2 ne peut reprendre qu'à la troisième période de 100 ms, car une limitation du CPU survient durant la deuxième période. Cela augmente le temps de réponse (RT) et provoque une latence de longue traîne.
L'explosion CPU résout la latence de longue traîne dans les charges de travail LS en permettant aux conteneurs d'accumuler des tranches de temps CPU inactives pour gérer les pics de demande. ACK prend en charge l'explosion CPU sur toutes les versions de kernel compatibles. Pour les kernels incompatibles, ACK surveille la limitation du CPU et ajuste dynamiquement les limites CPU des conteneurs pour obtenir un effet similaire.
QoS mémoire
Les conteneurs sont soumis aux limites de mémoire suivantes :
Limite de mémoire du conteneur : lorsque l'utilisation de la mémoire (y compris le cache de pages) approche de la limite, le noyau du système d'exploitation déclenche une récupération de mémoire, ce qui peut empêcher l'application de demander ou de libérer de la mémoire comme prévu.
Limite de mémoire du nœud : lorsque la limite de mémoire d'un conteneur dépasse sa demande, il peut surconsommer de la mémoire. Si la mémoire disponible du nœud devient insuffisante, le noyau du système d'exploitation récupère de la mémoire auprès des conteneurs, ce qui peut sévèrement dégrader les performances des applications dans les scénarios de colocalisation.
ack-koordinator fonctionne avec Alibaba Cloud Linux pour activer la QoS mémoire pour les pods. Il configure automatiquement le memcg en fonction des paramètres du conteneur et active les fonctionnalités de QoS memcg, de récupération asynchrone en arrière-plan et d'évaluation du filigrane minimum global. Cela optimise les performances des applications sensibles à la mémoire tout en garantissant une planification équitable de la mémoire.
Fonctionnalités de la QoS mémoire :
Lorsque l'utilisation de la mémoire d'un pod approche de sa limite, le memcg récupère la mémoire de manière asynchrone pour éviter une récupération complète synchrone, minimisant ainsi l'impact sur les performances de l'application.
Lorsque la mémoire du nœud est insuffisante, la mémoire est récupérée en priorité auprès des pods dont l'utilisation dépasse la demande, empêchant ainsi les pods en surconsommation de dégrader les autres.
-
Les demandes de mémoire des pods LS sont prioritaires, réduisant la probabilité de déclencher une récupération complète de la mémoire du nœud.
memory.limit_in_bytes : la limite supérieure de la mémoire pouvant être utilisée par un pod.
memory.high : le seuil de limitation de la mémoire.
memory.wmark_high : le seuil de récupération de la mémoire.
memory.min : le seuil de verrouillage de la mémoire.
Isolation des ressources basée sur le cache L3 et MBA
Les conteneurs colocatés partagent le cache L3 du nœud (cache de dernier niveau), avec une bande passante mémoire contrôlée par l'allocation de bande passante mémoire (MBA). ECS Bare Metal Instance (EBM) fournit la fonctionnalité LLC pour ajuster dynamiquement le cache CPU des pods et la fonctionnalité MBA pour contrôler la distribution de la bande passante mémoire. ack-koordinator limite davantage les ressources des pods BE de manière fine pour protéger les performances des pods LS.
Étapes suivantes
Consultez Prise en main pour créer un environnement de colocalisation LS et BE avec ack-koordinator. Fonctionnalités de colocalisation connexes :