Zpravidla je vždy potřeba poskytnout aplikaci vyhrazený fond zdrojů pro její správný a stabilní provoz. Ale co když několik aplikací běží na stejný výkon? Jak zajistit každému z nich minimum potřebných zdrojů? Jak můžete omezit spotřebu zdrojů? Jak správně rozložit zátěž mezi uzly? Jak zajistit, aby mechanismus horizontálního škálování fungoval, pokud se zatížení aplikace zvýší?
Musíte začít s tím, jaké hlavní typy zdrojů existují v systému - to je samozřejmě čas procesoru a RAM. V manifestech k8s jsou tyto typy zdrojů měřeny v následujících jednotkách:
- CPU - v jádrech
- RAM - v bytech
Navíc pro každý zdroj je možné nastavit dva typy požadavků - žádosti и limity. Požadavky – popisuje minimální požadavky na volné prostředky uzlu pro spuštění kontejneru (a podu jako celku), zatímco limity nastavují pevný limit na zdroje, které má kontejner k dispozici.
Je důležité pochopit, že manifest nemusí explicitně definovat oba typy, ale chování bude následující:
- Pokud jsou explicitně specifikovány pouze limity zdroje, pak požadavky na tento zdroj automaticky nabývají hodnoty rovné limitům (můžete to ověřit voláním entit description). Tito. ve skutečnosti bude kontejner omezen na stejné množství zdrojů, které vyžaduje ke spuštění.
- Pokud jsou pro zdroj explicitně specifikovány pouze požadavky, pak pro tento zdroj nejsou nastavena žádná horní omezení – tzn. kontejner je omezen pouze prostředky samotného uzlu.
Je také možné nakonfigurovat správu zdrojů nejen na úrovni konkrétního kontejneru, ale také na úrovni jmenného prostoru pomocí následujících entit:
- LimitRange — popisuje politiku omezení na úrovni kontejneru/podu v ns a je potřeba k popisu výchozích limitů pro kontejner/pod a také k zabránění vytváření zjevně tučných kontejnerů/pod (nebo naopak), omezení jejich počtu a určit možný rozdíl hodnot v limitech a požadavcích
- Kvóty zdrojů — popište politiku omezení obecně pro všechny kontejnery v ns a používá se zpravidla k vymezení zdrojů mezi prostředími (užitečné, když prostředí nejsou přesně vymezena na úrovni uzlů)
Níže jsou uvedeny příklady manifestů, které nastavují limity prostředků:
-
Na úrovni konkrétního kontejneru:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mTito. v tomto případě pro spuštění kontejneru s nginx budete potřebovat alespoň 1G volné paměti RAM a 0.2 CPU na uzlu, zatímco maximálně kontejner může spotřebovat 0.2 CPU a veškerou dostupnou RAM na uzlu.
-
Na celočíselné úrovni ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiTito. součet všech kontejnerů požadavků ve výchozím ns nemůže překročit 300 m pro CPU a 1G pro OP a součet všech limitů je 700 m pro CPU a 2G pro OP.
-
Výchozí limity pro kontejnery v ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4GiTito. ve výchozím jmenném prostoru pro všechny kontejnery bude požadavek nastaven na 100 m pro CPU a 1G pro OP, limit - 1 CPU a 2G. Zároveň je také nastaven limit na možné hodnoty v požadavku/limitu pro CPU (50m < x < 2) a RAM (500M < x < 4G).
-
Omezení na úrovni pod:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiTito. pro každý modul ve výchozím ns bude limit 4 vCPU a 1G.
Nyní bych vám rád řekl, jaké výhody nám nastavení těchto omezení může poskytnout.
Mechanismus vyvažování zátěže mezi uzly
Jak víte, komponenta k8s je zodpovědná za distribuci podů mezi uzly, jako např plánovač, který pracuje podle specifického algoritmu. Tento algoritmus prochází dvěma fázemi při výběru optimálního uzlu ke spuštění:
- filtrování
- V rozsahu
Tito. podle popsané zásady jsou zpočátku vybrány uzly, na kterých je možné spustit pod na základě sady predikáty (včetně kontroly, zda má uzel dostatek prostředků ke spuštění podu - PodFitsResources), a poté pro každý z těchto uzlů podle priority jsou uděleny body (včetně toho, že čím více volných zdrojů má uzel, tím více bodů je mu přiděleno - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) a pod je spuštěn na uzlu s největším počtem bodů (pokud tuto podmínku splní několik uzlů najednou, pak je vybrán náhodný).
Zároveň musíte pochopit, že plánovač se při posuzování dostupných zdrojů uzlu řídí daty, která jsou uložena v etcd - tzn. pro množství požadovaného/limitního zdroje každého podu spuštěného na tomto uzlu, ale ne pro skutečnou spotřebu zdrojů. Tyto informace lze získat z výstupu příkazu kubectl describe node $NODE, Například:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)Zde vidíme všechny moduly běžící na konkrétním uzlu a také zdroje, které každý modul požaduje. A takto vypadají protokoly plánovače, když je spuštěn cronjob-cron-events-1573793820-xt6q9 pod (tato informace se objeví v protokolu plánovače, když nastavíte 10. úroveň protokolování v argumentech spouštěcího příkazu -v=10):
široká racek
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10Zde vidíme, že plánovač zpočátku filtruje a generuje seznam 3 uzlů, na kterých může být spuštěn (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Poté vypočítá skóre na základě několika parametrů (včetně BalancedResourceAllocation, LeastResourceAllocation) pro každý z těchto uzlů, aby určil nejvhodnější uzel. Nakonec je pod naplánován na uzel s nejvyšším počtem bodů (zde mají dva uzly najednou stejný počet bodů 100037, takže je vybrán náhodný - nxs-k8s-s10).
Výkon: pokud uzel provozuje pody, pro které nejsou nastavena žádná omezení, pak pro k8s (z hlediska spotřeby zdrojů) to bude ekvivalentní tomu, jako by na tomto uzlu žádné takové pody nebyly. Pokud tedy máte podmínečně pod s obžerským procesem (například wowza) a nejsou pro něj nastavena žádná omezení, pak může nastat situace, kdy tento pod skutečně snědl všechny zdroje uzlu, ale pro k8s tento uzel je považován za nezatížený a bude oceněn stejným počtem bodů při hodnocení (přesně v bodech hodnotících dostupné zdroje) jako uzel, který nemá pracovní moduly, což v konečném důsledku může vést k nerovnoměrnému rozložení zátěže mezi uzly.
Podovo vystěhování
Jak víte, každému modulu je přiřazena jedna ze 3 tříd QoS:
- zaručeno — je přiřazen, když je pro každý kontejner v podu určen požadavek a limit pro paměť a procesor a tyto hodnoty se musí shodovat
- prasklavý — alespoň jeden kontejner v pod má požadavek a limit, přičemž požadavek < limit
- nejlepší úsilí — když ani jeden kontejner v pod nemá omezený zdroj
Současně, když uzel zaznamená nedostatek zdrojů (disk, paměť), kubelet začne řadit a vyřazovat moduly podle specifického algoritmu, který bere v úvahu prioritu modulu a jeho třídu QoS. Například, pokud mluvíme o RAM, pak na základě třídy QoS jsou body udělovány podle následujícího principu:
- Garantovaná: -998
- BestEffort: 1000
- Prasknutí: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Tito. se stejnou prioritou kubelet nejprve vypudí moduly s nejlepším úsilím třídy QoS z uzlu.
Výkon: pokud chcete snížit pravděpodobnost vystěhování požadovaného podu z uzlu v případě nedostatku zdrojů na něm, pak se spolu s prioritou musíte postarat také o nastavení požadavku/limitu pro něj.
Mechanismus pro horizontální automatické škálování aplikačních modulů (HPA)
Když je úkolem automaticky zvyšovat a snižovat počet podů v závislosti na využití zdrojů (systém - CPU/RAM nebo uživatel - rps), taková k8s entita jako HPA (Horizontal Pod Autoscaler). Jeho algoritmus je následující:
- Jsou určeny aktuální hodnoty sledovaného zdroje (currentMetricValue)
- Jsou určeny požadované hodnoty pro zdroj (desiredMetricValue), které se pro systémové prostředky nastavují pomocí požadavku
- Je určen aktuální počet replik (currentReplicas)
- Následující vzorec vypočítá požadovaný počet replik (desiredReplicas)
požadovanéRepliky = [ currentReplicas * ( currentMetricValue / requiredMetricValue )]
V tomto případě ke změně měřítka nedojde, když se koeficient (currentMetricValue / requiredMetricValue) blíží 1 (v tomto případě si můžeme sami nastavit povolenou chybu, standardně je 0.1).
Podívejme se, jak hpa funguje na příkladu aplikace app-test (popsané jako Deployment), kde je potřeba změnit počet replik v závislosti na spotřebě CPU:
-
Manifest aplikace
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusTito. vidíme, že aplikační modul je zpočátku spuštěn ve dvou instancích, z nichž každá obsahuje dva kontejnery nginx a nginx-exporter, pro každý z nich specifikovaný žádosti pro CPU.
-
Manifest HPA
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30Tito. Vytvořili jsme hpa, která bude monitorovat test aplikace Deployment a upravovat počet modulů s aplikací na základě indikátoru CPU (očekáváme, že modul by měl spotřebovat 30 % procesoru, který požaduje), přičemž počet replik je v rozmezí 2-10.
Nyní se podívejme na mechanismus provozu hpa, pokud aplikujeme zátěž na jedno z topenišť:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Celkem máme následující:
- Požadovaná hodnota (desiredMetricValue) - podle nastavení hpa máme 30%
- Aktuální hodnota (currentMetricValue) - pro výpočet controller-manager vypočítá průměrnou hodnotu spotřeby zdrojů v %, tzn. podmíněně dělá následující:
- Přijímá absolutní hodnoty metrik podů ze serveru metrik, tzn. 101m a 4m
- Vypočítá průměrnou absolutní hodnotu, tzn. (101 m + 4 m) / 2 = 53 m
- Získá absolutní hodnotu pro požadovanou spotřebu zdrojů (k tomu se sečtou požadavky všech kontejnerů) 60m + 30m = 90m
- Vypočítá průměrné procento spotřeby CPU vzhledem k požadavku pod, tj. 53 m / 90 m * 100 % = 59 %
Nyní máme vše, co potřebujeme, abychom určili, zda potřebujeme změnit počet replik; za tímto účelem vypočítáme koeficient:
ratio = 59% / 30% = 1.96
Tito. počet replik by se měl zvýšit ~2krát a činit [2 * 1.96] = 4.
Závěr: Jak vidíte, pro fungování tohoto mechanismu je nezbytnou podmínkou přítomnost požadavků na všechny kontejnery ve sledovaném podu.
Mechanismus pro horizontální automatické škálování uzlů (Cluster Autoscaler)
Aby se neutralizoval negativní dopad na systém během rázů zátěže, nestačí mít nakonfigurovaný hpa. Například podle nastavení ve správci řadiče hpa rozhodne, že počet replik je třeba zvýšit 2krát, ale uzly nemají volné zdroje pro spuštění takového počtu podů (tj. uzel nemůže poskytnout požadované zdroje do podu požadavků) a tyto pody se přepnou do stavu Nevyřízeno.
V tomto případě, pokud má poskytovatel odpovídající IaaS/PaaS (například GKE/GCE, AKS, EKS atd.), nástroj jako Autoscaler uzlu. Umožňuje vám nastavit maximální a minimální počet uzlů v clusteru a automaticky upravit aktuální počet uzlů (voláním API poskytovatele cloudu za účelem objednání/odstranění uzlu), když je nedostatek zdrojů v clusteru a podech. nelze naplánovat (jsou ve stavu Nevyřízeno).
Závěr: Aby bylo možné automaticky škálovat uzly, je nutné nastavit požadavky v kontejnerech podů, aby k8 mohly správně vyhodnotit zatížení uzlů a podle toho hlásit, že v clusteru nejsou žádné zdroje pro spuštění dalšího podu.
Závěr
Je třeba poznamenat, že nastavení limitů prostředků kontejneru není podmínkou pro úspěšné spuštění aplikace, ale přesto je lepší tak učinit z následujících důvodů:
- Pro přesnější provoz plánovače z hlediska vyvažování zátěže mezi k8s uzly
- Aby se snížila pravděpodobnost výskytu události „vyklizení pod“.
- Pro horizontální automatické škálování aplikačních modulů (HPA) pro práci
- Pro horizontální automatické škálování uzlů (Cluster Autoscaling) pro poskytovatele cloudu
Přečtěte si také další články na našem blogu:
Zdroj: www.habr.com