Kubernetes "Failed Scheduling" -virheiden korjaaminen

Pod-aikatauluongelmat ovat yksi yleisimmistä Kubernetes-virheistä. On useita syitä, miksi uusi kotelo voi juuttua a Pending tila kanssa FailedScheduling hänen syykseen. Tämän tilan näyttävä pod ei käynnistä säilöjä, joten et voi käyttää sovellustasi.

Ajoitusongelmien aiheuttamat odottavat podit eivät yleensä käynnisty ilman manuaalista puuttumista. Sinun on löydettävä perimmäinen syy ja ryhdyttävä toimiin klusterin korjaamiseksi. Tässä artikkelissa opit diagnosoimaan ja korjaamaan tämän ongelman, jotta voit lisätä työmäärääsi.

Epäonnistuneen ajoitusvirheen tunnistaminen

On normaalia, että paloissa näkyy a Pending tilaksi hetkeksi sen jälkeen, kun olet lisännyt ne klusteriisi. Kubernetesin on ajoitettava säilön esiintymät solmuissasi, ja näiden solmujen on vedettävä kuva rekisteristään. Ensimmäinen merkki pod-aikataulun epäonnistumisesta on, kun se aina näkyy Pending sen jälkeen, kun tavanomainen käynnistysaika on kulunut. Voit tarkistaa tilan suorittamalla Kubectl'sin get pods tilattu:

$ kubectl get pods NIMI VALMIS TILA KÄYNNISSÄ UUDELLEEN IKÄ demo-pod 0/1 Odottaa 0 4m05s

demo-pod yli neljä minuuttia, mutta se on edelleen Pending Osavaltio. Pods ei yleensä vie niin kauan käynnistää säiliöitä, joten on aika alkaa tutkia, mitä Kubernetes odottaa.

Seuraava diagnostiikkavaihe on noutaa Podin tapahtumahistoria käyttämällä describe pod tilattu:

$ kubectl kuvaa pod demo-pod ... Tapahtumat: Tyyppi Syy Ikä Lähettäjä Viesti ---- ------ ---- ---- ------- ... Varoitus Epäonnistunut Ajoitus 4 min oletus- ajastin 0/4 solmut ovat käytettävissä: 1 Liian monta podia, 3 Riittämätön suoritin.

Tapahtumaloki vahvistaa a FailedScheduling virhe on syy laajennukseen Pending Osavaltio. Tämä tapahtuma raportoidaan, kun Kubernetes ei pysty allokoimaan vaadittua määrää podeja yhdelle klusterin työntekijäsolmuista.

Tapahtumaviesti paljastaa, miksi ajoitus ei ole tällä hetkellä mahdollista: klusterissa on neljä solmua, mutta yksikään niistä ei voi ottaa podia. Kolmella solmulla on riittämätön suorittimen kapasiteetti, kun taas toinen on saavuttanut hyväksyttävien podien enimmäismäärän.

Epäonnistuneiden ajoitusvirheiden ja vastaavien ongelmien ymmärtäminen

Kubernetes voi ajoittaa podeja vain sellaisiin solmuihin, joilla on ylimääräisiä resursseja. Solmut, joiden suoritin tai muisti loppuvat, eivät voi enää ottaa koteloita. Podit voivat myös epäonnistua ajoituksessa, jos ne nimenomaisesti pyytävät enemmän resursseja kuin yksikään solmu pystyy tarjoamaan. Tämä pitää klusterin vakaana.

Kubernetes-ohjaustaso tietää, mitkä podit on jo varattu klusterin solmuille. Se käyttää näitä tietoja määrittääkseen solmujoukon, jotka voivat vastaanottaa uuden podin. Ajoitusvirhe tapahtuu, kun yhtään ehdokasta ei ole saatavilla, jolloin ryhmä jää jumiin Pending kunnes kyky vapautuu.

Kubernetes ei välttämättä myöskään ajoita podeja muista syistä. Solmut voidaan katsoa kelpaamattomiksi isännöimään podia useilla tavoilla, vaikka niillä olisi riittävät järjestelmäresurssit:

• Järjestelmänvalvoja on saattanut lukita solmun estääkseen sitä vastaanottamasta uusia podeja ennen huoltotoimenpidettä.
• Solmulla voi olla vaikutus, joka estää podeja ajoittamasta. Solmu ei hyväksy podiasi, ellei sillä ole vastaavaa toleranssia.
• Kotelosi saattaa pyytää a hostPort joka on jo linkitetty solmuun. Solmut voivat tarjota vain tietyn portin numeron yhdelle Podille kerrallaan.
• Kotelosi saattaa käyttää a nodeSelector tämä tarkoittaa, että se on ohjelmoitava tietyllä tunnisteella varustettuun solmuun. Merkitsemättömät solmut eivät ole kelvollisia.
• Podiden ja solmujen affiniteetit ja anti-affiniteetit voivat olla epätyydyttäviä, mikä aiheuttaa ajoitusristiriidan, joka estää uusien ryhmien hyväksymisen.
• Podissa voi olla a nodeName kenttä, joka identifioi tietyn aikataulutettavan solmun. Pod on jumissa, jos tämä solmu on offline-tilassa tai ajoittamaton.

