27 april by de konferinsje , as ûnderdiel fan 'e "DevOps" seksje, waard it rapport "Autoscaling and resource management in Kubernetes" jûn. It praat oer hoe't jo K8's kinne brûke om hege beskikberens fan jo applikaasjes te garandearjen en peakprestaasjes te garandearjen.
Troch tradysje binne wy bliid om te presintearjen (44 minuten, folle mear ynformatyf as it artikel) en de haad gearfetting yn tekstfoarm. Go!
Litte wy it ûnderwerp fan it rapport wurd foar wurd analysearje en fanôf it ein begjinne.
Kubernetes
Litte wy sizze dat wy Docker-konteners op ús host hawwe. Foar wat? Om te garandearjen repeatability en isolemint, dy't op syn beurt soarget foar ienfâldige en goede ynset, CI / CD. Wy hawwe in protte sokke auto's mei konteners.
Wat biedt Kubernetes yn dit gefal?
- Wy stopje mei te tinken oer dizze masines en begjinne te wurkjen mei de "wolk" kluster fan konteners of pods (groepen fan konteners).
- Boppedat tinke wy net iens oer yndividuele podden, mar beheare mearоgruttere groepen. Sok primitiven op hege nivo lit ús sizze dat d'r in sjabloan is foar it útfieren fan in bepaalde wurkdruk, en hjir is it fereaske oantal eksimplaren om it út te fieren. As wy it sjabloan letter feroarje, sille alle eksimplaren feroarje.
- Mei help fan deklarative API Ynstee fan in folchoarder fan spesifike kommando's út te fieren, beskriuwe wy de "struktuer fan 'e wrâld" (yn YAML), dy't makke is troch Kubernetes. En nochris: as de beskriuwing feroaret, sil de eigentlike werjefte ek feroarje.
Resource behear
CPU
Lit ús nginx, php-fpm en mysql op 'e tsjinner útfiere. Dizze tsjinsten sille eins noch mear prosessen rinne, wêrfan elk komputerboarnen fereasket:
(de nûmers op 'e slide binne "papegaaien", de abstrakte needsaak fan elk proses foar kompjûterkrêft)
Om it makliker te meitsjen om hjirmei te wurkjen, is it logysk om prosessen yn groepen te kombinearjen (bygelyks alle nginx-prosessen yn ien groep "nginx"). In ienfâldige en foar de hân lizzende manier om dit te dwaan is om elke groep yn in kontener te setten:
Om troch te gean, moatte jo ûnthâlde wat in kontener is (yn Linux). Har uterlik waard mooglik makke troch trije wichtige funksjes yn 'e kernel, dy't in lange tiid lyn ymplementearre: , и . En fierdere ûntwikkeling waard fasilitearre troch oare technologyen (ynklusyf handige "shells" lykas Docker):
Yn it ramt fan it rapport binne wy allinnich ynteressearre yn cgroups, om't kontrôlegroepen it diel binne fan 'e funksjonaliteit fan konteners (Docker, ensfh.) dy't boarnebehear útfiert. Prosessen kombineare yn groepen, lykas wy woenen, binne kontrôlegroepen.
Litte wy weromgean nei de CPU-easken foar dizze prosessen, en no foar groepen prosessen:
(Ik werhelje dat alle sifers in abstrakte útdrukking binne fan 'e needsaak foar boarnen)
Tagelyk hat de CPU sels in bepaalde finite boarne (yn it foarbyld is dit 1000), dêr't elkenien miskien misse kin (de som fan 'e behoeften fan alle groepen is 150+850+460=1460). Wat sil barre yn dit gefal?
De kernel begjint boarnen te fersprieden en docht it "reedlik", it jaan fan deselde hoemannichte boarnen oan elke groep. Mar yn it earste gefal binne der mear as nedich (333>150), sadat it oerskot (333-150=183) yn reserve bliuwt, dat ek lyk ferdield is tusken twa oare konteners:
As gefolch: de earste kontener hie genôch boarnen, de twadde - it hie net genôch boarnen, de tredde - it hie net genôch boarnen. Dit is it resultaat fan aksjes "earlike" planner yn Linux - . De wurking dêrfan kin oanpast wurde mei de opdracht gewichten elk fan 'e konteners. Bygelyks, lykas dit:
Litte wy nei it gefal sjen fan in tekoart oan boarnen yn 'e twadde kontener (php-fpm). Alle kontenerboarnen wurde gelyk ferdield tusken prosessen. As resultaat wurket it masterproses goed, mar alle arbeiders fertrage, en krije minder dan de helte fan wat se nedich binne:
Dit is hoe't de CFS-planner wurket. Wy sille fierder de gewichten neame dy't wy oan konteners tawize fersiken. Wêrom dit sa is - sjoch fierder.
Litte wy de hiele situaasje fan 'e oare kant sjen. Sa't jo witte, liede alle diken nei Rome, en yn it gefal fan in kompjûter, nei de CPU. Ien CPU, in protte taken - jo hawwe in ferkearsljocht nedich. De ienfâldichste manier om boarnen te behearjen is "ferkearsljocht": se joegen ien proses in fêste tagongstiid foar de CPU, dan de folgjende, ensfh.
Dizze oanpak wurdt hurde kwotas neamd (hurde beheining). Lit ús it gewoan ûnthâlde as grinzen. As jo lykwols limiten oan alle konteners ferspriede, ûntstiet in probleem: mysql ried lâns de dyk en op in stuit is syn need foar CPU einige, mar alle oare prosessen wurde twongen om te wachtsjen oant de CPU idle.
Litte wy weromgean nei de Linux-kernel en har ynteraksje mei de CPU - it algemiene byld is as folget:
cgroup hat twa ynstellings - yn essinsje binne dit twa ienfâldige "twists" wêrmei jo kinne bepale:
- gewicht foar container (fersiken) is oandielen;
- persintaazje fan de totale CPU tiid foar wurkjen oan container taken (grinzen) is kwota.
Hoe te mjitten CPU?
D'r binne ferskate manieren:
- wat papieren, gjinien wit - jo moatte elke kear ûnderhannelje.
- Rinte dúdliker, mar relatyf: 50% fan in tsjinner mei 4 kearnen en mei 20 kearnen binne folslein oare dingen.
- Jo kinne de al neamde brûke gewichten, dy't Linux wit, mar se binne ek relatyf.
- De meast adekwate opsje is om komputerboarnen yn te mjitten sekonden. Dy. yn sekonden fan prosessor tiid relatyf oan sekonden fan echte tiid: 1 sekonde prosessor tiid waard jûn per 1 echte sekonde - dit is ien hiele CPU kearn.
Om it praten noch makliker te meitsjen, begûnen se direkt yn te mjitten kearnen, betsjut troch harren deselde CPU tiid relatyf oan de echte. Sûnt Linux begrypt gewichten, mar net sa folle CPU-tiid / kearnen, wie in meganisme nedich foar it oersetten fan de iene nei de oare.
Litte wy beskôgje in ienfâldich foarbyld mei in tsjinner mei 3 CPU kearnen, dêr't trije pods sille wurde jûn gewichten (500, 1000 en 1500) dy't maklik omboud ta de oerienkommende dielen fan 'e kearnen tawiisd oan harren (0,5, 1 en 1,5).
As jo nimme in twadde tsjinner, dêr't der sil wêze twa kear safolle kearnen (6), en pleatse deselde pods dêr, de ferdieling fan kearnen kin maklik berekkene troch gewoan fermannichfâldigje mei 2 (respektivelik 1, 2 en 3). Mar in wichtich momint bart as in fjirde pod ferskynt op dizze tsjinner, waans gewicht, foar it gemak, sil wêze 3000. It nimt fuort in part fan de CPU boarnen (de helte fan de kearnen), en foar de oerbleaune pods se wurde opnij berekkene (halved):
Kubernetes en CPU boarnen
Yn Kubernetes wurde CPU-boarnen normaal mjitten yn milliadrax, d.w.s. 0,001 kearnen wurde nommen as basisgewicht. (Itselde ding yn Linux / cgroups terminology wurdt in CPU-diel neamd, hoewol, krekter, 1000 millicores = 1024 CPU-oandielen.) K8s soarget derfoar dat it net pleatst mear pods op de tsjinner as der CPU middels foar de som fan de gewichten fan alle pods.
Hoe komt dit? As jo in tsjinner tafoegje oan in Kubernetes-kluster, wurdt rapportearre hoefolle CPU-kearnen it beskikber is. En by it meitsjen fan in nije pod, wit de Kubernetes-planner hoefolle kearnen dizze pod nedich is. Sa sil de pod wurde tawiisd oan in server wêr't genôch kearnen binne.
Wat sil barre as net fersyk is oantsjutte (d.w.s. de pod hat gjin definiearre oantal kearnen dy't it nedich is)? Litte wy útfine hoe't Kubernetes yn 't algemien boarnen telt.
Foar in pod kinne jo sawol oanfragen (CFS-planner) as grinzen opjaan (ûnthâld it ferkearsljocht?):
- As se gelyk oantsjutte, dan wurdt de pod in QoS-klasse tawiisd garantearre. Dit oantal kearnen altyd beskikber foar it is garandearre.
- As it fersyk is minder as de limyt - QoS klasse burstable. Dy. Wy ferwachtsje dat in pod bygelyks altyd 1 kearn brûkt, mar dizze wearde is der gjin beheining foar: soms pod kin mear brûke (as de tsjinner hjir fergees boarnen foar hat).
- D'r is ek in QoS-klasse bêste ynspanning - it omfettet dy pods wêrfoar fersyk net spesifisearre is. Middels wurde jûn oan harren lêste.
ûnthâld
Mei ûnthâld is de situaasje fergelykber, mar wat oars - ommers, de aard fan dizze boarnen is oars. Yn 't algemien is de analogy as folget:
Litte wy sjen hoe't oanfragen wurde ymplementearre yn it ûnthâld. Lit de pods libje op de tsjinner, feroarjen ûnthâld konsumpsje, oant ien fan harren wurdt sa grut dat it rint út ûnthâld. Yn dit gefal ferskynt de OOM-killer en deadet it grutste proses:
Dit past net altyd by ús, dus is it mooglik om te regeljen hokker prosessen foar ús wichtich binne en net fermoarde wurde moatte. Om dit te dwaan, brûk de parameter oom_score_adj.
Litte wy weromgean nei de QoS-klassen fan 'e CPU en in analogy tekenje mei de oom_score_adj-wearden dy't de prioriteiten foar ûnthâldferbrûk bepale foar pods:
- De leechste oom_score_adj wearde foar in pod - -998 - betsjut dat sa'n pod as lêste fermoarde wurde moat, dit garantearre.
- De heechste wearde fan 1000 bêste ynspanning, sokke podden wurde earst deamakke.
- Om de oerbleaune wearden te berekkenjen (burstable) der is in formule, wêrfan de essinsje delkomt op it feit dat hoe mear middels in pod frege hat, hoe minder kâns dat it fermoarde wurdt.
De twadde "twist" - limit_in_bytes - foar grinzen. Dêrmei is alles ienfâldiger: wy jouwe gewoan de maksimale hoemannichte útjûn ûnthâld ta, en hjir (oars as de CPU) is d'r gjin sprake fan hoe't jo it (ûnthâld) mjitte.
Totaal
Elke pod yn Kubernetes wurdt jûn requests и limits - beide parameters foar CPU en ûnthâld:
- basearre op oanfragen wurket de Kubernetes-planner, dy't pods ferspraat ûnder servers;
- basearre op alle parameters wurdt de QoS-klasse fan 'e pod bepaald;
- Relative gewichten wurde berekkene basearre op CPU fersiken;
- de CFS-planner is konfigureare op basis fan CPU-oanfragen;
- OOM killer is konfigurearre basearre op ûnthâld fersiken;
- in "ferkearsljocht" wurdt ynsteld basearre op CPU grinzen;
- Op grûn fan ûnthâld grinzen wurdt in limyt ynsteld foar de cgroup.
Yn 't algemien beantwurdet dizze foto alle fragen oer hoe't it haaddiel fan boarnebehear yn Kubernetes komt.
Autoscaling
K8s kluster-autoscaler
Lit ús foarstelle dat it hiele kluster al beset is en der moat in nije pod oanmakke wurde. Wylst de pod net ferskine kin, hinget it yn status Pending. Om it te ferskinen kinne wy in nije server ferbine mei it kluster of ... ynstallearje cluster-autoscaler, wat it foar ús docht: in firtuele masine bestelle fan 'e wolkprovider (mei in API-fersyk) en ferbine it mei it kluster , wêrnei't de pod tafoege wurdt.
Dit is autoscaling fan it Kubernetes-kluster, dat wurket geweldich (yn ús ûnderfining). Lykwols, lykas op oare plakken, binne d'r hjir wat nuânses ...
Sa lang as wy ferhege it kluster grutte, alles wie goed, mar wat bart der as it kluster begûn himsels te befrijen? It probleem is dat migrearjen fan pods (om hosts frij te meitsjen) is heul technysk lestich en djoer yn termen fan boarnen. Kubernetes brûkt in folslein oare oanpak.
Beskôgje in kluster fan 3 tsjinners dy't Deployment hat. It hat 6 pods: no binne d'r 2 foar elke tsjinner. Om ien of oare reden woene wy ien fan 'e servers útsette. Om dit te dwaan sille wy it kommando brûke kubectl drain, hokker:
- sil it ferstjoeren fan nije pods nei dizze tsjinner ferbiede;
- sil besteande pods op 'e tsjinner wiskje.
Sûnt Kubernetes is ferantwurdlik foar it behâld fan it oantal pods (6), it gewoan sil opnij oanmeitsje se op oare knopen, mar net op dyjinge dy't útskeakele is, om't it al is markearre as net beskikber foar hosting fan nije pods. Dit is in fûnemintele monteur foar Kubernetes.
Lykwols, hjir is ek in nuânse. Yn in ferlykbere situaasje, foar StatefulSet (ynstee fan Deployment), sille de aksjes oars wêze. No hawwe wy al in steatlike applikaasje - bygelyks trije pods mei MongoDB, wêrfan ien in soarte fan probleem hat (de gegevens binne skansearre wurden of in oare flater dy't foarkomt dat de pod goed begjint). En wy beslute opnij ien tsjinner út te skeakeljen. Wat barre sil?
MongoDB koe stjerre omdat it in quorum nedich is: foar in kluster fan trije ynstallaasjes moatte op syn minst twa funksjonearje. Lykwols, dit net bart - tank oan PodDisruptionBudget. Dizze parameter bepaalt it minimale fereaske oantal wurkjende pods. Wittende dat ien fan 'e MongoDB-pods net mear wurket, en sjen dat PodDisruptionBudget is ynsteld foar MongoDB minAvailable: 2, Kubernetes sil jo net tastean om in pod te wiskjen.
Bottom line: om de beweging (en yn feite, it opnij oanmeitsjen) fan pods goed te wurkjen as it kluster wurdt frijlitten, is it nedich om PodDisruptionBudget te konfigurearjen.
Horizontale skaalfergrutting
Litte wy in oare situaasje beskôgje. D'r is in applikaasje dy't rint as ynset yn Kubernetes. Brûkersferkear komt nei har pods (d'r binne bygelyks trije fan har), en wy mjitte in bepaalde yndikator yn har (bygelyks CPU-load). As de lading ferheget, registrearje wy it op in skema en ferheegje it oantal pods om oanfragen te fersprieden.
Hjoed yn Kubernetes hoecht dit net mei de hân te dwaan: in automatyske ferheging / fermindering fan it oantal pods is konfigureare ôfhinklik fan 'e wearden fan' e mjitten load-yndikatoaren.
De wichtichste fragen hjir binne: wat krekt te mjitten и hoe te ynterpretearjen krigen wearden (foar it meitsjen fan in beslút oer it feroarjen fan it oantal pods). Jo kinne in protte mjitte:
Hoe dit technysk te dwaan - metriken sammelje, ensfh. - Ik spruts yn detail yn it rapport oer . En it wichtichste advys foar it kiezen fan de optimale parameters is eksperimint!
der binne (Gebrûk sêding en flaters), de betsjutting dêrfan is as folget. Op hokker basis hat it sin om bygelyks php-fpm te skaaljen? Op grûn fan it feit dat de arbeiders útrinne, is dit utilisaasje. En as de arbeiders oer binne en nije ferbiningen wurde net akseptearre, is dit al sêding. Beide parameters moatte wurde mjitten, en ôfhinklik fan de wearden moat skaalfergrutting wurde útfierd.
Yn stee fan in konklúzje
It rapport hat in fuortsetting: oer fertikale skaalfergrutting en hoe't jo de juste boarnen selektearje. Ik sil oer dit prate yn takomstige fideo's op - abonnearje sadat jo it net misse!
Fideo's en dia's
Fideo fan de foarstelling (44 minuten):
Presintaasje fan it rapport:
PS
Oare rapporten oer Kubernetes op ús blog:
- «» (Andrey Polovov; 8 april 2019 op Saint HighLoad++);
- «» (Dmitry Stolyarov; 8 novimber 2018 op HighLoad++);
- «» (Dmitry Stolyarov; 28 maaie 2018 by RootConf);
- «» (Dmitry Stolyarov; 7 novimber 2017 op HighLoad++);
- «» (Dmitry Stolyarov; 6 juny 2017 by RootConf).
Boarne: www.habr.com