Kube-scheduler, belirtilen politikalara uygun olarak düğümler arasında bölmeleri planlamaktan sorumlu olan Kubernetes'in ayrılmaz bir bileşenidir. Çoğu zaman, bir Kubernetes kümesinin çalışması sırasında, varsayılan kube-scheduler'ın politika seti çoğu günlük görev için uygun olduğundan, bölmeleri planlamak için tam olarak hangi politikaların kullanıldığını düşünmemiz gerekmez. Ancak, bölmelerin dağılımında ince ayar yapmamızın önemli olduğu durumlar vardır ve bu görevi gerçekleştirmenin iki yolu vardır:
- Özel kural kümesiyle kube-scheduler oluşturun
- Kendi planlayıcınızı yazın ve ona API sunucu istekleriyle çalışmasını öğretin
Bu makalede, projelerimizden birinde bölmelerin eşit olmayan zamanlaması sorununu çözmek için tam olarak ilk noktanın uygulanmasını anlatacağım.
Kube-scheduler'a ait çalışma hakkında kısa tanıtım
Kube-scheduler'ın bölmeleri doğrudan programlamaktan sorumlu olmadığı, yalnızca bir bölmenin yerleştirileceği düğümü belirlemekten sorumlu olduğu gerçeği dikkate değerdir. Diğer bir deyişle, kube-scheduler çalışmasının sonucu, programlama isteği için API sunucusuna döndürdüğü düğümün adıdır ve işi burada biter.
İlk olarak, kube-scheduler, yüklem ilkelerine göre bir Bölmenin programlanabileceği düğümleri listeler. Ayrıca, bu listedeki her düğüm, öncelik politikalarına göre belirli sayıda puan alır. Sonuç olarak, en yüksek puana sahip düğüm seçilir. Aynı maksimum puana sahip düğümler varsa, rastgele bir tane seçilir. Şartlar (filtreleme) ve öncelikler (puanlama) politikalarının bir listesi ve açıklaması şu adreste bulunabilir: .
Sorun gövdesinin açıklaması
Nixys'te tutulan çok sayıda farklı Kubernetes kümesine rağmen, bölmeleri planlama sorunuyla ilk kez yakın zamanda, projelerimizden biri için çok sayıda periyodik görev çalıştırmanın gerekli hale gelmesiyle karşılaştık (~ 100 CronJob varlığı). Sorunun açıklamasını olabildiğince basitleştirmek için, örneğin, içinde dakikada bir cron görevinin başlatıldığı ve CPU üzerinde bir miktar yük oluşturan bir mikro hizmeti ele alalım. Cron görevinin çalışması için, tamamen aynı üç düğüm (her birinde 24 vCPU) tahsis edildi.
Aynı zamanda, girdi verilerinin miktarı sürekli değiştiği için CronJob'un tam olarak ne kadar süre çalışacağını söylemek imkansızdır. Ortalama olarak, normal kube-scheduler işlemi sırasında her düğüm, her düğümün CPU'sunda yükün ~ %3-4'unu oluşturan 20-30 iş örneği çalıştırır:
Sorunun kendisi, bazen cron görev bölmelerinin üç düğümden biri için planlanmayı bırakmasıdır. Yani, bir noktada, düğümlerden biri için tek bir bölme planlanmazken, diğer iki düğümde 6-8 görev örneği çalışıyor ve CPU üzerindeki yükün ~% 40-60'ını oluşturuyordu:
Sorun kesinlikle rastgele bir sıklıkta tekrarlandı ve ara sıra kodun yeni bir versiyonunun kullanıma sunulduğu anla ilişkilendirildi.
Kube-scheduler'ın loglama seviyesini 10. seviyeye (-v=10) çıkararak, değerlendirme sürecinde her node'un kaç puan aldığını kaydetmeye başladık. Normal zamanlama sırasında, günlüklerde aşağıdaki bilgiler görülebilir:
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, Score: (10)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, Score: (10)
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, Score: (10)
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:781] Host Node01 => Score 100043
generic_scheduler.go:781] Host Node02 => Score 100043
generic_scheduler.go:781] Host Node03 => Score 100043Onlar. Günlüklerden elde edilen bilgilere bakılırsa, düğümlerin her biri eşit sayıda son puan aldı ve planlama için rastgele bir tanesi seçildi. Problem planlaması sırasında günlükler şöyle görünüyordu:
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPodAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPodAffinityPriority, Score: (0)
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPodAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: SelectorSpreadPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPriority, Score: (10)
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPriority, Score: (10)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: NodeAffinityPriority, Score: (0)
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: SelectorSpreadPriority, Score: (10)
generic_scheduler.go:781] Host Node03 => Score 100041
generic_scheduler.go:781] Host Node02 => Score 100041
generic_scheduler.go:781] Host Node01 => Score 100038Buradan, düğümlerden birinin diğerlerinden daha az toplam puan aldığı ve bu nedenle planlamanın yalnızca maksimum puanı alan iki düğüm için yapıldığı görülebilmektedir. Böylece, sorunun tam olarak bölmelerin planlanmasında yattığından emin olduk.
Sorunu çözmeye yönelik diğer algoritma bizim için açıktı - günlükleri analiz etmek, düğümün hangi önceliğe göre puan almadığını anlamak ve gerekirse varsayılan kube-zamanlayıcının politikalarını ayarlamak. Ancak burada iki önemli zorlukla karşı karşıyayız:
- Maksimum günlük kaydı düzeyi (10), yalnızca bazı öncelikler için puan dizisini yansıtır. Yukarıdaki günlük alıntısında, günlüklere yansıyan tüm öncelikler için, düğümlerin normal ve problem çizelgelemede aynı sayıda puan aldığını, ancak problem çizelgeleme durumunda nihai sonucun farklı olduğunu görebilirsiniz. Böylece, bazı öncelikler için puanlamanın "perde arkasında" gerçekleştiği sonucuna varabiliriz ve düğümün hangi öncelik için puan almadığını anlamamızın hiçbir yolu yoktur. Bu konuyu detaylı olarak şurada anlattık. Github'daki Kubernetes deposu. Yazma sırasında geliştiricilerden, Kubernetes v1.15,1.16, 1.17 ve XNUMX güncellemelerinde günlük kaydı desteğinin ekleneceğine dair bir yanıt alındı.
- kube-scheduler'ın şu anda hangi belirli ilke kümesiyle çalıştığını anlamanın kolay bir yolu yoktur. evet içinde bu liste listelenmiştir, ancak öncelik politikalarının her biri için hangi ağırlıkların ayarlandığı hakkında bilgi içermez. Yalnızca ağırlıkları görebilir veya varsayılan kube-zamanlayıcının ilkelerini düzenleyebilirsiniz. .
Düğümün, uygulamayı çalıştırmak için gereken görüntüye zaten sahipse düğüme puan veren ImageLocalityPriority ilkesine göre puan kazanmadığını düzeltmeyi başardığımızda belirtmekte fayda var. Yani, uygulamanın yeni sürümünün kullanıma sunulması sırasında, cron görevinin iki düğümde çalışmak için zamanı vardı, bunlara liman işçisi kayıt defterinden yeni bir görüntü indiriyordu ve bu nedenle iki düğüm, göreli olarak daha yüksek bir son puan aldı. Üçüncü.
Yukarıda yazdığım gibi, günlüklerde ImageLocalityPriority politikasının değerlendirilmesi hakkında bilgi görmüyoruz, bu nedenle, varsayımımızı kontrol etmek için, uygulamanın yeni sürümüyle görüntüyü üçüncü düğümde biriktirdik, ardından planlama doğru çalıştı Zamanlama sorununun nadiren gözlemlenmesinin nedeni, ImageLocalityPriority politikasıydı, daha sıklıkla başka bir şeyle ilişkilendirildi. Varsayılan kube-zamanlayıcının öncelikler listesindeki ilkelerin her birinin hatalarını tam olarak ayıklayamadığımız için, bölme planlama ilkelerinin esnek yönetimine ihtiyacımız vardı.
Sorunun formüle edilmesi
Sorunun çözümünün olabildiğince hedeflenmesini istedik, yani Kubernetes'in ana varlıkları (burada varsayılan kube-zamanlayıcıyı kastediyoruz) değişmeden kalmalıdır. Bir sorunu bir yerde çözüp başka bir yerde yaratmak istemedik. Böylece, sorunu çözmek için makalenin girişinde açıklanan iki seçeneğe geldik - ek bir zamanlayıcı oluşturmak veya kendinizinkini yazmak. Cron görevlerini zamanlamak için temel gereksinim, yükü üç düğüm arasında eşit olarak dağıtmaktır. Bu gereklilik, mevcut kube-scheduler politikaları tarafından karşılanabilir, dolayısıyla görevimiz için kendi zamanlayıcımızı yazmanın bir anlamı yoktur.
Ek bir kube-zamanlayıcı oluşturma ve dağıtma yönergeleri şu bölümde açıklanmaktadır: . Ancak, Deployment varlığının kube-scheduler gibi kritik bir hizmetin işleyişinde hata toleransını sağlamak için yeterli olmadığı bize göründü, bu nedenle yeni kube-scheduler'ı Kubelet'in doğrudan izleyeceği bir Statik Bölme olarak dağıtmaya karar verdik. . Bu nedenle, yeni kube-scheduler için aşağıdaki gereksinimlere sahibiz:
- Hizmet, tüm küme ana bilgisayarlarında Statik Bölme olarak dağıtılmalıdır
- Kube-scheduler ile aktif pod'un kullanılamaması durumunda yük devretme sağlanmalıdır.
- Planlama sırasında ana öncelik, düğümdeki kullanılabilir kaynakların miktarı olmalıdır (LeastRequestedPriority)
Uygulama çözümleri
Kubernetes v1.14.7'deki tüm çalışmaları yapacağımızı hemen belirtelim, çünkü projede bu sürüm kullanılmıştır. Yeni kube-scheduler'ımız için bir bildirim yazarak başlayalım. Varsayılan bildirimi (/etc/kubernetes/manifests/kube-scheduler.yaml) esas alıp aşağıdaki forma getirelim:
kind: Pod
metadata:
labels:
component: scheduler
tier: control-plane
name: kube-scheduler-cron
namespace: kube-system
spec:
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --port=10151
- --secure-port=10159
- --config=/etc/kubernetes/scheduler-custom.conf
- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
- --v=2
image: gcr.io/google-containers/kube-scheduler:v1.14.7
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 8
httpGet:
host: 127.0.0.1
path: /healthz
port: 10151
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 15
name: kube-scheduler-cron-container
resources:
requests:
cpu: '0.1'
volumeMounts:
- mountPath: /etc/kubernetes/scheduler.conf
name: kube-config
readOnly: true
- mountPath: /etc/localtime
name: localtime
readOnly: true
- mountPath: /etc/kubernetes/scheduler-custom.conf
name: scheduler-config
readOnly: true
- mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
name: policy-config
readOnly: true
hostNetwork: true
priorityClassName: system-cluster-critical
volumes:
- hostPath:
path: /etc/kubernetes/scheduler.conf
type: FileOrCreate
name: kube-config
- hostPath:
path: /etc/localtime
name: localtime
- hostPath:
path: /etc/kubernetes/scheduler-custom.conf
type: FileOrCreate
name: scheduler-config
- hostPath:
path: /etc/kubernetes/scheduler-custom-policy-config.json
type: FileOrCreate
name: policy-configKısaca ana değişiklikler hakkında:
- Pod ve konteyner adı kube-scheduler-cron olarak değiştirildi
- Seçenek tanımlandığında 10151 ve 10159 bağlantı noktalarını kullanmak için belirtildi
hostNetwork: trueve varsayılan kube-scheduler (10251 ve 10259) ile aynı bağlantı noktalarını kullanamayız. - --config parametresini kullanarak hizmetin başlaması gereken yapılandırma dosyasını belirtin
- Yapılandırma dosyasını (scheduler-custom.conf) ve zamanlama ilkesi dosyasını (scheduler-custom-policy-config.json) ana bilgisayardan bağlamak için yapılandırılmıştır
Kube-scheduler'ımızın varsayılana benzer haklara ihtiyacı olacağını unutmayın. Küme rolünü düzenleyin:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Şimdi yapılandırma dosyasında ve çizelgeleme ilkesi dosyasında bulunması gerekenlerden bahsedelim:
- Yapılandırma dosyası (scheduler-custom.conf)
Varsayılan kube-zamanlayıcının yapılandırmasını almak için parametreyi kullanmanız gerekir.--write-config-toarasında . Ortaya çıkan konfigürasyonu /etc/kubernetes/scheduler-custom.conf dosyasına yerleştirip aşağıdaki forma getireceğiz:
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
schedulerName: kube-scheduler-cron
bindTimeoutSeconds: 600
clientConnection:
acceptContentTypes: ""
burst: 100
contentType: application/vnd.kubernetes.protobuf
kubeconfig: /etc/kubernetes/scheduler.conf
qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
failureDomains: kubernetes.io/hostname,failure-domain.beta.kubernetes.io/zone,failure-domain.beta.kubernetes.io/region
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10151
leaderElection:
leaderElect: true
leaseDuration: 15s
lockObjectName: kube-scheduler-cron
lockObjectNamespace: kube-system
renewDeadline: 10s
resourceLock: endpoints
retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10151
percentageOfNodesToScore: 0
algorithmSource:
policy:
file:
path: "/etc/kubernetes/scheduler-custom-policy-config.json"Kısaca ana değişiklikler hakkında:
- SchedulerName hizmetimizin adını kube-scheduler-cron olarak ayarlayın.
- Parametrede
lockObjectNameayrıca hizmetimizin adını belirlemeli ve parametrenin doğru olduğundan emin olmalıyız.leaderElecttrue olarak ayarlayın (bir ana düğümünüz varsa, değeri false olarak ayarlayabilirsiniz). - Parametrede zamanlama politikalarının açıklamasıyla birlikte dosyanın yolu belirtildi
algorithmSource.
Anahtarın parametrelerini düzenlediğimiz ikinci paragrafta daha ayrıntılı olarak durmaya değer. leaderElection. Hata toleransı için etkinleştirdik (leaderElect) kube-scheduler'ımızın bölmeleri arasında onlar için tek bir uç nokta kullanarak bir lider (ana) seçme süreci (resourceLock) adlı kube-scheduler-cron (lockObjectName) kube sistemi ad alanında (lockObjectNamespace). Kubernetes'in ana bileşenlerin (kube-scheduler dahil) yüksek kullanılabilirliğini nasıl sağladığı şurada bulunabilir: .
- Zamanlama ilkesi dosyası (scheduler-custom-policy-config.json)
Daha önce yazdığım gibi, varsayılan kube-scheduler'ın hangi özel politikalarla çalıştığını ancak kodunu analiz ederek bulabiliriz. Yani, yapılandırma dosyasına benzeterek, varsayılan kube-scheduler'ın zamanlama ilkelerine sahip dosyayı alamıyoruz. /etc/kubernetes/scheduler-custom-policy-config.json dosyasında bizi ilgilendiren çizelgeleme politikalarını şu şekilde açıklayalım:
{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
{
"name": "GeneralPredicates"
}
],
"priorities": [
{
"name": "ServiceSpreadingPriority",
"weight": 1
},
{
"name": "EqualPriority",
"weight": 1
},
{
"name": "LeastRequestedPriority",
"weight": 1
},
{
"name": "NodePreferAvoidPodsPriority",
"weight": 10000
},
{
"name": "NodeAffinityPriority",
"weight": 1
}
],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}Bu nedenle kube-scheduler, önce GeneralPredicates ilkesine (PodFitsResources, PodFitsHostPorts, Ana BilgisayarAdı ve MatchNodeSelector ilke kümesini içerir) göre bir Bölmenin programlanabileceği düğümleri listeler. Ardından her düğüm, öncelikler dizisindeki politika grubuna göre değerlendirilir. Görevimizin koşullarını yerine getirmek için böyle bir politikalar dizisinin en iyi çözüm olacağını düşündük. Ayrıntılı açıklamalarıyla birlikte bir dizi politikanın şu adreste mevcut olduğunu hatırlatmama izin verin: . Görevinizi gerçekleştirmek için, kullanılan politika setini kolayca değiştirebilir ve bunlara uygun ağırlıkları atayabilirsiniz.
Bölümün başında oluşturduğumuz yeni kube-scheduler bildirimi, kube-scheduler-custom.yaml olarak adlandırılacak ve üç ana düğümde /etc/kubernetes/manifests konumuna yerleştirilecek. Her şey doğru yapılırsa, Kubelet her düğümde bölmeyi başlatacak ve yeni kube-zamanlayıcımızın günlüklerinde ilke dosyamızın başarıyla uygulandığına dair bilgiler göreceğiz:
Creating scheduler from configuration: {{ } [{GeneralPredicates <nil>}] [{ServiceSpreadingPriority 1 <nil>} {EqualPriority 1 <nil>} {LeastRequestedPriority 1 <nil>} {NodePreferAvoidPodsPriority 10000 <nil>} {NodeAffinityPriority 1 <nil>}] [] 10 false}
Registering predicate: GeneralPredicates
Predicate type GeneralPredicates already registered, reusing.
Registering priority: ServiceSpreadingPriority
Priority type ServiceSpreadingPriority already registered, reusing.
Registering priority: EqualPriority
Priority type EqualPriority already registered, reusing.
Registering priority: LeastRequestedPriority
Priority type LeastRequestedPriority already registered, reusing.
Registering priority: NodePreferAvoidPodsPriority
Priority type NodePreferAvoidPodsPriority already registered, reusing.
Registering priority: NodeAffinityPriority
Priority type NodeAffinityPriority already registered, reusing.
Creating scheduler with fit predicates 'map[GeneralPredicates:{}]' and priority functions 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'Şimdi geriye kalan tek şey, CronJob'umuzun özelliklerinde, bölmelerini programlamaya yönelik tüm isteklerin yeni kube-zamanlayıcımız tarafından işlenmesi gerektiğini belirtmektir:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Sonuç
Sonunda, doğrudan kubelet tarafından izlenen, benzersiz bir dizi zamanlama politikasına sahip ek bir kube-zamanlayıcımız oldu. Ek olarak, eski liderin herhangi bir nedenle kullanılamaması durumunda kube-scheduler'ımızın bölmeleri arasında yeni bir liderin seçimini ayarladık.
Normal uygulamalar ve hizmetler, varsayılan kube-scheduler aracılığıyla programlanmaya devam eder ve tüm cron görevleri tamamen yenisine aktarılır. Cron görevleri tarafından oluşturulan yük artık tüm düğümlere eşit olarak dağıtılır. Cron görevlerinin çoğunun, projenin ana uygulamalarıyla aynı düğümlerde yürütüldüğü düşünülürse, bu durum, kaynak eksikliği nedeniyle bölmelerin hareket etme riskini önemli ölçüde azalttı. Ek kube-zamanlayıcının kullanıma sunulmasından sonra, cron işlerinin düzensiz zamanlanmasıyla ilgili sorunlar kalmadı.
Ayrıca blogumuzdaki diğer makaleleri de okuyun:
Kaynak: habr.com