Kubernetes: pourquoi est-il si important de configurer la gestion des ressources système?

En règle générale, il est toujours nécessaire de fournir un pool de ressources dédié à toute application pour son fonctionnement correct et stable. Mais que se passe-t-il si plusieurs applications fonctionnent sur les mêmes capacités à la fois? Comment fournir le minimum de ressources nécessaires pour chacun d'eux? Comment puis-je limiter la consommation de ressources? Comment répartir correctement la charge entre les nœuds? Comment assurer le mécanisme de mise à l'échelle horizontale en cas de charge accrue sur l'application?

Vous devez commencer par quels types de ressources de base existent dans le système - bien sûr, le temps processeur et la RAM. Dans les manifestes k8s, ces types de ressources sont mesurés dans les unités suivantes:

• CPU - dans les cœurs
• RAM - en octets

De plus, pour chaque ressource, il est possible de définir deux types d'exigences: les demandes et les limites . Demandes - décrit les exigences minimales pour les ressources libres du nœud pour exécuter le conteneur (et l'âtre dans son ensemble), tandis que limits définit une limite stricte sur les ressources disponibles pour le conteneur.

Il est important de comprendre que dans le manifeste, il n'est pas nécessaire de définir explicitement les deux types, et le comportement sera le suivant:

• Si seules les limites de la ressource sont définies explicitement, les demandes pour cette ressource prennent automatiquement une valeur égale aux limites (cela peut être vérifié en appelant des entités de description). C'est-à-dire en fait, le fonctionnement du conteneur sera limité par la même quantité de ressources dont il a besoin pour fonctionner.
• Si seules les demandes sont explicitement définies pour une ressource, aucune restriction n'est définie au-dessus de cette ressource, c'est-à-dire le conteneur n'est limité que par les ressources du nœud lui-même.

Il est également possible de configurer la gestion des ressources non seulement au niveau d'un conteneur spécifique, mais également au niveau de l'espace de noms à l'aide des entités suivantes:

• LimitRange - décrit la politique de restriction au niveau du conteneur / foyer en ns et est nécessaire pour décrire les restrictions par défaut sur le conteneur / foyer, ainsi que pour empêcher la création de conteneurs / foyers manifestement gras (ou vice versa), limiter leur nombre et déterminer la différence possible entre les limites et demandes
• ResourceQuotas - décrivent la politique de restriction en général pour tous les conteneurs en ns et est utilisé, en règle générale, pour différencier les ressources entre les environnements (utile lorsque les environnements ne sont pas rigoureusement délimités au niveau des nœuds)

Voici des exemples de manifestes dans lesquels des limites de ressources sont définies:

• Au niveau du conteneur spécifique:

  
  

  containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200m 

  
  

  C'est-à-dire dans ce cas, pour démarrer un conteneur avec nginx, vous aurez besoin d'au moins la présence d'OP 1G gratuit et de 0,2 CPU sur le nœud, tandis que le conteneur maximum peut consommer 0,2 CPU et tous les OP disponibles sur le nœud.

  
  

• Au niveau entier ns:

  
  

   apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2Gi 

  
  

  C'est-à-dire la somme de tous les conteneurs de demande dans les n par défaut ne peut pas dépasser 300 m pour le CPU et 1 G pour l'OP, et la somme de toutes les limites est de 700 m pour le CPU et 2 G pour l'OP.

  
  

• Restrictions par défaut pour les conteneurs en ns:

  
  

   apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4Gi 

  
  

  C'est-à-dire dans l'espace de noms par défaut pour tous les conteneurs, par défaut, la demande sera définie à 100 m pour le CPU et 1G pour l'OP, limite - 1 CPU et 2G. Dans le même temps, une restriction a également été établie sur les valeurs possibles dans la demande / limite pour le CPU (50m <x <2) et la RAM (500M <x <4G).

  
  

• Limitations au niveau du foyer ns:

  
  

   apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1Gi 

  
  

  C'est-à-dire pour chaque foyer dans les ns par défaut, une limite de 4 vCPU et 1G sera fixée.

  
  

J'aimerais maintenant vous dire quels avantages l'installation de ces restrictions peut nous apporter.

Le mécanisme d'équilibrage de charge entre les nœuds

Comme vous le savez, le composant k8s tel que l' ordonnanceur , qui fonctionne selon un certain algorithme, est responsable de la répartition des foyers par noeuds. Cet algorithme en train de choisir le nœud optimal à exécuter passe par deux étapes:

1. Filtrage
2. Classement

C'est-à-dire selon la politique décrite, les nœuds sont initialement sélectionnés sur lesquels un foyer peut être lancé en fonction d'un ensemble de prédicats (y compris si le nœud a suffisamment de ressources pour faire fonctionner un foyer - PodFitsResources), puis des points sont attribués pour chacun de ces nœuds, selon des priorités (y compris, plus le nœud dispose de ressources libres - plus il lui est attribué de points - LeastResourceAllocation / LeastRequestedPriority / BalancedResourceAllocation) et est exécuté sur le nœud avec le plus de points (si plusieurs nœuds remplissent cette condition à la fois, un aléatoire est sélectionné).

