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

En général, il est toujours nécessaire de fournir un pool de ressources dédiées à une application pour son bon fonctionnement. Mais que faire si plusieurs applications fonctionnent sur les mêmes ressources ? Comment garantir que chacune d'elles dispose du minimum nécessaire ? Comment limiter la consommation de ressources ? Comment répartir efficacement la charge entre les nœuds ? Comment faire en sorte que le mécanisme de mise à l'échelle horizontale fonctionne lors d'une augmentation de la charge sur les applications ?

Il faut d'abord tenir compte des principaux types de ressources disponibles dans le système — à savoir le temps processeur et la mémoire vive. Dans les manifestes k8s, ces types de ressources sont mesurés dans les unités suivantes :

CPU — en cœurs
RAM — en octets

Pour chaque ressource, il est possible de définir deux types de demandes — requests et limits. Requests — décrit les exigences minimales en termes de ressources libre sur le nœud pour faire fonctionner le conteneur (et le pod en général), tandis que limits fixe une limite stricte des 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 seul limits est spécifié pour la ressource, alors requests pour cette ressource prend automatiquement la valeur de limits (ce qui peut être vérifié en appelant describe de l'entité). Cela signifie que le fonctionnement du conteneur sera limité au même nombre de ressources dont il a besoin pour son lancement.
Si seules requests sont spécifiées pour la ressource, aucune restriction supérieure n'est imposée — c'est-à-dire que le conteneur n'est limité que par les ressources du nœud lui-même.

Il est également possible de gérer les ressources non seulement au niveau du conteneur spécifique, mais aussi au niveau du namespace à l'aide des entités suivantes :

LimitRange — décrit la politique de limitation au niveau du conteneur/pod dans le ns et est nécessaire pour définir les limitations par défaut sur le conteneur/pod, ainsi que pour prévenir la création de conteneurs/pods manifestement surdimensionnés (ou inversement), limiter leur quantité et déterminer la différence possible entre les limits et requests.
ResourceQuotas — décrit la politique de limitation en général pour tous les conteneurs dans le ns et est généralement utilisée pour la répartition des ressources par environnement (utile lorsque les environnements ne sont pas strictement séparés au niveau des nœuds)

Ci-dessous sont des exemples de manifestes où des limites de ressources sont établies :

Au niveau d'un conteneur spécifique :
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
C'est-à-dire que, dans ce cas, pour exécuter un conteneur avec nginx, il faut au minimum avoir 1G de RAM libre et 0,2 CPU sur le nœud, tout en sachant que le conteneur peut consommer jusqu'à 0,2 CPU et toute la RAM disponible sur le nœud.
Au niveau de tout le 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 que la somme de toutes les demandes des conteneurs dans le ns par défaut ne peut pas dépasser 300m pour le CPU et 1G pour la RAM, tandis que la somme de toutes les limites ne peut pas dépasser 700m pour le CPU et 2G pour la RAM.
Limites par défaut pour les conteneurs dans le 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 que dans le namespace par défaut, une demande de 100m pour le CPU et 1G pour la RAM sera établie par défaut pour tous les conteneurs, avec une limite de 1 CPU et 2G. De plus, une restriction sur les valeurs possibles dans la demande/limite pour le CPU (50m < x < 2) et la RAM (500M < x < 4G) est également définie.
Limites au niveau des pods dans le ns :
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
C'est-à-dire que pour chaque pod dans le ns par défaut, une limite de 4 vCPU et 1G sera appliquée.

Maintenant, j'aimerais parler des avantages que nous pouvons tirer de l'établissement de ces limites.

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

Comme nous le savons, la répartition des pods entre les nœuds est assurée par un composant de k8s, scheduler, qui fonctionne selon un certain algorithme. Cet algorithme passe par deux étapes lors du choix du nœud optimal pour le lancement :

Filtrage
Classement

C'est-à-dire qu'en fonction de la politique décrite, les nœuds sur lesquels le pod peut être exécuté sont initialement sélectionnés sur la base de plusieurs predicates (y compris la vérification que la ressource du nœud est suffisante pour exécuter le pod — PodFitsResources), puis pour chacun de ces nœuds, selon priorities des points sont attribués (plus les ressources de la node sont libres, plus elle reçoit de points — LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) et se lance sur la node avec le plus de points (si plusieurs nodes remplissent cette condition, l'une d'elles est choisie au hasard).

Il faut comprendre que le scheduler évalue les ressources disponibles de la node en se basant sur les données stockées dans etcd — c'est-à-dire sur la somme des ressources demandées/limites de chaque pod lancé sur cette node, mais pas sur la consommation réelle des ressources. Ces informations peuvent être obtenues en exécutant 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, i.e., 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 lancés sur une node spécifique ainsi que les ressources requises par chacun d'eux. Voici à quoi ressemblent les logs du scheduler lors du lancement du pod cronjob-cron-events-1573793820-xt6q9 (ces informations apparaîtront dans les logs du scheduler si le niveau de log est réglé sur 10 lors de l'exécution en définissant les arguments de la commande —v=10) :

log

I1115 07:57:21.637791       1 scheduling_queue.go:908] Tentative de planifier le pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Tentative de planifier le pod : nxs-stage\/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s5 est autorisée, le nœud exécute seulement 16 sur 110 pods.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s6 est autorisée, le nœud exécute seulement 20 sur 110 pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s3 est autorisée, le nœud exécute seulement 20 sur 110 pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s4 est autorisée, le nœud exécute seulement 17 sur 110 pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s10 est autorisée, le nœud exécute seulement 16 sur 110 pods.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s12 est autorisée, le nœud exécute seulement 9 sur 110 pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s11 est autorisée, le nœud exécute seulement 11 sur 110 pods.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s1 est autorisée, le nœud exécute seulement 19 sur 110 pods.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s2 est autorisée, le nœud exécute seulement 21 sur 110 pods.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s9 est autorisée, le nœud exécute seulement 16 sur 110 pods.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s8 est autorisée, le nœud exécute seulement 18 sur 110 pods.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s13 est autorisée, le nœud exécute seulement 8 sur 110 pods.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s10 est autorisée, les termes d'anti-affinité des pods existants sont satisfaits.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s8 est autorisée, les termes d'anti-affinité des pods existants sont satisfaits.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s9 est autorisée, les termes d'anti-affinité des pods existants sont satisfaits.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] La planification du pod nxs-stage\/cronjob-cron-events-1573793820-xt6q9 sur le nœud nxs-k8s-s7 est autorisée, le nœud exécute seulement 25 sur 110 pods.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10 : AllocationRessourceÉquilibrée, capacité 39900 millicores 66620178432 octets mémoire, demande totale 2343 millicores 9640186880 octets mémoire, score 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10 : AllocationRessourceMinimale, capacité 39900 millicores 66620178432 octets mémoire, demande totale 2343 millicores 9640186880 octets mémoire, score 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9 : AllocationRessourceÉquilibrée, capacité 39900 millicores 66620170240 octets mémoire, demande totale 4107 millicores 11307422720 octets mémoire, score 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8 : AllocationRessourceÉquilibrée, capacité 39900 millicores 66620178432 octets mémoire, demande totale 5847 millicores 24333637120 octets mémoire, score 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9 : AllocationRessourceMinimale, capacité 39900 millicores 66620170240 octets mémoire, demande totale 4107 millicores 11307422720 octets mémoire, score 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8 : AllocationRessourceMinimale, capacité 39900 millicores 66620178432 octets mémoire, demande totale 5847 millicores 24333637120 octets mémoire, score 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10 : PrioritéToléranceTaints, Score : (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8 : PrioritéToléranceTaints, Score : (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9 : PrioritéToléranceTaints, Score : (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10 : PrioritéAffinitéNœud, Score : (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8 : PrioritéAffinitéNœud, Score : (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9 : PrioritéAffinitéNœud, Score : (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10 : PrioritéAffinitéInterPod, Score : (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8 : PrioritéAffinitéInterPod, Score : (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9 : PrioritéAffinitéInterPod, Score : (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9 : PrioritéRépartitionSélecteur, Score : (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Hôte nxs-k8s-s10 => Score 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Hôte nxs-k8s-s8 => Score 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Hôte nxs-k8s-s9 => Score 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumerVolumesPod pour le pod "nxs-stage\/cronjob-cron-events-1573793820-xt6q9", nœud "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumerVolumesPod pour le pod "nxs-stage\/cronjob-cron-events-1573793820-xt6q9", nœud "nxs-k8s-s10" : tous les PVC sont liés et rien à faire                                                                             
I1115 07:57:21.639333       1 factory.go:733] Tentative de lier cronjob-cron-events-1573793820-xt6q9 à nxs-k8s-s10

