Kubernetes "FailedScheduling" Hatalarında Nasıl Hata Ayıklanır
Pod zamanlama sorunları, en yaygın Kubernetes hatalarından biridir. Yeni bir bölmenin bir yuvaya takılmasının birkaç nedeni vardır. Pending
ile devlet FailedScheduling
onun nedeni olarak. Bu durumu gösteren bir bölme herhangi bir kapsayıcı başlatmaz, bu nedenle uygulamanızı kullanamazsınız.
Zamanlama sorunlarından kaynaklanan bekleyen bölmeler, normalde manuel müdahale olmadan başlamaz. Temel nedeni bulmanız ve kümenizi onarmak için harekete geçmeniz gerekir. Bu makalede, iş yüklerinizi artırabilmeniz için bu sorunu nasıl tanılayıp çözeceğinizi öğreneceksiniz.
özet
FailedScheduling Hatasını Belirleme
Kapsüllerin bir Pending
durumlarını kümenize ekledikten sonra kısa bir süre için Kubernetes'in düğümleriniz üzerinde kapsayıcı örnekleri planlaması ve bu düğümlerin görüntüyü kendi kayıt defterinden çekmesi gerekir. Bir bölme planlama hatasının ilk işareti, her zaman şu şekilde görünmesidir: Pending
olağan başlatma süresi geçtikten sonra. Kubectl'i çalıştırarak durumu kontrol edebilirsiniz. get pods
sipariş:
$ kubectl kapsülleri al İSİM HAZIR DURUM YENİDEN BAŞLIYOR YAŞ demo-pod 0/1 Beklemede 0 4m05s
demo-pod
dört dakikadan fazla, ama yine de Pending
Durum. Kapsüllerin kapsayıcıları başlatması genellikle o kadar uzun sürmez, bu nedenle Kubernetes'in neler beklediğini araştırmaya başlamanın zamanı geldi.
Bir sonraki teşhis adımı, Pod'un olay geçmişini describe pod
sipariş:
$ kubectl pod demo-pod'u tanımlıyor ... Olaylar: Tür Neden Yaş Mesajdan ---- ------ ---- ---- ------- ... Uyarı FailedScheduling 4m default- zamanlayıcı 0/4 düğüm mevcut: 1 Çok fazla bölme, 3 Yetersiz işlemci.
Olay günlüğü bir FailedScheduling
hata, uzantının nedenidir Pending
Durum. Bu olay, Kubernetes gerekli sayıda bölmeyi kümenizin çalışan düğümlerinden birine tahsis edemediğinde raporlanır.
Olay mesajı, programlamanın şu anda neden mümkün olmadığını açıklar: Kümede dört düğüm vardır, ancak bunların hiçbiri bölmeyi alamaz. Düğümlerden üçü yetersiz CPU kapasitesine sahipken, diğeri kabul edebileceği bölme sayısında tavana ulaştı.
FailedScheduling Hatalarını ve Benzeri Sorunları Anlamak
Kubernetes, yalnızca yedek kaynaklara sahip düğümlerdeki bölmeleri zamanlayabilir. CPU'su veya belleği biten düğümler artık bölmeleri alamazlar. Bölmeler ayrıca herhangi bir düğümün sağlayabileceğinden daha fazla kaynak talep ederlerse planlamada başarısız olabilirler. Bu, kümenizin sabit kalmasını sağlar.
Kubernetes kontrol düzlemi, kümenizdeki düğümlere hangi bölmelerin önceden tahsis edildiğini bilir. Yeni bir bölmeyi alabilen düğüm kümesini belirlemek için bu bilgiyi kullanır. Uygun aday olmadığında, kapsülün takılıp kalmasına neden olan bir planlama hatası oluşur Pending
yetenek serbest bırakılana kadar.
Kubernet'ler ayrıca başka nedenlerle bölmeleri planlamayabilir. Düğümler, yeterli sistem kaynaklarına sahip olsalar bile, çeşitli şekillerde bir Kapsül barındırmaya uygun görülmeyebilir:
- Düğüm, bir bakım işleminden önce yeni bölmeler almasını önlemek için bir yönetici tarafından kilitlenmiş olabilir.
- Düğüm, bölmelerin programlanmasını önleyen bir etkiye sahip olabilir. Kapsülünüz, eşleşen bir toleransa sahip olmadığı sürece düğüm tarafından kabul edilmeyecektir.
- Pod'unuz istiyor olabilir
hostPort
zaten düğüme bağlı olan. Düğümler, aynı anda yalnızca bir Kapsül için belirli bir bağlantı noktası numarası sağlayabilir. - Pod'unuz kullanıyor olabilir
nodeSelector
bu, belirli bir etikete sahip bir düğümde programlanması gerektiği anlamına gelir. Etiketlenmemiş düğümler uygun olmayacaktır. - Bölmelerin ve düğümlerin yakınlıkları ve yakınlıkları tatmin edici olmayabilir ve yeni bölmelerin kabul edilmesini önleyen bir zamanlama çakışmasına neden olabilir.
- Pod bir olabilir
nodeName
programlanacak belirli bir düğümü tanımlayan alan. Bu düğüm çevrimdışıysa veya programlanmamışsa, bölme beklemeye alınır.
sorumluluğundadır kube-scheduler
, Kubernetes zamanlayıcı, bu koşullar üzerinde çalışmak ve yeni bir bölmeyi barındırabilecek düğüm kümesini belirlemek için. A FailedScheduling
Olay, düğümlerden hiçbiri kriterleri karşılamadığında gerçekleşir.
Zamanlama Başarısız Durumunu Çözme
Yanında görüntülenen mesaj FailedScheduling
genellikle kümenizdeki her bir düğümün neden bölmeyi alamadığını ortaya çıkarır. Sorunu gidermeye başlamak için bu bilgileri kullanabilirsiniz. Yukarıdaki örnekte, küme dört bölmeye sahipti, üçü CPU sınırına ulaşılmıştı ve biri bölme sayısı sınırını aşmıştı.
Küme kapasitesi, bu durumda temel nedendir. Ek esneklik sağlayacak kaynaklar ekleyerek, donanım tüketimi sorunlarını ele almak için kümenizi yeni düğümlerle ölçeklendirebilirsiniz. Bu aynı zamanda maliyetlerinizi de artıracağından, öncelikle kümenizde yedekli bölmeler olup olmadığını kontrol etmeye değer. Kullanılmayan kaynakların kaldırılması, yeni kaynaklar için kapasiteyi serbest bırakır.
kullanarak düğümlerinizin her birinde bulunan kaynakları inceleyebilirsiniz. describe node
sipariş:
$ kubectl düğüm demo-düğümünü tanımlar ... Tahsis edilen kaynaklar: (Toplam limitler yüzde 100'ün üzerinde olabilir, yani fazla taahhüt edilmiş olabilir.) Kaynak Talep Limitleri -------- -------- ---- -- işlemci 812m (%90) 202m (%22) bellek 905Mi (%57) 715Mi (%45) kısa ömürlü depolama 0 (%0) 0 (%0) büyük sayfalar-2Mi 0 (%0) 0 (%0)
Bu düğümdeki bölmeler zaten kullanılabilir belleğin %57'sini istiyor. Yeni bir bölme kendisi için 1 Gi talep ederse, düğüm planlama talebini kabul edemez. Düğümlerinizin her biri için bu bilgileri izlemek, kümenizin aşırı tedarik edilip edilmediğini değerlendirmenize yardımcı olabilir. Düğümlerinizden birinin arızalanması ve iş yüklerinin başka bir düğümde yeniden planlanması gerekmesi durumunda yedek kapasiteye sahip olmanız önemlidir.
Eksik programlanabilir düğümlerden kaynaklanan planlama hataları, aşağıdakine benzer bir mesaj görüntüler. FailedScheduling
Etkinlik:
0/4 düğüm mevcut: 4 düğüm programlanamadı
Döngüye alındıkları için programlanamayan düğümler aşağıdakileri içerecektir: SchedulingDisabled
durum alanında:
$ kubectl get nodes ADI DURUM ROLLER YAŞ SÜRÜM düğüm-1 Hazır,SchedulingDisabled kontrol düzlemi,master 26m v1.23.3
Yeni bölmeler almasına izin vermek için düğümün bağlantısını kaldırabilirsiniz:
$ kubectl kayıtsız düğüm-1 düğüm/düğüm-1 kordonsuz
Düğümler kapalı olmadığında ve yeterli kaynağa sahip olduğunda, zamanlama hatalarına genellikle kirlilik veya hata neden olur. nodeSelector
Pod'unuzdaki alan. Eğer kullanırsan nodeSelector
yazım hatası yapmadığınızı ve kümenizde belirttiğiniz etiketlere sahip bölmeler olduğunu doğrulayın.
Düğümler kirlendiğinde, bölmenizin manifest dosyasına ilgili toleransı eklediğinizden emin olun. Örnek olarak, burada kirlenmiş bir düğüm var, bu nedenle bölmeler, bir demo-taint: allow
hata payı:
$ kubectl taint düğümleri node-1 demo-taint=allow:NoSchedule
Düğümde planlayabilmeleri için bölme bildirimlerinizi düzenleyin:
spec: toleranslar: - anahtar: demo kusuru Şebeke: Eşit değer: izin vermek Efekt: program yok
neden olan sorunu çözün FailedScheduling
durumu, Kubernetes'in bekleyen bölmelerinizi planlamaya devam etmesine izin verecektir. Kontrol düzlemi düğümlerinizdeki değişiklikleri algıladıktan kısa bir süre sonra otomatik olarak çalışmaya başlayacaklar. Sorun, yanlış benzeşim veya yakınlık gibi bölme bildiriminizdeki hatalardan kaynaklanmadıkça bölmelerinizi yeniden başlatmanız veya el ile yeniden oluşturmanız gerekmez. nodeSelector
alanlar.
özet
FailedScheduling
Kubernetes, kümenizdeki bir düğüme yeni bir bölme yerleştiremediğinde hatalar oluşur. Bu genellikle mevcut düğümlerinizin CPU, bellek ve disk gibi donanım kaynaklarının tükenmesinden kaynaklanır. Böyle bir durumda, kümenizi ek düğümler içerecek şekilde ölçeklendirerek sorunu çözebilirsiniz.
Zamanlama hataları ayrıca, bölmeler, kümenizdeki kullanılabilir düğümler tarafından şu anda karşılanamayan düğüm benzerliklerini, anti-benzeşimlerini ve seçicileri belirttiğinde de ortaya çıkar. Engellenen ve kirlenmiş düğümler, Kubernet'lerin kullanabileceği seçenekleri daha da azaltır. Bu tür bir sorun, bildirimlerinizi etiketlerdeki yazım hataları için kontrol ederek ve artık ihtiyacınız olmayan kısıtlamaları kaldırarak çözülebilir.