Kubernetes hjá DomClick: hvernig á að sofa í friði og stjórna þyrping af 1000 örþjónustum

Ég heiti Viktor Yagofarov og ég er að þróa Kubernetes pallinn hjá DomClick sem tækniþróunarstjóri í Ops (aðgerða) teyminu. Mig langar að tala um uppbyggingu Dev <-> Ops ferla okkar, eiginleika þess að reka einn af stærstu k8s þyrpingunum í Rússlandi, sem og DevOps/SRE venjur sem teymið okkar beitir.

Ops lið

Í Ops teyminu eru nú 15 manns. Þrír þeirra bera ábyrgð á skrifstofunni, tveir vinna á öðru tímabelti og eru til taks, þar á meðal á nóttunni. Þannig er einhver frá Ops alltaf við eftirlitið og tilbúinn að bregðast við atviki af hvaða flóknu sem er. Við erum ekki með næturvaktir, sem varðveitir sálarlífið okkar og gefur öllum tækifæri til að fá nægan svefn og eyða frítíma, ekki bara við tölvuna.

Allir hafa mismunandi hæfileika: netverjar, DBA, ELK stafla sérfræðingar, Kubernetes stjórnendur/hönnuðir, eftirlit, sýndarvæðing, vélbúnaðarsérfræðingar o.s.frv. Eitt sameinar alla - allir geta komið í staðinn fyrir hvaða okkar sem er að einhverju leyti: til dæmis kynna nýja hnúta í k8s þyrpinguna, uppfæra PostgreSQL, skrifa CI/CD + Ansible leiðslu, gera eitthvað sjálfvirkt í Python/Bash/Go, tengja vélbúnað við Gagnaver. Sterk hæfni á hvaða sviði sem er kemur ekki í veg fyrir að þú breytir um stefnu og byrjar að bæta þig á einhverju öðru sviði. Til dæmis gekk ég til liðs við fyrirtæki sem PostgreSQL sérfræðingur og nú er aðalábyrgðarsvið mitt Kubernetes klasar. Í liðinu er hvaða hæð sem er velkomin og tilfinningin fyrir skiptimynt er mjög þróuð.

Við the vegur, við erum að veiða. Kröfur til umsækjenda eru nokkuð staðlaðar. Fyrir mig persónulega er mikilvægt að einstaklingur passi inn í liðið, sé ósammála en kunni líka að verja sín sjónarmið, vilji þróast og sé óhræddur við að gera eitthvað nýtt, komi með hugmyndir sínar. Einnig er krafist forritunarkunnáttu í forskriftarmálum, þekkingu á grunnatriðum Linux og ensku. Enska er einfaldlega þörf til þess að einstaklingur, ef um fakap er að ræða, geti googlað lausnina á vandamálinu á 10 sekúndum, en ekki á 10 mínútum. Það er nú mjög erfitt að finna sérfræðinga með djúpa þekkingu á Linux: það er fyndið, en tveir af hverjum þremur umsækjendum geta ekki svarað spurningunni „Hvað er álagsmeðaltal? Úr hverju er það gert?“ og spurningin „Hvernig á að setja saman kjarnasorp úr C forriti“ er talin eitthvað úr heimi ofurmannanna... eða risaeðlna. Við verðum að sætta okkur við þetta, þar sem fólk hefur venjulega mjög þróaða aðra hæfileika, en við munum kenna Linux. Svarið við spurningunni „af hverju þarf DevOps verkfræðingur að vita allt þetta í nútíma skýjaheimi“ verður að vera utan ramma greinarinnar, en í þremur orðum: allt þetta er nauðsynlegt.

Verkfæri liðsins

Verkfærateymið gegnir mikilvægu hlutverki í sjálfvirkni. Aðalverkefni þeirra er að búa til þægileg grafísk og CLI verkfæri fyrir forritara. Til dæmis, innri þróun okkar Confer gerir þér kleift að setja forrit í Kubernetes bókstaflega út með örfáum músarsmellum, stilla tilföng þess, lykla úr hvelfingu osfrv. Áður var Jenkins + Helm 2, en ég þurfti að þróa mitt eigið tól til að útrýma copy-paste og koma á einsleitni í líftíma hugbúnaðarins.

Ops teymið skrifar ekki leiðslur fyrir forritara, en getur ráðlagt um hvaða mál sem er í skrifum sínum (sumt fólk er enn með Helm 3).

DevOps

