Dela via

Felsöka statusen Inte redo för en felfri nod

  • Artikel

I den här artikeln beskrivs ett scenario där statusen för en Azure Kubernetes Service-klusternod (AKS) ändras till Inte redo när noden är i felfritt tillstånd under en viss tid. Den här artikeln beskriver den specifika orsaken och tillhandahåller en möjlig lösning.

Förutsättningar

Symptom

Statusen för en klusternod som har ett felfritt tillstånd (alla tjänster som körs) ändras oväntat till Inte redo. Om du vill visa status för en nod kör du följande kubectl describe-kommando :

kubectl describe nodes

Orsak

Kubelet slutade publicera statusen Klar.

Granska utdata från kubectl describe nodes kommandot för att hitta fältet Villkor och blocken Kapacitet och Allokerbar . Visas innehållet i de här fälten som förväntat? (I fältet messageVillkor innehåller egenskapen till exempel strängen "kubelet is posting ready status"?) Om du i det här fallet har direkt åtkomst till SSH (Secure Shell) till noden kontrollerar du de senaste händelserna för att förstå felet. Titta i filen /var/log/messages . Du kan också generera kubelet- och container daemon-loggfilerna genom att köra följande gränssnittskommandon:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

När du har kört de här kommandona undersöker du daemonloggfilerna för mer information om felet.

Steg 1: Sök efter ändringar på nätverksnivå

Om alla klusternoder återgår till statusen Inte redo kontrollerar du om några ändringar har gjorts på nätverksnivå. Exempel på ändringar på nätverksnivå är följande:

  • Dns-ändringar (Domain Name System)
  • Ändringar i brandväggsporten
  • Nätverkssäkerhetsgrupper (NSG:er) har lagts till

Om det fanns ändringar på nätverksnivå gör du eventuella nödvändiga korrigeringar. Stoppa och starta om noderna som körs när du har åtgärdat problemen. Om noderna förblir i felfritt tillstånd efter dessa korrigeringar kan du hoppa över de återstående stegen på ett säkert sätt.

Steg 2: Stoppa och starta om noderna

Om bara några få noder återgår till statusen Inte redo stoppar du och startar om noderna. Enbart den här åtgärden kan återställa noderna till ett felfritt tillstånd. Kontrollera sedan Azure Kubernetes Service diagnostiköversikten för att avgöra om det finns några problem, till exempel följande problem:

  • Nodfel
  • Fel vid källnätverksadressöversättning (SNAT)
  • Prestandaproblem med nodindata/utdataåtgärder per sekund (IOPS)
  • Andra problem

Om diagnostiken inte upptäcker några underliggande problem kan du på ett säkert sätt hoppa över de återstående stegen.

Steg 3: Åtgärda SNAT-problem för offentliga AKS API-kluster

Upptäckte AKS-diagnostik några SNAT-problem? I så fall vidtar du några av följande åtgärder, beroende på vad som är lämpligt:

  • Kontrollera om anslutningarna förblir inaktiva under lång tid och förlita dig på den inaktiva tidsgränsen som är standard för att frigöra porten. Om anslutningarna uppvisar det här beteendet kan du behöva minska standardtidsgränsen på 30 minuter.

  • Fastställ hur programmet skapar utgående anslutning. Använder den till exempel kodgranskning eller paketinsamling?

  • Avgör om den här aktiviteten representerar det förväntade beteendet eller i stället visar att programmet beter sig felaktigt. Använd mått och loggar i Azure Monitor för att underbygga dina resultat. Du kan till exempel använda kategorin Misslyckades som ett SNAT-Connections mått.

  • Utvärdera om lämpliga mönster följs.

  • Utvärdera om du bör minska SNAT-portöverbelastningen med hjälp av extra utgående IP-adresser och fler allokerade utgående portar. Mer information finns i Skala antalet hanterade utgående offentliga IP-adresser och Konfigurera de allokerade utgående portarna.

Steg 4: Åtgärda problem med IOPS-prestanda

Om AKS-diagnostik upptäcker problem som minskar IOPS-prestanda kan du vidta några av följande åtgärder efter behov:

  • Om du vill öka IOPS på VM-skalningsuppsättningar ändrar du diskstorleken genom att distribuera en ny nodpool.

  • Öka nodens SKU-storlek för mer minne och processorbearbetning.

  • Överväg att använda tillfälliga operativsystem.

  • Begränsa processor- och minnesanvändningen för poddar. Dessa gränser hjälper till att förhindra cpu-förbrukning av noder och minnesbrist.

  • Använd metoder för schemaläggningstopologi för att lägga till fler noder och distribuera belastningen mellan noderna. Mer information finns i Begränsningar för spridning av poddtopologi.

Steg 5: Åtgärda trådningsproblem

Kubernetes-komponenter som kubelets och containerbaserade körningsmiljöer är starkt beroende av trådning, och de skapar nya trådar regelbundet. Om allokeringen av nya trådar misslyckas kan det här felet påverka tjänstberedskapen på följande sätt:

  • Nodstatusen ändras till Inte redo, men den startas om av en reparationsåtgärd och kan återställas.

  • I loggfilerna /var/log/messages och /var/log/syslog finns det upprepade förekomster av följande felposter:

    pthread_create misslyckades: Resursen är inte tillgänglig för tillfället av olika processer

    Processerna som nämns är containerbaserade och eventuellt kubelet.

  • Nodstatusen ändras till Inte redo strax efter att pthread_create felposterna har skrivits till loggfilerna.

Process-ID:er (PID) representerar trådar. Standardantalet PID:ar som en podd kan använda kan vara beroende av operativsystemet. Standardnumret är dock minst 32 768. Den här mängden är mer än tillräckligt många PID:er för de flesta situationer. Finns det några kända programkrav för högre PID-resurser? Om det inte finns det kanske inte ens en åttafaldig ökning till 262 144 PID:er räcker för att hantera ett högresursprogram.

Identifiera i stället det felaktiga programmet och vidta sedan lämpliga åtgärder. Överväg andra alternativ, till exempel att öka storleken på den virtuella datorn eller uppgradera AKS. Dessa åtgärder kan tillfälligt åtgärda problemet, men de är inte en garanti för att problemet inte återkommer igen.

Om du vill övervaka antalet trådar för varje kontrollgrupp (cgroup) och skriva ut de åtta översta cgroupsna kör du följande kommando för gränssnittet:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Mer information finns i Process-ID-gränser och reservationer.

Kubernetes erbjuder två metoder för att hantera PID-överbelastning på nodnivå:

  1. Konfigurera det maximala antalet PID:ar som tillåts på en podd i en kubelet med hjälp av parametern --pod-max-pids . Den här konfigurationen pids.max anger inställningen i cgroup för varje podd. Du kan också använda parametrarna --system-reserved och --kube-reserved för att konfigurera systemet respektive kubelet-gränserna.

  2. Konfigurera PID-baserad borttagning.

Obs!

Som standard konfigureras ingen av dessa metoder. Dessutom kan du för närvarande inte konfigurera någon av metoderna med hjälp av Nodkonfiguration för AKS-nodpooler.

Steg 6: Använd en högre tjänstnivå

Du kan se till att AKS API-servern har hög tillgänglighet genom att använda en högre tjänstnivå. Mer information finns i serviceavtalet för drifttid för Azure Kubernetes Service (AKS).

Mer information