Dans le même temps, vous devez comprendre que le planificateur, lors de l'évaluation des ressources disponibles du nœud, se concentre sur les données stockées dans etcd - c'est-à-dire par la quantité de ressource demandée / limite de chaque pod s'exécutant sur ce nœud, mais pas par la consommation réelle de ressources. Ces informations peuvent être obtenues dans la sortie de la commande kubectl describe node $NODE , par exemple:

 # kubectl describe nodes nxs-k8s-s1 .. Non-terminated Pods: (9 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- --- ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d Allocated resources: (Total limits may be over 100 percent, ie, overcommitted.) Resource Requests Limits -------- -------- ------ cpu 487m (3%) 822m (5%) memory 15856217600 (2%) 749976320 (3%) ephemeral-storage 0 (0%) 0 (0%) 

Ici, nous voyons tous les pods s'exécutant sur un nœud particulier, ainsi que les ressources que chacun des pods demande. Et voici à quoi ressemblent les journaux du planificateur lors du démarrage du pod cronjob-cron-events-1573793820-xt6q9 (ces informations apparaissent dans le journal du planificateur lors de la définition du 10e niveau de journalisation dans les arguments de la commande de démarrage --v = 10):

 I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9 I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods. I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods. I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods. I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods. I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods. I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods. I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods. I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods. I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods. I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods. I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods. I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods. I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied. I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied. I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied. I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods. I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9 I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8 I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9 I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7 I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8 I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7 I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10) I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10) I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10) I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0) I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0) I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0) I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0) I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0) I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0) I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10) I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037 I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034 I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037 I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10" I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10 