Hvað DevOps varðar, sjáum við þetta svona:

Dev teymi skrifa kóða, rúlla honum út í gegnum Confer to dev -> qa/stage -> prod. Ábyrgð á því að kóðinn hægi ekki á sér og innihaldi ekki villur er hjá Dev og Ops teymunum. Á daginn á vakthafandi úr Ops-teyminu fyrst og fremst að bregðast við atviki með umsókn sinni og á kvöldin og nóttu á vakthafandi stjórnandi (Ops) að vekja vakthafandi framkvæmdaraðila ef hann veit fyrir viss um að vandamálið sé ekki í innviðum. Allar mælingar og viðvaranir í vöktun birtast sjálfkrafa eða hálfsjálfvirkt.

Ábyrgðarsvið Ops hefst frá því augnabliki sem forritið er sett í framleiðslu, en ábyrgð Dev endar ekki þar - við gerum það sama og erum í sama báti.

Hönnuðir ráðleggja stjórnendum ef þeir þurfa hjálp við að skrifa stjórnanda örþjónustu (til dæmis Go backend + HTML5), og stjórnendur ráðleggja forriturum um hvers kyns innviðavandamál eða vandamál sem tengjast k8s.

Við the vegur, við erum alls ekki með einliða, aðeins örþjónustur. Fjöldi þeirra sveiflast hingað til á milli 900 og 1000 í prod k8s þyrpingunni, ef hann er mældur með tölu dreifing. Fjöldi fræbelgja sveiflast á milli 1700 og 2000. Nú eru um 2000 fræbelgir í stofnklasanum.

Ég get ekki gefið upp nákvæmar tölur, þar sem við fylgjumst með óþarfa örþjónustu og skerum þær út hálfsjálfvirkt. K8s hjálpar okkur að halda utan um óþarfa aðila ónýtur-rekstraraðili, sem sparar mikið fjármagn og peninga.

Auðlindastjórnun

Eftirlit

Vel uppbyggt og fræðandi eftirlit verður hornsteinninn í rekstri stórs klasa. Við höfum ekki enn fundið alhliða lausn sem myndi dekka 100% af öllum vöktunarþörfum, þannig að við búum reglulega til mismunandi sérsniðnar lausnir í þessu umhverfi.

• Zabbix. Gamla góða vöktun sem er fyrst og fremst ætlað að fylgjast með heildarástandi innviða. Það segir okkur hvenær hnútur deyr hvað varðar vinnslu, minni, diska, net osfrv. Ekkert yfirnáttúrulegt, en við höfum líka sérstakt DaemonSet af umboðsmönnum, með hjálp sem við fylgjumst til dæmis með ástandi DNS í þyrpingunni: við leitum að heimskum Coredns-belg, við athugum framboð á ytri vélum. Það virðist sem hvers vegna nenna þessu, en með miklu magni af umferð er þessi hluti alvarlegur bilun. Ég nú þegar lýst, hvernig ég átti í erfiðleikum með DNS frammistöðu í þyrpingu.
• Prometheus rekstraraðili. Safn mismunandi útflytjenda gefur mikla yfirsýn yfir alla þætti klasans. Næst sjáum við þetta allt fyrir okkur á stórum mælaborðum í Grafana og notum alertmanager fyrir viðvaranir.

Annað gagnlegt tæki fyrir okkur var lista-inngangur. Við skrifuðum það eftir að við lentum nokkrum sinnum í aðstæðum þar sem eitt lið skarast á Ingress slóðum annars liðs, sem leiddi til 50x villna. Nú áður en þeir fara í framleiðslu, athuga verktaki að enginn verði fyrir áhrifum, og fyrir teymið mitt er þetta gott tæki til að greina vandamál með Ingresses. Það er fyndið að í fyrstu var það skrifað fyrir admina og það leit frekar „klaufalegt“ út, en eftir að þróunarteymin urðu ástfangin af tólinu breyttist það mikið og fór að líta ekki út eins og „admin gerði vefandlit fyrir admina. ” Bráðum munum við yfirgefa þetta tól og slíkar aðstæður verða staðfestar jafnvel áður en leiðslan er rúlluð út.

Liðsauðlindir í teningnum

Áður en við förum inn í dæmin er þess virði að útskýra hvernig við úthlutum fjármagni fyrir örþjónustur.

