Problèmes courants avec les noeuds et les pods

Découvrez comment identifier et résoudre les problèmes courants liés aux noeuds et aux pods sur les clusters créés à l'aide de Kubernetes Engine (OKE).

Vous pouvez rencontrer ces problèmes avec les noeuds et les pods sur les clusters que vous avez créés à l'aide de Kubernetes Engine.

Noeuds de processus actif et/ou pods ne répondant pas bloqués à l'état En attente en raison de ressources insuffisantes

Les problèmes suivants peuvent survenir avec les noeuds et les pods sur les clusters créés à l'aide de Kubernetes Engine :

  • Les noeuds de processus actif ne répondent pas.
  • Les noeuds de processus actif dont le statut est NotReady en réponse à la commande kubectl get node.
  • Pods bloqués à l'état En attente, avec des messages tels que FailedScheduling due to Insufficient cpu ou FailedScheduling due to Insufficient memory.

L'une des causes probables de ces problèmes est l'insuffisance des ressources système pour les démons système Kubernetes et OS.

Nous vous recommandons d'utiliser les indicateurs de kubelet --kube-reserved et --system-reserved pour réserver des ressources de CPU et de mémoire aux démons système Kubernetes (tels que kubelet et container runtime) et aux démons système de système d'exploitation (tels que sshd et systemd), respectivement. Par exemple :

  • --kube-reserved=cpu=500m,memory=1Gi
  • --system-reserved=cpu=100m,memory=100Mi

Les pods exécutés sur un noeud de processus actif peuvent consommer toutes les ressources d'UC et de mémoire disponibles, et ainsi empêcher l'exécution d'autres processus essentiels (tels que les démons du système d'exploitation et Kubernetes) sur le noeud. Lorsque les démons du système d'exploitation et Kubernetes ne peuvent pas s'exécuter, le noeud de processus actif peut ne plus répondre, être instable et s'arrêter brutalement en cas de charge importante.

Pour empêcher les pods de demander des ressources requises par les démons système de système d'exploitation et Kubernetes, incluez les indicateurs de kubelet --kube-reserved et --system-reserved en tant qu'options kubelet-extra-args dans un script cloud-init personnalisé. Pour plus d'informations et un exemple, reportez-vous à Exemple 4 : utilisation d'un script Cloud-init personnalisé pour réserver des ressources pour les démons système Kubernetes et de système d'exploitation.

Lorsque vous utilisez l'indicateur de kubelet --kube-reserved pour réserver une partie des ressources d'UC et de mémoire d'un noeud de processus actif en vue de leur utilisation par les démons système Kubernetes, tenez compte des recommandations suivantes :

  • La quantité de ressources d'UC que nous vous recommandons de réserver pour les démons système Kubernetes dépend du nombre de coeurs d'UC sur le noeud de processus actif, comme indiqué dans le tableau suivant :
    Nombre de coeurs de processeur sur le noeud de processus actif 1 2 3 4 5 Plus de 5
    CPU recommandée à réserver, en millicore (m) 60 min 70 min 80 min 85 min 90 min 2,5 m supplémentaires pour chaque coeur supplémentaire sur le noeud de processus actif
  • La quantité de ressource de mémoire que nous vous recommandons de réserver pour les démons système Kubernetes dépend de la quantité de mémoire sur le noeud de processus actif, comme indiqué dans le tableau suivant :
    Mémoire sur le noeud de processus actif, dans GiB 4 GiB 8 GiB 16 GiB 128 GiB Plus de 128 GiB
    Mémoire recommandée à réserver, dans GiB 1 GiB 1 GiB 2 GiB 9 GiB 20 MiB supplémentaires pour chaque GiB supplémentaire de mémoire de noeud de processus actif

Lorsque vous utilisez l'indicateur de kubelet --system-reserved pour réserver une partie des ressources de CPU et de mémoire d'un noeud à l'utilisation par les démons du système d'exploitation, tenez compte des recommandations suivantes :

  • La quantité de ressources CPU que nous vous recommandons de réserver pour les démons du système d'exploitation (quelle que soit la forme du noeud) est de 100 m (millicore).
  • La quantité de ressources de mémoire que nous vous recommandons de réserver pour les démons du système d'exploitation (quelle que soit la forme du noeud) est de 100 Mi (mébioctets).

Notez que nos recommandations d'UC et de mémoire pour les indicateurs de kubelet --kube-reserved et --system-reserved peuvent ne pas être optimales pour les charges globales que vous prévoyez d'exécuter. Vous devrez donc peut-être modifier les valeurs en conséquence. Vous devrez peut-être également ajuster les valeurs au fil du temps.

Pour voir la différence entre le nombre total de ressources sur un noeud de processus actif et les ressources sur le noeud que les charges globales peuvent utiliser, exécutez la commande suivante :

kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity

Exemple de sortie :

  allocatable:
    cpu: 15743m
    ephemeral-storage: "34262890849"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 234972476Ki
    pods: "110"
  capacity:
    cpu: "16"
    ephemeral-storage: 37177616Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 257197372Ki
    pods: "110"

La différence entre la CPU "capacité" et la mémoire "allocable" dans l'exemple de sortie inclut les réservations de CPU et de mémoire pour les démons du système d'exploitation et Kubernetes.

Remarque

À partir de juin 2024, les recommandations pour les réservations de ressources de CPU et de mémoire pour les démons système Kubernetes et OS décrits dans cette section sont utilisées comme valeurs par défaut pour toutes les images OKE, pour toutes les versions de Kubernetes prises en charge. Les recommandations sont également utilisées comme valeurs par défaut pour toutes les images de plate-forme pour Kubernetes version 1.30 et ultérieure. Les valeurs par défaut s'appliquent à la fois lorsque vous indiquez une image OKE publiée en juin 2024 (ou ultérieurement) et lorsque vous mettez à niveau la version de Kubernetes exécutée sur un cluster vers la version 1.30 (ou ultérieure). Si vous indiquez une image OKE publiée en juin 2024 (ou ultérieurement) ou si vous mettez à niveau un cluster vers Kubernetes version 1.30, nous vous recommandons de vérifier que les réservations par défaut sont appropriées pour les charges globales que vous prévoyez d'exécuter.

La création de pools de noeuds virtuels affiche un message indiquant que le serveur API est inaccessible

Lors de la création d'un pool de noeuds virtuels dans un cluster que vous avez créé à l'aide de Kubernetes Engine, le message suivant peut s'afficher si vous visualisez les journaux de demande de travail ou les erreurs de demande de travail pour l'ID de demande de travail de l'opération :

API Server Unreachable, Check network configuration and ensure network path between Virtual Node and API Server exist

Ce message indique un problème de configuration réseau. Vérifiez que le réseau est configuré correctement pour permettre aux noeuds virtuels du pool de noeuds virtuels de communiquer avec le serveur d'API Kubernetes. Pour obtenir une configuration réseau appropriée, reportez-vous à la section Example Network Resource Configuration for Cluster with Virtual Nodes.