Comment nettoyer les anciennes tâches Kubernetes
Agence web » Actualités du digital » Comment déboguer les erreurs Kubernetes « FailedScheduling »

Comment déboguer les erreurs Kubernetes « FailedScheduling »

Les problèmes de planification de pod sont l’une des erreurs Kubernetes les plus courantes. Il existe plusieurs raisons pour lesquelles un nouveau pod peut rester bloqué dans un Pending état avec FailedScheduling comme sa raison. Un pod qui affiche cet état ne démarrera aucun conteneur, vous ne pourrez donc pas utiliser votre application.

Les pods en attente causés par des problèmes de planification ne démarrent normalement pas sans une intervention manuelle. Vous devrez rechercher la cause première et prendre des mesures pour réparer votre cluster. Dans cet article, vous apprendrez à diagnostiquer et à résoudre ce problème afin de pouvoir augmenter vos charges de travail.

Identification d’une erreur FailedScheduling

Il est normal que les pods affichent un Pending statut pendant une courte période après les avoir ajoutés à votre cluster. Kubernetes doit planifier des instances de conteneur sur vos nœuds et ces nœuds doivent extraire l’image de son registre. Le premier signe de l’échec de la planification d’un pod est lorsqu’il s’affiche toujours comme Pending une fois la période de démarrage habituelle écoulée. Vous pouvez vérifier l’état en exécutant Kubectl’s get pods commande:

$ kubectl get pods

NAME        READY   STATUS      RESTARTS    AGE
demo-pod    0/1     Pending     0           4m05s

demo-pod a plus de quatre minutes, mais il est toujours dans le Pending Etat. Les pods ne mettent généralement pas autant de temps à démarrer les conteneurs, il est donc temps de commencer à enquêter sur ce que Kubernetes attend.

L’étape de diagnostic suivante consiste à récupérer l’historique des événements du pod à l’aide du describe pod commande:

$ kubectl describe pod demo-pod

...
Events:
  Type     Reason            Age       From               Message
  ----     ------            ----      ----               -------
  ...
  Warning  FailedScheduling  4m        default-scheduler  0/4 nodes are available: 1 Too many pods, 3 Insufficient cpu.

L’historique des événements confirme une FailedScheduling l’erreur est la raison de la prolongation Pending Etat. Cet événement est signalé lorsque Kubernetes ne peut pas allouer le nombre requis de pods à l’un des nœuds de travail de votre cluster.

Le message de l’événement révèle pourquoi la planification est actuellement impossible : il y a quatre nœuds dans le cluster, mais aucun d’entre eux ne peut prendre le pod. Trois des nœuds ont une capacité CPU insuffisante tandis que l’autre a atteint un plafond sur le nombre de pods qu’il peut accepter.

Comprendre les erreurs FailedScheduling et les problèmes similaires

Kubernetes ne peut programmer des pods que sur des nœuds disposant de ressources de réserve. Les nœuds dont la capacité de processeur ou de mémoire est épuisée ne peuvent plus prendre de pods. Les pods peuvent également échouer dans la planification s’ils demandent explicitement plus de ressources que n’importe quel nœud ne peut en fournir. Cela maintient la stabilité de votre cluster.

Le plan de contrôle Kubernetes connaît les pods déjà alloués aux nœuds de votre cluster. Il utilise ces informations pour déterminer l’ensemble de nœuds pouvant recevoir un nouveau pod. Une erreur de planification se produit lorsqu’aucun candidat n’est disponible, laissant le pod bloqué Pending jusqu’à ce que la capacité soit libérée.

Kubernetes peut également ne pas planifier les pods pour d’autres raisons. Les nœuds peuvent être jugés inéligibles pour héberger un pod de plusieurs manières, même s’ils disposent de ressources système adéquates :

  • Le nœud a peut-être été bouclé par un administrateur pour l’empêcher de recevoir de nouveaux pods avant une opération de maintenance.
  • Le nœud pourrait être entaché d’un effet qui empêche les pods de planifier. Votre pod ne sera pas accepté par le nœud à moins qu’il n’ait une tolérance correspondante.
  • Votre pod demande peut-être un hostPort qui est déjà lié au nœud. Les nœuds ne peuvent fournir qu’un numéro de port particulier à un seul pod à la fois.
  • Votre pod utilise peut-être un nodeSelector cela signifie qu’il doit être programmé sur un nœud avec une étiquette particulière. Les nœuds sans étiquette ne seront pas éligibles.
  • Les affinités et les anti-affinités des pods et des nœuds peuvent être insatisfaisantes, provoquant un conflit de planification qui empêche l’acceptation de nouveaux pods.
  • Le Pod peut avoir un nodeName champ qui identifie un nœud spécifique à planifier. Le pod sera bloqué en attente si ce nœud est hors ligne ou non planifié.

