Share via

Problemen met de status Niet gereed van een goed functionerend knooppunt oplossen

  • Artikel

In dit artikel wordt een scenario besproken waarin de status van een AKS-clusterknooppunt (Azure Kubernetes Service) verandert in Niet gereed nadat het knooppunt enige tijd in orde is. In dit artikel wordt de specifieke oorzaak beschreven en wordt een mogelijke oplossing geboden.

Vereisten

Symptomen

De status van een clusterknooppunt met een status in orde (alle services die worden uitgevoerd) verandert onverwacht in Niet gereed. Voer de volgende kubectl-beschrijfopdracht uit om de status van een knooppunt weer te geven:

kubectl describe nodes

Oorzaak

De kubelet is gestopt met het posten van de status Gereed .

Bekijk de uitvoer van de kubectl describe nodes opdracht om het veld Voorwaarden en de blokken Capaciteit en Toewijsbaar te vinden. Wordt de inhoud van deze velden weergegeven zoals verwacht? (Bevat de eigenschap in het veld Voorwaarden bijvoorbeeld de message tekenreeks 'kubelet is status gereed voor posten'?) Als u in dit geval directe SSH-toegang (Secure Shell) hebt tot het knooppunt, controleert u de recente gebeurtenissen om de fout te begrijpen. Kijk in het bestand /var/log/messages . Of genereer de logboekbestanden kubelet en container-daemon door de volgende shell-opdrachten uit te voeren:

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

Nadat u deze opdrachten hebt uitgevoerd, controleert u de daemonlogboekbestanden voor meer informatie over de fout.

Stap 1: controleren op wijzigingen op netwerkniveau

