Sådan rydder du op i gamle Kubernetes-opgaver
Webbureau » Digitale nyheder » Sådan fejlretter du Kubernetes "FailedScheduling"-fejl

Sådan fejlretter du Kubernetes "FailedScheduling"-fejl

Pod-planlægningsproblemer er en af ​​de mest almindelige Kubernetes-fejl. Der er flere grunde til, at en ny pod kan sidde fast i en Pending stat med FailedScheduling som hans grund. En pod, der viser denne status, vil ikke starte nogen containere, så du vil ikke være i stand til at bruge din applikation.

Afventende pods forårsaget af planlægningsproblemer starter normalt ikke uden manuel indgriben. Du bliver nødt til at finde årsagen og tage skridt til at reparere din klynge. I denne artikel lærer du, hvordan du diagnosticerer og løser dette problem, så du kan øge dine arbejdsbyrder.

Identifikation af en Failed Scheduling-fejl

Det er normalt, at pods viser en Pending status i kort tid efter at have føjet dem til din klynge. Kubernetes skal planlægge containerforekomster på dine noder, og disse noder skal trække billedet fra dets registreringsdatabase. Det første tegn på en pod-planlægningsfejl er, når den altid dukker op som Pending efter den sædvanlige opstartsperiode er udløbet. Du kan tjekke status ved at køre Kubectl's get pods bestilte:

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

demo-pod mere end fire minutter, men det er stadig i Pending Stat. Pods tager normalt ikke så lang tid at starte containere, så det er på tide at begynde at undersøge, hvad Kubernetes forventer.

Det næste diagnostiske trin er at hente Pod'ens hændelseshistorik ved hjælp af describe pod bestilte:

$ kubectl describe pod demo-pod ... Begivenheder: Indtast Årsag Alder Fra Besked ---- ------ ---- ---- ------- ... Advarsel mislykketPlanlægning 4m standard- skemalægger 0/4 noder er tilgængelige: 1 For mange pods, 3 Utilstrækkelig cpu.

Hændelsesloggen bekræfter en FailedScheduling fejlen er årsagen til forlængelsen Pending Stat. Denne hændelse rapporteres, når Kubernetes ikke kan allokere det nødvendige antal pods til en af ​​din klynges arbejdsknudepunkter.

Begivenhedsmeddelelsen afslører, hvorfor planlægning i øjeblikket ikke er mulig: Der er fire noder i klyngen, men ingen af ​​dem kan tage poden. Tre af noderne har utilstrækkelig CPU-kapacitet, mens den anden har nået et loft over antallet af pods, den kan acceptere.

Forståelse af Failed Scheduling-fejl og lignende problemer

Kubernetes kan kun planlægge pods på noder med ekstra ressourcer. Noder, der løber tør for CPU eller hukommelse, kan ikke længere klare pods. Pods kan også fejle i planlægningen, hvis de eksplicit anmoder om flere ressourcer, end en enkelt node kan levere. Dette holder din klynge stabil.

Kubernetes-kontrolplanet ved, hvilke pods der allerede er allokeret til noder i din klynge. Den bruger disse oplysninger til at bestemme det sæt af noder, der kan modtage en ny pod. En planlægningsfejl opstår, når ingen kandidat er tilgængelig, hvilket efterlader poden fast Pending indtil evnen er frigivet.

Kubernetes planlægger muligvis heller ikke pods af andre årsager. Noder kan anses for uegnede til at være vært for en Pod på flere måder, selvom de har tilstrækkelige systemressourcer:

  • Noden kan være blevet låst af en administrator for at forhindre den i at modtage nye pods før en vedligeholdelsesoperation.
  • Noden kan have en effekt, der forhindrer pods i at planlægge. Din pod vil ikke blive accepteret af noden, medmindre den har en matchende tolerance.
  • Din pod anmoder muligvis om en hostPort som allerede er knyttet til noden. Noder kan kun give et bestemt portnummer til én Pod ad gangen.
  • Din pod bruger muligvis en nodeSelector det betyder, at det skal programmeres på en node med et bestemt tag. Ikke-taggede noder vil ikke være kvalificerede.
  • Affiniteterne og anti-affiniteterne for pods og noder kan være utilfredsstillende, hvilket forårsager en planlægningskonflikt, der forhindrer nye pods i at blive accepteret.
  • Poden kan have en nodeName felt, der identificerer en specifik node, der skal planlægges. Poden vil blive stående i venteposition, hvis denne node er offline eller ikke-planlagt.

Det er ansvaret for kube-scheduler, Kubernetes-planlæggeren, til at arbejde gennem disse forhold og identificere det sæt af noder, der kan være vært for en ny pod. EN FailedScheduling Hændelsen opstår, når ingen af ​​noderne opfylder kriterierne.