On voit ici qu'initialement le planificateur effectue un filtrage et forme une liste de 3 nœuds sur lesquels il est possible de s'exécuter (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Il calcule ensuite des points selon plusieurs paramètres (dont BalancedResourceAllocation, LeastResourceAllocation) pour chacun de ces nœuds afin de déterminer le nœud le plus adapté. En fin de compte, il est prévu sous le nœud avec le plus de points (ici, deux nœuds ont à la fois le même nombre de points 100037, donc un aléatoire est sélectionné - nxs-k8s-s10).

Conclusion : si les pods fonctionnent sur le nœud pour lequel aucune restriction n'est définie, alors pour les k8 (du point de vue de la consommation des ressources), cela sera équivalent à comme si ces pods étaient complètement absents sur ce nœud. Par conséquent, si vous avez, par convention, un pod avec un processus vorace (par exemple, wowza) et qu'il n'y a pas de restrictions pour cela, alors une situation peut se produire lorsque en fait celui donné a mangé toutes les ressources du nœud, mais en même temps pour k8, ce nœud est considéré comme déchargé et il se verra attribuer le même nombre de points lors du classement (à savoir, en points avec une évaluation des ressources disponibles), ainsi qu'un nœud qui n'a pas de pas de travail, ce qui peut finalement conduire à une répartition inégale de la charge entre les nœuds.

Expulsion du foyer

Comme vous le savez, chacun des pods se voit attribuer l'une des 3 classes QoS:

1. guaranuted - est attribué lorsque la demande et la limite sont définies pour chaque conteneur dans l'âtre pour la mémoire et le processeur, et ces valeurs doivent correspondre
2. éclatable - au moins un conteneur dans le foyer a une demande et une limite, tandis que la demande <limite
3. meilleur effort - quand aucun récipient dans le foyer est limité en ressources

Dans le même temps, lorsqu'il y a une pénurie de ressources (disque, mémoire) sur le nœud, kubelet commence à classer et à expulser les pods selon un certain algorithme qui prend en compte la priorité du pod et de sa classe QoS. Par exemple, si nous parlons de RAM, alors sur la base de la classe QoS, les points sont attribués selon le principe suivant:

• Garanti : -998
• BestEffort : 1000
• Burstable : min (max (2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

C'est-à-dire avec la même priorité, kubelet expulsera d'abord les pods avec la classe de QoS avec le meilleur effort du nœud.

Conclusion : si vous souhaitez réduire la probabilité d'expulsion du pod nécessaire du nœud en cas de ressources insuffisantes, alors avec la priorité, vous devez également prendre soin de définir la demande / limite pour celui-ci.

Mécanisme de mise à l'échelle horizontale du foyer d'application (HPA)

Lorsque la tâche consiste à augmenter et diminuer automatiquement le nombre de pod en fonction de l'utilisation des ressources (système - CPU / RAM ou utilisateur - rps), une entité k8 comme HPA (Horizontal Pod Autoscaler) peut aider dans sa solution. Dont l'algorithme est le suivant:

1. Les lectures actuelles de la ressource observée (currentMetricValue) sont déterminées
2. Les valeurs souhaitées pour la ressource (desireMetricValue) sont déterminées, qui sont définies pour les ressources système à l'aide de la demande
3. Le nombre actuel de répliques est déterminé (currentReplicas)
4. La formule suivante calcule le nombre souhaité de répliques (répliques souhaitées)
   desireReplicas = [currentReplicas * (currentMetricValue / desireMetricValue)]

Cependant, la mise à l'échelle ne se produira pas lorsque le coefficient (currentMetricValue / desireMetricValue) est proche de 1 (nous pouvons définir l'erreur admissible nous-mêmes, par défaut, il est de 0,1).

Envisagez hpa en utilisant l'application de test d'application (décrite comme Déploiement), où il est nécessaire de modifier le nombre de répliques, en fonction de la consommation du processeur:

• Manifeste d'application

  
  

   kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-status 

  
  

  C'est-à-dire nous voyons que sous l'application, elle est initialement lancée dans deux instances, chacune contenant deux conteneurs nginx et nginx-exporter, pour chacun desquels des requêtes pour le CPU sont données.

  
  

• Manifeste HPA

  
  

   apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30 

  
  

  C'est-à-dire nous avons créé un hpa qui surveillera le test d'application de déploiement et ajustera le nombre de foyers avec l'application en fonction de l'indicateur cpu (nous nous attendons à ce que le foyer consomme 30% pour cent du CPU demandé par lui), tandis que le nombre de répliques est compris entre 2 et 10.

  
  

  Maintenant, nous considérerons le mécanisme de fonctionnement hpa si nous appliquons une charge à l'un des foyers:

  
  

    # kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi 

  
  

Au total, nous avons les éléments suivants:

• Valeur souhaitée (désiréMetricValue) - selon les paramètres hpa, nous avons 30%
• Valeur actuelle (currentMetricValue) - pour le calcul, le contrôleur-gestionnaire calcule la valeur moyenne de la consommation de ressources en%, c'est-à-dire fait conditionnellement ce qui suit:
  
  1. Obtient les valeurs absolues des mesures de foyer du serveur de mesures, c.-à-d. 101m et 4m
  2. Calcule la valeur absolue moyenne, c'est-à-dire (101m + 4m) / 2 = 53m
  3. Obtient la valeur absolue de la consommation de ressources souhaitée (pour cela, la demande de tous les conteneurs est sommée) 60m + 30m = 90m
  4. Calcule le pourcentage moyen de la consommation du processeur par rapport au foyer de la demande 53 m / 90 m * 100% = 59%

Maintenant, nous avons tout le nécessaire pour déterminer s'il est nécessaire de changer le nombre de répliques, pour cela nous calculons le coefficient:

ratio = 59% / 30% = 1.96

C'est-à-dire le nombre de répliques doit être augmenté ~ 2 fois et constituer [2 * 1,96] = 4.

Conclusion: Comme vous pouvez le voir, pour que ce mécanisme fonctionne, une condition préalable est d'inclure la disponibilité des demandes pour tous les conteneurs dans l'âtre observé.

Le mécanisme de mise à l'échelle automatique horizontale des nœuds (Cluster Autoscaler)

Afin de neutraliser l'impact négatif sur le système lors d'éclats de charge, la présence d'un hpa réglé n'est pas suffisante. Par exemple, selon les paramètres du gestionnaire de contrôleur hpa décide que le nombre de répliques doit être augmenté de 2 fois, cependant, il n'y a pas de ressources libres sur les nœuds pour exécuter un tel nombre de pods (c'est-à-dire que le nœud ne peut pas fournir les ressources demandées pour les demandes de pod) et ces pods entrer dans l'état En attente.

Dans ce cas, si le fournisseur dispose des IaaS / PaaS appropriés (par exemple, GKE / GCE, AKS, EKS, etc.), un outil tel que Node Autoscaler peut nous aider. Il vous permet de définir le nombre maximal et minimal de nœuds dans le cluster et d'ajuster automatiquement le nombre actuel de nœuds (en accédant à l'API du fournisseur de cloud pour commander / supprimer des nœuds) lorsqu'il y a une pénurie de ressources dans le cluster et que les pods ne peuvent pas être planifiés (dans l'état En attente).

Conclusion: pour pouvoir dimensionner automatiquement les nœuds, il est nécessaire de spécifier des requêtes dans les conteneurs de foyer afin que les k8 puissent évaluer correctement la charge des nœuds et signaler en conséquence qu'il n'y a pas de ressources dans le cluster pour démarrer le foyer suivant.

Conclusion

Il convient de noter que la définition de limites de ressources pour le conteneur n'est pas une condition préalable au lancement réussi de l'application, mais il est toujours préférable de le faire pour les raisons suivantes:

1. Pour un fonctionnement plus précis du planificateur en termes d'équilibrage de charge entre les nœuds k8s
2. Pour réduire la probabilité d'un événement d'éviction du foyer
3. Pour les foyers d'application à mise à l'échelle horizontale (HPA)
4. Pour une mise à l'échelle automatique horizontale des nœuds (mise à l'échelle automatique de cluster) pour les fournisseurs de cloud

Lisez également d'autres articles sur notre blog:

• Tekton Pipeline - Pipelines natifs de Kubernetes
• Création de modules dynamiques pour Nginx
• Quel a été le résultat de la migration de ClickHouse sans autorisation vers ClickHouse avec autorisation
• Comprendre le package de contexte dans Golang
• Trois astuces simples pour réduire les images de docker
• Sauvegarde d'un grand nombre de projets Web hétérogènes