Minu nimi on Viktor Yagofarov ja arendan Kubernetese platvormi DomClickis Opsi (operatsiooni) meeskonna tehnilise arendusjuhina. Tahaksin rääkida meie Dev <-> Ops protsesside ülesehitusest, Venemaa ühe suurima k8s-klastri toimimise funktsioonidest ning meie meeskonna poolt rakendatavatest DevOps/SRE tavadest.
Opsi meeskond
Opsi meeskonnas on praegu 15 inimest. Kolm neist vastutavad kontori eest, kaks töötavad erinevas ajavööndis ja on saadaval ka öösel. Seega on keegi Opsist alati monitori juures ja valmis reageerima mis tahes keerukusega juhtumile. Meil ei ole öiseid vahetusi, mis säilitavad meie psüühika ja annavad igaühele võimaluse piisavalt magada ja veeta vaba aega mitte ainult arvuti taga.
Kõigil on erinevad kompetentsid: võrgutegijad, DBA-d, ELK stacki spetsialistid, Kubernetese administraatorid/arendajad, monitooring, virtualiseerimine, riistvaraspetsialistid jne. Üks asi ühendab kõiki – igaüks saab meist mingil määral asendada: näiteks tuua k8s-klastrisse uusi sõlmi, värskendada PostgreSQL-i, kirjutada CI/CD + Ansible torujuhe, automatiseerida midagi Pythonis/Bash/Gos, ühendada riistvara Andmekeskus. Tugevad kompetentsid ühelgi alal ei takista tegevussuunda muutmast ja mõnes muus valdkonnas ennast täiendamast. Näiteks liitusin ettevõttega PostgreSQL-i spetsialistina ja nüüd on minu peamiseks vastutusvaldkonnaks Kubernetese klastrid. Meeskonnas on teretulnud igasugune kõrgus ja võimendustunne on väga arenenud.
Muide, me jahime. Kandidaatidele esitatavad nõuded on üsna standardsed. Minu jaoks isiklikult on oluline, et inimene sobiks meeskonda, oleks konfliktivaba, aga oskaks ka oma seisukohta kaitsta, tahaks areneda ja ei karda midagi uut teha ning pakub oma ideid. Samuti on vajalik programmeerimisoskus skriptikeeltes, Linuxi ja inglise keele põhitõdede tundmine. Inglise keelt on vaja lihtsalt selleks, et inimene saaks fakapi korral guugeldada probleemile lahenduse 10 sekundiga, mitte 10 minutiga. Nüüd on väga raske leida Linuxi kohta sügavate teadmistega spetsialiste: see on naljakas, kuid kaks kolmest kandidaadist ei suuda vastata küsimusele „Mis on koormuse keskmine? Millest see tehtud on?“ ning küsimust „Kuidas C-programmist tuumpump kokku panna“ peetakse millekski supermeeste... ehk dinosauruste maailmast. Peame sellega leppima, kuna tavaliselt on inimestel kõrgelt arenenud muud kompetentsid, aga me õpetame Linuxit. Vastus küsimusele “miks peab DevOpsi insener seda kõike tänapäevases pilvemaailmas teadma” tuleb küll artikli ulatusest välja jätta, kuid kolme sõnaga: see kõik on vajalik.
Meeskonna tööriistad
Tööriistade meeskond mängib automatiseerimises olulist rolli. Nende peamine ülesanne on luua arendajatele mugavad graafilised ja CLI tööriistad. Näiteks võimaldab meie sisemine arendus Confer teil sõna otseses mõttes vaid mõne hiireklõpsuga Kubernetesesse rakendust levitada, konfigureerida selle ressursse, varahoidla võtmeid jne. Varem oli Jenkins + Helm 2, kuid ma pidin välja töötama oma tööriista, et kõrvaldada kopeerimine ja kleepimine ja tuua tarkvara elutsüklisse ühtlus.
Opsi meeskond ei kirjuta arendajatele torujuhtmeid, kuid võib anda nõu kõigis nende kirjutamise küsimustes (mõnel inimesel on endiselt Helm 3).
DevOps
Mis puutub DevOpsi, siis näeme seda järgmiselt:
Arendusmeeskonnad kirjutavad koodi, avaldavad selle kaudu Confer to dev -> qa/stage -> prod. Selle eest, et kood ei aeglustuks ega sisaldaks vigu, vastutavad arendus- ja operatsioonitiimid. Päevasel ajal peaks Ops-meeskonna valves olev inimene ennekõike oma rakendusega reageerima intsidendile ning õhtul ja öösel peaks valves olev administraator (Ops) äratama valves oleva arendaja, kui ta sellest teab. veenduge, et probleem ei ole infrastruktuuris. Kõik seire mõõdikud ja hoiatused kuvatakse automaatselt või poolautomaatselt.
Opsi vastutusala algab hetkest, kui rakendus on kasutusele võetud, kuid Devi vastutus sellega ei lõpe – me teeme sama asja ja oleme samas paadis.
Arendajad nõustavad administraatoreid, kui nad vajavad abi administraatori mikroteenuse kirjutamisel (nt Go backend + HTML5), ja administraatorid nõustavad arendajaid infrastruktuuri või k8-ga seotud probleemides.
Muide, meil pole üldse monoliiti, ainult mikroteenused. Nende arv kõigub prod k900s klastris 1000 ja 8 vahel, kui seda arvu järgi mõõta kasutuselevõtt. Kaunade arv kõigub 1700 ja 2000 vahel. Praegu on tooteklastris umbes 2000 kauna.
Täpseid numbreid ma anda ei oska, kuna jälgime mittevajalikke mikroteenuseid ja lõikame need poolautomaatselt välja. K8s aitab meil mittevajalike olemite üle arvet pidada , mis säästab palju ressursse ja raha.
Ressursside haldamine
Jälgimine
Hästi struktureeritud ja informatiivne monitooring saab suure klastri toimimise nurgakiviks. Me ei ole veel leidnud universaalset lahendust, mis kataks 100% kõigist seirevajadustest, mistõttu loome perioodiliselt selles keskkonnas erinevaid kohandatud lahendusi.
- Zabbix. Vana hea monitooring, mis on mõeldud eelkõige infrastruktuuri üldise seisukorra jälgimiseks. See ütleb meile, kui sõlm sureb töötlemise, mälu, ketaste, võrgu jms osas. Ei midagi üleloomulikku, aga meil on ka eraldi agentide DaemonSet, mille abil jälgime näiteks DNS-i seisu klastris: otsime lolle coredns podisid, kontrollime väliste hostide saadavust. Näib, et milleks sellega vaeva näha, kuid suure liiklusmahu korral on see komponent tõsine tõrkekoht. Ma juba , kuidas ma võitlesin klastris DNS-i jõudlusega.
- Prometheuse operaator. Erinevate eksportijate komplekt annab suure ülevaate kõigist klastri komponentidest. Järgmisena visualiseerime seda kõike Grafana suurtel armatuurlaudadel ja kasutame hoiatuste jaoks alertmanagerit.
Teine meie jaoks kasulik tööriist oli . Kirjutasime selle pärast seda, kui olime mitu korda kokku puutunud olukorraga, kus üks meeskond kattus teise meeskonna sisenemisteed, mille tulemuseks oli 50-kordsed vead. Nüüd kontrollivad arendajad enne tootmisse juurutamist, et see ei mõjutaks kedagi ja minu meeskonna jaoks on see hea tööriist Ingressesiga seotud probleemide esmaseks diagnoosimiseks. Naljakas on see, et algul oli see kirjutatud administraatoritele ja tundus üsna kohmakas, kuid pärast seda, kui arendajameeskonnad sellesse tööriista armusid, muutus see palju ja hakkas välja nägema mitte nagu "administraator tegi administraatoritele veebinäo". ” Varsti loobume sellest tööriistast ja sellised olukorrad valideeritakse juba enne torujuhtme kasutuselevõttu.
Meeskonna ressursid kuubis
Enne näidete juurde asumist tasub selgitada, kuidas me ressursse eraldame mikroteenused.
Et mõista, millised meeskonnad ja millistes kogustes oma kasutavad ресурсы (protsessor, mälu, kohalik SSD), eraldame iga käsu oma nimeruum “Kuubis” ja piirata selle maksimaalseid protsessori, mälu ja ketta võimalusi, olles eelnevalt meeskondade vajadused läbi arutanud. Sellest lähtuvalt ei blokeeri üks käsk üldiselt kogu klastrit juurutamiseks, eraldades tuhandeid südamikke ja terabaite mälu. Juurdepääs nimeruumile antakse AD kaudu (kasutame RBAC-i). Nimeruumid ja nende piirangud lisatakse tõmbepäringu kaudu GIT-i hoidlasse ja seejärel kuvatakse kõik automaatselt Ansible'i torustiku kaudu.
Näide meeskonnale ressursside eraldamisest:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Taotlused ja piirangud
kuubik" Küsi on garanteeritud reserveeritud ressursside arv kaun (üks või mitu dokkimiskonteinerit) klastris. Limiit on garanteerimata maksimum. Diagrammidel on sageli näha, kuidas mõni meeskond on seadnud endale liiga palju taotlusi kõigi oma rakenduste jaoks ega saa rakendust "Kuubis" juurutada, kuna kõik nende nimeruumi all olevad päringud on juba "kulutatud".
Õige väljapääs sellest olukorrast on vaadata tegelikku ressursitarbimist ja võrrelda seda taotletud summaga (Taotlus).
Ülaltoodud ekraanipiltidel näete, et taotletud protsessorid on sobitatud lõimede tegeliku arvuga ja piirangud võivad ületada protsessori lõimede tegeliku arvu =)
Vaatame nüüd mõnda nimeruumi üksikasjalikult (valisin nimeruumi kube-system - süsteemi nimeruumi "Cube" enda komponentide jaoks) ja vaatame tegelikult kasutatud protsessori aja ja mälu suhet nõutavasse:
On ilmne, et süsteemiteenuste jaoks on reserveeritud palju rohkem mälu ja protsessorit, kui seda tegelikult kasutatakse. Kube-süsteemi puhul on see õigustatud: juhtus, et nginx ingress controller või nodelocaldns oma tipus tabasid CPU-d ja kulutasid palju RAM-i, nii et siin on selline reserv õigustatud. Lisaks ei saa me tugineda viimase 3 tunni graafikutele: soovitav on näha ajaloolisi mõõdikuid pikema aja jooksul.
Töötati välja “soovituste” süsteem. Näiteks siin on näha, milliste ressursside puhul oleks parem “limiite” (ülemine lubatud riba) tõsta, et “drosselit” ei tekiks: hetk, mil ressurss on juba kulutanud CPU või mälu määratud ajalõikes ja ootab, kuni see "lahti külmutatakse":
Ja siin on kaunad, mis peaksid nende isusid ohjeldama:
edasi drossel + ressursside jälgimine, saate kirjutada rohkem kui ühe artikli, nii et küsige küsimusi kommentaarides. Mõne sõnaga võin öelda, et selliste mõõdikute automatiseerimine on väga keeruline ja nõuab palju aega ja tasakaalustamist “akna” funktsioonide ja “CTE” Prometheuse / VictoriaMetricsiga (need terminid on jutumärkides, kuna seal on peaaegu PromQL-is pole midagi sellist ja peate jagama hirmutavad päringud mitmeks tekstiekraaniks ja neid optimeerima).
Tänu sellele on arendajatel olemas tööriistad oma nimeruumide jälgimiseks Cube’is ning nad saavad ise valida, kus ja mis kellaaegadel milliste rakenduste ressursse “lõigata” ning millistele serveritele öö läbi terve CPU anda.
Metoodikad
Sellises seltskonnas nagu praegu moodne, järgime DevOps- ja SRE- praktik Kui ettevõttel on 1000 mikroteenust, umbes 350 arendajat ja 15 administraatorit kogu taristu jaoks, tuleb olla "moes": kõigi nende "basssõnade" taga on tungiv vajadus kõik ja kõik automatiseerida ning administraatorid ei tohiks olla kitsaskohaks. protsessides.
Opsina pakume arendajatele erinevaid mõõdikuid ja armatuurlaudu, mis on seotud teenuse reageerimise määra ja vigadega.
Kasutame selliseid metoodikaid nagu: , и neid omavahel kombineerides. Püüame minimeerida armatuurlaudade arvu, et ühe pilguga oleks selge, milline teenus parajasti halveneb (näiteks vastusekoodid sekundis, reageerimisaeg 99. protsentiili võrra) ja nii edasi. Niipea, kui üldiste armatuurlaudade jaoks on vaja uusi mõõdikuid, joonistame ja lisame need kohe.
Ma pole kuu aega graafikuid joonistanud. See on ilmselt hea märk: see tähendab, et enamik "soove" on juba ellu viidud. Juhtus nii, et nädala jooksul joonistasin vähemalt korra päevas mõne uue graafiku.
Saadud tulemus on väärtuslik, sest praegu pöörduvad arendajad üsna harva administraatorite poole küsimustega "kuhu vaadata mingit mõõdikut".
Rakendamine Teenindusvõrk on kohe nurga taga ja peaks kõigi elu oluliselt lihtsamaks muutma, kolleegid Toolsist on juba lähedal abstraktse “Terve inimese Istio” rakendamisele: iga HTTP(de) päringu elutsükkel on jälgimisel nähtav ja see talitustevahelise (ja mitte ainult) suhtluse käigus on alati võimalik aru saada, „mis etapis kõik katki läks”. Tellige uudised DomClicki keskusest. =)
Kubernetese infrastruktuuri tugi
Ajalooliselt kasutame paigatud versiooni Kubespray — Sobiv roll Kubernetese juurutamisel, laiendamisel ja värskendamisel. Mingil hetkel katkestati põhiharust mitte-kubeadmi installide tugi ja kubeadmile ülemineku protsessi ei pakutud. Selle tulemusel tegi Southbridge'i ettevõte oma kahvli (kubeadmi toega ja kriitiliste probleemide kiirparandusega).
Kõigi k8-klastrite värskendamise protsess näeb välja järgmine:
- Võtke Kubespray Southbridge'ist, uurige meie teemast, Merjim.
- Anname värskenduse välja Stress- "Kuup".
- Toome värskenduse välja üks sõlm korraga (Ansible puhul on see „serial: 1”) dev- "Kuup".
- Uuendame Prod laupäeva õhtul üks sõlm korraga.
Tulevikus on plaanis see välja vahetada Kubespray millegi kiirema jaoks ja minge edasi kubeadm.
Kokku on meil kolm “Kuubikut”: Stress, Dev ja Prod. Plaanime käivitada veel ühe (kuum ooterežiim) Prod-“Cube” teises andmekeskuses. Stress и dev elada "virtuaalsetes masinates" (oVirt for Stress ja VMWare cloud for Dev). Prod- "Cube" elab "paljast metallist": need on identsed sõlmed, millel on 32 protsessori keerme, 64-128 GB mälu ja 300 GB SSD RAID 10 - neid on kokku 50. Kolm "õhukest" sõlme on pühendatud "meistritele" Prod- "Kuuba": 16 GB mälu, 12 protsessori keerme.
Müügil eelistame kasutada "paljast metallist" ja vältida tarbetuid kihte nagu OpenStack: me ei vaja "mürarikkaid naabreid" ja protsessorit varastada aega. Ja haldamise keerukus kahekordistub majasisese OpenStacki puhul.
CI/CD “Cubic” ja muude infrastruktuuri komponentide jaoks kasutame eraldi GIT-serverit Helm 3 (see oli üsna valus üleminek Helm 2-st, kuid oleme valikutega väga rahul aatomi-), Jenkins, Ansible ja Docker. Meile meeldivad funktsioonide harud ja juurutamine erinevatesse keskkondadesse ühest hoidlast.
Järeldus
Üldiselt näeb DevOpsi protsess DomClickis välja operatsiooniinseneri vaatenurgast. Artikkel osutus oodatust vähem tehniliseks: seetõttu jälgige DomClicki uudiseid Habré lehel: Kubernetese ja muu kohta tuleb rohkem "kõva" artikleid.
Allikas: www.habr.com