Container Service for Kubernetes:Use hotspot-aware descheduling to balance node loads

Cycle d'exécution

Le désordonnanceur Koordinator s'exécute périodiquement. Chaque cycle d'exécution comprend trois étapes :

1. Collecte des données : Récupération des informations relatives aux nœuds et aux charges de travail, ainsi que des données d'utilisation des ressources.

2. Exécution des plug-ins (exemple avec LowNodeLoad) :

   1. Identification des nœuds constituant des points chauds en fonction des seuils highThresholds et lowThresholds.

   2. Parcours de tous les nœuds identifiés comme points chauds, notation des Pods éligibles et tri en vue de leur expulsion. Voir la section Politique de notation des Pods.

   3. Vérification de chaque Pod candidat par rapport aux contraintes de migration : capacité du cluster, utilisation des ressources et limites du ratio de réplicas. Consultez la section Politiques de désordonnancement des points chauds conscientes de la charge.

   4. Marquage des Pods validés comme candidats à la migration et exclusion des autres.

3. Expulsion et migration des Pods : Expulsion des candidats à la migration via l'API d'expulsion.

Classification des nœuds

Le plug-in LowNodeLoad classe les nœuds en trois catégories selon deux seuils : lowThresholds (seuil d'inactivité) et highThresholds (seuil de point chaud).

Exemple avec lowThresholds = 45 % et highThresholds = 70 % :

1. Nœud inactif : L'utilisation des ressources est inférieure à lowThresholds (< 45 %).

2. Nœud normal : L'utilisation des ressources se situe entre lowThresholds et highThresholds (45–70 %). Il s'agit de la plage cible.

3. Nœud constituant un point chaud : L'utilisation des ressources dépasse highThresholds (> 70 %). Les Pods sont expulsés jusqu'à ce que la charge du nœud descende à 70 % ou moins.

Les données d'utilisation des ressources sont mises à jour toutes les minutes et reflètent la moyenne sur 5 minutes.

Si tous les nœuds dépassent lowThresholds , la charge du cluster est considérée comme élevée et le désordonnancement est suspendu, même si certains nœuds dépassent highThresholds .

Politiques de désordonnancement des points chauds conscientes de la charge

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # System configuration. Do not modify this section.
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s  # Execution interval. Must not exceed detectorCacheTimeout.
    dryRun: false               # Set to true for read-only mode (no evictions).
    # End of system configuration.

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule:
          disabled:
            - name: "*"  # All plugins disabled by default (shown for reference only).
        balance:
          enabled:
            - name: LowNodeLoad
        evict:
          disabled:
            - name: "*"  # All plugins disabled by default (shown for reference only).
          enabled:
            - name: MigrationController

      pluginConfig:
      - name: MigrationController
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1       # Max Pods migrating simultaneously per node. 0 = unlimited.
          maxMigratingPerNamespace: 1  # Max Pods migrating simultaneously per namespace.
          maxMigratingPerWorkload: 1   # Max Pods migrating simultaneously per workload (e.g., Deployment).
          maxUnavailablePerWorkload: 2 # Max unavailable replicas per workload during migration.
          evictLocalStoragePods: false # Whether to evict Pods using HostPath or emptyDir volumes.
          objectLimiters:
            workload:               # At most 1 replica migrated per workload within 5 minutes.
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:
            cpu: 20
            memory: 30
          highThresholds:
            cpu: 50
            memory: 60

          anomalyCondition:
            consecutiveAbnormalities: 5  # Number of consecutive checks above highThresholds
                                          # before a node is classified as a hot spot.
                                          # Counter resets after eviction.

          detectorCacheTimeout: "5m"  # Cache duration for hot spot checks.
                                      # Must be >= deschedulingInterval.

          evictableNamespaces:
            include:
              - default
            # exclude:
            #   - "kube-system"
            #   - "koordinator-system"

          nodeSelector:  # Process only the specified nodes.
            matchLabels:
              alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****

          podSelectors:  # Process only the specified Pods.
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

Configuration système du désordonnanceur Koordinator

Configuration du contrôle d'expulsion et de migration

Configuration du plug-in LowNodeLoad

L'utilisation du nœud dépasse le seuil, mais les Pods ne sont pas expulsés

La cause la plus fréquente est une configuration inactive du désordonnanceur. Vérifiez les points suivants dans l'ordre :

1. Périmètre non configuré : Le désordonnanceur traite uniquement les namespaces et les nœuds explicitement inclus (ou non exclus). Vérifiez les paramètres evictableNamespaces et nodeSelector.

2. Désordonnanceur non redémarré après modification de la configuration : Les modifications de configuration nécessitent un redémarrage. Consultez l'Étape 2 pour obtenir les instructions.

3. Intervalle supérieur au délai d'expiration du cache : deschedulingInterval (par défaut : 2 min) ne doit pas dépasser detectorCacheTimeout (par défaut : 5 min), sinon la détection des points chauds échoue. Ajustez ces valeurs et redémarrez.

4. Nœud ne dépassant pas systématiquement le seuil : Le désordonnanceur utilise une moyenne lissée. Un nœud n'est classé comme point chaud qu'après avoir dépassé highThresholds pendant consecutiveAbnormalities cycles consécutifs (par défaut : 5, soit environ 10 minutes). La commande kubectl top node ne reflète que la dernière minute ; effectuez une surveillance sur une période plus longue pour confirmer une utilisation soutenue.

5. Capacité insuffisante du cluster : Avant d'expulser un Pod, le désordonnanceur vérifie qu'un autre nœud dispose d'une capacité libre suffisante. Si ce n'est pas le cas, l'expulsion est ignorée. Ajoutez des nœuds pour augmenter la capacité.

6. Charge de travail à réplica unique : Les Pods à réplica unique ne sont pas expulsés par défaut. Pour contourner cette restriction, ajoutez l'annotation descheduler.alpha.kubernetes.io/evict: "true" au Pod ou aux métadonnées du modèle de la charge de travail (spec.template.metadata). Cette fonctionnalité n'est pas prise en charge dans les versions ack-koordinator v1.3.0-ack1.6 à v1.3.0-ack1.8. Effectuez la mise à niveau vers la dernière version pour utiliser cette fonctionnalité.

7. Pod utilisant HostPath ou emptyDir : Ces Pods sont exclus du désordonnancement par défaut. Définissez evictLocalStoragePods: true dans MigrationController pour activer l'expulsion. Consultez la section Configuration du contrôle d'expulsion et de migration.

8. Nombre excessif de réplicas indisponibles ou en cours de migration : Si le nombre de réplicas indisponibles ou en cours de migration atteint maxUnavailablePerWorkload ou maxMigratingPerWorkload, les expulsions suivantes sont bloquées. Attendez la fin des expulsions en cours ou augmentez ces limites.

9. Nombre de réplicas inférieur ou égal à la limite de migration : Si le nombre total de réplicas est inférieur ou égal à maxMigratingPerWorkload ou maxUnavailablePerWorkload, la charge de travail est ignorée. Diminuez ces valeurs ou utilisez des pourcentages.

Le désordonnanceur redémarre fréquemment

Une ConfigMap manquante ou invalide provoque des boucles de redémarrage. Vérifiez le format de la ConfigMap en vous référant à la section Configuration avancée, puis procédez au redémarrage comme indiqué à l'Étape 2.

Interaction entre la planification consciente de la charge et le désordonnancement des points chauds

Activez les deux fonctionnalités pour obtenir un équilibrage de charge optimal. Le désordonnancement expulse les Pods des nœuds surchargés, tandis que la planification consciente de la charge place les Pods replanifiés sur des nœuds dont l'utilisation est plus faible.

Définissez loadAwareThreshold de manière à correspondre à highThresholds. Consultez les sections Utiliser la planification consciente de la charge et Politiques de planification.

Quelles données d'utilisation le désordonnanceur utilise-t-il ?

Le désordonnanceur calcule une moyenne lissée sur plusieurs cycles. L'expulsion ne se déclenche que lorsque l'utilisation moyenne reste supérieure à highThresholds pendant le nombre de cycles consécutifs configuré (par défaut : environ 10 minutes).

Le désordonnanceur exclut le cache de page des calculs de mémoire (celui-ci pouvant être libéré par le système d'exploitation). La commande kubectl top node inclut le cache de page ; utilisez Managed Service for Prometheus pour consulter la métrique réelle.