Til að skilja hvaða lið og í hvaða magni nota sitt auðlindir (örgjörvi, minni, staðbundin SSD), úthlutum við hverri skipun sinni nafnrými í „teningnum“ og takmarka hámarksgetu hans hvað varðar örgjörva, minni og disk, eftir að hafa áður rætt þarfir liðanna. Samkvæmt því mun ein skipun, almennt séð, ekki loka fyrir allan klasann fyrir dreifingu, og úthlutar þúsundum kjarna og terabæta af minni. Aðgangur að nafnrými er veittur í gegnum AD (við notum RBAC). Nafnarýmum og takmörkunum þeirra er bætt við með dragbeiðni í GIT geymsluna og síðan er öllu sjálfkrafa rúllað út í gegnum Ansible leiðsluna.

Dæmi um úthlutun fjármagns til teymi:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

Beiðnir og takmörk

teningur" Beiðni er fjöldi tryggðra frátekinna auðlinda fyrir pod (einn eða fleiri hafnargámar) í þyrpingu. Hámark er óábyrgð hámark. Þú getur oft séð á línuritunum hvernig sumt teymi hefur sett sér of margar beiðnir fyrir öll sín forrit og getur ekki sent forritið á „Tenninginn“ þar sem öllum beiðnum undir nafnrými þeirra hefur þegar verið „eytt“.

Rétta leiðin út úr þessari stöðu er að skoða raunverulega auðlindanotkun og bera saman við umbeðið magn (Request).

Á skjámyndunum hér að ofan geturðu séð að „beðnir“ örgjörvar passa við raunverulegan fjölda þráða og takmörk geta farið yfir raunverulegan fjölda örgjörvaþráða =)

Nú skulum við skoða nokkur nafnrými í smáatriðum (ég valdi nafnrými kube-system - kerfisnafnarýmið fyrir íhluti „tenningsins“ sjálfs) og sjáum hlutfallið milli raunverulegs notaðs örgjörvatíma og minnis til þess sem óskað er eftir:

Það er augljóst að mun meira minni og örgjörvi er frátekið fyrir kerfisþjónustur en raunverulega er notað. Þegar um kube-kerfið er að ræða er þetta réttlætanlegt: það gerðist að nginx innrásarstýring eða nodelocaldns í hámarki lentu í örgjörvanum og neyttu mikið af vinnsluminni, svo hér er slík varasjóður réttlætanleg. Að auki getum við ekki treyst á töflur síðustu 3 klukkustundirnar: æskilegt er að sjá sögulegar mælingar yfir langan tíma.

Kerfi „ráðlegginga“ var þróað. Til dæmis, hér geturðu séð hvaða auðlindir væru betur settar með því að hækka „mörkin“ (efri leyfða stikan) þannig að „throttling“ eigi sér ekki stað: augnablikið þegar auðlind hefur þegar eytt örgjörva eða minni í úthlutaðri tímasneið og bíður þar til það verður „affryst“:

Og hér eru fræbelgirnir sem ættu að hefta matarlystina:

á inngjöf + eftirlit með auðlindum, þú getur skrifað fleiri en eina grein, svo spyrðu spurninga í athugasemdunum. Í nokkrum orðum get ég sagt að verkefnið við að gera slíkar mælingar sjálfvirkar er mjög erfitt og krefst mikils tíma og jafnvægisaðgerða með „glugga“ aðgerðum og „CTE“ Prometheus / VictoriaMetrics (þessi hugtök eru innan gæsalappa, þar sem það er næstum ekkert þessu líkt í PromQL, og þú verður að skipta skelfilegum fyrirspurnum í nokkra textaskjái og fínstilla þær).

Fyrir vikið hafa verktaki verkfæri til að fylgjast með nafnasvæðum sínum í Cube og þeir geta valið sjálfir hvar og á hvaða tíma hvaða forrit geta látið „klippa“ auðlindir sínar og hvaða netþjóna er hægt að fá allan CPU alla nóttina.

Aðferðafræði

Í fyrirtækinu eins og það er núna smart, fylgjumst við með DevOps- og SRE-iðkandi Þegar fyrirtæki er með 1000 örþjónustur, um 350 forritara og 15 stjórnendur fyrir allan innviðina, þá verður þú að „vera í tísku“: á bak við öll þessi „baswords“ er brýn þörf á að gera allt og alla sjálfvirkt og stjórnendur ættu ekki að vera flöskuháls í ferlum.

Sem Ops bjóðum við upp á ýmsa mælikvarða og mælaborð fyrir þróunaraðila sem tengjast svörunarhlutfalli þjónustu og villum.