Løsning af tidsplan mislykket status

Meddelelsen ved siden af FailedScheduling afslører normalt, hvorfor hver node i din klynge ikke kunne tage poden. Du kan bruge disse oplysninger til at starte fejlfinding af problemet. I eksemplet ovenfor havde klyngen fire pods, tre, hvor CPU-grænsen var nået, og en, der havde overskredet en pod-antal-grænse.

Klyngekapacitet er hovedårsagen i dette tilfælde. Du kan skalere din klynge med nye noder for at løse hardwareforbrugsproblemer, og tilføje ressourcer, der vil give yderligere fleksibilitet. Da dette også vil øge dine omkostninger, er det værd at tjekke først, om du har overflødige pods i din klynge. Fjernelse af ubrugte ressourcer vil frigøre kapacitet til nye.

Du kan inspicere de tilgængelige ressourcer på hver af dine noder ved hjælp af describe node bestilte:

$ kubectl beskriv node demo-node ... Tildelte ressourcer: (Samlede grænser kan være over 100 procent, dvs. overforpligtede.) Ressourceanmodningsgrænser -------- -------- ---- -- cpu 812m (90%) 202m (22%) hukommelse 905Mi (57%) 715Mi (45%) kortvarig lagring 0 (0%) 0 (0%) enorme sider-2Mi 0 (0%) 0 (0%)

Pods på denne node anmoder allerede om 57 % af den tilgængelige hukommelse. Hvis en ny pod anmodede om 1 Gi for sig selv, ville noden ikke være i stand til at acceptere planlægningsanmodningen. Overvågning af disse oplysninger for hver af dine noder kan hjælpe dig med at vurdere, om din klynge er ved at blive overprovisioneret. Det er vigtigt at have ledig kapacitet, hvis en af ​​dine noder svigter, og dens arbejdsbelastninger skal omlægges på en anden.

Planlægningsfejl på grund af manglende planlægningsknuder vil vise en meddelelse svarende til følgende i FailedScheduling en begivenhed:

0/4 noder er tilgængelige: 4 node(r) kunne ikke planlægges

Noder, der ikke kan planlægges, fordi de er blevet sløjfet, vil inkludere SchedulingDisabled i deres statusfelt:

$ kubectl få noder NAVN STATUS ROLLER ALDER VERSION node-1 Klar, SchedulingDeaktiveret kontrolplan, master 26m v1.23.3

Du kan fjerne linket til noden for at tillade den at modtage nye pods:

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

Når noder ikke er lukkede og har tilstrækkelige ressourcer, er planlægningsfejl normalt forårsaget af kontaminering eller fejl nodeSelector felt på din Pod. Hvis du bruger nodeSelectorkontroller, at du ikke har lavet en tastefejl, og at der er pods i din klynge, som har de etiketter, du har angivet.

Når noder er forurenede, skal du sørge for, at du har inkluderet den tilsvarende tolerance i din pods manifest. Som et eksempel, her er en node, der er blevet forurenet, så pods vil ikke planlægge, medmindre de har en demo-taint: allow tolerance:

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

Rediger dine pod-manifester, så de kan planlægge på noden:

spec:
  tolerancer:
    - nøgle: demo lugt
      operatør: Ens
      værdi: tillade
      effekt: NoSchedule

Løs problemet, der forårsager FailedScheduling tilstand vil tillade Kubernetes at genoptage planlægningen af ​​dine ventende pods. De vil begynde at køre automatisk kort efter, at kontrolplanet har registreret ændringer i dine noder. Du behøver ikke at genstarte eller manuelt genskabe dine pods, medmindre problemet skyldes fejl i dit pod-manifest, såsom ukorrekt affinitet eller nodeSelector marker.

resumé

FailedScheduling fejl opstår, når Kubernetes ikke kan placere en ny pod på en node i din klynge. Dette skyldes ofte, at dine eksisterende noder løber tør for hardwareressourcer såsom CPU, hukommelse og disk. Når dette er tilfældet, kan du løse problemet ved at skalere din klynge til at inkludere yderligere noder.

Planlægningsfejl opstår også, når pods specificerer nodeaffiniteter, anti-affiniteter og vælgere, som i øjeblikket ikke kan tilfredsstilles af de tilgængelige noder i din klynge. Blokerede og forurenede noder reducerer yderligere mulighederne for Kubernetes. Denne type problemer kan løses ved at tjekke dine manifester for stavefejl i etiketterne og fjerne begrænsninger, som du ikke længere har brug for.

★ ★ ★ ★ ★