Felsöka vanliga fel vid automatisk reparation av noder
När Azure Kubernetes Service (AKS) identifierar en nod med NotReady
status i mer än fem minuter försöker den reparera noden automatiskt. Automatisk reparation av nod är en tjänst som passar bäst. Det garanterar inte att noden kan återställas till ett felfritt tillstånd. Mer information finns i processen för automatisk reparation av noder.
Under processen för automatisk reparation av noden initierar reboot
AKS , reimage
och redeploy
åtgärder på noden som inte är felfri. Fel kan inträffa på grund av olika orsaker och felkoder identifieras via Kubernetes-händelser. Du kan använda Kubernetes-händelser för att övervaka statusen för noden och åtgärderna för automatisk reparation.
Den här artikeln innehåller potentiella orsaker och lösningar på vanliga fel vid automatisk reparation av noder och beskriver metodtips för övervakning av nodens automatiska reparationsprocess.
Förutsättningar
Kontrollera följande Kubernetes-händelser för att identifiera typen av autoreparation av en nod:
Anledning | Händelsemeddelande | Beskrivning |
---|---|---|
NodeRebootError | Omstarten av noden misslyckades på grund av ett åtgärdsfel: [felkod här] | Genereras när det finns ett fel med åtgärden reboot . |
NodeReimageError | Åtgärden för automatisk reparation av nod kunde inte repareras på grund av ett åtgärdsfel: [felkod här] | Genereras när det finns ett fel med åtgärden reimage . |
NodeRedeployError | Åtgärden för automatisk reparation av nod kunde inte distribueras på grund av ett åtgärdsfel: [felkod här] | Genereras när det finns ett fel med åtgärden redeploy . |
Kommentar
Eftersom noden redan är i ett feltillstånd innan processen för automatisk reparation påverkas inte klustret eller programmen i de flesta fall av automatiska reparationsfel för noder. När du stöter på fel med automatisk reparation av noder rekommenderar vi att du försöker reparera noden genom att följa anvisningarna i Grundläggande felsökning av nodfel som inte är klara. Om du inte kan återställa den till en Succeeded
status och se beständiga fel som rapporterats av automatisk reparation av noden kontaktar du Azure Support om du behöver hjälp.
Vanliga felkoder
Felkod | Orsak och lösning |
---|---|
VMExtensionProvisioningError | Det gick inte att etablera en eller flera vm-tillägg på den virtuella datorn. Mer information om möjliga feltyper och felsökningssteg finns i Felsöka ERR_VHD_FILE_NOT_FOUND felkod (124). Om du vill fastställa det exakta etableringsfelet för VM-tillägg på noden kan du visa felinformation i Azure Portal. |
InvalidParameter | Det här felet uppstår om nodens automatiska reparationsprocess försöker komma åt en nod som inte längre finns. |
scaleSetNameAndInstanceIDFromProviderID misslyckades | Det här problemet uppstår när noden inte är korrekt etablerad. |
ManagedIdentityCredential-autentiseringen misslyckades | Det här problemet uppstår när noden inte initieras korrekt. |
VMRedeploymentFailed | Det här felet uppstår när du försöker distribuera om noden. I det här fallet kan nodpoolen ange ett feltillstånd. Mer information om potentiella orsaker och felsökningssteg finns i Felsöka Azure Kubernetes Service-kluster eller noder i ett feltillstånd. |
TooManyVMRedeploymentRequests | Det här felet uppstår när klustret överskrider gränsen för omdistribueringsbegäranden för virtuella datorer. Redeploy är en av de automatiska reparationsåtgärderna för noden. Det här felet innebär att åtgärden redeploy inte kan reparera noden. Information om hur du felsöker problemet nod som inte är redo finns i Grundläggande felsökning av nodfel som inte är klara. |
OutboundConnectivityNotEnabledOnVMSS | Det här felet uppstår när noden eller den övergripande vm-skalningsuppsättningen inte har utgående åtkomst aktiverad. Lös problemet genom att aktivera säker utgående åtkomst för din skalningsuppsättning med hjälp av en metod som passar bäst för ditt program. Mer information finns i "OutboundConnectivityNotEnabledOnVM. Ingen utgående anslutning har konfigurerats för den virtuella datorn." |
Metodtips för automatisk reparation av noder
AKS lagrar Kubernetes-händelser från den senaste timmen som standard. Vi rekommenderar att du aktiverar Container Insights så att du kan lagra händelser i upp till 90 dagar. Du kan också köra frågor mot händelser och konfigurera aviseringar för att snabbt identifiera fel med automatisk reparation av noder.
Automatisk reparation av nod är en tjänst som passar bäst. Det garanterar inte att noden kan återställas till en
Ready
status. Vi rekommenderar att du aktivt övervakar och ställer in aviseringar för nodproblem som inte är redo och felsöker och löser dessa problem själv. Mer information finns i grundläggande felsökning av problem med Nod som inte är redo.
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.