Kumbuka. tafsiri.: Historia hii inayofumbua macho ya Omioβmjumlishi wa safari za Uropaβhuchukua wasomaji kutoka kwa nadharia ya msingi hadi ujanja wa kuvutia wa kiutendaji wa usanidi wa Kubernetes. Kufahamiana na kesi kama hizo husaidia sio tu kupanua upeo wako, lakini pia kuzuia shida zisizo za kawaida.
Je, umewahi kuwa na maombi kukwama, kuacha kujibu ukaguzi wa afya, na kushindwa kufahamu kwa nini? Maelezo moja yanayowezekana yanahusiana na vikomo vya mgao wa rasilimali za CPU. Hii ndio tutazungumza juu ya makala hii.
TL; DR:
Tunapendekeza kwa nguvu kuzima vikomo vya CPU katika Kubernetes (au kuzima sehemu za CFS katika Kubelet) ikiwa unatumia toleo la Linux kernel na hitilafu ya mgao wa CFS. Katika msingi serious na mdudu ambao husababisha kusukuma na kuchelewesha kupita kiasi.
Katika Omio miundombinu yote inasimamiwa na Kubernetes. Kazi zetu zote za hali na zisizo na uraia zinaendeshwa kwa Kubernetes pekee (tunatumia Google Kubernetes Engine). Katika miezi sita iliyopita, tulianza kuona kushuka kwa nasibu. Programu husimamisha au kuacha kujibu ukaguzi wa afya, kupoteza muunganisho kwenye mtandao, nk. Tabia hii ilitushangaza kwa muda mrefu, na hatimaye tukaamua kulichukulia tatizo hilo kwa uzito.
Muhtasari wa makala:
- Maneno machache kuhusu vyombo na Kubernetes;
- Jinsi maombi na mipaka ya CPU hutekelezwa;
- Jinsi kikomo cha CPU kinavyofanya kazi katika mazingira ya msingi nyingi;
- Jinsi ya kufuatilia CPU throttling;
- Suluhisho la shida na nuances.
Maneno machache kuhusu vyombo na Kubernetes
Kubernetes kimsingi ndio kiwango cha kisasa katika ulimwengu wa miundombinu. Kazi yake kuu ni orchestration ya vyombo.
Vyombo
Hapo awali, tulilazimika kuunda vizalia vya programu kama Java JAR/WARs, Mayai ya Python, au vitekelezo ili kuendeshwa kwenye seva. Hata hivyo, ili kuwafanya kazi, kazi ya ziada ilipaswa kufanywa: kufunga mazingira ya wakati wa kukimbia (Java / Python), kuweka faili muhimu katika maeneo sahihi, kuhakikisha utangamano na toleo maalum la mfumo wa uendeshaji, nk. Kwa maneno mengine, umakini mkubwa ulipaswa kulipwa kwa usimamizi wa usanidi (ambao mara nyingi ulikuwa chanzo cha ugomvi kati ya wasanidi programu na wasimamizi wa mfumo).
Vyombo vilibadilisha kila kitu. Sasa artifact ni picha ya chombo. Inaweza kuwakilishwa kama aina ya faili iliyopanuliwa inayoweza kutekelezwa isiyo na programu tu, bali pia mazingira kamili ya utekelezaji (Java/Python/...), pamoja na faili/vifurushi muhimu, vilivyosakinishwa awali na tayari kukimbia. Vyombo vinaweza kutumwa na kuendeshwa kwenye seva tofauti bila hatua zozote za ziada.
Kwa kuongeza, vyombo hufanya kazi katika mazingira yao ya sandbox. Wana adapta yao ya mtandao ya kawaida, mfumo wao wa faili na ufikiaji mdogo, uongozi wao wa taratibu, vikwazo vyao wenyewe kwenye CPU na kumbukumbu, nk. Yote hii inatekelezwa shukrani kwa mfumo maalum wa kernel ya Linux - nafasi za majina.
Mabernet
Kama ilivyoelezwa hapo awali, Kubernetes ni orchestrator ya chombo. Inafanya kazi kama hii: unaipatia mashine nyingi, na kisha kusema: "Halo, Kubernetes, wacha tuzindue mifano kumi ya kontena langu na vichakataji 2 na kumbukumbu ya GB 3 kila moja, na iendelee kufanya kazi!" Kubernetes atashughulikia mengine. Itapata uwezo wa bure, kuzindua vyombo na kuwasha upya ikiwa ni lazima, toa sasisho wakati wa kubadilisha matoleo, nk. Kimsingi, Kubernetes hukuruhusu kuondoa kijenzi cha maunzi na kutengeneza aina mbalimbali za mifumo inayofaa kwa kupeleka na kuendesha programu.
Kubernetes kutoka kwa mtazamo wa mlei
Ni nini maombi na mipaka katika Kubernetes
Sawa, tumefunika vyombo na Kubernetes. Pia tunajua kwamba vyombo vingi vinaweza kukaa kwenye mashine moja.
Mfano unaweza kuchora na ghorofa ya jumuiya. Jengo kubwa (mashine/vitengo) huchukuliwa na kukodishwa kwa wapangaji kadhaa (vyombo). Kubernetes anafanya kazi kama mchuuzi. Swali linatokea, jinsi ya kuwaweka wapangaji kutoka kwa migogoro na kila mmoja? Je, ikiwa mmoja wao, sema, anaamua kukopa bafuni kwa nusu ya siku?
Hapa ndipo maombi na mipaka hutumika. CPU Kuomba zinahitajika tu kwa madhumuni ya kupanga. Hiki ni kitu kama "orodha ya matakwa" ya chombo, na hutumiwa kuchagua nodi inayofaa zaidi. Wakati huo huo CPU Punguza inaweza kulinganishwa na makubaliano ya kukodisha - mara tu tunapochagua kitengo cha kontena, the haiwezi kwenda nje ya mipaka iliyowekwa. Na hapa ndipo tatizo linapotokea...
Jinsi maombi na vikomo vinatekelezwa katika Kubernetes
Kubernetes hutumia utaratibu wa kusukuma (kuruka mizunguko ya saa) iliyojengwa ndani ya kernel kutekeleza vikomo vya CPU. Ikiwa programu itazidi kikomo, upunguzaji sauti unawezeshwa (yaani, inapokea mizunguko machache ya CPU). Maombi na mipaka ya kumbukumbu hupangwa kwa njia tofauti, kwa hivyo ni rahisi kugundua. Ili kufanya hivyo, angalia tu hali ya mwisho ya kuanzisha upya ya pod: ikiwa ni "OOMKilled". Kusonga kwa CPU sio rahisi sana, kwani K8s hufanya tu vipimo vipatikane kwa matumizi, sio kwa vikundi.
Ombi la CPU
Jinsi ombi la CPU linatekelezwa
Kwa unyenyekevu, hebu tuangalie mchakato wa kutumia mashine iliyo na 4-msingi CPU kama mfano.
K8s hutumia utaratibu wa kikundi cha kudhibiti (cgroups) ili kudhibiti ugawaji wa rasilimali (kumbukumbu na processor). Mfano wa hierarchical unapatikana kwa ajili yake: mtoto hurithi mipaka ya kikundi cha wazazi. Maelezo ya usambazaji yanahifadhiwa katika mfumo wa faili wa kawaida (/sys/fs/cgroup) Katika kesi ya processor hii ni /sys/fs/cgroup/cpu,cpuacct/*.
K8s hutumia faili cpu.share kutenga rasilimali za processor. Kwa upande wetu, kikundi cha mizizi kinapata hisa 4096 za rasilimali za CPU - 100% ya nguvu inayopatikana ya processor (1 msingi = 1024; hii ni thamani ya kudumu). Kikundi cha mizizi kinasambaza rasilimali sawia kulingana na hisa za vizazi vilivyosajiliwa cpu.share, na wao, kwa upande wao, hufanya vivyo hivyo na wazao wao, nk. Kwenye nodi ya kawaida ya Kubernetes, kikundi cha mizizi kina watoto watatu: system.slice, user.slice ΠΈ kubepods. Vikundi viwili vya kwanza vinatumika kusambaza rasilimali kati ya mizigo muhimu ya mfumo na programu za watumiaji nje ya K8s. Ya mwisho - kubepods β imeundwa na Kubernetes ili kusambaza rasilimali kati ya maganda.
Mchoro hapo juu unaonyesha kuwa vikundi vidogo vya kwanza na vya pili vilipokea kila moja 1024 hisa, pamoja na kikundi kidogo cha kuberpod kilichotengwa 4096 hisa Hii inawezekanaje: baada ya yote, kikundi cha mizizi kinaweza kufikia tu 4096 hisa, na jumla ya hisa za wazao wake huzidi kwa kiasi kikubwa idadi hii (6144)? Jambo ni kwamba thamani ina mantiki, kwa hivyo kipanga ratiba cha Linux (CFS) kinaitumia kutenga rasilimali za CPU sawia. Kwa upande wetu, vikundi viwili vya kwanza vinapokea 680 hisa halisi (16,6% ya 4096), na kubepod inapokea iliyobaki 2736 hisa Katika kesi ya kupungua kwa muda, vikundi viwili vya kwanza havitatumia rasilimali zilizotengwa.
Kwa bahati nzuri, kipanga ratiba kina utaratibu wa kuzuia upotevu wa rasilimali za CPU ambazo hazijatumika. Inahamisha uwezo "wa kutofanya kazi" kwenye bwawa la kimataifa, ambalo husambazwa kwa vikundi vinavyohitaji nguvu ya ziada ya processor (uhamisho hutokea kwa makundi ili kuepuka hasara za kuzunguka). Njia sawa inatumika kwa wazao wote wa vizazi.
Utaratibu huu unahakikisha usambazaji wa haki wa nguvu za processor na kuhakikisha kwamba hakuna mchakato wa "kuiba" rasilimali kutoka kwa wengine.
Kikomo cha CPU
Licha ya ukweli kwamba usanidi wa mipaka na maombi katika K8s inaonekana sawa, utekelezaji wao ni tofauti sana: hii. kupotosha zaidi na sehemu ndogo kabisa iliyoandikwa.
K8s hujihusisha kutekeleza mipaka. Mipangilio yao imeainishwa katika faili cfs_period_us ΠΈ cfs_quota_us kwenye saraka ya kikundi (faili pia iko hapo cpu.share).
Tofauti cpu.share, mgawo unategemea muda, na sio kwa nguvu inayopatikana ya processor. cfs_period_us inabainisha muda wa kipindi (epoch) - daima ni 100000 ΞΌs (100 ms). Kuna chaguo la kubadilisha thamani hii katika K8s, lakini inapatikana tu katika alpha kwa sasa. Kiratibu hutumia enzi kuanzisha upya sehemu zilizotumika. Faili ya pili cfs_quota_us, hubainisha muda unaopatikana (idadi) katika kila kipindi. Kumbuka kwamba pia imeainishwa katika microseconds. Kiwango kinaweza kuzidi urefu wa enzi; kwa maneno mengine, inaweza kuwa zaidi ya 100 ms.
Wacha tuangalie hali mbili kwenye mashine-msingi 16 (aina ya kawaida ya kompyuta tuliyo nayo Omio):
Hali ya 1: nyuzi 2 na kikomo cha ms 200. Hakuna kukaba
Hali ya 2: nyuzi 10 na kikomo cha ms 200. Kusonga huanza baada ya ms 20, ufikiaji wa rasilimali za kichakataji hurejeshwa baada ya 80 ms nyingine.
Wacha tuseme umeweka kikomo cha CPU 2 kokwa; Kubernetes itatafsiri thamani hii hadi 200 ms. Hii ina maana kwamba chombo kinaweza kutumia upeo wa 200ms za muda wa CPU bila kugusa.
Na hapa ndipo furaha huanza. Kama ilivyoelezwa hapo juu, nafasi inayopatikana ni 200 ms. Ikiwa unafanya kazi sambamba kumi nyuzi kwenye mashine ya msingi-12 (tazama mchoro wa hali ya 2), wakati maganda mengine yote hayafanyi kazi, nafasi itakamilika kwa ms 20 tu (tangu 10 * 20 ms = 200 ms), na nyuzi zote za ganda hili zitaning'inia. Β» (kaba) kwa 80 ms zinazofuata. Iliyotajwa tayari , kwa sababu ambayo msukumo mwingi hutokea na chombo hakiwezi hata kutimiza mgawo uliopo.
Jinsi ya kutathmini throttling katika maganda?
Ingia tu kwenye ganda na utekeleze cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- jumla ya idadi ya vipindi vya mpangilio; -
nr_throttled- idadi ya vipindi vya throttled katika muundonr_periods; -
throttled_time- muda wa kupunguzwa kwa muda katika nanoseconds.
Nini kinaendelea kweli?
Matokeo yake, tunapata msisimko mkubwa katika programu zote. Wakati mwingine yuko ndani mara moja na nusu nguvu kuliko inavyotarajiwa!
Hii inasababisha makosa mbalimbali - kushindwa kwa kuangalia utayari, kufungia kwa chombo, mapumziko ya muunganisho wa mtandao, kuisha kwa muda ndani ya simu za huduma. Hii hatimaye husababisha kuongezeka kwa muda wa kusubiri na viwango vya juu vya makosa.
Uamuzi na matokeo
Kila kitu ni rahisi hapa. Tuliachana na vikomo vya CPU na kuanza kusasisha kernel ya Mfumo wa Uendeshaji katika vikundi hadi toleo jipya zaidi, ambalo hitilafu ilirekebishwa. Idadi ya makosa (HTTP 5xx) katika huduma zetu ilishuka mara moja kwa kiasi kikubwa:
Hitilafu za HTTP 5xx
Hitilafu za HTTP 5xx kwa huduma moja muhimu
Muda wa kujibu p95
Muda wa kusubiri wa ombi la huduma muhimu, asilimia 95
Gharama za uendeshaji
Idadi ya saa za mfano zilizotumika
Nini kukamata?
Kama ilivyoelezwa mwanzoni mwa makala:
Mfano unaweza kuchorwa na nyumba ya jumuia... Kubernetes hufanya kazi kama mali isiyohamishika. Lakini jinsi ya kuwaweka wapangaji kutoka kwa migogoro na kila mmoja? Je, ikiwa mmoja wao, sema, anaamua kukopa bafuni kwa nusu ya siku?
Hapa kuna samaki. Chombo kimoja kisichojali kinaweza kula rasilimali zote za CPU zinazopatikana kwenye mashine. Ikiwa una stack ya maombi ya smart (kwa mfano, JVM, Go, Node VM imeundwa vizuri), basi hii sio tatizo: unaweza kufanya kazi katika hali kama hizo kwa muda mrefu. Lakini ikiwa programu hazijaboreshwa vizuri au hazijaboreshwa kabisa (FROM java:latest), hali inaweza kupata nje ya udhibiti. Huko Omio, tuna faili za kiotomatiki za msingi zilizo na mipangilio chaguomsingi ya kutosha kwa rafu kuu ya lugha, kwa hivyo suala hili halikuwepo.
Tunapendekeza ufuatilie vipimo (matumizi, kueneza na makosa), ucheleweshaji wa API na viwango vya makosa. Hakikisha kuwa matokeo yanakidhi matarajio.
marejeo
Hii ni hadithi yetu. Nyenzo zifuatazo zilisaidia sana kuelewa kinachoendelea:
- ;
- ;
- ;
- ;
- - tafuta "cpu throttling".
Kubernetes mdudu anaripoti:
- ;
- ;
- .
Je, umekumbana na matatizo kama hayo katika mazoezi yako au una uzoefu unaohusiana na kuporomoka katika mazingira ya uzalishaji yaliyo na vyombo? Shiriki hadithi yako katika maoni!
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com