Kube-planeerija on Kubernetese lahutamatu komponent, mis vastutab sõlmede ajastamise eest vastavalt määratud poliitikatele. Tihti ei pea me Kubernetese klastri töötamise ajal mõtlema, milliseid poliitikaid podide ajastamiseks kasutatakse, kuna vaikekube-ajasti poliitikate komplekt sobib enamiku igapäevaste toimingute jaoks. Siiski on olukordi, kus meie jaoks on oluline kaunade eraldamise protsessi peenhäälestada, ja selle ülesande täitmiseks on kaks võimalust:
- Looge kohandatud reeglistikuga kube-planeerija
- Kirjutage oma ajakava ja õpetage seda API-serveri päringutega töötama
Selles artiklis kirjeldan esimese punkti rakendamist, et lahendada ühes meie projektis küttekollete ebaühtlase ajastamise probleem.
Lühitutvustus kube-scheduleri toimimise kohta
Eriti väärib märkimist tõsiasi, et kube-scheduler ei vastuta kaustade otsese ajastamise eest – ta vastutab ainult selle sõlme määramise eest, millele podi paigutada. Teisisõnu, kube-planeerija töö tulemuseks on sõlme nimi, mille ta tagastab API serverile ajastamispäringu jaoks ja sellega tema töö lõpeb.
Esiteks koostab kube-planeerija loendi sõlmedest, millele saab vastavalt predikaatide poliitikale ajastada podi. Järgmisena saab iga selle loendi sõlm vastavalt prioriteetide poliitikale teatud arvu punkte. Selle tulemusena valitakse maksimaalse punktide arvuga sõlm. Kui on sõlme, millel on sama maksimaalne punktisumma, valitakse juhuslik. Predikaatide (filtreerimine) ja prioriteetide (skoorimine) poliitikate loendi ja kirjelduse leiate .
Probleemse keha kirjeldus
Hoolimata suurest arvust erinevate Kubernetese klastrite arvust, mida Nixys hooldab, puutusime esimest korda kokku poodide ajastamise probleemiga alles hiljuti, kui ühel meie projektil oli vaja käitada suurt hulka perioodilisi ülesandeid (~100 CronJobi olemit). Et probleemi kirjeldust võimalikult palju lihtsustada, võtame näiteks ühe mikroteenuse, mille raames käivitatakse kord minutis cron-ülesanne, mis tekitab CPU-le teatud koormuse. Cron-ülesande käivitamiseks eraldati kolm absoluutselt identsete omadustega sõlme (igaühel 24 vCPU-d).
Samal ajal on võimatu täpselt öelda, kui kaua CronJobi käivitamine aega võtab, kuna sisendandmete maht muutub pidevalt. Keskmiselt töötab kube-scheduleri normaalse töö ajal iga sõlm 3-4 tööeksemplari, mis tekitavad ~20-30% iga sõlme CPU koormusest:
Probleem ise seisneb selles, et mõnikord lakkasid cron ülesandepodide ajastamine ühes kolmest sõlmest. See tähendab, et mingil ajahetkel ei olnud ühe sõlme jaoks ette nähtud ainsatki taskut, samas kui kahes teises sõlmes töötas 6-8 ülesande koopiat, mis tekitas ~40-60% protsessori koormusest:
Probleem kordus täiesti juhuslikult ja aeg-ajalt korreleerus hetkega, kui koodi uus versioon välja tuli.
Suurendades kube-planeerija logimise taset tasemele 10 (-v=10), hakkasime registreerima, kui palju punkte iga sõlm hindamisprotsessi käigus kogus. Tavalise planeerimise ajal võis logides näha järgmist teavet:
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 100043Need. logidest saadud teabe põhjal otsustades said kõik sõlmed võrdse arvu lõpppunkte ja planeerimiseks valiti juhuslik. Probleemse planeerimise ajal nägid logid välja sellised:
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 100038Millest on näha, et üks sõlmedest kogus teistest vähem lõpppunkte ja seetõttu planeeriti ainult kahe maksimumpunkti saanud sõlme kohta. Seega olime kindlasti veendunud, et probleem seisneb just kaunade ajastamises.
Edasine probleemi lahendamise algoritm oli meile ilmne - analüüsige logisid, mõistke, millise prioriteediga sõlm punkte ei saanud, ja vajadusel kohandage vaikimisi kube-planeerija poliitikaid. Siin seisame aga silmitsi kahe olulise raskusega:
- Maksimaalsel raietasemel (10) kajastatakse ainult mõne prioriteedi eest kogutud punkte. Ülaltoodud logide väljavõttest on näha, et kõigi logides kajastuvate prioriteetide puhul saavad sõlmed tava- ja probleemiplaanis sama arvu punkte, kuid probleemi planeerimise puhul on lõpptulemus erinev. Seega võime järeldada, et mõne prioriteedi puhul toimub punktiarvestus "kulisside taga" ja me ei saa kuidagi aru, millise prioriteedi eest sõlm punkte ei saanud. Kirjeldasime seda probleemi üksikasjalikult artiklis Kubernetese hoidla Githubis. Artikli kirjutamise ajal saadi arendajatelt vastus, et Kubernetes v1.15,1.16, 1.17 ja XNUMX uuendustesse lisatakse logimise tugi.
- Pole lihtne aru saada, millise konkreetse poliitikakomplektiga kube-scheduler praegu töötab. Jah, sisse see loend on loetletud, kuid see ei sisalda teavet selle kohta, millised konkreetsed kaalud on igale prioriteedipoliitikale määratud. Vaikimisi kube-planeerija kaalusid või reegleid saate muuta ainult rakenduses .
Väärib märkimist, et ükskord saime fikseerida, et sõlm ei saanud punkte vastavalt ImageLocalityPriority poliitikale, mis annab punktid sõlmele, kui sellel on juba rakenduse käitamiseks vajalik pilt. See tähendab, et rakenduse uue versiooni avaldamise ajal suutis cron-ülesanne töötada kahel sõlmel, laadides neile dockeri registrist uue pildi ja seega said kaks sõlme kolmandaga võrreldes kõrgema lõppskoori. .
Nagu ma eespool kirjutasin, ei näe me logides teavet ImageLocalityPriority poliitika hindamise kohta, seega oma eelduse kontrollimiseks laadisime rakenduse uue versiooniga pildi kolmandasse sõlme, misjärel ajastamine töötas õigesti. . Just ImageLocalityPriority poliitika tõttu täheldati ajakava probleemi üsna harva, sagedamini seostati seda millegi muuga. Kuna me ei saanud vaikimisi kube-plaanija prioriteetide loendis olevat iga poliitikat täielikult siluda, tekkis meil vajadus poodide ajastamise poliitikate paindliku haldamise järele.
Probleemi avaldus
Tahtsime, et probleemi lahendus oleks võimalikult konkreetne, see tähendab, et Kubernetese põhiolemid (siinkohal peame silmas vaikimisi kube-plaanijat) jääksid muutumatuks. Me ei tahtnud probleemi ühes kohas lahendada ja teises kohas luua. Nii jõudsime probleemi lahendamiseks kahe võimaluseni, millest teatati artikli sissejuhatuses - täiendava ajakava loomine või enda kirjutamine. Cron-ülesannete ajastamise põhinõue on koormuse ühtlane jaotamine kolme sõlme vahel. Selle nõude saab rahuldada olemasolevate kube-ajasti poliitikatega, nii et meie probleemi lahendamiseks pole mõtet kirjutada oma planeerijat.
Täiendava kube-planeerija loomise ja juurutamise juhiseid kirjeldatakse artiklis . Meile aga tundus, et juurutusolemist ei piisa sellise kriitilise teenuse nagu kube-planeerija töös tõrketaluvuse tagamiseks, mistõttu otsustasime juurutada staatilise podina uue kube-planeerija, mida hakatakse otse jälgima. Kubeleti poolt. Seega on meil uue kube-plaanija jaoks järgmised nõuded:
- Teenus tuleb juurutada staatilise podina kõigis klastri ülemseadmetes
- Kui kube-ajastajaga aktiivne pod pole saadaval, tuleb tagada tõrketaluvus
- Planeerimisel peaks peamine prioriteet olema sõlmes saadaolevate ressursside arv (LeastRequestedPriority)
Rakenduslahendused
Tasub kohe märkida, et kõik tööd teeme Kubernetes v1.14.7-s, sest See on versioon, mida projektis kasutati. Alustuseks kirjutame oma uuele kube-planeerijale manifesti. Võtame aluseks vaikemanifesti (/etc/kubernetes/manifests/kube-scheduler.yaml) ja viime selle järgmisele kujule:
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-configLühidalt peamistest muudatustest:
- Podi ja konteineri nimeks muudeti kube-scheduler-cron
- Määratud suvandina pordide 10151 ja 10159 kasutamine
hostNetwork: trueja me ei saa kasutada samu porte kui vaikimisi kube-planeerija (10251 ja 10259) - Parameetri --config abil määrasime konfiguratsioonifaili, millega teenust käivitada
- Konfigureeritud konfiguratsioonifaili (scheduler-custom.conf) ja ajastamispoliitika faili (scheduler-custom-policy-config.json) ühendamine hostist
Ärge unustage, et meie kube-planeerija vajab vaikeõigusega sarnaseid õigusi. Muutke selle klastri rolli:
kubectl edit clusterrole system:kube-scheduler...
resourceNames:
- kube-scheduler
- kube-scheduler-cron
...Räägime nüüd sellest, mis peaks sisalduma konfiguratsioonifailis ja ajastamispoliitika failis:
- Konfiguratsioonifail (scheduler-custom.conf)
Kube-planeerija vaikekonfiguratsiooni saamiseks peate kasutama parameetrit--write-config-tokohta . Asetame saadud konfiguratsiooni faili /etc/kubernetes/scheduler-custom.conf ja redigeerime selle järgmisele kujule:
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"Lühidalt peamistest muudatustest:
- Määrasime ajakava nimetuse meie teenuse kube-scheduler-cron nimeks.
- Parameetris
lockObjectNameSamuti peate määrama meie teenuse nime ja veenduma, et parameeterleaderElectseatud väärtusele Tõene (kui teil on üks põhisõlm, saate selle väärtuseks False määrata). - Määras faili tee koos ajastamispoliitika kirjeldusega parameetris
algorithmSource.
Tasub lähemalt uurida teist punkti, kus muudame võtme parameetreid leaderElection. Veataluvuse tagamiseks oleme lubanud (leaderElect) meie kube-planeerija kaustade vahel liidri (ülema) valimise protsess, kasutades nende jaoks ühte lõpp-punkti (resourceLock) nimega kube-scheduler-cron (lockObjectName) kube-süsteemi nimeruumis (lockObjectNamespace). Kuidas Kubernetes tagab põhikomponentide (sh kube-scheduleri) kõrge kättesaadavuse, leiad siit .
- Ajastamispoliitika fail (scheduler-custom-policy-config.json)
Nagu ma varem kirjutasin, saame teada, milliste konkreetsete poliitikatega kube-planeerija töötab, ainult selle koodi analüüsides. See tähendab, et me ei saa vaikimisi kube-planeerija jaoks ajastamispoliitikaga faili hankida samamoodi nagu konfiguratsioonifaili. Kirjeldame meid huvitavaid ajastamispoliitikaid failis /etc/kubernetes/scheduler-custom-policy-config.json järgmiselt.
{
"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
}Seega koostab kube-planeerija esmalt loendi sõlmedest, kuhu saab vastavalt GeneralPredicatesi poliitikale (mis sisaldab PodFitsResourcesi, PodFitsHostPortsi, HostName'i ja MatchNodeSelectori poliitikat) loendi. Seejärel hinnatakse iga sõlme vastavalt prioriteetide massiivi poliitikatele. Meie ülesande tingimuste täitmiseks leidsime, et selline poliitika oleks optimaalne lahendus. Lubage mul teile meelde tuletada, et eeskirjade komplekt koos nende üksikasjalike kirjeldustega on saadaval . Oma ülesande täitmiseks saate lihtsalt muuta kasutatavate poliitikate komplekti ja määrata neile asjakohased kaalud.
Nimetame uue kube-scheduleri manifesti, mille lõime peatüki alguses, kube-scheduler-custom.yaml ja asetame selle kolmele põhisõlmele järgmisele teele /etc/kubernetes/manifests. Kui kõik on õigesti tehtud, käivitab Kubelet igas sõlmes podi ja meie uue kube-planeerija logides näeme teavet selle kohta, et meie poliitikafaili rakendati edukalt:
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:{}]'Nüüd jääb üle vaid märkida meie CronJobi spetsifikatsioonis, et kõik selle kaustade ajastamise taotlused peaks töötlema meie uus kube-planeerija:
...
jobTemplate:
spec:
template:
spec:
schedulerName: kube-scheduler-cron
...Järeldus
Lõppkokkuvõttes saime ainulaadse ajastamispoliitikaga täiendava kube-planeerija, mille tööd jälgib otse kubelet. Lisaks oleme oma kube-schedleri kaunade vahel paika pannud uue juhi valimised juhuks, kui vana juht mingil põhjusel kättesaamatuks jääb.
Tavalised rakendused ja teenused ajastatakse jätkuvalt vaikimisi kube-planeerija kaudu ning kõik cron-i ülesanded on täielikult uude üle viidud. Cron-ülesannete tekitatud koormus jaotatakse nüüd ühtlaselt kõigi sõlmede vahel. Arvestades, et enamik cron-i ülesandeid täidetakse samades sõlmedes kui projekti põhirakendused, on see oluliselt vähendanud ressursside puudumise tõttu kaustade teisaldamise ohtu. Pärast täiendava kube-planeerija kasutuselevõttu ei tekkinud enam probleeme cron-ülesannete ebaühtlase ajakavaga.
Loe ka teisi meie ajaveebi artikleid:
Allikas: www.habr.com