Se on vastuulla kube-scheduler, Kubernetes-ajoitus, jotta nämä ehdot selviävät ja solmujoukot voidaan tunnistaa, jotka voivat isännöidä uutta podia. A FailedScheduling Tapahtuma tapahtuu, kun yksikään solmu ei täytä ehtoja.

Aikataulu epäonnistui -tilan ratkaiseminen

Viesti näkyy vieressä FailedScheduling yleensä paljastaa, miksi kukin klusterin solmu ei voinut ottaa podia vastaan. Voit käyttää näitä tietoja ongelman vianmäärityksen aloittamiseen. Yllä olevassa esimerkissä klusterissa oli neljä podia, joista kolme oli saavuttanut CPU-rajan ja yksi ylitti pod-määrärajan.

Klusterin kapasiteetti on tässä tapauksessa perimmäinen syy. Voit skaalata klusterisi uusilla solmuilla laitteiston kulutusongelmien ratkaisemiseksi ja lisäämällä resursseja, jotka tarjoavat lisää joustavuutta. Koska tämä lisää myös kustannuksiasi, kannattaa ensin tarkistaa, onko klusterissasi ylimääräisiä podeja. Käyttämättömien resurssien poistaminen vapauttaa kapasiteettia uusille.

Voit tarkistaa kussakin solmussasi käytettävissä olevat resurssit käyttämällä describe node tilattu:

$ kubectl kuvaile solmun demo-solmu ... Allokoidut resurssit: (Kokonaisrajat voivat olla yli 100 prosenttia, eli ylisitovia.) Resurssipyyntörajat -------- -------- ---- -- prosessori 812m (90%) 202m (22%) muisti 905Mi (57%) 715Mi (45%) lyhytaikainen tallennus 0 (0%) 0 (0%) valtavat sivut - 2Mi 0 (0%) 0 (0%)

Tämän solmun podit vaativat jo 57 % käytettävissä olevasta muistista. Jos uusi pod pyysi 1 Gi:tä itselleen, solmu ei pystyisi hyväksymään ajoituspyyntöä. Näiden tietojen tarkkaileminen kunkin solmukohtaisesti voi auttaa sinua arvioimaan, onko klusterisi ylivarattu. On tärkeää, että sinulla on vapaata kapasiteettia siltä varalta, että jokin solmuistasi epäonnistuu ja sen työmäärät on ajoitettava toiseen.

Puuttuvista ajoitetuista solmuista johtuvat ajoitusvirheet näyttävät seuraavan kaltaisen viestin FailedScheduling Tapahtuma:

0/4 solmua on saatavilla: 4 solmua ei ollut aikataulutettu

Solmut, joita ei voida ajoittaa, koska ne on silmukattu, sisältävät SchedulingDisabled tilakentässään:

$ kubectl get nodes NIMI TILA ROOLIT IKÄ VERSIO solmu-1 Valmis,AjoitusPoistettu ohjaustaso, Master 26m v1.23.3

Voit poistaa solmun linkityksen, jotta se voi vastaanottaa uusia ryhmiä:

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

Kun solmut eivät ole suljettuja ja niillä on riittävästi resursseja, ajoitusvirheet johtuvat yleensä kontaminaatiosta tai virheestä nodeSelector kenttä Podissasi. Jos käytät nodeSelectorvarmista, että et ole tehnyt kirjoitusvirhettä ja että klusterissasi on podeja, joissa on määrittämäsi tunnisteet.

Kun solmut ovat saastuneet, varmista, että olet sisällyttänyt vastaavan toleranssin pod-luetteloon. Esimerkkinä tässä on solmu, joka on saastunut, joten palot eivät aikatauluta, ellei niillä ole demo-taint: allow toleranssi:

$ kubectl tait nodes node-1 demo-taint=allow:NoSchedule

Muokkaa pod-luetteloita, jotta ne voivat ajoittaa solmuun:

tekniset tiedot:
  toleranssit:
    - avain: demo tait
      operaattori: Yhtä suuri
      arvo: sallia
      vaikutus: NoSchedule

Ratkaise ongelma, joka aiheuttaa FailedScheduling tila sallii Kubernetesin jatkaa odottavien podien ajoittamista. Ne alkavat toimia automaattisesti pian sen jälkeen, kun ohjaustaso havaitsee muutokset solmuissasi. Sinun ei tarvitse käynnistää podeja uudelleen tai luoda uudelleen manuaalisesti, ellei ongelma johdu pod-luettelon virheistä, kuten virheellisestä affiniteettista tai nodeSelector kenttiä.

yhteenveto

FailedScheduling virheitä ilmenee, kun Kubernetes ei voi sijoittaa uutta ryhmää klusterin solmuun. Tämä johtuu usein siitä, että olemassa olevat solmut loppuvat laitteistoresursseista, kuten suorittimesta, muistista ja levystä. Kun näin on, voit korjata ongelman skaalaamalla klusterin sisältämään lisäsolmuja.

Ajoitusvirheitä esiintyy myös silloin, kun podit määrittävät solmuaffiniteetit, anti-affiniteetit ja valitsijat, joita klusterin käytettävissä olevat solmut eivät tällä hetkellä pysty täyttämään. Estetyt ja saastuneet solmut vähentävät Kubernetesin käytettävissä olevia vaihtoehtoja entisestään. Tämän tyyppiset ongelmat voidaan ratkaista tarkistamalla luetteloiden kirjoitusvirheet tarroissa ja poistamalla tarpeettomat rajoitukset.