Við notum aðferðafræði eins og: RED, NOTA и Gullmerkimeð því að sameina þau saman. Við reynum að lágmarka fjölda mælaborða þannig að í fljótu bragði sé ljóst hvaða þjónusta er í niðurníðslu (til dæmis svarkóðar á sekúndu, viðbragðstími um 99. hundraðshluta) og svo framvegis. Um leið og einhverjar nýjar mælikvarðar verða nauðsynlegar fyrir almenn mælaborð teiknum við strax og bætum þeim við.

Ég hef ekki teiknað línurit í mánuð. Þetta er líklega gott merki: það þýðir að flestar „óskir“ hafa þegar verið að veruleika. Það kom fyrir að í vikunni myndi ég teikna nýtt graf að minnsta kosti einu sinni á dag.

Niðurstaðan sem myndast er dýrmæt vegna þess að nú fara verktaki frekar sjaldan til stjórnenda með spurningar „hvar á að skoða einhvers konar mælikvarða.

Framkvæmd Þjónustunet er rétt handan við hornið og ætti að gera lífið mun auðveldara fyrir alla, samstarfsmenn frá Tools eru nú þegar nálægt því að innleiða ágripið „Istio of a healthy person“: lífsferill hverrar HTTP(s) beiðni verður sýnilegur í eftirliti, og það verður alltaf hægt að skilja „á hvaða stigi allt bilaði“ í samskiptum milli þjónustuaðila (en ekki aðeins). Gerast áskrifandi að fréttum frá DomClick miðstöðinni. =)

Stuðningur við Kubernetes innviði

Sögulega notum við pjattuðu útgáfuna Kubespray — Ansible hlutverk til að dreifa, útvíkka og uppfæra Kubernetes. Á einhverjum tímapunkti var stuðningur við uppsetningar utan kubeadm skorinn úr aðalgreininni og ekki var lagt til að skipta yfir í kubeadm. Fyrir vikið bjó Southbridge fyrirtækið til sinn eigin gaffal (með kubeadm stuðningi og skyndilausn fyrir mikilvæg vandamál).

Ferlið við að uppfæra alla k8s klasa lítur svona út:

• Taktu Kubespray frá Southbridge, athugaðu með þráðinn okkar, Merjim.
• Við erum að útfæra uppfærsluna til Streita- "Teningur".
• Við birtum uppfærsluna einn hnút í einu (í Ansible er þetta „röð: 1“) í dev- "Teningur".
• Við uppfærum Prod á laugardagskvöldið einn hnút í einu.

Það eru áform um að skipta um það í framtíðinni Kubespray fyrir eitthvað hraðari og farðu til kubeadm.

Alls höfum við þrjá „kubba“: Stress, Dev og Prod. Við ætlum að setja af stað annað (heitur biðstaða) Prod-„Cube“ í annarri gagnaverinu. Streita и dev búa í „sýndarvélum“ (oVirt for Stress og VMWare cloud for Dev). Prod- „Tenningur“ lifir á „berum málmi“: þetta eru eins hnútar með 32 örgjörvaþræði, 64-128 GB af minni og 300 GB SSD RAID 10 - það eru 50 þeirra alls. Þrír „þunnir“ hnútar eru tileinkaðir „meisturum“ Prod- „Kúba“: 16 GB af minni, 12 CPU þræðir.

Við sölu viljum við frekar nota „beran málm“ og forðast óþarfa lög eins og OpenStack: við þurfum ekki „hávaðasama nágranna“ og CPU stela tíma. Og flækjustig stjórnsýslunnar um það bil tvöfaldast þegar um er að ræða OpenStack innanhúss.

Fyrir CI/CD „Cubic“ og aðra innviðahluta notum við sérstakan GIT netþjón, Helm 3 (það var frekar sársaukafull umskipti frá Helm 2, en við erum mjög ánægð með valkostina kjarnorku), Jenkins, Ansible og Docker. Við elskum útibú og dreifingu í mismunandi umhverfi frá einni geymslu.

Ályktun

Þetta er almennt séð hvernig DevOps ferlið lítur út hjá DomClick frá sjónarhóli rekstrarverkfræðings. Greinin reyndist minna tæknileg en ég bjóst við: fylgdu því DomClick fréttum á Habré: það verða fleiri „harðkjarna“ greinar um Kubernetes og fleira.

Heimild: www.habr.com