Delen via

Problemen met een wijziging in een goed knooppunt oplossen in status Niet gereed

  • Artikel

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

Voorwaarden

Symptomen

De status van een clusterknooppunt met een status in orde (alle actieve services) wordt onverwacht gewijzigd in Niet gereed. Voer de volgende kubectl describe-opdracht uit om de status van een knooppunt weer te geven:

kubectl describe nodes

Oorzaak

De kubelet heeft de status Gereed niet meer geplaatst.

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

# 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

Nadat u deze opdrachten hebt uitgevoerd, bekijkt u de berichten en daemon-logboekbestanden voor meer informatie over de fout.

Oplossing

Stap 1: Controleren op wijzigingen op netwerkniveau

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

  • Domain Name System (DNS) wijzigingen
  • Wijzigingen in firewallregels, zoals poort, FQDN's (Fully Qualified Domain Names), enzovoort.
  • Netwerkbeveiligingsgroepen (NSG's) toegevoegd
  • Configuraties van routetabellen toegepast of gewijzigd voor AKS-verkeer

Als er wijzigingen zijn aangebracht op netwerkniveau, moet u de benodigde correcties aanbrengen. Als u directe SSH-toegang (Secure Shell) tot het knooppunt hebt, kunt u de curl of telnet opdracht gebruiken om de connectiviteit met uitgaande AKS-vereisten te controleren. Nadat u de problemen hebt opgelost, stopt u de knooppunten en start u deze opnieuw. 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 een paar knooppunten zijn teruggedraaid naar de status Niet gereed , stopt u de knooppunten en start u deze opnieuw. Deze actie kan alleen de nodes retourneren naar een goede status. Controleer vervolgens het diagnostische overzicht van Azure Kubernetes Service om te bepalen of er problemen zijn, zoals de volgende problemen:

  • Nodefouten
  • Bron network address translation (SNAT) fouten
  • Prestatieproblemen met node-invoer/uitvoerbewerkingen per seconde (IOPS)
  • Overige problemen

Als de diagnostische gegevens geen onderliggende problemen detecteren en de knooppunten worden geretourneerd naar de status Gereed, kunt u de resterende stappen veilig overslaan.

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

Heeft AKS diagnostische gegevens SNAT-problemen ontdekt? 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. Gebruikt het bijvoorbeeld codebeoordeling of pakketopname?

  • Bepaal of deze activiteit het verwachte gedrag vertegenwoordigt of, in plaats daarvan, geeft aan 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 metrische gegevens voor SNAT-verbindingen.

  • Evalueer of de juiste patronen worden gevolgd.

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

Zie Problemen met SNAT-poortuitputting op AKS-knooppunten oplossen voor meer informatie over het oplossen van problemen met exhaution van SNAT-poorten.

Stap 4: IOPS-prestatieproblemen oplossen

Als AKS-diagnose problemen ontdekt die de IOPS-prestaties verminderen, voert u een aantal van de volgende acties uit, indien van toepassing:

  • Als u IOPS op virtuele-machineschaalsets (VM's) wilt vergroten, kiest u een grotere schijfgrootte die betere IOPS-prestaties biedt door een nieuwe knooppuntgroep te implementeren. Het rechtstreeks wijzigen van het formaat van VMSS wordt niet ondersteund. Zie Het formaat van knooppuntgroepen wijzigen in Azure Kubernetes Service (AKS) voor meer informatie over het wijzigen van het formaat van knooppuntgroepen.

  • Verhoog de node-SKU-grootte voor meer geheugen- en CPU-verwerkingsmogelijkheden.

  • Overweeg het gebruik van kortstondige besturingssystemen.

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

  • Gebruik planningstopologiemethoden om meer nodes toe te voegen en de belasting over de nodes te verdelen. Zie Beperkingen voor spreiding van podtopologieen voor meer informatie.

Stap 5: threadingproblemen oplossen

Kubernetes-onderdelen, zoals kubelets en runtimes in containers, zijn sterk afhankelijk van threading en ze zorgen regelmatig voor 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 opgestart door een herstelprogramma en kan worden hersteld.

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

    pthread_create is mislukt: resource is tijdelijk niet beschikbaar voor verschillende processen

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

  • De status van het knooppunt verandert in Niet gereed kort nadat 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 aantal is meer dan genoeg PID's voor de meeste situaties. Zijn er bekende toepassingsvereisten voor hogere PID-bronnen? Als dat niet zo is, is zelfs een achtvoudige toename tot 262.144 PID's mogelijk niet voldoende om een resourcetoepassing te kunnen gebruiken.

Identificeer in plaats daarvan de overtredende toepassing en voer vervolgens de juiste actie uit. Overweeg andere opties, zoals het vergroten van de VM-grootte of het upgraden van AKS. Deze acties kunnen het probleem tijdelijk verhelpen, maar ze zijn geen garantie dat het probleem niet opnieuw wordt weergegeven.

Voer de volgende shell-opdracht uit om het aantal threads voor elke besturingsgroep (cgroup) te bewaken en de acht belangrijkste cgroups 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 Proces-id-limieten en -reserveringen voor meer informatie.

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

  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 wordt de pids.max instelling ingesteld binnen de cgroup van elke pod. U kunt ook de --system-reserved en --kube-reserved parameters gebruiken om respectievelijk de limieten voor het systeem en kubelet te configureren.

  2. Configureer verwijdering op basis van PID.

Notitie

Standaard worden geen van deze methoden 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 met behulp van een hogere servicelaag. Zie de SLA voor uptime van Azure Kubernetes Service (AKS) voor meer informatie.

Meer informatie