Moje ime je Viktor Yagofarov i razvijam Kubernetes platformu u DomClicku kao voditelj tehničkog razvoja u Ops (operativnom) timu. Želio bih razgovarati o strukturi naših Dev <-> Ops procesa, značajkama rada jednog od najvećih k8s klastera u Rusiji, kao i DevOps/SRE praksi koje naš tim primjenjuje.
Operativni tim
Ops tim trenutno ima 15 ljudi. Troje ih je odgovorno za ured, dvoje rade u drugoj vremenskoj zoni i dostupni su, uključujući i noću. Tako je netko iz Opsa uvijek na monitoru i spreman odgovoriti na incident bilo koje složenosti. Nemamo noćne smjene, što čuva našu psihu i svima daje priliku da dovoljno spavaju i provode slobodno vrijeme ne samo za računalom.
Svatko ima različite kompetencije: mrežni stručnjaci, DBA-ovi, stručnjaci za ELK stog, Kubernetes administratori/programeri, stručnjaci za nadzor, virtualizaciju, hardverski stručnjaci itd. Jedna stvar ujedinjuje sve - svatko može zamijeniti bilo koga od nas u određenoj mjeri: na primjer, uvesti nove čvorove u k8s klaster, ažurirati PostgreSQL, napisati CI/CD + Ansible cjevovod, automatizirati nešto u Python/Bash/Go, spojiti hardver na Podatkovni centar. Jake kompetencije u bilo kojem području vas ne sprječavaju da promijenite smjer djelovanja i počnete se usavršavati u nekom drugom području. Na primjer, pridružio sam se tvrtki kao stručnjak za PostgreSQL, a sada su moje glavno područje odgovornosti Kubernetes klasteri. U timu je svaka visina dobrodošla, a osjećaj za moć je vrlo razvijen.
Usput, mi smo u lovu. Zahtjevi za kandidate su prilično standardni. Osobno mi je bitno da se osoba uklopi u tim, da je nekonfliktna, ali i da zna braniti svoje stajalište, da se želi razvijati i ne boji se raditi nešto novo, te nudi svoje ideje. Također, potrebne su vještine programiranja na skriptnim jezicima, poznavanje osnova Linuxa i engleskog jezika. Engleski je potreban jednostavno da bi čovjek u slučaju fakapa mogao guglati rješenje problema za 10 sekundi, a ne za 10 minuta. Sada je vrlo teško pronaći stručnjake s dubokim poznavanjem Linuxa: smiješno je, ali dva od tri kandidata ne mogu odgovoriti na pitanje "Što je prosječno opterećenje? Od čega je napravljen?”, a pitanje “Kako sastaviti core dump iz C programa” smatraju nečim iz svijeta supermena... ili dinosaura. Moramo se pomiriti s tim, jer obično ljudi imaju visoko razvijene druge kompetencije, ali mi ćemo podučavati Linux. Odgovor na pitanje “zašto DevOps inženjer mora sve to znati u modernom svijetu oblaka” morat ćemo ostaviti izvan okvira članka, ali u tri riječi: sve je to potrebno.
Timski alati
Tim alata igra značajnu ulogu u automatizaciji. Njihov glavni zadatak je stvoriti prikladne grafičke i CLI alate za programere. Na primjer, naš interni razvojni Confer omogućuje vam da doslovno uvedete aplikaciju u Kubernetes sa samo nekoliko klikova mišem, konfigurirate njezine resurse, ključeve iz trezora itd. Prethodno je postojao Jenkins + Helm 2, ali sam morao razviti vlastiti alat za uklanjanje copy-paste i ujednačavanje životnog ciklusa softvera.
Ops tim ne piše cjevovode za programere, ali može savjetovati o svim problemima u svom pisanju (neki ljudi još uvijek imaju Helm 3).
DevOps
Što se tiče DevOps-a, vidimo ga ovako:
Dev timovi pišu kod, puštaju ga putem Confer to dev -> qa/stage -> prod. Odgovornost za osiguranje da se kod ne usporava i ne sadrži pogreške leži na Dev i Ops timovima. Danju bi dežurni iz Ops tima trebao prije svega reagirati na incident sa svojom aplikacijom, a navečer i noću bi dežurni administrator (Ops) trebao probuditi dežurnog programera ako zna za sigurni da problem nije u infrastrukturi. Sve metrike i upozorenja u praćenju pojavljuju se automatski ili poluautomatski.
Područje odgovornosti Opsa počinje od trenutka kada je aplikacija uvedena u proizvodnju, ali odgovornost Deva tu ne prestaje - mi radimo istu stvar i u istom smo čamcu.
Programeri savjetuju administratore ako im je potrebna pomoć u pisanju administratorske mikrousluge (na primjer, Go backend + HTML5), a administratori savjetuju programere o svim infrastrukturnim problemima ili problemima povezanim s k8s.
Usput, mi uopće nemamo monolit, samo mikroservise. Njihov broj do sada varira između 900 i 1000 u klasteru prod k8s, ako se mjeri brojem raspoređivanja. Broj mahuna varira između 1700 i 2000. Trenutno postoji oko 2000 mahuna u proizvodnom klasteru.
Ne mogu dati točne brojke, jer pratimo nepotrebne mikroservise i izrezujemo ih poluautomatski. K8s nam pomaže pratiti nepotrebne entitete , što štedi mnogo resursa i novca.
Upravljanje resursima
nadgledanje
Dobro strukturirano i informativno praćenje postaje kamen temeljac u radu velikog klastera. Još uvijek nismo pronašli univerzalno rješenje koje bi pokrilo 100% svih potreba praćenja, stoga povremeno kreiramo različita prilagođena rješenja u ovom okruženju.
- Zabbix. Dobri stari monitoring, koji je prvenstveno namijenjen praćenju ukupnog stanja infrastrukture. Govori nam kada čvor umire u smislu obrade, memorije, diskova, mreže i tako dalje. Ništa nadnaravno, ali imamo i zaseban DaemonSet agenata, uz pomoć kojih, primjerice, pratimo stanje DNS-a u klasteru: tražimo glupe coredns podove, provjeravamo dostupnost vanjskih hostova. Čini se zašto se time zamarati, ali s velikim količinama prometa ova je komponenta ozbiljna točka kvara. ja već , kako sam se borio s performansama DNS-a u klasteru.
- Operater Prometej. Skup različitih izvoznika daje veliki pregled svih komponenti klastera. Zatim sve to vizualiziramo na velikim nadzornim pločama u Grafani, a za upozorenja koristimo alertmanager.
Još jedan koristan alat za nas bio je . Napisali smo to nakon što smo se nekoliko puta susreli sa situacijom u kojoj je jedan tim preklapao ulazne staze drugog tima, što je rezultiralo 50x greškama. Sada prije postavljanja u proizvodnju, programeri provjeravaju da nitko neće biti pogođen, a za moj tim ovo je dobar alat za početnu dijagnozu problema s Ingressesom. Smiješno je što je u početku bio napisan za administratore i izgledao je prilično “nespretno”, ali nakon što su se dev timovi zaljubili u alat, dosta se promijenio i počeo izgledati kao da je “admin napravio web lice za administratore. ” Uskoro ćemo napustiti ovaj alat i takve će situacije biti potvrđene čak i prije nego što se cjevovod pokrene.
Timski resursi u Cubeu
Prije nego što prijeđemo na primjere, vrijedi objasniti kako raspodjeljujemo resurse za mikrousluge.
Da biste razumjeli koji timovi iu kojim količinama koriste svoje resursi (procesor, memorija, lokalni SSD), svakoj naredbi dodjeljujemo svoju imenski prostor u “Cube” i ograničiti njegove maksimalne mogućnosti u pogledu procesora, memorije i diska, prethodno raspravivši potrebe timova. U skladu s tim, jedna naredba, općenito, neće blokirati cijeli klaster za implementaciju, dodjeljivanjem tisuća jezgri i terabajta memorije. Pristup imenskom prostoru omogućen je kroz AD (koristimo RBAC). Prostori imena i njihova ograničenja dodaju se putem zahtjeva za povlačenjem u GIT repozitorij, a zatim se sve automatski pokreće kroz Ansible cjevovod.
Primjer dodjele resursa timu:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Zahtjevi i ograničenja
kockica" Zatražite je broj zajamčenih rezerviranih resursa za mahuna (jedan ili više docker spremnika) u klasteru. Limit je nezajamčeni maksimum. Često možete vidjeti na grafovima kako si neki tim postavi previše zahtjeva za sve svoje aplikacije i ne može implementirati aplikaciju u “Cube”, jer su svi zahtjevi pod njihovim namespaceom već “potrošeni”.
Ispravan izlaz iz ove situacije je pogledati stvarnu potrošnju resursa i usporediti je sa traženom količinom (Zahtjev).
Na gornjim snimkama zaslona možete vidjeti da su “Traženi” CPU-i usklađeni sa stvarnim brojem niti, a ograničenja mogu premašiti stvarni broj CPU niti =)
Sada pogledajmo neki prostor imena u detalje (odabrao sam prostor naziva kube-system - sistemski prostor imena za komponente same "Cube") i vidimo omjer stvarno korištenog procesorskog vremena i memorije prema traženom:
Očito je da je puno više memorije i CPU-a rezervirano za usluge sustava nego što se zapravo koristi. U slučaju kube-sustava to je opravdano: dogodilo se da nginx ingress controller ili nodelocaldns na svom vrhuncu pogode CPU i troše puno RAM-a, pa je ovdje takva rezerva opravdana. Osim toga, ne možemo se osloniti na grafikone za posljednja 3 sata: poželjno je vidjeti povijesne metrike kroz dulje vremensko razdoblje.
Razvijen je sustav “preporuka”. Na primjer, ovdje možete vidjeti za koje bi resurse bilo bolje podići "ograničenja" (gornja dopuštena traka) kako ne bi došlo do "prigušivanja": trenutak kada je resurs već potrošio CPU ili memoriju u dodijeljenom vremenskom odsječku i čeka da se “odmrzne”:
A evo i mahuna koje bi im trebale obuzdati apetit:
na prigušivanje + praćenje resursa, možete napisati više od jednog članka, pa postavljajte pitanja u komentarima. U nekoliko riječi, mogu reći da je zadatak automatizacije takvih metrika vrlo težak i zahtijeva puno vremena i balansiranja s funkcijama "prozora" i "CTE" Prometheus / VictoriaMetrics (ovi pojmovi su pod navodnicima, jer postoji gotovo ništa slično u PromQL-u, a strašne upite morate podijeliti na nekoliko ekrana teksta i optimizirati ih).
Kao rezultat toga, programeri imaju alate za nadgledanje svojih imenskih prostora u Cubeu i mogu sami birati gdje i u koje vrijeme kojim aplikacijama se resursi mogu "srezati", a kojim se poslužiteljima može dati cijeli CPU cijelu noć.
Metodologije
U firmi kakva je sada moderan, pridržavamo se DevOps-a SRE-praktičar Kad tvrtka ima 1000 mikroservisa, oko 350 developera i 15 admina za cijelu infrastrukturu, morate “biti moderni”: iza svih tih “bazova” krije se hitna potreba za automatizacijom svega i svakoga, a admini ne bi trebali biti usko grlo u procesima.
Kao Ops, pružamo različite metrike i nadzorne ploče za programere u vezi sa stopama odgovora usluge i pogreškama.
Koristimo metodologije kao što su: , и njihovim kombiniranjem. Pokušavamo minimizirati broj nadzornih ploča kako bi na prvi pogled bilo jasno koja je usluga trenutno degradirana (na primjer, kodovi odgovora u sekundi, vrijeme odgovora za 99. percentil), i tako dalje. Čim neke nove metrike postanu potrebne za opće nadzorne ploče, odmah ih crtamo i dodajemo.
Nisam crtao grafikone mjesec dana. Ovo je vjerojatno dobar znak: znači da je većina “želja” već ostvarena. Dešavalo se da tijekom tjedna barem jednom dnevno nacrtam neki novi grafikon.
Dobiveni rezultat je vrijedan jer sada programeri prilično rijetko odlaze administratorima s pitanjem "gdje pogledati neku vrstu metrike."
uvođenje Servisna mreža je pred vratima i trebao bi svima uvelike olakšati život, kolege iz Toolsa već su blizu implementacije apstraktnog “Istija zdrave osobe”: životni ciklus svakog HTTP(s) zahtjeva bit će vidljiv u praćenju, a uvijek će biti moguće razumjeti "u kojoj je fazi sve puklo" tijekom interakcije između usluga (i ne samo). Pretplatite se na vijesti iz DomClick huba. =)
Podrška za Kubernetes infrastrukturu
Povijesno gledano, koristimo zakrpanu verziju Kubespray — Ansible uloga za implementaciju, proširenje i ažuriranje Kubernetesa. U nekom trenutku, podrška za ne-kubeadm instalacije prekinuta je iz glavne grane, a postupak prelaska na kubeadm nije predložen. Kao rezultat toga, tvrtka Southbridge napravila je vlastitu vilicu (s kubeadm podrškom i brzim rješenjem za kritične probleme).
Proces ažuriranja svih k8s klastera izgleda ovako:
- uzeti Kubespray iz Southbridgea, provjerite s našom temom, Merjim.
- Uvodimo ažuriranje za Stres- "Kocka".
- Uvodimo ažuriranje jedan po jedan čvor (u Ansibleu to je "serijski: 1") u dev- "Kocka".
- Mi ažuriramo Podsticaj u subotu navečer jedan po jedan čvor.
Postoje planovi za njegovu zamjenu u budućnosti Kubespray za nešto brže i otići na kubeadm.
Ukupno imamo tri “kocke”: Stress, Dev i Prod. Planiramo pokrenuti još jedan (vruće stanje pripravnosti) Prod-“Cube” u drugom podatkovnom centru. Stres и dev žive u “virtualnim strojevima” (oVirt za Stress i VMWare cloud za Dev). Podsticaj- “Cube” živi na “golom metalu”: to su identični čvorovi s 32 CPU niti, 64-128 GB memorije i 300 GB SSD RAID 10 - ima ih ukupno 50. Tri "tanka" čvora posvećena su "majstorima" Podsticaj- “Kuba”: 16 GB memorije, 12 CPU niti.
Za prodaju radije koristimo "goli metal" i izbjegavamo nepotrebne slojeve poput OpenStack: ne trebaju nam "bučni susjedi" i CPU ukrasti vrijeme. A složenost administracije otprilike se udvostručuje u slučaju vlastitog OpenStacka.
Za CI/CD “Cubic” i druge infrastrukturne komponente koristimo zasebni GIT poslužitelj, Helm 3 (bio je to prilično bolan prijelaz s Helma 2, ali jako smo zadovoljni opcijama atomski), Jenkins, Ansible i Docker. Volimo ogranke značajki i implementaciju u različita okruženja iz jednog repozitorija.
Zaključak
Općenito govoreći, ovako izgleda DevOps proces u DomClicku iz perspektive operativnog inženjera. Pokazalo se da je članak manje tehnički nego što sam očekivao: stoga pratite vijesti o DomClicku na Habréu: bit će još "hardcore" članaka o Kubernetesu i više.
Izvor: www.habr.com