Sıfırdan başlayın K8'ler: Çizelgeleme sürecine ve zamanlayıcının algoritmasına giriş
Kılavuz : En popüler konteyner otomasyon işlem ve bakım platformu olan Kubernetes, açıklayıcı bir şekilde esnek konteyner düzenlemesini uygular.Bu makale, ana filtreler ve Puan algoritmalarının yanı sıra v1.16 sürümüne dayalı olarak K8'lerin temel zamanlama çerçevesini ve sürecini ayrıntılı olarak tanıtır. Uygulama vb. Ve özel zamanlama yeteneklerini uygulamanın iki yolunu tanıttı.
Planlama süreci
Planlama sürecine genel bakış
Şu anda en yaygın konteyner otomasyon operasyon ve bakım platformu olarak, K8s konteyner düzenlemesinin temel bileşeni olan kube-scheduler, bugün tanıtacağım kahramanı olacak. Aşağıdaki sürümlerin tümü, release-1.16 Temel olarak, aşağıdaki şekil kube-scheduler'ın ana bileşenlerini göstermektedir:
Zamanlayıcının planlama stratejisi başlangıç yapılandırması şu anda üç yöntemi desteklemektedir: yapılandırma dosyası / komut satırı parametreleri / ConfigMap. Planlama stratejisi, ana planlama sürecinde hangi filtrelerin (Tahminler), puanlama cihazlarının (Öncelikler), harici olarak genişletilmiş programlayıcıların (Genişleticiler) ve yeni desteklenen SchedulerFramwork özel uzantı noktalarının (Eklentiler) kullanılacağını belirtecek şekilde yapılandırılabilir.
MuhbirZamanlayıcı başladığında, Bölmeler, Düğümler, Kalıcı Hacim (PV), Kalıcı Hacim İddiası (PVC) vb. Gibi K8s bilgilendirme mekanizması aracılığıyla kube-apiserver'dan planlama yapmak için gereken verileri almak için Liste + İzleme'yi kullanır ve bu verileri kesinleştirir. Ön işleme, zamanlayıcının Önbelleği olarak kullanılır.
Sevk hattıGeçmek Muhbir Sıraya programlanması gereken Bölmeyi ekleyin ve Ardışık Düzen, Bölmeyi bekleyen Kuyruk Açısından yürütme için Ardışık Düzeneğe geçiş yapacaktır.
Zamanlama ardışık düzeninin (Çizelge Ardışık Düzeni) esas olarak üç aşaması vardır: Zamanlayıcı İş Parçacığı, İş Parçacığını Bekle, İş Parçacığını Bağla.
- Zamanlayıcı İş Parçacığı aşaması : Yukarıdaki mimari diyagramdan, Schduler Thread'in Ön Filtre deneyimini yaşayacağını görebiliriz. > Filtre > Sonrası Filtre > Puan- > Rezerv basitçe Filtre olarak anlaşılabilir > Puan- > Rezerv.
Filtre aşaması, Kapsül Özelliği açıklamasını karşılayan Düğümleri seçmek için kullanılır; Puan aşaması, Filtreden sonra Düğümleri puanlamak ve sıralamak için kullanılır; Yedek aşaması, Bölmeyi NodeCache'deki sıralı optimum Düğümle birleştirerek Kapsülün bu Düğüme tahsis edildiğini gösterir. Bırakın, bu Düğümü filtrelemek ve puanlamak için planlanmayı bekleyen bir sonraki Kapsül, henüz atanan Kapsülü görebilir.
- İş Parçacığını Bekle aşaması: Bu aşama, Bölme ile ilişkili kaynakların Hazır beklemesini beklemek için kullanılabilir; örneğin, PVC'nin PV'sinin başarılı bir şekilde oluşturulmasını beklemek veya ilişkili Bölmenin Çete planlamasında başarılı bir şekilde planlanmasını beklemek, vb .;
- İplik Bağlama aşaması: Kube APIServer, Pod ve Node arasındaki ilişkiyi sürdürmek için kullanılır.
Tüm zamanlama ardışık düzeni yalnızca seri halde bir Bölme olan Zamanlayıcı İş Parçacığı aşamasında planlanır ve Bekle ve Bağla aşamalarında Bölmeler eşzamansız ve paralel olarak yürütülür.
Ayrıntılı planlama süreci
Kube-scheduler'ın ana bileşenlerinin işlevlerini ve ilişkilerini açıkladıktan sonra, Scheduler Pipeline'ın belirli çalışma prensibini daha derinlemesine anlayalım. Aşağıda, kube-scheduler'ın ayrıntılı bir akış şeması yer almaktadır. İlk olarak, programlama kuyruğunu açıklayın:
Zamanlama Üç alt sıra vardır activeQ, backoffQ ve unchedulableQ.
Zamanlayıcı başladığında, planlanmayı bekleyen tüm Bölmeler activieQ'ya girecektir. ActiveQ, Bölmenin önceliğine göre sıralanacaktır. Zamanlayıcı Boru Hattı, Ardışık Düzen yürütme planlama süreci için activeQ'dan bir Kapsül alacaktır. Zamanlama başarısız olduğunda, duruma göre doğrudan planlanamazQ veya geri çekilmeyi seçecektir. Geçerli Kapsül planlama dönemi sırasında Zamanlayıcı Önbelleği'nde Düğüm Önbelleği ve Bölme Önbelleği gibi bir değişiklik olursa, geri çekilmeQ'ya girecek, aksi takdirde programlanamazQ'ya girecektir.
unschedulableQ, activeQ'yu veya backoffQ'yu daha uzun bir süre boyunca düzenli olarak temizler (örneğin, 60 saniye) veya Zamanlayıcı Önbelleği değiştiğinde, ilişkili Bölmeyi activeQ'yu veya backoffQ'yu temizlemek için tetikler; backoffQ, programlanamazQ'yu programlanamazQ'dan daha hızlı hale getirmek için geri çekilme mekanizmasını kullanır. Kapsül, yeniden planlama için activeQ'ya girer.
Daha sonra, Zamanlayıcı İş Parçacığı aşamasını ayrıntılı olarak tanıtacağız. Zamanlayıcı ardışık düzeninde planlanmayı bekleyen bir Kapsül aldığınızda, Filtre mantığı eşleştirmesi gerçekleştirmek için ilgili Düğümü NodeCache'den alacaksınız. Düğümün NodeCache'den geçişi işlemi için basitçe özetlenebilecek bir uzamsal algoritma optimizasyonu vardır. Planlamanın felaket toleransını göz önünde bulundurarak tüm düğümleri filtrelemekten kaçınmak için Örnekleme programı .
Spesifik optimizasyon algoritması mantığı (İlgilenen öğrenciler, node_tree.go'nun Next yöntemini görebilir): NodeCache'de Node, bölgeye göre bölünür. Filtreleme aşamasında, NodeCache için bir zondeIndex tutulur.Her düğüm filtreleme için açılır, zoneIndex bir pozisyon geri hareket ettirilir ve sonra bölgenin düğüm listesinden bir düğüm alınır.
Yukarıdaki şekilde dikey eksende her seferinde otomatik olarak artan bir nodeIndex olduğunu görebilirsiniz. Geçerli bölgedeki düğümün verisi yoksa, sonraki bölgeden verileri alır. Yaklaşık süreç, zoneIndex'in soldan sağa gitmesidir ve nodeIndex, elde edilen Düğüm düğümlerinin bölgeye göre dağılmasını sağlayarak düğümlerin az dengeli dağıtımını göz önünde bulundurarak tüm düğümleri filtrelemekten kaçınmaktır. (En son sürüm-v.1.17 sürümü bu algoritmayı iptal etti, iptalin neden Bölme tercihini ve düğüm tercihini dikkate almaması gerektiğini ve Bölmenin Teknik Özellik gereksinimlerini uygulamadığını)
Örnekleme programı İçerideki örnekleme ölçeği kısaca burada tanıtılmıştır, varsayılan Örnekleme oranı Formül = Maks (5, 50-kümedeki düğüm sayısı / 125), örnekleme ölçeği = Maks (100, kümedeki düğüm sayısı * örnekleme oranı).
İşte bir örnek: düğüm boyutu 3000 düğümdür, ardından ** örnekleme oranı = Maks (5, 50-3000 / 125) =% 26, sonra Örnekleme boyutu * = Maks (100, 30000.26) = 780. Programlama hattında, Filtre 780 aday düğümle eşleştiği sürece, Filtre işlemi durdurulabilir ve Puan aşamasına gidebilir.
Puan aşaması Politika tarafından yapılandırılan puanlama eklentisine göre sıralayın ve en yüksek puana sahip düğüm SelectHost olarak seçilir. Ardından bu Kapsülü bu Düğüme atayın. Bu işleme Reserver aşaması Hesap defteri avansı olarak adlandırılabilir. Preemption işlemi, Pod'un PodCache'deki durumunu Varsayılan durumuna (bellek durumunda) değiştirir.
Zamanlama süreci şunları içerir: Pod durum makinesinin yaşam döngüsü İşte Pod'un ana durumlarına kısa bir giriş: İlk (Sanal durum) - > Varsayıldı (Reserver) - > Katma - > silindi (Sanal durum); Pod verilerinin Informer izleme aracılığıyla bu düğüme tahsis edileceği belirlendiğinde, Kapsül durumu Eklendi olarak değiştirilecektir. Düğüm seçildiğinde ve Bağlama durumundayken, Bağlama başarısız olabilir. Bağlama başarısız olduğunda, önceden doldurulmuş defteri, Varsayılan durumu silip Kapsülü Düğümden kaldırmak için Varsayılmış veriler olarak Başlangıç durumuna geri döndürmek için geri alınacaktır. Defter temizlendi.
Bağlama başarısız olursa, Kapsül, planlanamazQ kuyruğuna geri bırakılacaktır. Planlama kuyruğunda, Kapsüller hangi koşullar altında geri çekmeye gidecek? Bu çok detaylı bir noktadır. Böyle bir zamanlama döngüsü sırasında Önbellek değişirse, Bölme backoffQ'ya yerleştirilecektir. BackoffQ'daki bekleme süresi, çizelgelemeyenQ'dakinden daha kısa olacaktır. BackoffQ'da, üssel güç düşüşü olan 2'lik bir düşürme stratejisi vardır. İlk tekrar denemenin 1s, ikincinin 2s, üçüncünün 4s, dördüncünün 8s ve maksimumun 10s olduğunu varsayarsak.
Planlama algoritması uygulaması
Dayanaklar (filtre)
Filtreler, işlevsel amaçlarına göre dört kategoriye ayrılabilir:
- Depolama eşleşmesi ile ilgili
- Pode ve Node eşleşmesiyle ilgili
- Kapsül ve Kapsül eşleşmesiyle ilgili
- Kapsül parçalanmasıyla ilgili
Birkaç filtrenin depolamayla ilgili işlevleri:
- NoVolumeZoneConflict , Eşleşecek düğümü pv'yi takip edecek şekilde kısıtlamak için pvc ile ilişkili pv etiketindeki bölgeyi \ az ayarlayın;
- MaxCSIVolumeCountPred , PVC üzerinde belirtilen Provizyonun CSI eklentisindeki tek bir makinenin maksimum PV limitini doğrulamak için kullanılır;
- CheckVolumeBindingPred , Pvc ve pv'nin bağlanma işlemi sırasında mantık kontrolü yapılır, içeride yazılan mantık daha karmaşıktır, esas olarak pv'nin nasıl yeniden kullanılacağı;
- NoDiskConfict SCSI depolama birimi çoğaltılmayacaktır.
- CheckNodeCondition: Düğümün programlanmaya hazır olup olmadığını kontrol etmek için, node.condition koşul türünü kontrol edin: Ready is true, NetworkUnavailable is false ve Node.Spec.Unschedulable is false;
- CheckNodeUnschedulable: Düğüm düğümünde bir NodeUnschedulable işareti var.Bu düğümü doğrudan kube-controller aracılığıyla programlanamaz olarak işaretleyebiliriz, bu durumda bu düğüm programlanmayacaktır. 1.16 sürümünde, bu Planlanamaz bir Taints haline geldi. Başka bir deyişle, Bölmede işaretlenen Toleratların bu Kusurları tolere edip edemeyeceğini doğrulamanız gerekir;
- PodToleratesNodeTaints: Düğümün Bozukluklarının Pod Toleratlarına dahil edilip edilmediğini kontrol edin;
- PodFitsHostPorts: Kapsül üzerindeki Kap tarafından bildirilen Bağlantı Noktalarının Düğüm üzerinde zaten tahsis edilmiş olan Bölme tarafından kullanılıp kullanılmadığını kontrol edin;
- MatchNodeSelector : Pod.Spec.Affinity.NodeAffinity ve Pod.Spec.NodeSelector'ın Labels of Node ile eşleşip eşleşmediğini doğrulayın.
MatchinterPodAffinity: Temelde PodAffinity ve PodAntiAffinity'nin doğrulama mantığı. En büyük karmaşıklık, Affinity'deki PodAffinityTerm açıklaması tarafından desteklenen TopologyKey'de yatmaktadır (düğüm / bölge / az gibi topolojik yapılarda ifade edilebilir). Bu aslında bir performans katilidir.
Kapsül parçalanmasıyla ilgili- EvenPodsSpread
- CheckServiceAffinity
Bu yeni bir özelliktir. İlk olarak, EvenPodsSpread içindeki Spec tanımına bir göz atalım: -Belirtilen TopologyKey'deki koşulları karşılayan bir Pod grubunun dağıtım gereksinimlerini tanımlayın.
Aşağıdaki şekilde gösterildiği gibi, bir Kapsül grubunu nasıl tanımlayacağımıza bir göz atalım:
spec: topologySpreadConstraints: -maxSkew: 1 whenUnsatisfiable: DoNotSchedule topologyKey: k8s.io/hostname seçici: matchLabels: uygulama: foo matchExpressions: -key: uygulama operatör: İçinde değerler:seçici : Parçalanması gereken topolojiyi açıklamak için kullanılan bir Kapsül grubu listesi
topologyKey : Hangi topolojik yapı üzerinde hareket eder;
maxSkew : İzin verilen maksimum dengesizlik miktarı;
ne zaman tatmin edilemez : TopologySpreadConstraint karşılanmadığında strateji, DoNotSchedule: filtre aşamasında hareket etmek anlamına gelir, ScheduleAnyway: puan aşamasında hareket etmek.
Aşağıdaki örnek şunları açıklamaktadır:
Seçici, etiketleri app = foo ile eşleşen tüm bölmeleri seçer. Bölge düzeyinde dağılmış olmaları gerekir ve izin verilen maksimum dengesizlik sayısı 1'dir.
Kümede üç bölge vardır ve yukarıdaki şekilde app = foo etiket değerine sahip Pod'a hem zone1 hem de zone2'de bir kapsül atanır.
Dengesizlik miktarını hesaplamanın formülü şöyledir: ActualSkew = count-min (count)
Öncelikle, seçiciye göre uygun Kapsüllerin bir listesini alın
İkincisi, saymak için topologyKey'e göre gruplandıracak
ŞEKİL'de gösterildiği gibi:
MaxSkew'in 1 olduğu varsayılırsa, zone1 / zone2'ye atanmışsa, eğriltme değeri 2'dir ve bu, daha önce ayarlanan maxSkew'den daha büyüktür. Bu bir maç değil, bu yüzden sadece zone3'e atanabilir. Bölge 3'e tahsis edilmişse, min (sayım) 1 ve sayı 1 ise, o zaman çarpıklık 0'a eşittir, bu nedenle yalnızca bölge2'ye tahsis edilebilir.
MaxSkew'in 2 olduğunu, z1 (z2) 'ye atandığını, eğriltme değerinin 2/1/0 (1/2/0) olduğunu ve maksimum değerin 2 olduğunu varsayalım, < = maxSkew. Bu z1 / z2 / z3'ün seçilmesine izin verilir.
EvenPodsSpread, bir TopologyAnahtar üzerinde bir Pod grubunun dengeli dağılımını gerçekleştirebilir. Her topo'yu dengelemeniz gerekiyorsa, maxSkew'i 1'e ayarlayabilirsiniz. Elbette, bu açıklama, kaç topoloji Değerinin atanması gerektiği gibi bazı kontrollerden yoksundur. limit.
Öncelikler
Şimdi puanlama algoritmasına bakalım: Puanlama algoritmasının çözdüğü ana problemler küme parçalanması, afet toleransı, su seviyesi, afinite ve anti-afinitedir.
Kategoriye göre dört kategoriye ayrılabilir:
- Düğüm su seviyesi
- Kapsül parçalanması (topp, servis, denetleyici)
- Düğüm afinitesi ve anti afinite
- Bölme afinitesi ve anti afinite
Ardından, puanlayıcıyla ilgili ilk kaynak düzeyini tanıtın.
Yukarıdaki şekilde gösterildiği gibi, kaynak düzeyiyle ilgili dört ana düğüm puanlama algoritması vardır.
- Kaynak seviyesi formülü kavramı
İstek Düğüm kaynakları tahsis etti; Ayrılabilir : Düğümün zamanlanabilir kaynakları
- Öncelikli ayrılık
Kapsülü, en büyük boşta kaynağa sahip düğüm yerine en yüksek kaynak boşta kalma oranına sahip düğüme atayın, şu formül: kaynak boşta kalma oranı = (Tahsis Edilebilir-İstek) / Tahsis Edilebilir , Değer daha büyük olduğunda puan daha yüksek olur ve önce yüksek puanlı düğümler atanır. onların arasında (Ayrılabilir-İstek) Kapsül bu düğüme ayrıldıktan sonraki ücretsiz kaynakların sayısını temsil eder.
- Öncelikli yığınlama
Kapsülü en yüksek kaynak kullanımına sahip düğüme atayın, şu formül: kaynak kullanımı = Talep / Tahsis Edilebilir , Kaynak kullanım oranı ne kadar yüksekse, puan o kadar yüksek ve puan o kadar yüksek düğüme atanacaktır.
- Parçalanma oranı
Düğümdeki birden çok kaynak arasındaki kaynak kullanım oranındaki farkı ifade eder. Şu anda üç tür kaynak desteklenmektedir: CPU / Mem / Disk. Yalnızca CPU / Mem dikkate alınırsa, parçalanma oranı formülü = Mut. Örneğin, CPU ayırma oranı% 99 ve bellek ayırma oranı% 50 olduğunda, parçalama oranı =% 99 -% 50 =% 50, bu durumda bu örnekte% 1 CPU ve% 50 Mem kaldı. Bu tür bir konteyner Mem dışında kalabilir. Puan = 1-Parçalanma oranı, parçalanma oranı ne kadar yüksekse puan o kadar düşük olur.
- Oranı belirtin
Küme üzerindeki düğüm kaynak tahsisinin dağıtım eğrisini kontrol etmek için Zamanlayıcı başladığında her kaynak kullanım oranı için bir puan ayarlayabilirsiniz.
Pod ayrılması
Kapsül'ün çözmek için parçaladığı sorun, farklı topolojilerde konuşlandırılmış bir grup uygun Kapsülün yayılma gereksinimlerini desteklemektir.
- SelectorSpreadPriority
Kontrolörün altındaki ve Kapsülün ait olduğu tüm Bölmelerin Düğümde bölünmesi gerekliliğini gerçekleştirmek için kullanılır. Uygulama şu şekildedir: Denetleyici altındaki tüm Bölmeleri, tahsis edilecek Bölmenin ait olduğu denetleyiciye göre hesaplayacak, toplam sayının T olduğunu varsayacak ve bu Bölmeler için istatistikleri bulundukları Düğüme göre gruplayacaktır; N (bir Düğüm ile temsil edilir) varsayarak İstatistik değeri), daha sonra Düğümdeki puan (TN) / T puanı olarak sayılır.Değer ne kadar büyükse, bu düğümün denetleyici dağıtımı o kadar az, iş yükü bölmesi ayrılması talebini karşılamak için puan o kadar yüksek olur.
- ServiceSpreadingPriority
Resmi yorum SelectorSpreadPriority'nin yerine kullanılmasının yüksek olasılık olduğunu söylüyor. Kişisel olarak şunu anlıyorum: Hizmet, hizmetlerin dağıtımını yeterince parçalayabildiğimiz sürece bir hizmet grubunu temsil eder.
- EvenPodsSpreadPriority
Belirli bir topolojide bir grup nitelikli Kapsülün dağıtım gereksinimlerini belirtmek için kullanılır.Bu, daha esnek ve özelleştirilmiş bir yoldur ve aynı zamanda daha karmaşık bir kullanım yoludur.
Bu kullanım yöntemi her zaman değişebileceğinden, topoloji yapısının şu şekilde olduğunu varsayıyoruz: Spec'in düğüm üzerine dağıtılması gerekiyor, Spec'in belirtilen labelSelector koşulunun bu düğümde sağlandığını hesaplamak için yukarıdaki şekildeki hesaplama formülünü takip edebiliriz. Bölme sayısı ve ardından maksimum farkı hesaplayın ve ardından Düğüm tarafından atanan ağırlığı hesaplayın.Değer büyükse değere öncelik verilir.
Düğüm afinitesi ve anti afinite
- NodeAffinityPriority , Bu, Pod ve Düğümün afinitesini ve anti afinitesini tatmin etmek içindir;
- ServiceAntiAffinity , Hizmet kapsamındaki Kapsüllerin belirli bir Düğüm etiketinin değerine göre dengelenmesini desteklemektir. Örneğin, kümenin düğümleri için bulutta ve bulutun altında iki düğüm kümesi vardır.Hizmetlerin bulut üzerinde ve dışında eşit olarak dağıtılmasını istiyoruz.Düğüm üzerinde belirli bir etiket olduğunu varsayarsak, dağıtımı dağıtmak için bu ServiceAntiAffinity'yi kullanabiliriz;
- NodeLabelPrioritizer , Temel olarak belirli belirli etiket Düğümlerine öncelik tahsisi sağlamak için Algoritma çok basittir Başlangıçta, etiket koşulunun Düğüm üzerinde, programlama ilkesi (SchedulerPolicy) tarafından yapılandırılan etiket değerine göre karşılanıp karşılanmadığı ve koşulu karşılayan düğümün ilk atanıp atanmadığı belirlenir;
- ImageLocalityPriority , Düğüm yakınlığının ana düşüncesi, görüntü indirme hızıdır. Düğümde bir ayna varsa, Kapsül önce bu düğüme programlanır ve aynanın boyutu da burada dikkate alınır.Örneğin, Bölmenin birkaç aynası vardır. Ayna ne kadar büyükse indirme hızı o kadar yavaş olur. Düğümdeki mevcut aynayı takip eder. Boyut öncelik ilişkisi.
InterPodAffinityPriority
Önce kullanım senaryolarını tanıtın:
- İlk örnek, örneğin, uygulama A veri sağlar ve uygulama B hizmetler sağlar A ve B, ağ iletimini optimize etmek için yerel ağı çalıştırmak üzere birlikte konuşlandırılabilir;
- İkinci örnekte, uygulama A ve uygulama B'nin her ikisi de CPU yoğun uygulamalarsa ve birbirleriyle çakışacakları kanıtlanırsa, bu kural ayarı onları mümkün olduğunca aynı düğümde tutmak için kullanılabilir.
NodePreferAvoidPodsPriority
Belirli kontrolörlerin mümkün olduğu kadar belirli node'lara tahsis edilmeme yeteneğini gerçekleştirmek için kullanılır; hangi kontrolörlerin Node'a tahsis edilmemesi gerektiğini bildirmek için node üzerine açıklamalar ekleyerek, eğer tatmin olmazsa öncelik verilecektir.
Planlayıcı nasıl yapılandırılır
Yapılandırma planlayıcıya giriş
Bir planlayıcı nasıl başlatılır, iki durum vardır:
- Birincisi, zamanlayıcıyı herhangi bir parametre belirtmeden varsayılan yapılandırma ile başlatabiliriz;
- İkincisi, konfigürasyon çizelgesi dosyasını belirleyebiliriz.
Varsayılan olarak başlarsak, varsayılan yapılandırmanın başlangıç parametrelerinin ne olduğunu bilmek isteriz? Varsayılan yapılandırmayı belirli bir dosyaya yazmak için --write-config-to komutunu kullanabilirsiniz.
Aşağıdaki şekilde gösterildiği gibi varsayılan yapılandırma dosyasına bir göz atalım:
- algoritmaSource : Algoritma sağlayıcısı, şu anda üç yöntem sağlamaktadır: Sağlayıcı, dosya, configMap, daha sonra tanıtılacaktır;
- percentOfNodesToscore : Programlayıcı tarafından sağlanan bir genişletme yeteneği, Düğüm düğümlerinin örnekleme ölçeğini azaltabilir;
- schedulerName : Planlayıcı başladığında hangi Bölmelerin programlamadan sorumlu olduğunu belirtmek için kullanılır; belirtilmezse, varsayılan ad varsayılan programlayıcıdır;
- bindTimeoutSeconds : Bağlanma aşamasının çalışma süresini saniye cinsinden belirtmek için kullanılır;
- ClientConnection : Kube-apiserver ile etkileşim için bazı parametre yapılandırmalarını yapılandırmak için kullanılır. Örneğin, contentType, burada protobuf olarak belirtilen kube-apiserver ile etkileşim için kullanılan bir serileştirme protokolüdür;
- disablePreemption : Önleme planlamasını kapatın;
- hardPodAffinitySymnetricweight : PodAffinity ve NodeAffinity'nin ağırlığını yapılandırın.
algoritmaSource
Filtreler ve puanlayıcılar gibi bazı yapılandırma dosyası biçimleri aşağıda verilmiştir. Şu anda, üç yol vardır:
- Sağlayıcı
- dosya
- configMap
Sağlayıcı belirtilmişse, bunu uygulamanın iki yolu vardır:
- Biri DefaultPrivider'dır;
- Bunlardan biri ClusterAutoscalerProvider'dır.
Önce ClusterAutoscalerProvider yığınlanır ve önce DefaultPrivider bozulur. Bu stratejiyle ilgili olarak, düğümünüzde otomatik ölçeklendirme etkinleştirildiğinde, ClusterAutoscalerProvider'ı mümkün olduğunca kullanmak ihtiyaçlarınızı daha iyi karşılayacaktır.
Aşağıdaki şekilde gösterildiği gibi, politika dosyasının yapılandırma içeriğine bir göz atın:
Burada yapılandırılmış filtre tahminlerini, yapılandırılmış puanlama cihazı önceliklerini ve yapılandırdığımız genişletilmiş planlayıcıyı görebilirsiniz. Buradaki daha ilginç parametrelerden biri: alwaysCheckAllPredicates. Filtre listelerinden biri false? Döndürdüğünde yürütmeye devam edip etmeyeceğini kontrol etmek için kullanılır. Varsayılan kesinlikle yanlıştır; doğru olarak yapılandırılırsa, her eklentiden geçecektir.
Planlayıcı nasıl genişletilir
Zamanlayıcı Genişletici
İlk önce Schedule Extender'ın neler yapabileceğine bakın? Resmi programlayıcıyı başlattıktan sonra, başka bir genişletilmiş programlayıcı başlatabilirsiniz.
Yapılandırma dosyası aracılığıyla, yukarıda bahsedilen Polic dosyasındaki genişleticinin yapılandırması, bir https hizmeti olup olmadığı ve hizmetin halihazırda NodeCache'ye sahip olup olmadığı genişletici hizmetin URL adresini içerir. Bir NodeCache varsa, zamanlayıcı yalnızca düğüm adları listesini iletir. Etkinleştirilmezse, programlayıcı tüm düğüm bilgisi tam yapılarını geçecektir.
Göz ardı edilebilir Bu parametre, ağa ulaşılamadığında veya hizmetin bir hata bildirdiğinde programlayıcının genişletilmiş programlayıcıyı göz ardı edip edemeyeceğini gösterir. ManagedResources'e göre, resmi programlayıcı, bu Kaynakla karşılaştığında genişletilmiş planlayıcıyı kullanacaktır, belirtilmezse, tümü genişletilmiş planlayıcıyı kullanacaktır.
İşte GPU paylaşımına bir örnek. Genişletilmiş programlayıcı, her karta tahsis edilen bellek boyutunu kaydedecektir Resmi programlayıcı, sadece Düğüm düğümündeki toplam grafik kartı belleğinin yeterli olup olmadığından sorumludur. Buradaki genişletilmiş kaynağa example / gpu-men: 200g adı verilir. Planlanacak bir Kapsül olduğunu varsayarsak, genişletilmiş kaynaklarımızı kube-scheduler aracılığıyla göreceğiz. Bu genişletilmiş kaynak yapılandırmasının, planlama aşamasında yapılandırılmış url'yi geçirecek olan genişletilmiş zamanlayıcıyı kullanması gerekir. Zamanlayıcının gpu-paylaşımını uygulama yeteneğini elde etmek için genişletilmiş planlayıcıyı çağırmak için adres.
Zamanlayıcı Çerçevesi
Bu, uzantı noktası kullanımı ve eşzamanlılık modelinden ayrı olarak sunulan iki noktaya bölünmüştür.
Uzatma noktasının temel amacıUzatma noktalarının temel amaçları aşağıdaki gibidir:
- QueueSort: Özel Bölmelerin sıralanmasını desteklemek için kullanılır. QueueSort'un sıralama algoritması belirtilirse, zamanlama kuyruğundaki belirtilen sıralama algoritmasına göre sıralanır;
- Ön filtre: Bu aşamada ayarlanabilen Kapsül önbelleği gibi Kapsül isteklerini ön işleme;
- Filtre: Filtreyi genişletmek içindir, istediğiniz bazı filtreleri ekleyebilirsiniz, örneğin, az önce bahsedilen gpu-paylaşımlı burada uygulanabilir;
- PostFilter: günlükler / ölçümler için veya Puanlamadan önce veri ön işlemesi yapmak için kullanılabilir. Örneğin, burada özel bir önbellek eklentisi yapılabilir;
- Puan: İyileştirme sağlamak için bu arayüz aracılığıyla bir puanlama eklentisidir;
- Reserver: Durum bilgisi olan eklentiler için kaynaklar için bellek muhasebesi yapabilirsiniz;
- İzin ver: bekle, reddet, onayla, çetenin ekleme noktası olarak kullanılabilir. Bu, her bölme için yapılabilir, tüm Bölmelerin başarılı bir şekilde planlanmasını bekleyebilir ve devam etmeden önce kullanılabilir duruma ulaşabilir, bir bölme başarısız olursa, buradan reddedilebilir;
- PreBind: Düğümü gerçekten bağlamadan önce bazı işlemleri gerçekleştirin, örneğin: bulut diskini Düğüme bağlayın;
- Bağlama: Bir Kapsül yalnızca bir BindPlugin tarafından işlenir;
- PostBind: Bağlama başarılı olduktan sonra yürütülen mantık, örneğin, günlükler / ölçümler için kullanılabilir;
- Ayrılmamış: Permit'ten Bind'e kadar olan aşamalarda, bir hata bildirildiği sürece, geri alınacaktır. Örneğin, Permit başarısız olursa ve PreBind önceki aşamada başarısız olursa, tüm kaynaklar geri alınacaktır.
Eşzamanlılık modeli, yukarıdaki şeklin açık mavi kısmında gösterildiği gibi, ana planlama sürecinin Ön Filtreden Rezerv'e olduğu anlamına gelir. Kuyruktan bir Kapsül alındıktan ve Yedeğin sonuna kadar programlandıktan sonra, Bölme Eşzamansız olarak Bekleme İş Parçacığına devredilecektir.Bekleme İş Parçacığı başarılı bir şekilde beklerse, bu tür bir iş parçacığı modeli olan Bağlama İş Parçacığına teslim edilecektir.
Özel EklentiÖzel bir Eklenti nasıl yazılır ve kaydedilir?
İşte resmi bir örnek: Bağlama aşamasında, Kapsülü bir Düğüme bağlamanız ve Kube-apiserver'ı bağlamanız gerekir. Burada iki ana arayüz olduğunu görebilirsiniz.Bind arayüzü, zamanlayıcının adını ve bağlama mantığını bildirmektir. Son olarak, yapım yönteminin ne tür bir mantık olduğunu anlatan bir inşaat yöntemi uygulamalıyız.
Özel Eklentinin planlayıcısını başlatın:
- SATICI
- çatal
Başlangıçta kaydolmanın iki yolu vardır:
- İlk yol, kendiniz bir komut dosyası yazmak ve zamanlayıcı kodu satıcısını satıcı aracılığıyla eklemektir. Scheduler.NewSchedulerCommand'i başlatırken defaultbinder'ı kaydedin, böylece bir zamanlayıcı başlatabilirsiniz;
- İkinci yol, kube-scheduler kaynak kodunu çatallamak ve ardından zamanlayıcının varsayılan bağlayıcısını yazmaç eklentisi aracılığıyla kaydetmektir. Eklentiyi kaydettikten sonra, bir komut dosyası oluşturmaya gidin, bir yansıtma oluşturun ve ardından başladığında yapılandırma dosyasının plugins.bind.enable içinde başlatın.
Bu makalenin özeti
Bu, bu makalenin içeriğini tamamlıyor. İşte herkes için kısa bir özet:
- İlk bölüm, size zamanlayıcının genel iş akışının yanı sıra bazı hesaplama algoritması optimizasyonlarını tanıtır;
- İkinci bölüm, filtre bileşenlerinin uygulanmasını ve çizelgelemenin ana çalışma bileşenlerinin puan bileşenlerini ayrıntılı olarak tanıtır ve çeşitli puan kullanım senaryolarını listeler;
- Üçüncü bölüm, programlayıcının konfigürasyon dosyasının kullanım talimatlarını tanıtır, böylece herkes bu konfigürasyonlar aracılığıyla istenen programlama davranışını gerçekleştirebilir;
- Dördüncü bölüm, özel iş senaryolarının çizelgeleme gereksinimlerini karşılamak için çizelgeleme yeteneklerinin genişletici / çerçeve aracılığıyla nasıl genişletileceğini, bazı gelişmiş kullanımları tanıtır.