C’est la responsabilité de kube-scheduler, le planificateur Kubernetes, pour travailler sur ces conditions et identifier l’ensemble de nœuds pouvant accueillir un nouveau pod. UN FailedScheduling L’événement se produit lorsqu’aucun des nœuds ne répond aux critères.

Résolution de l’état Échec de la planification

Le message affiché à côté de FailedScheduling révèlent généralement pourquoi chaque nœud de votre cluster n’a pas pu prendre le pod. Vous pouvez utiliser ces informations pour commencer à résoudre le problème. Dans l’exemple ci-dessus, le cluster avait quatre pods, trois où la limite de CPU avait été atteinte et un qui avait dépassé une limite de nombre de pods.

La capacité du cluster est la cause principale dans ce cas. Vous pouvez faire évoluer votre cluster avec de nouveaux nœuds pour résoudre les problèmes de consommation matérielle, en ajoutant des ressources qui offriront une flexibilité supplémentaire. Comme cela augmentera également vos coûts, il vaut la peine de vérifier d’abord si vous avez des pods redondants dans votre cluster. La suppression des ressources inutilisées libérera de la capacité pour de nouvelles.

Vous pouvez inspecter les ressources disponibles sur chacun de vos nœuds à l’aide de la describe node commande:

$ kubectl describe node demo-node

...
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                812m (90%)   202m (22%)
  memory             905Mi (57%)  715Mi (45%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%)

Les pods de ce nœud demandent déjà 57 % de la mémoire disponible. Si un nouveau pod demandait 1 Gi pour lui-même, le nœud ne serait pas en mesure d’accepter la demande de planification. La surveillance de ces informations pour chacun de vos nœuds peut vous aider à évaluer si votre cluster devient sur-provisionné. Il est important de disposer d’une capacité de réserve au cas où l’un de vos nœuds deviendrait défectueux et que ses charges de travail devraient être reprogrammées sur un autre.

Les échecs de planification dus à l’absence de nœuds planifiables afficheront un message similaire au suivant dans le FailedScheduling un événement:

0/4 nodes are available: 4 node(s) were unschedulable

Les nœuds qui ne peuvent pas être programmés parce qu’ils ont été bouclés incluront SchedulingDisabled dans leur champ d’état :

$ kubectl get nodes
NAME       STATUS                     ROLES                  AGE   VERSION
node-1     Ready,SchedulingDisabled   control-plane,master   26m   v1.23.3

Vous pouvez dissocier le nœud pour lui permettre de recevoir de nouveaux pods :

$ kubectl uncordon node-1
node/node-1 uncordoned

Lorsque les nœuds ne sont pas bouclés et disposent de ressources suffisantes, les erreurs de planification sont généralement causées par une contamination ou une erreur nodeSelector champ sur votre Pod. Si vous utilisez nodeSelectorvérifiez que vous n’avez pas fait de faute de frappe et qu’il existe des pods dans votre cluster qui portent les libellés que vous avez spécifiés.

Lorsque les nœuds sont contaminés, assurez-vous d’avoir inclus la tolérance correspondante dans le manifeste de votre pod. À titre d’exemple, voici un nœud qui a été contaminé afin que les pods ne planifient pas à moins qu’ils n’aient un demo-taint: allow tolérance:

$ kubectl taint nodes node-1 demo-taint=allow:NoSchedule

Modifiez vos manifestes de pod afin qu’ils puissent planifier sur le nœud :

spec:
  tolerations:
    - key: demo-taint
      operator: Equal
      value: allow
      effect: NoSchedule

Résoudre le problème à l’origine de la FailedScheduling state permettra à Kubernetes de reprendre la planification de vos pods en attente. Ils commenceront à s’exécuter automatiquement peu de temps après que le plan de contrôle aura détecté les modifications apportées à vos nœuds. Vous n’avez pas besoin de redémarrer ou de recréer manuellement vos pods, sauf si le problème est dû à des erreurs dans le manifeste de votre pod, telles qu’une affinité incorrecte ou nodeSelector des champs.

Sommaire

FailedScheduling des erreurs se produisent lorsque Kubernetes ne peut pas placer un nouveau pod sur un nœud de votre cluster. Cela est souvent dû au fait que vos nœuds existants manquent de ressources matérielles telles que le processeur, la mémoire et le disque. Lorsque c’est le cas, vous pouvez résoudre le problème en mettant à l’échelle votre cluster pour inclure des nœuds supplémentaires.

Les échecs de planification surviennent également lorsque les pods spécifient des affinités, des anti-affinités et des sélecteurs de nœuds qui ne peuvent actuellement pas être satisfaits par les nœuds disponibles dans votre cluster. Les nœuds bloqués et contaminés réduisent encore les options disponibles pour Kubernetes. Ce type de problème peut être résolu en vérifiant si vos manifestes contiennent des fautes de frappe dans les étiquettes et en supprimant les contraintes dont vous n’avez plus besoin.

★★★★★