Abril 27 sa komperensya , isip kabahin sa seksyon sa "DevOps", ang report nga "Autoscaling ug pagdumala sa kapanguhaan sa Kubernetes" gihatag. Naghisgot kini kung giunsa nimo magamit ang mga K8 aron masiguro ang taas nga pagkaanaa sa imong mga aplikasyon ug masiguro ang labing kataas nga pasundayag.
Pinaagi sa tradisyon, nalipay kami sa pagpresentar (44 ka minuto, labi pa ka impormasyon kaysa sa artikulo) ug ang panguna nga summary sa porma sa teksto. Lakaw!
Atong analisahon ang hilisgutan sa report pulong sa pulong ug magsugod gikan sa katapusan.
Kubernetes
Ingnon ta nga adunay mga sudlanan sa Docker sa among host. Para unsa? Aron masiguro ang pag-usab ug pag-inusara, nga sa baylo nagtugot alang sa yano ug maayo nga pag-deploy, CI / CD. Daghan kami sa ingon nga mga sakyanan nga adunay mga sudlanan.
Unsa ang gihatag sa Kubernetes niini nga kaso?
- Mohunong kami sa paghunahuna bahin sa kini nga mga makina ug magsugod sa pagtrabaho kauban ang "panganod" pundok sa mga sudlanan o mga pod (mga grupo sa mga sudlanan).
- Dugang pa, wala kami maghunahuna bahin sa indibidwal nga mga pod, apan nagdumala paΠΎdagkong mga grupo. Ang ingon taas nga lebel nga mga primitibo tuguti kami sa pag-ingon nga adunay usa ka template alang sa pagpadagan sa usa ka piho nga workload, ug ania ang gikinahanglan nga gidaghanon sa mga higayon sa pagpadagan niini. Kung usbon namon ang template, ang tanan nga mga higayon mausab.
- Uban sa tabang sa deklaratibo nga API Imbis nga ipatuman ang usa ka han-ay sa piho nga mga sugo, among gihulagway ang "struktura sa kalibutan" (sa YAML), nga gimugna sa Kubernetes. Ug usab: kung magbag-o ang paghulagway, ang aktwal nga pagpakita niini mausab usab.
Pagdumala sa kahinguhaan
CPU
Padaganon nato ang nginx, php-fpm ug mysql sa server. Kini nga mga serbisyo adunay labi pa nga mga proseso nga nagdagan, nga ang matag usa nanginahanglan mga kapanguhaan sa pag-compute:
(ang mga numero sa slide kay "parrots", ang abstract nga panginahanglan sa matag proseso alang sa computing power)
Aron mas sayon ββββang pagtrabaho niini, makatarunganon nga isagol ang mga proseso ngadto sa mga grupo (pananglitan, ang tanan nga mga proseso sa nginx ngadto sa usa ka grupo nga "nginx"). Usa ka yano ug klaro nga paagi sa pagbuhat niini mao ang pagbutang sa matag grupo sa usa ka sudlanan:
Aron magpadayon, kinahanglan nimong hinumdoman kung unsa ang usa ka sudlanan (sa Linux). Ang ilang panagway nahimong posible tungod sa tulo ka mahinungdanong bahin sa kernel, nga gipatuman sa dugay na nga panahon: , ΠΈ . Ug ang dugang nga pag-uswag gipadali sa ubang mga teknolohiya (lakip ang kombenyente nga "mga kabhang" sama sa Docker):
Sa konteksto sa taho, interesado lang kami mga grupo, tungod kay ang mga kontrol nga grupo mao ang bahin sa pagpaandar sa mga sudlanan (Docker, ug uban pa) nga nagpatuman sa pagdumala sa kapanguhaan. Ang mga proseso nga gihiusa ngadto sa mga grupo, sumala sa among gusto, mga kontrol nga grupo.
Mobalik kita sa mga kinahanglanon sa CPU alang niini nga mga proseso, ug karon alang sa mga grupo sa mga proseso:
(Akong gisubli nga ang tanan nga mga numero usa ka abstract nga pagpahayag sa panginahanglan alang sa mga kapanguhaan)
Sa samang higayon, ang CPU mismo adunay usa ka limitado nga kapanguhaan (sa pananglitan kini mao ang 1000), nga mahimong kulang sa tanan (ang sumada sa mga panginahanglan sa tanang grupo kay 150+850+460=1460). Unsa ang mahitabo niini nga kaso?
Ang kernel nagsugod sa pag-apod-apod sa mga kapanguhaan ug gihimo kini nga "patas", nga naghatag sa parehas nga kantidad sa mga kapanguhaan sa matag grupo. Apan sa unang kaso, adunay mas daghan niini kay sa gikinahanglan (333> 150), mao nga ang sobra (333-150=183) nagpabilin nga reserba, nga parehas usab nga giapod-apod tali sa duha ka laing mga sudlanan:
Ingon usa ka sangputanan: ang una nga sudlanan adunay igo nga mga kapanguhaan, ang ikaduha - wala kini igo nga mga kapanguhaan, ang ikatulo - wala kini igo nga mga kapanguhaan. Kini ang resulta sa mga aksyon "matinud-anon" nga scheduler sa Linux - . Ang operasyon niini mahimong i-adjust gamit ang assignment mga timbang matag usa sa mga sudlanan. Pananglitan, sama niini:
Atong tan-awon ang kaso sa kakulang sa mga kapanguhaan sa ikaduhang sudlanan (php-fpm). Ang tanan nga mga kahinguhaan sa sudlanan parehas nga giapod-apod tali sa mga proseso. Ingon usa ka sangputanan, maayo ang proseso sa master, apan ang tanan nga mga trabahante hinay, nga nakadawat walaβy katunga sa ilang kinahanglan:
Ingon niini ang pagtrabaho sa CFS scheduler. Tawgon pa namon ang mga gibug-aton nga among gi-assign sa mga sudlanan mga hangyo. Ngano nga ingon niini - tan-awa ang dugang.
Atong tan-awon ang tibuok nga sitwasyon gikan sa pikas nga bahin. Sama sa imong nahibal-an, ang tanan nga mga dalan padulong sa Roma, ug sa kaso sa usa ka kompyuter, sa CPU. Usa ka CPU, daghang mga buluhaton - kinahanglan nimo ang suga sa trapiko. Ang pinakasimple nga paagi sa pagdumala sa mga kahinguhaan mao ang "traffic light": gihatagan nila ang usa ka proseso og usa ka pirmi nga oras sa pag-access sa CPU, dayon ang sunod, ug uban pa.
Kini nga pamaagi gitawag nga lisud nga mga quota (lisud nga limitasyon). Atong hinumdoman kini sa yano nga paagi mga kinutuban. Bisan pa, kung nag-apod-apod ka sa mga limitasyon sa tanan nga mga sudlanan, adunay usa ka problema: ang mysql nagmaneho sa dalan ug sa pila ka punto ang panginahanglan niini alang sa CPU natapos, apan ang tanan nga ubang mga proseso napugos sa paghulat hangtod sa CPU. walay pulos.
Balikan nato ang Linux kernel ug ang interaksyon niini sa CPU - ang kinatibuk-ang hulagway mao ang mosunod:
Ang cgroup adunay duha ka mga setting - sa tinuud duha kini ka yano nga "mga twist" nga nagtugot kanimo sa pagtino:
- gibug-aton alang sa sudlanan (mga hangyo) mao nakigbahin;
- porsyento sa kinatibuk-ang oras sa CPU alang sa pagtrabaho sa mga buluhaton sa sudlanan (mga limitasyon) mao ang quota.
Unsaon pagsukod sa CPU?
Adunay lain-laing mga paagi:
- Unsa mga parrots, walay nahibalo - kinahanglan nimo nga makigsabot sa matag higayon.
- Interes mas klaro, apan paryente: 50% sa usa ka server nga adunay 4 nga mga core ug adunay 20 nga mga cores hingpit nga lahi nga mga butang.
- Mahimo nimong gamiton ang mga nahisgutan na mga timbang, nga nahibal-an sa Linux, apan sila usab paryente.
- Ang labing igo nga kapilian mao ang pagsukod sa mga kapanguhaan sa pag-compute sa segundos. Mga. sa mga segundo sa oras sa processor nga may kalabotan sa mga segundo sa tinuud nga oras: 1 segundo sa oras sa processor gihatag matag 1 tinuod nga segundo - kini usa ka tibuuk nga core sa CPU.
Aron mas sayon ββang pagsulti, nagsugod sila sa pagsukod direkta sa sulod mga lugas, nga nagpasabut nga sila parehas nga oras sa CPU nga may kalabotan sa tinuod. Tungod kay ang Linux nakasabut sa mga gibug-aton, apan dili kaayo oras sa CPU / mga core, usa ka mekanismo ang gikinahanglan aron mahubad gikan sa usa ngadto sa lain.
Atong tagdon ang usa ka yano nga pananglitan sa usa ka server nga adunay 3 nga mga cores sa CPU, diin ang tulo ka pods hatagan og gibug-aton (500, 1000 ug 1500) nga daling makabig ngadto sa katugbang nga mga bahin sa mga cores nga gigahin kanila (0,5, 1 ug 1,5).
Kung magkuha ka usa ka ikaduha nga server, diin adunay doble nga gidaghanon sa mga cores (6), ug ibutang ang parehas nga mga pods didto, ang pag-apod-apod sa mga cores dali nga makalkula pinaagi sa pagpadaghan sa 2 (1, 2 ug 3, matag usa). Apan ang usa ka importante nga gutlo mahitabo sa diha nga ang usa ka ikaupat nga pod makita sa niini nga server, kansang gibug-aton, alang sa kasayon, mahimong 3000. Gikuha niini ang bahin sa mga kapanguhaan sa CPU (katunga sa mga cores), ug alang sa nahabilin nga mga pod sila gikalkulo pag-usab (gitunga):
Kubernetes ug mga kapanguhaan sa CPU
Sa Kubernetes, ang mga kapanguhaan sa CPU kasagarang gisukod sa milliadrax, i.e. Ang 0,001 nga mga cores gikuha isip base nga gibug-aton. (Ang parehas nga butang sa terminolohiya sa Linux/cgroups gitawag nga usa ka bahin sa CPU, bisan pa, labi ka tukma, 1000 millicores = 1024 nga bahin sa CPU.) Gisiguro sa K8s nga dili kini magbutang ug daghang mga pod sa server kaysa adunay mga kapanguhaan sa CPU alang sa sumada sa mga gibug-aton sa tanan nga mga pod.
Sa unsang paagi kini mahitabo? Kung magdugang ka usa ka server sa usa ka cluster sa Kubernetes, gitaho kung pila ang mga core sa CPU nga magamit niini. Ug kung maghimo usa ka bag-ong pod, nahibal-an sa scheduler sa Kubernetes kung pila ka mga core ang kinahanglan niini nga pod. Sa ingon, ang pod ma-assign sa usa ka server diin adunay igo nga mga cores.
Unsa ang mahitabo kung dili gipiho ang hangyo (i.e. ang pod walay tino nga gidaghanon sa mga core nga gikinahanglan niini)? Atong hisgotan kung giunsa pag-ihap sa Kubernetes ang mga kapanguhaan.
Alang sa usa ka pod mahimo nimong ipiho ang duha nga mga hangyo (CFS scheduler) ug mga limitasyon (hinumdomi ang suga sa trapiko?):
- Kung sila gitakda nga managsama, nan ang pod gi-assign sa usa ka klase sa QoS garantiya. Kini nga gidaghanon sa mga cores kanunay nga magamit niini gigarantiyahan.
- Kung ang hangyo gamay ra sa limitasyon - klase sa QoS mabuak. Mga. Naglaum kami nga ang usa ka pod, pananglitan, kanunay nga mogamit sa 1 nga core, apan kini nga kantidad dili usa ka limitasyon alang niini: paghigugma pod makagamit ug dugang (kung ang server adunay libre nga mga kapanguhaan alang niini).
- Adunay usab usa ka klase sa QoS labing paningkamot - kini naglakip sa mga pod nga wala gipiho ang hangyo. Ang mga kapanguhaan gihatag ngadto kanila sa katapusan.
handumanan
Uban sa panumduman, ang sitwasyon parehas, apan gamay nga lahi - pagkahuman, lahi ang kinaiya niini nga mga kahinguhaan. Sa kinatibuk-an, ang analogy mao ang mosunod:
Atong tan-awon kung giunsa ang mga hangyo gipatuman sa memorya. Himoa nga ang mga pod mabuhi sa server, nga mag-usab sa konsumo sa panumduman, hangtud nga ang usa kanila mahimong dako kaayo nga kini nahutdan sa memorya. Niini nga kaso, ang OOM killer makita ug mopatay sa kinadak-ang proseso:
Dili kini kanunay nga angay kanato, mao nga posible nga i-regulate kung unsang mga proseso ang hinungdanon alang kanato ug dili kinahanglan patyon. Aron mahimo kini, gamita ang parameter oom_score_adj.
Balikan nato ang mga klase sa QoS sa CPU ug magdrowing og analogy sa oom_score_adj values ββββnga nagtino sa mga prayoridad sa konsumo sa memorya alang sa mga pod:
- Ang labing ubos nga oom_score_adj nga kantidad alang sa usa ka pod - -998 - nagpasabut nga ang ingon nga pod kinahanglan nga patyon sa katapusan, kini garantiya.
- Ang labing taas - 1000 - mao labing paningkamot, ang maong mga pod unang gipatay.
- Aron makalkulo ang nahabilin nga mga kantidad (mabuak) naay pormula, ang esensiya niini nagsukad sa kamatuoran nga mas daghang resources ang gipangayo pod, mas gamay ang posibilidad nga mapatay.
Ang ikaduha nga "twist" - limit_in_bytes - alang sa mga limitasyon. Uban niini, ang tanan mas simple: gi-assign lang namo ang maximum nga gidaghanon sa gi-isyu nga panumduman, ug dinhi (dili sama sa CPU) walay pangutana kon unsaon pagsukod niini (memorya).
Total
Ang matag pod sa Kubernetes gihatag requests ΠΈ limits - pareho nga mga parameter alang sa CPU ug memorya:
- base sa mga hangyo, ang Kubernetes scheduler nagtrabaho, nga nag-apod-apod sa mga pod sa mga server;
- base sa tanan nga mga parametro, ang klase sa QoS sa pod gitino;
- Ang mga paryente nga gibug-aton gikalkulo base sa mga hangyo sa CPU;
- ang CFS scheduler gi-configure base sa mga hangyo sa CPU;
- Ang OOM killer gi-configure base sa mga hangyo sa memorya;
- usa ka "traffic light" gi-configure base sa mga limitasyon sa CPU;
- Base sa mga limitasyon sa memorya, usa ka limitasyon ang gi-configure para sa cgroup.
Sa kinatibuk-an, kini nga litrato nagtubag sa tanan nga mga pangutana kung giunsa ang panguna nga bahin sa pagdumala sa kapanguhaan nahitabo sa Kubernetes.
Autoscaling
K8s cluster-autoscaler
Atong hunahunaon nga ang tibuok cluster kay okupado na ug usa ka bag-ong pod kinahanglan nga himoon. Samtang ang pod dili makita, kini nagbitay sa status pending. Aron kini makita, mahimo natong ikonektar ang usa ka bag-ong server sa cluster o ... i-install ang cluster-autoscaler, nga buhaton kini alang kanato: pag-order og virtual machine gikan sa cloud provider (gamit ang API request) ug ikonektar kini sa cluster , human niana ang pod idugang .
Kini ang autoscaling sa Kubernetes cluster, nga maayo kaayo (sa among kasinatian). Bisan pa, sama sa ubang lugar, adunay pipila nga mga nuances dinhi ...
Hangtud nga gipadako namon ang gidak-on sa cluster, maayo ang tanan, apan unsa ang mahitabo kung ang cluster nagsugod sa pagpalingkawas sa iyang kaugalingon? Ang problema mao nga ang paglalin sa mga pod (aron mapalaya ang mga host) lisud kaayo sa teknikal ug mahal sa mga termino sa mga kahinguhaan. Ang Kubernetes naggamit sa usa ka hingpit nga lahi nga pamaagi.
Hunahunaa ang usa ka kumpol sa 3 nga mga server nga adunay Deployment. Kini adunay 6 pod: karon adunay 2 alang sa matag server. Sa pipila ka rason gusto namong i-off ang usa sa mga server. Sa pagbuhat niini atong gamiton ang sugo kubectl drain, nga:
- magdili sa pagpadala ug bag-ong mga pod niini nga server;
- papason ang mga naa na pod sa server.
Tungod kay ang Kubernetes ang responsable sa pagmintinar sa gidaghanon sa mga pod (6), kini yano maghimo pag-usab kini sa ubang mga node, apan dili sa usa nga nabaldado, tungod kay kini gimarkahan na nga dili magamit alang sa pag-host sa mga bag-ong pod. Kini usa ka sukaranan nga mekaniko alang sa Kubernetes.
Bisan pa, adunay usa ka nuance dinhi usab. Sa parehas nga sitwasyon, para sa StatefulSet (imbes nga Deployment), lahi ang mga aksyon. Karon aduna na kami'y stateful nga aplikasyon - pananglitan, tulo ka pod nga adunay MongoDB, ang usa niini adunay usa ka matang sa problema (ang data nahimo nga dunot o laing sayup nga nagpugong sa pod sa pagsugod sa husto). Ug nakahukom na usab kami nga dili pag-disable ang usa ka server. Unsay mahitabo?
MongoDB mahimo mamatay tungod kay nagkinahanglan kini og korum: alang sa usa ka pungpong sa tulo ka mga instalasyon, labing menos duha ang kinahanglang molihok. Apan, kini dili mahitabo - salamat sa PodDisruptionBudget. Kini nga parameter nagtino sa minimum nga gikinahanglan nga gidaghanon sa nagtrabaho pods. Nahibal-an nga ang usa sa mga MongoDB pod wala na molihok, ug nakita nga ang PodDisruptionBudget gitakda para sa MongoDB minAvailable: 2, Kubernetes dili motugot kanimo sa pagtangtang sa usa ka pod.
Ubos nga linya: aron ang paglihok (ug sa tinuud, ang paghimo pag-usab) sa mga pod nga molihok sa husto kung ang cluster gipagawas, kinahanglan nga i-configure ang PodDisruptionBudget.
Horizontal scaling
Atong tagdon ang laing sitwasyon. Adunay usa ka aplikasyon nga nagdagan ingon Deployment sa Kubernetes. Ang trapiko sa tiggamit moabut sa mga pod niini (pananglitan, adunay tulo niini), ug gisukod namon ang usa ka piho nga timailhan sa kanila (ingon, ang load sa CPU). Kung modaghan ang load, among irekord kini sa usa ka eskedyul ug dugangan ang gidaghanon sa mga pod aron maapod-apod ang mga hangyo.
Karon sa Kubernetes dili kini kinahanglan nga buhaton nga mano-mano: ang usa ka awtomatik nga pagtaas/pagkunhod sa gidaghanon sa mga pod gi-configure depende sa mga kantidad sa gisukod nga mga indikasyon sa pagkarga.
Ang nag-unang mga pangutana dinhi mao ang: unsa gyud ang sukod ΠΈ unsaon pag interpret nakuha nga mga kantidad (alang sa paghimo og desisyon sa pagbag-o sa gidaghanon sa mga pod). Daghan ka masukod:
Giunsa kini pagbuhat sa teknikal - pagkolekta mga sukatan, ug uban pa. β Ako misulti sa detalye sa report mahitungod sa . Ug ang panguna nga tambag alang sa pagpili sa labing kamalaumon nga mga parameter mao eksperimento!
Adunay (Utilization Saturation ug Errors), ang kahulogan niini mao ang mosunod. Sa unsa nga sukaranan nga makatarunganon ang pagsukod, pananglitan, php-fpm? Base sa kamatuoran nga ang mga trabahante nahutdan, kini mao paggamit. Ug kung ang mga trabahante nahuman na ug ang mga bag-ong koneksyon dili madawat, kini na saturation. Ang duha niini nga mga parameter kinahanglan nga sukdon, ug depende sa mga kantidad, ang pag-scale kinahanglan nga himuon.
Kay sa usa ka konklusyon
Ang report adunay usa ka pagpadayon: mahitungod sa bertikal scaling ug sa unsa nga paagi sa pagpili sa husto nga mga kapanguhaan. Akong hisgutan kini sa umaabot nga mga video sa - subscribe para dili ka masipyat!
Mga video ug mga slide
Video gikan sa pasundayag (44 minuto):
Presentasyon sa report:
PS
Ang ubang mga taho bahin sa Kubernetes sa among blog:
- «» (Andrey Polovov; Abril 8, 2019 sa Saint HighLoad++);
- «» (Dmitry Stolyarov; Nobyembre 8, 2018 sa HighLoad++);
- «» (Dmitry Stolyarov; Mayo 28, 2018 sa RootConf);
- «» (Dmitry Stolyarov; Nobyembre 7, 2017 sa HighLoad++);
- «» (Dmitry Stolyarov; Hunyo 6, 2017 sa RootConf).
Source: www.habr.com