Ici, nous voyons qu'initialement, le scheduler effectue une filtration et forme une liste de 3 nœuds sur lesquels un déploiement est possible (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Il procède ensuite au calcul des points selon plusieurs paramètres (y compris BalancedResourceAllocation, LeastResourceAllocation) pour chacun de ces nœuds afin de déterminer le nœud le plus approprié. En fin de compte, le déploiement se fait sur le nœud avec le plus grand nombre de points (ici, deux nœuds ont le même score de 100037, donc un est choisi au hasard — nxs-k8s-s10).

Sortie: si des pods fonctionnent sur un nœud sans limitations définies, cela signifie pour k8s (en termes de consommation de ressources) qu'il est équivalent à la situation où ces pods n'existent pas sur ce nœud. Donc, si vous avez, par exemple, un pod avec un processus gourmand (comme wowza) et qu'aucune limite n'est définie, il pourrait arriver que ce pod consomme toutes les ressources du nœud, mais pour k8s, ce nœud est considéré comme non chargé et recevra le même nombre de points lors du classement (dans les points d'évaluation des ressources disponibles), qu'un nœud sans pods en fonctionnement, ce qui peut finalement conduire à une répartition inégale de la charge entre les nœuds.

Éviction d'un pod

Comme on le sait, à chaque pod est attribuée l'une des 3 classes QoS :

garanti — attribuée lorsque, pour chaque conteneur dans le pod, un request et un limit de mémoire et CPU sont définis, ces valeurs devant coïncider
instances burstable. — lorsqu'au moins un conteneur dans le pod a un request et un limit, avec request < limit
meilleur effort — lorsque aucun conteneur dans le pod n'est limité en ressources

Cependant, lorsque le nœud manque de ressources (disque, mémoire), kubelet commence à classer et à évincer les pods selon un algorithme déterminé, tenant compte de la priorité du pod et de sa classe QoS. Par exemple, en ce qui concerne la RAM, des points sont attribués selon la classe QoS selon le principe suivant :

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

Ainsi, avec une priorité identique, kubelet évincera en priorité les pods avec la classe QoS meilleur effort.

Sortie: si vous souhaitez réduire la probabilité d'éviction d'un pod important sur un nœud en cas de manque de ressources, il est nécessaire, en plus de la priorité, de s'assurer de définir un request/limit pour celui-ci.

Mécanisme de mise à l'échelle horizontale automatique des pods d'application (HPA)

Lorsqu'il s'agit d'augmenter ou de diminuer automatiquement le nombre de pods en fonction de l'utilisation des ressources (système — CPU/RAM ou utilisateur — rps), une entité k8s telle que HPA (Horizontal Pod Autoscaler) peut aider dans cette solution. Son algorithme est le suivant :

Les valeurs des ressources observées actuelles (currentMetricValue) sont déterminées
Les valeurs souhaitées pour la ressource (desiredMetricValue) sont déterminées, qui pour les ressources système sont définies à l'aide de la demande
Le nombre actuel de répliques (currentReplicas) est déterminé
Le nombre de répliques souhaité (desiredReplicas) est calculé selon la formule suivante
desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]

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

