Documentation sur Oracle Cloud Infrastructure

Problèmes courants liés aux noeuds et aux pods

Découvrez comment identifier et résoudre les problèmes courants liés aux noeuds et aux pods des grappes que vous avez créées à l'aide de Kubernetes Engine (OKE).

Vous pourriez rencontrer ces problèmes avec les noeuds et les pods des grappes que vous avez créées à l'aide de Kubernetes Engine.

Noeuds de travail ou pods non réactifs bloqués à l'état En attente en raison de ressources insuffisantes

Les problèmes suivants peuvent survenir avec les noeuds et les pods des grappes que vous avez créées à l'aide de Kubernetes Engine :

  • Les noeuds de travail ne répondent pas.
  • Noeuds de travail avec un statut affiché comme NotReady en réponse à la commande kubectl get node.
  • Les pods sont bloqués à l'état En attente, avec des messages tels que FailedScheduling due to Insufficient cpu ou FailedScheduling due to Insufficient memory.

Une cause probable 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 kubelet --kube-reserved et --system-reserved pour réserver des ressources d'UC et de mémoire pour les démons du système Kubernetes (tels que kubelet et container runtime) et les démons du 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 travail peuvent consommer toutes les ressources d'UC et de mémoire disponibles et empêcher ainsi 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 Kubernetes et du système d'exploitation ne peuvent pas s'exécuter, le noeud de travail peut ne pas répondre, être instable et se bloquer de manière inattendue sous une forte charge.

Pour empêcher les pods de demander des ressources requises par les démons de système Kubernetes et de système d'exploitation, 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, voir Exemple 4 : Utilisation d'un script Cloud-init personnalisé pour réserver des ressources pour les démons de système Kubernetes et de système d'exploitation.

Lorsque vous utilisez l'indicateur kubelet --kube-reserved pour réserver une partie des ressources d'UC et de mémoire d'un noeud de travail à utiliser par les démons du 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 travail, comme indiqué dans le tableau suivant :
    Nombre de coeurs d'UC sur le noeud de travail 1 2 3 4 5 Est supérieur à 5
    UC recommandée pour la réservation, en millicore (m) 60 m 70 m 80 m 85 m 90 m 2,5 m de plus pour chaque coeur supplémentaire sur le noeud de travail
  • La quantité de ressources 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 travail, comme indiqué dans le tableau suivant :
    Mémoire sur le noeud de travail, 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 travail

Lorsque vous utilisez l'indicateur kubelet --system-reserved pour réserver une partie des ressources d'UC et de mémoire d'un noeud à utiliser 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 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ébibytes).

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 de travail que vous prévoyez d'exécuter, de sorte que vous devrez 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 travail et les ressources sur le noeud que les charges de travail 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 "allouable" dans l'exemple de sortie inclut les réservations de CPU et de mémoire pour les démons système Kubernetes et OS.

Note

À partir de juin 2024, les recommandations relatives aux réservations de ressources 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 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 spécifiez une image OKE publiée en juin 2024 (ou ultérieurement) et lorsque vous mettez à niveau la version de Kubernetes exécutée sur une grappe vers la version 1.30 (ou ultérieure). Si vous spécifiez une image OKE publiée en juin 2024 (ou ultérieurement) ou si vous mettez à niveau une grappe vers Kubernetes version 1.30, nous vous recommandons de vérifier que les réservations par défaut sont appropriées pour les charges de travail que vous prévoyez d'exécuter.

La création de groupes de noeuds virtuels affiche un message " Serveur d'API inaccessible "

Lors de la création d'un groupe de noeuds virtuels dans une grappe que vous avez créée à l'aide de Kubernetes Engine, le message suivant peut s'afficher si vous consultez les journaux de demande de travail ou les erreurs de demande de travail pour l'ID 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 groupe de noeuds virtuels de communiquer avec le serveur d'API Kubernetes. Pour une configuration de réseau appropriée, voir Exemple de configuration de ressources de réseau pour une grappe avec des noeuds virtuels.