Hvordan rydde opp i gamle Kubernetes-oppgaver
Webbyrå » Digitale nyheter » Slik feilsøker du Kubernetes "FailedScheduling"-feil

Slik feilsøker du Kubernetes "FailedScheduling"-feil

Pod-planleggingsproblemer er en av de vanligste Kubernetes-feilene. Det er flere grunner til at en ny pod kan sette seg fast i en Pending stat med FailedScheduling som hans grunn. En pod som viser denne statusen vil ikke starte noen beholdere, så du vil ikke kunne bruke applikasjonen din.

Ventende pods forårsaket av planleggingsproblemer starter normalt ikke uten manuell inngripen. Du må finne årsaken og iverksette tiltak for å reparere klyngen din. I denne artikkelen lærer du hvordan du diagnostiserer og løser dette problemet slik at du kan øke arbeidsbelastningen.

Identifisere en feil i planleggingsfeil

Det er normalt at pods viser en Pending status for en kort stund etter at du har lagt dem til i klyngen din. Kubernetes må planlegge containerforekomster på nodene dine, og disse nodene må hente bildet fra registret. Det første tegnet på en pod-planleggingsfeil er når den alltid dukker opp som Pending etter at den vanlige oppstartsperioden er utløpt. Du kan sjekke statusen ved å kjøre Kubectl's get pods bestilte:

$ kubectl få pods NAVN KLAR STATUS OMSTARTS ALDER demo-pod 0/1 Venter 0 4m05s

demo-pod mer enn fire minutter, men det er fortsatt i Pending Stat. Pods tar vanligvis ikke så lang tid å starte containere, så det er på tide å begynne å undersøke hva Kubernetes forventer.

Det neste diagnostiske trinnet er å hente Pods hendelseshistorikk ved å bruke describe pod bestilte:

$ kubectl describe pod demo-pod ... Hendelser: Skriv inn Årsak Alder Fra melding ---- ------ ---- ---- ------- ... Advarsel mislyktes Scheduling 4m default- planlegger 0/4 noder er tilgjengelige: 1 for mange pods, 3 utilstrekkelig cpu.

Hendelsesloggen bekrefter en FailedScheduling feilen er årsaken til utvidelsen Pending Stat. Denne hendelsen rapporteres når Kubernetes ikke kan tildele det nødvendige antallet pods til en av klyngens arbeidsnoder.

Hendelsesmeldingen avslører hvorfor planlegging for øyeblikket ikke er mulig: det er fire noder i klyngen, men ingen av dem kan ta poden. Tre av nodene har utilstrekkelig CPU-kapasitet mens den andre har nådd et tak på antall pods den kan akseptere.

Forstå Failed Scheduling-feil og lignende problemer

Kubernetes kan bare planlegge pods på noder med ledige ressurser. Noder som går tom for CPU eller minne kan ikke lenger ta pods. Pods kan også mislykkes i planleggingen hvis de eksplisitt ber om flere ressurser enn en node kan gi. Dette holder klyngen din stabil.

Kubernetes-kontrollplanet vet hvilke poder som allerede er allokert til noder i klyngen din. Den bruker denne informasjonen til å bestemme settet med noder som kan motta en ny pod. En planleggingsfeil oppstår når ingen kandidat er tilgjengelig, noe som gjør at poden sitter fast Pending til evnen er sluppet.

Kubernetes kan heller ikke planlegge pods av andre grunner. Noder kan anses som ikke kvalifisert til å være vert for en Pod på flere måter, selv om de har tilstrekkelige systemressurser:

  • Noden kan ha blitt låst av en administrator for å forhindre at den mottar nye pods før en vedlikeholdsoperasjon.
  • Noden kan ha en effekt som hindrer pods i å planlegge. Poden din vil ikke bli akseptert av noden med mindre den har en matchende toleranse.
  • Poden din ber kanskje om en hostPort som allerede er knyttet til noden. Noder kan bare gi et bestemt portnummer til én Pod om gangen.
  • Poden din bruker kanskje en nodeSelector dette betyr at den må programmeres på en node med en bestemt tag. Umerkede noder vil ikke være kvalifisert.
  • Affinitetene og anti-affinitetene til pods og noder kan være utilfredsstillende, noe som forårsaker en planleggingskonflikt som hindrer nye pods fra å bli akseptert.
  • Poden kan ha en nodeName felt som identifiserer en spesifikk node å planlegge. Poden blir stående på vent hvis denne noden er frakoblet eller ikke planlagt.

Det er ansvaret for kube-scheduler, Kubernetes-planleggeren, for å jobbe gjennom disse forholdene og identifisere settet med noder som kan være vert for en ny pod. EN FailedScheduling Hendelsen oppstår når ingen av nodene oppfyller kriteriene.

