Dela via

Felsöka en ändring i en felfri nod till Inte klar-status

  • Artikel

I den här artikeln beskrivs ett scenario där statusen för en AKS-klusternod (Azure Kubernetes Service) ändras till Inte redo när noden är i felfritt tillstånd under en 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 dessa fält som förväntat? (Till exempel i Villkorsfält , innehåller message egenskapen strängen "kubelet håller på att publicera status"?) Om du i det här fallet har direkt åtkomst till Secure Shell (SSH) till noden kontrollerar du de senaste händelserna för att förstå felet. Titta i filen /var/log/messages . Eller generera kubelet- och container daemon-loggfilerna genom att köra följande gränssnittskommandon:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

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

Lösning

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

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

  • Ändringar i DNS (Domain Name System)
  • Brandväggsregeländringar, till exempel port, fullständigt kvalificerade domännamn (FQDN) och så vidare.
  • Tillagda nätverkssäkerhetsgrupper (NSG:er)
  • Tillämpade eller ändrade routningstabellkonfigurationer för AKS-trafik

Om det fanns ändringar på nätverksnivå gör du eventuella nödvändiga korrigeringar. Om du har direkt åtkomst till SSH (Secure Shell) till noden kan du använda curl kommandot eller telnet för att kontrollera anslutningen till utgående AKS-krav. När du har åtgärdat problemen stoppar och startar du om noderna. Om noderna förblir i felfritt tillstånd efter dessa korrigeringar kan du på ett säkert sätt hoppa över de återstående stegen.

Steg 2: Stoppa och starta om noderna

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

  • Nodfel
  • SNAT-fel (Source Network Address Translation)
  • Prestandaproblem med nodindata/utdataåtgärder per sekund (IOPS)
  • Andra problem

Om diagnostiken inte upptäcker några underliggande problem och noderna återgår till statusen Klar 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 en längre tid och förlita dig på den inaktiva tidsgränsen som standard för att frigöra porten. Om anslutningarna uppvisar det här beteendet kan du behöva minska standardtidsgränsen på 30 minuter.

  • Ta reda på 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 det 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 mått för SNAT-anslutningar.

  • 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.

Mer information om hur du felsöker SNAT-portexhaution finns i Felsöka SNAT-portöverbelastning på AKS-noder.

Steg 4: Åtgärda prestandaproblem med IOPS

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

  • Om du vill öka IOPS på VM-skalningsuppsättningar (VM) väljer du en större diskstorlek som ger bättre IOPS-prestanda genom att distribuera en ny nodpool. Direkt storleksändring av VMSS stöds inte direkt. Mer information om hur du ändrar storlek på nodpooler finns i Ändra storlek på nodpooler i Azure Kubernetes Service (AKS).

  • Öka nodens SKU-storlek för mer minnes- och processorbearbetningskapacitet.

  • Ö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 processorförbrukning av noder och minnesbrist.

  • Använd topologimetoder för schemaläggning 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ådproblem

Kubernetes-komponenter som kubelets och containerbaserade runtimes ä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 klar, 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 failed: Resursen är tillfälligt otillgänglig av olika processer

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

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

Process-ID:er (PID) representerar trådar. Standardantalet PID:er som en podd kan använda kan vara beroende av operativsystemet. Standardnumret är dock minst 32 768. Den här mängden utgör mer än nog med 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 programmet som orsakar problemet och vidta sedan lämpliga åtgärder. Överväg andra alternativ, till exempel att öka storleken på den virtuella datorn eller att 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 cgroups kör du följande gränssnittskommando:

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:er 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 system- respektive kubelet-gränser.

  2. Konfigurera PID-baserad borttagning.

Kommentar

Som standard konfigureras inga 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 med hjälp av en högre tjänstnivå. Mer information finns i Azure Kubernetes Service (AKS) Uptime SLA.

Mer information