Mano vardas Viktoras Yagofarovas, kuriu Kubernetes platformą DomClick kaip techninės plėtros vadovas Ops (operacijos) komandoje. Norėčiau pakalbėti apie mūsų Dev <-> Ops procesų struktūrą, vieno didžiausių k8 klasterių Rusijoje veikimo ypatumus, taip pat mūsų komandos taikomą DevOps/SRE praktiką.
Operacijų komanda
„Ops“ komandą šiuo metu sudaro 15 žmonių. Trys iš jų yra atsakingi už biurą, du dirba kitoje laiko juostoje ir yra pasiekiami, taip pat ir naktį. Taigi kažkas iš „Ops“ visada yra prie monitoriaus ir pasiruošęs reaguoti į bet kokio sudėtingumo incidentą. Pas mus nėra naktinių pamainų, kurios išsaugo mūsų psichiką ir kiekvienam suteikia galimybę pakankamai išsimiegoti ir leisti laisvalaikį ne tik prie kompiuterio.
Kiekvienas turi skirtingas kompetencijas: tinklų kūrėjai, DBA, ELK stack specialistai, Kubernetes administratoriai / kūrėjai, stebėjimo, virtualizacijos, techninės įrangos specialistai ir kt. Vienas dalykas visus vienija – kiekvienas gali kažkiek pakeisti bet kurį iš mūsų: pavyzdžiui, įvesti naujus mazgus į k8s klasterį, atnaujinti PostgreSQL, parašyti CI/CD + Ansible dujotiekį, automatizuoti kažką Python/Bash/Go, prijungti aparatūrą prie Duomenų centras. Stiprios kompetencijos bet kurioje srityje netrukdo keisti veiklos krypties ir pradėti tobulėti kokioje nors kitoje srityje. Pavyzdžiui, aš prisijungiau prie įmonės kaip „PostgreSQL“ specialistas, o dabar pagrindinė mano atsakomybės sritis yra „Kubernetes“ klasteriai. Komandoje bet koks ūgis yra sveikintinas, o sverto jausmas labai išvystytas.
Beje, mes medžiojame. Reikalavimai kandidatams yra gana standartiniai. Man asmeniškai svarbu, kad žmogus įsilietų į kolektyvą, būtų nekonfliktiškas, bet ir mokėtų apginti savo požiūrį, norėtų tobulėti ir nebijotų daryti kažko naujo, siūlytų savo idėjas. Taip pat būtini programavimo įgūdžiai skriptų kalbomis, Linux ir anglų kalbos pagrindų žinios. Anglų kalbos reikia tiesiog tam, kad žmogus, įvykus fakapui, galėtų per 10 sekundžių, o ne per 10 minučių, google surasti problemos sprendimą. Dabar labai sunku rasti specialistų, turinčių gilių Linux žinių: juokinga, bet du iš trijų kandidatų negali atsakyti į klausimą „Kas yra vidutinė apkrova? Iš ko jis pagamintas?“, o klausimas „Kaip surinkti branduolį iš C programos“ yra laikomas kažkuo iš antžmogių... arba dinozaurų pasaulio. Turime su tuo susitaikyti, nes paprastai žmonės turi labai išvystytas kitas kompetencijas, bet mes išmokysime Linux. Atsakymas į klausimą „kodėl DevOps inžinieriui visa tai reikia žinoti šiuolaikiniame debesų pasaulyje“ teks palikti už straipsnio ribų, tačiau trimis žodžiais: viso to reikia.
Komandos įrankiai
Įrankių komanda atlieka svarbų vaidmenį automatizuojant. Pagrindinė jų užduotis – sukurti patogius grafinius ir CLI įrankius kūrėjams. Pavyzdžiui, mūsų vidinė plėtra Confer leidžia tiesiog keliais pelės paspaudimais paleisti programą Kubernetes, sukonfigūruoti jos išteklius, raktus iš saugyklos ir kt. Anksčiau buvo Jenkins + Helm 2, bet turėjau sukurti savo įrankį, kad pašalinčiau kopijavimą ir įklijavimą ir programinės įrangos gyvavimo ciklą suvienodinčiau.
„Ops“ komanda nerašo konvejerių kūrėjams, tačiau gali patarti visais rašymo klausimais (kai kurie žmonės vis dar turi „Helm 3“).
DevOps
Kalbant apie „DevOps“, tai matome taip:
Kūrėjų komandos rašo kodą, išleidžia jį per Confer to dev -> qa/stage -> prod. Atsakomybė už tai, kad kodas nesulėtėtų ir jame nebūtų klaidų, tenka kūrėjų ir operacijų komandoms. Dieną budintis asmuo iš Ops komandos pirmiausia turėtų atsakyti į incidentą savo paraiška, o vakare ir naktį budintis administratorius (Ops) turėtų pažadinti budintį kūrėją, jei žino įsitikinkite, kad problema ne infrastruktūroje. Visi stebėjimo rodikliai ir įspėjimai rodomi automatiškai arba pusiau automatiškai.
Ops atsakomybės sritis prasideda nuo to momento, kai programa pradedama gaminti, tačiau Dev atsakomybė tuo nesibaigia – mes darome tą patį ir esame toje pačioje valtyje.
Kūrėjai pataria administratoriams, jei jiems reikia pagalbos rašant administratoriaus mikropaslaugą (pavyzdžiui, Go backend + HTML5), o administratoriai pataria kūrėjams bet kokiais infrastruktūros ar su k8s susijusiais klausimais.
Beje, monolito visai neturime, tik mikroservisus. Jų skaičius iki šiol svyruoja tarp 900 ir 1000 prod k8s klasteryje, jei matuojamas pagal skaičių dislokacijos. Ankštarų skaičius svyruoja nuo 1700 iki 2000. Šiuo metu produktų klasteryje yra apie 2000 ankštarų.
Tikslių skaičių pateikti negaliu, nes mes stebime nereikalingas mikropaslaugas ir jas išpjauname pusiau automatiškai. K8s padeda mums sekti nereikalingus objektus , kuris sutaupo daug išteklių ir pinigų.
Resursu valdymas
Stebėjimas
Gerai struktūrizuotas ir informatyvus stebėjimas tampa kertiniu didelio klasterio veiklos akmeniu. Kol kas neradome universalaus sprendimo, kuris patenkintų 100% visų stebėjimo poreikių, todėl šioje aplinkoje periodiškai kuriame skirtingus individualius sprendimus.
- Zabbix. Senas geras monitoringas, kuris visų pirma skirtas bendrai infrastruktūros būklei sekti. Tai mums praneša, kada mazgas miršta apdorojimo, atminties, diskų, tinklo ir pan. Nieko antgamtiško, bet turime ir atskirą agentų DaemonSet, kurio pagalba, pavyzdžiui, stebime DNS būseną klasteryje: ieškome kvailų coredns podų, tikriname išorinių hostų prieinamumą. Atrodytų, kam dėl to nerimauti, tačiau esant dideliam srautui, šis komponentas yra rimta gedimo vieta. Aš jau , kaip aš kovojau su DNS našumu klasteryje.
- Prometėjas operatorius. Įvairių eksportuotojų rinkinys suteikia didelę visų klasterio komponentų apžvalgą. Toliau visa tai vizualizuojame didelėse „Grafana“ prietaisų skydeliuose ir įspėjimams naudojame „alertmanager“.
Kitas mums naudingas įrankis buvo . Parašėme jį po to, kai kelis kartus susidūrėme su situacija, kai viena komanda sutampa su kitos komandos įėjimo keliais, todėl klaidų buvo 50 kartų. Dabar, prieš diegdami į gamybą, kūrėjai patikrina, ar niekas nebus paveiktas, o mano komandai tai yra geras įrankis pradinei „Ingresses“ problemų diagnostikai. Juokinga, kad iš pradžių jis buvo skirtas administratoriams ir atrodė gana „gremėzdiškas“, tačiau kūrėjų komandoms įsimylėjus įrankį, jis labai pasikeitė ir pradėjo atrodyti ne taip, kaip „adminas padarė žiniatinklio veidą administratoriams. “ Netrukus atsisakysime šio įrankio ir tokios situacijos bus patvirtintos dar prieš pradedant eksploatuoti dujotiekį.
Komandos ištekliai kube
Prieš pereinant prie pavyzdžių, verta paaiškinti, kaip paskirstome išteklius mikropaslaugos.
Suprasti, kurios komandos ir kokiais kiekiais naudoja savo išteklių (procesorius, atmintis, vietinis SSD), kiekvienai komandai skiriame savo vardų sritis „Kube“ ir apriboti jo maksimalias galimybes procesoriaus, atminties ir disko atžvilgiu, prieš tai aptarę komandų poreikius. Atitinkamai, viena komanda apskritai neužblokuos viso klasterio diegimui, paskirdama tūkstančius branduolių ir terabaitų atminties. Prieiga prie vardų erdvės suteikiama per AD (naudojame RBAC). Vardų erdvės ir jų ribos įtraukiamos į GIT saugyklą per ištraukimo užklausą, o tada viskas automatiškai išleidžiama per Ansible dujotiekį.
Išteklių paskirstymo komandai pavyzdys:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Prašymai ir limitai
kubeliais" Prašymas yra garantuotų rezervuotų išteklių skaičius su (vienas ar daugiau doko konteinerių) grupėje. Limitas yra negarantuotas maksimumas. Grafikuose dažnai galite pamatyti, kaip kai kuri komanda nustatė sau per daug užklausų visoms savo programoms ir negali įdiegti programos į „Kubą“, nes visos užklausos pagal jų vardų sritį jau buvo „išleistos“.
Teisinga išeitis iš šios situacijos yra pažvelgti į faktinį išteklių suvartojimą ir palyginti jį su prašoma suma (Užklausa).
Aukščiau pateiktose ekrano kopijose matote, kad „Prašyti“ CPU yra suderinti su tikruoju gijų skaičiumi, o ribos gali viršyti tikrąjį procesoriaus gijų skaičių =)
Dabar pažvelkime į kai kurias vardų sritis išsamiai (aš pasirinkau vardų sritį kube-system - sistemos vardų erdvę pačiam „Kubo“ komponentams) ir pamatysime faktiškai naudojamo procesoriaus laiko ir atminties santykį su prašoma:
Akivaizdu, kad sistemos paslaugoms rezervuota daug daugiau atminties ir procesoriaus, nei iš tikrųjų naudojama. Kube-sistemos atveju tai pateisinama: atsitiko, kad nginx ingress controller arba nodelocaldns savo piko metu pataikė į CPU ir sunaudojo daug RAM, todėl čia toks rezervas yra pateisinamas. Be to, negalime pasikliauti pastarųjų 3 valandų diagramomis: pageidautina matyti istorinę metriką per ilgą laikotarpį.
Buvo sukurta „rekomendacijų“ sistema. Pavyzdžiui, čia galite pamatyti, kuriems ištekliams būtų geriau pakelti "ribas" (viršutinę leistiną juostą), kad nebūtų "droselių": momentas, kai resursas jau išeikvoja procesorių arba atmintį tam skirtoje laiko dalyje ir laukia, kol bus „atšaldytas“:
O štai ankštys turėtų pažaboti jų apetitą:
apie droselis + išteklių stebėjimas, galite parašyti daugiau nei vieną straipsnį, todėl užduokite klausimus komentaruose. Keliais žodžiais galiu pasakyti, kad tokios metrikos automatizavimo užduotis yra labai sudėtinga ir reikalauja daug laiko bei subalansavimo su „lango“ funkcijomis ir „CTE“ Prometheus / VictoriaMetrics (šie terminai yra kabutėse, nes yra beveik nieko panašaus PromQL, ir jūs turite suskirstyti bauginančias užklausas į kelis teksto ekranus ir jas optimizuoti).
Dėl to kūrėjai turi įrankius savo vardų erdvėms stebėti Cube ir gali patys pasirinkti, kur ir kokiu metu programoms gali būti „nukirpti“ ištekliai ir kuriems serveriams visą naktį gali būti suteiktas visas CPU.
Metodikos
Įmonėje, kokia yra dabar madinga, laikomės DevOps- ir SRE-praktikas Kai įmonė turi 1000 mikropaslaugų, apie 350 kūrėjų ir 15 administratorių visai infrastruktūrai, turi „būti madingas“: už visų šių „baisžodžių“ slypi skubi būtinybė viską ir visus automatizuoti, o administratoriai neturėtų būti kliūtis. procesuose.
Kaip „Ops“, kūrėjams teikiame įvairias metrikas ir informacijos suvestines, susijusias su paslaugų atsakymų dažniu ir klaidomis.
Mes naudojame tokias metodikas kaip: , и juos derinant kartu. Stengiamės sumažinti prietaisų skydelių skaičių, kad iš pirmo žvilgsnio būtų aišku, kuri paslauga šiuo metu degraduoja (pvz., atsako kodai per sekundę, atsako laikas 99 procentiliu) ir pan. Kai tik prireikia naujų bendrųjų prietaisų skydelių metrikų, iškart jas nubraižome ir pridedame.
Grafikų nebraižau jau mėnesį. Tai tikriausiai geras ženklas: tai reiškia, kad dauguma „norų“ jau buvo įgyvendinti. Taip atsitiko, kad per savaitę bent kartą per dieną nubraižydavau kokį nors naują grafiką.
Gautas rezultatas yra vertingas, nes dabar kūrėjai gana retai kreipiasi į administratorius su klausimais „kur pažvelgti į kokią nors metriką“.
Įgyvendinimas Serviso tinklelis yra visai šalia ir turėtų palengvinti gyvenimą visiems, kolegos iš Tools jau yra arti abstrakčios „Sveiko žmogaus Istio“ įgyvendinimo: kiekvienos HTTP (-ų) užklausos gyvavimo ciklas bus matomas stebint, ir visada bus galima suprasti, „kuriame etape viskas sugedo“ tarnybų (ir ne tik) sąveikos metu. Prenumeruokite naujienas iš DomClick centro. =)
Kubernetes infrastruktūros palaikymas
Istoriškai mes naudojame pataisytą versiją Kubespray — Tinkamas vaidmuo diegiant, plečiant ir atnaujinant Kubernetes. Tam tikru momentu parama ne kubeadm įrenginiams buvo nutraukta iš pagrindinės šakos, o perėjimo prie kubeadm procesas nebuvo pasiūlytas. Dėl to „Southbridge“ įmonė sukūrė savo šakę (su „kubeadm“ palaikymu ir greitu kritinių problemų sprendimu).
Visų k8s grupių atnaujinimo procesas atrodo taip:
- Paimkime Kubespray iš Southbridge, patikrinkite mūsų siūlą, Merjim.
- Išleidžiame naujinimą į Stresas- "Kubas".
- Atnaujinimą išleidžiame po vieną mazgą (Ansible tai yra „serijinis: 1“). dev- "Kubas".
- Mes atnaujiname Bakstelėjimas šeštadienio vakarą po vieną mazgą.
Ateityje planuojama jį pakeisti Kubespray ko nors greičiau ir eikite į kubeadm.
Iš viso turime tris „kubus“: Stresą, Dev ir Prod. Planuojame paleisti dar vieną (karštas budėjimo režimas) Prod-"Cube" antrajame duomenų centre. Stresas и dev gyvena „virtualiose mašinose“ („oVirt for Stress“ ir „VMWare cloud“, skirta „Dev“). Bakstelėjimas- „Kubas“ gyvena ant „pliku metalo“: tai identiški mazgai su 32 procesoriaus gijomis, 64–128 GB atminties ir 300 GB SSD RAID 10 – iš viso jų yra 50. Trys „ploni“ mazgai yra skirti „šeimininkams“ Bakstelėjimas- „Kuba“: 16 GB atminties, 12 procesoriaus gijų.
Parduodant mes norime naudoti „pliką metalą“ ir vengti nereikalingų sluoksnių, pvz OpenStack: mums nereikia „triukšmingų kaimynų“ ir procesoriaus vogti laiką. O vidinio OpenStack atveju administravimo sudėtingumas padvigubėja.
CI/CD „Cubic“ ir kitiems infrastruktūros komponentams naudojame atskirą GIT serverį „Helm 3“ (tai buvo gana skausmingas perėjimas nuo „Helm 2“, bet mes labai patenkinti pasirinkimais atominis), Jenkins, Ansible ir Docker. Mums patinka funkcijų filialai ir diegimas įvairiose aplinkose iš vienos saugyklos.
išvada
Apskritai taip atrodo „DevOps“ procesas „DomClick“ operacijų inžinieriaus požiūriu. Straipsnis pasirodė ne toks techninis, kaip tikėjausi: todėl sekite „DomClick“ naujienas Habré: bus daugiau „kietųjų“ straipsnių apie Kubernetes ir dar daugiau.
Šaltinis: www.habr.com