Considérons le fonctionnement de l'HPA à l'aide de l'application app-test (décrite comme un déploiement), où il est nécessaire de modifier le nombre de répliques en fonction de la consommation du CPU :

Manifeste de l'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 que nous voyons que le pod avec l'application est initialement exécuté en deux exemplaires, chacun contenant deux conteneurs nginx et nginx-exporter, pour lesquels est défini requests pour le CPU.

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 que nous avons créé un HPA qui surveillera le déploiement app-test et régulera le nombre de pods avec l'application en fonction de l'indicateur de CPU (nous nous attendons à ce que le pod consomme 30 % de l'CPU qui lui est demandé), tout en maintenant le nombre de répliques dans la plage de 2 à 10.

Maintenant, considérons le mécanisme de fonctionnement de l'HPA, si une charge est appliquée à l'un des pods :

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

En résumé, nous avons ce qui suit :

La valeur désirée (desiredMetricValue) — selon les paramètres hpa, est de 30%
La valeur actuelle (currentMetricValue) — pour le calcul, le controller-manager évalue la consommation moyenne des ressources en %, c'est-à-dire qu'il effectue l'opération suivante :
1. Il obtient les valeurs absolues des métriques des pods à partir du serveur de métriques, c'est-à-dire 101m et 4m
2. Il calcule la valeur moyenne absolue, c'est-à-dire (101m + 4m) / 2 = 53m
3. Il obtient la valeur absolue pour la consommation souhaitée de ressources (pour cela, il additionne les requêtes de tous les conteneurs) 60m + 30m = 90m
4. Il calcule le pourcentage moyen de consommation CPU par rapport à la demande du pod, c'est-à-dire 53m / 90m * 100% = 59%

Maintenant, nous avons tout ce qu'il faut pour déterminer si le nombre de réplicas doit être modifié, pour cela, nous calculons le ratio :

ratio = 59% / 30% = 1.96

C'est-à-dire que le nombre de réplicas doit être multiplié par ~2, ce qui donne [2 * 1.96] = 4.

Conclusion : Comme on peut le constater, pour que ce mécanisme fonctionne, il est également nécessaire d'avoir des requêtes pour tous les conteneurs dans le pod observé.

Mécanisme d'autoscaling horizontal des nœuds (Cluster Autoscaler)

Pour atténuer l'impact négatif sur le système lors de pics de charge, le simple fait d'avoir un hpa configuré peut ne pas suffire. Par exemple, selon les paramètres dans le hpa, le manager du contrôleur décide que le nombre de réplicas doit être multiplié par 2, cependant, il n'y a pas de ressources libres sur les nœuds pour exécuter ce nombre de pods (c'est-à-dire que le nœud ne peut pas fournir les ressources demandées par les pods). Ces pods passent alors dans un état Pending.