Løser tidsplan mislyktes status

Meldingen som vises ved siden av FailedScheduling avslører vanligvis hvorfor hver node i klyngen din ikke kunne ta poden. Du kan bruke denne informasjonen til å begynne å feilsøke problemet. I eksemplet ovenfor hadde klyngen fire pods, tre der CPU-grensen var nådd og en som hadde overskredet en pod-tellegrense.

Klyngekapasitet er hovedårsaken i dette tilfellet. Du kan skalere klyngen din med nye noder for å løse problemer med maskinvareforbruk, og legge til ressurser som vil gi ekstra fleksibilitet. Siden dette også vil øke kostnadene dine, er det verdt å sjekke først om du har overflødige pods i klyngen din. Fjerning av ubrukte ressurser vil frigjøre kapasitet til nye.

Du kan inspisere ressursene som er tilgjengelige på hver av nodene dine ved å bruke describe node bestilte:

$ kubectl beskrive node demo-node ... Tildelte ressurser: (Totale grenser kan være over 100 prosent, dvs. overengasjert.) Ressursforespørsler Grenser -------- -------- ---- -- cpu 812m (90%) 202m (22%) minne 905Mi (57%) 715Mi (45%) kortvarig lagring 0 (0%) 0 (0%) enorme sider-2Mi 0 (0%) 0 (0%)

Podene på denne noden ber allerede om 57 % av det tilgjengelige minnet. Hvis en ny pod ba om 1 Gi for seg selv, ville ikke noden kunne godta planleggingsforespørselen. Å overvåke denne informasjonen for hver av nodene dine kan hjelpe deg med å vurdere om klyngen din blir overprovisionert. Det er viktig å ha ledig kapasitet i tilfelle en av nodene dine svikter og arbeidsbelastningen må omplanlegges på en annen.

Planleggingsfeil på grunn av manglende planbare noder vil vise en melding som ligner på følgende i FailedScheduling Begivenhet:

0/4 noder er tilgjengelige: 4 node(r) kunne ikke planlegges

Noder som ikke kan planlegges fordi de har blitt loopet vil inkludere SchedulingDisabled i statusfeltet deres:

$ kubectl få noder NAVN STATUS ROLLER ALDER VERSJON node-1 Klar, SchedulingDeaktivert kontrollplan, master 26m v1.23.3

Du kan koble fra noden for å la den motta nye poder:

$ kubectl uncordon node-1 node/node-1 uncordoned

Når noder ikke er lukket og har tilstrekkelige ressurser, er planleggingsfeil vanligvis forårsaket av forurensning eller feil nodeSelector feltet på Poden din. Hvis du bruker nodeSelectorbekreft at du ikke har skrevet en skrivefeil og at det er pods i klyngen din som har etikettene du spesifiserte.

Når noder er forurenset, sørg for at du har inkludert den tilsvarende toleransen i podens manifest. Som et eksempel, her er en node som er blitt forurenset, så pods vil ikke planlegge med mindre de har en demo-taint: allow toleranse:

$ kubectl taint noder node-1 demo-taint=allow:NoSchedule

Rediger pod-manifestene dine slik at de kan planlegge på noden:

spec:
  tolerasjoner:
    - nøkkel: demo-flekk
      operatør: Lik
      verdi: tillate
      effekt: NoSchedule

Løs problemet som forårsaker FailedScheduling staten vil tillate Kubernetes å gjenoppta planleggingen av ventende pods. De vil begynne å kjøre automatisk kort tid etter at kontrollplanet oppdager endringer i nodene dine. Du trenger ikke å starte på nytt eller manuelt gjenskape podene dine med mindre problemet skyldes feil i pod-manifestet, for eksempel feil tilhørighet eller nodeSelector felt.

sammendrag

FailedScheduling feil oppstår når Kubernetes ikke kan plassere en ny pod på en node i klyngen din. Dette er ofte forårsaket av at de eksisterende nodene dine går tom for maskinvareressurser som CPU, minne og disk. Når dette er tilfelle, kan du fikse problemet ved å skalere klyngen til å inkludere flere noder.

Planleggingsfeil oppstår også når pods spesifiserer nodetilhørigheter, antiaffiniteter og velgere som for øyeblikket ikke kan tilfredsstilles av de tilgjengelige nodene i klyngen din. Blokkerte og forurensede noder reduserer mulighetene som er tilgjengelige for Kubernetes ytterligere. Denne typen problemer kan løses ved å sjekke manifestene for skrivefeil i etikettene og fjerne begrensninger som du ikke lenger trenger.

★ ★ ★ ★ ★