Als alle clusterknooppunten de status Niet gereed hebben, controleert u of er wijzigingen zijn opgetreden op netwerkniveau. Voorbeelden van wijzigingen op netwerkniveau zijn de volgende items:

  • Dns-wijzigingen (Domain Name System)
  • Wijzigingen in firewallpoort
  • Netwerkbeveiligingsgroepen (NSG's) toegevoegd

Als er wijzigingen zijn op netwerkniveau, moet u de benodigde correcties aanbrengen. Stop en start de knooppunten die worden uitgevoerd opnieuw nadat u de problemen hebt opgelost. Als de knooppunten na deze oplossingen in orde blijven, kunt u de resterende stappen veilig overslaan.

Stap 2: De knooppunten stoppen en opnieuw starten

Als slechts enkele knooppunten de status Niet gereed hebben, stopt u de knooppunten en start u deze opnieuw. Alleen al deze actie kan de status van de knooppunten in orde retourneren. Controleer vervolgens Azure Kubernetes Service diagnostisch overzicht om te bepalen of er problemen zijn, zoals de volgende problemen:

  • Knooppuntfouten
  • SNAT-fouten (Source Network Address Translation)
  • Prestatieproblemen met knooppuntinvoer/uitvoerbewerkingen per seconde (IOPS)
  • Andere problemen

Als de diagnose geen onderliggende problemen detecteert, kunt u de resterende stappen veilig overslaan.

Stap 3: SNAT-problemen voor openbare AKS API-clusters oplossen

Zijn er SNAT-problemen met de AKS-diagnose aan het licht gekomen? Als dat het geval is, voert u een aantal van de volgende acties uit, indien van toepassing:

  • Controleer of uw verbindingen lang inactief blijven en afhankelijk zijn van de standaard time-out voor inactiviteit om de poort vrij te geven. Als de verbindingen dit gedrag vertonen, moet u mogelijk de standaardtime-out van 30 minuten verminderen.

  • Bepaal hoe uw toepassing uitgaande connectiviteit maakt. Wordt er bijvoorbeeld gebruikgemaakt van codebeoordeling of pakketopname?

  • Bepaal of deze activiteit het verwachte gedrag vertegenwoordigt of in plaats daarvan laat zien dat de toepassing zich niet gedraagt. Gebruik metrische gegevens en logboeken in Azure Monitor om uw bevindingen te onderbouwen. U kunt bijvoorbeeld de categorie Mislukt gebruiken als een metrische SNAT-Connections.

  • Evalueer of de juiste patronen worden gevolgd.

  • Evalueer of u de uitputting van SNAT-poorten moet beperken door extra uitgaande IP-adressen en meer toegewezen uitgaande poorten te gebruiken. Zie Het aantal beheerde uitgaande openbare IP-adressen schalen en De toegewezen uitgaande poorten configureren voor meer informatie.

Stap 4: IOPS-prestatieproblemen oplossen

Als de diagnostische gegevens van AKS problemen aan het licht brengen die de IOPS-prestaties verminderen, voert u een aantal van de volgende acties uit, indien van toepassing:

  • Wijzig de schijfgrootte door een nieuwe knooppuntgroep te implementeren om de IOPS op virtuele-machineschaalsets (VM's) te verhogen.

  • Vergroot de knooppunt-SKU-grootte voor meer geheugen en CPU-verwerkingscapaciteit.

  • Overweeg het gebruik van kortstondig besturingssysteem.

  • Beperk het CPU- en geheugengebruik voor pods. Deze limieten helpen het CPU-verbruik van knooppunten en situaties met onvoldoende geheugen te voorkomen.

  • Gebruik planningstopologiemethoden om meer knooppunten toe te voegen en de belasting over de knooppunten te verdelen. Zie Beperkingen voor podtopologiespreiding voor meer informatie.

Stap 5: Problemen met threading oplossen

Kubernetes-onderdelen, zoals kubelets en containerruntimes , zijn sterk afhankelijk van threading en ze genereren regelmatig nieuwe threads. Als de toewijzing van nieuwe threads mislukt, kan deze fout de gereedheid van de service als volgt beïnvloeden:

  • De status van het knooppunt verandert in Niet gereed, maar wordt opnieuw gestart door een herstelprogramma en kan worden hersteld.

  • In de logboekbestanden /var/log/messages en /var/log/syslog zijn er herhaalde exemplaren van de volgende foutvermeldingen:

    pthread_create mislukt: Resource tijdelijk niet beschikbaar door verschillende processen

    De processen die worden genoemd, omvatten containerd en mogelijk kubelet.

  • De status van het knooppunt verandert in Niet gereed zodra de pthread_create foutvermeldingen naar de logboekbestanden zijn geschreven.

Proces-id's (PID's) vertegenwoordigen threads. Het standaardaantal PID's dat een pod kan gebruiken, is mogelijk afhankelijk van het besturingssysteem. Het standaardnummer is echter ten minste 32.768. Dit bedrag is voor de meeste situaties meer dan voldoende PID's. Zijn er bekende toepassingsvereisten voor hogere PID-resources? Als dat niet het geval is, is zelfs een achtvoudige toename naar 262.144 PINCODEs mogelijk niet voldoende om een toepassing met veel resources te kunnen gebruiken.

Identificeer in plaats daarvan de betreffende toepassing en onderneem vervolgens de juiste actie. Overweeg andere opties, zoals het vergroten van de VM-grootte of het upgraden van AKS. Deze acties kunnen het probleem tijdelijk verhelpen, maar bieden geen garantie dat het probleem niet opnieuw optreedt.

Voer de volgende shell-opdracht uit om het aantal threads voor elke controlegroep (cgroup) te bewaken en de acht bovenste groepen af te drukken:

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'

Zie Limieten en reserveringen voor proces-id's voor meer informatie.

Kubernetes biedt twee methoden voor het beheren van PID-uitputting op knooppuntniveau:

  1. Configureer het maximum aantal PID's dat is toegestaan op een pod binnen een kubelet met behulp van de --pod-max-pids parameter. Met deze configuratie stelt u de pids.max instelling in de cgroup van elke pod in. U kunt ook de --system-reserved parameters en --kube-reserved gebruiken om respectievelijk de systeem- en kubeletlimieten te configureren.

  2. Op PID gebaseerde verwijdering configureren.

Opmerking

Geen van deze methoden is standaard ingesteld. Bovendien kunt u momenteel geen van beide methoden configureren met behulp van knooppuntconfiguratie voor AKS-knooppuntgroepen.

Stap 6: een hogere servicelaag gebruiken

U kunt ervoor zorgen dat de AKS API-server hoge beschikbaarheid heeft door een hogere servicelaag te gebruiken. Zie de SLA Azure Kubernetes Service (AKS) Uptime voor meer informatie.

Meer informatie