Dans ce cas, si le fournisseur dispose d'une IaaS/PaaS appropriée (par exemple, GKE/GCE, AKS, EKS, etc.), un outil tel que Node Autoscaler. Cela permet de définir un nombre maximal et minimal de nœuds dans le cluster et de réguler automatiquement le nombre actuel de nœuds (en appelant l'API du fournisseur cloud pour commander/supprimer un nœud), lorsque des pénuries de ressources sont observées dans le cluster et que les pods ne peuvent pas être programmés (se trouvent en état Pending).

Conclusion : Pour permettre l'autoscaling des nœuds, il est nécessaire de définir des requêtes dans les conteneurs des pods, afin que k8s puisse évaluer correctement la charge des nœuds et indiquer qu'il n'y a pas suffisamment de ressources dans le cluster pour démarrer le prochain pod.

Conclusion

Il convient de noter que la mise en place de limites de ressources pour le conteneur n'est pas une condition nécessaire au démarrage réussi de l'application, mais il est néanmoins préférable de le faire pour les raisons suivantes :

Pour un fonctionnement plus précis du scheduler en ce qui concerne la répartition de la charge entre les nœuds k8s
Pour réduire la probabilité de l'événement "expulsion du pod"
Pour le fonctionnement de l'autoscaling horizontal des pods de l'application (HPA)
Pour le fonctionnement de l'autoscaling horizontal des nœuds (Cluster Autoscaling) chez les fournisseurs de cloud

Lisez aussi d'autres articles sur notre blog :

Source : habr.com

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