Moje ime je Viktor Yagofarov i razvijam Kubernetes platformu u DomClick-u kao menadžer tehničkog razvoja u Ops (operativnom) timu. Želio bih da vam ispričam o strukturi naših Dev <-> Ops procesa, o karakteristikama rada jednog od najvećih k8s klastera u Rusiji, kao io DevOps / SRE praksama koje naš tim koristi.
Team Ops
Operativni tim trenutno broji 15 ljudi. Troje od njih je odgovorno za kancelariju, dvoje rade u drugoj vremenskoj zoni i dostupni su, uključujući i noću. Tako je neko iz Ops-a uvijek na monitoru i spreman je odgovoriti na incident bilo koje složenosti. Nemamo noćne smjene, što čuva naš mentalitet i daje svima mogućnost da se dovoljno naspaju i slobodno vrijeme provedu ne samo za kompjuterom.
Svi imaju različite kompetencije: mrežni stručnjaci, DBA, stručnjaci za ELK stack, Kubernetes administratori / programeri, nadzor, virtuelizacija, stručnjaci za hardver, itd. Jedna stvar ujedinjuje sve - svako može u određenoj mjeri zamijeniti bilo koga od nas: na primjer, uvesti nove čvorove u k8s klaster, ažurirati PostgreSQL, napisati CI / CD + Ansible pipeline, automatizirati nešto u Python / Bash / Go, povezati komad hardvera na DPC. Jake kompetencije u bilo kojoj oblasti ne ometaju promjenu smjera aktivnosti i početak rada u nekoj drugoj oblasti. Na primjer, dobio sam posao u kompaniji kao stručnjak za PostgreSQL, a sada su moja glavna oblast odgovornosti Kubernetes klasteri. U timu je svaki rast samo dobrodošao i osećaj za rame je veoma razvijen.
Usput, lovimo. Uslovi za kandidate su prilično standardni. Meni lično je važno da se osoba uklopi u tim, da je nekonfliktna, ali i da ume da brani svoje gledište, da želi da se razvija i da se ne plaši da uradi nešto novo, da ponudi svoje ideje. Također, potrebne su vještine programiranja u skript jezicima, poznavanje osnova Linuxa i engleskog jezika. Engleski je potreban samo da bi osoba u slučaju fakapa proguglala rješenje problema za 10 sekundi, a ne za 10 minuta. Sa stručnjacima s dubokim poznavanjem Linuxa, to je sada vrlo teško: smiješno, ali dva od tri kandidata ne mogu odgovoriti na pitanje „Šta je prosjek opterećenja? Od čega se sastoji?", A pitanje" Kako prikupiti jezgro iz programa sish "smatra se nečim iz svijeta nadljudi ... ili dinosaura. Moramo da se pomirimo s tim, pošto ljudi obično imaju visoko razvijene druge kompetencije, a mi ćemo predavati Linux. Odgovor na pitanje „zašto DevOps inženjer treba da zna sve ovo u savremenom svetu oblaka“ moraće da ostane van okvira članka, ali u tri reči: sve je to neophodno.
Naredba alata
Tim Tools igra značajnu ulogu u automatizaciji. Njihov glavni zadatak je kreiranje praktičnih grafičkih i CLI alata za programere. Na primjer, naš interni razvoj Confera omogućava vam da uvedete aplikaciju u Kubernetes sa samo nekoliko klikova mišem, konfigurirate njene resurse, ključeve iz trezora itd. Nekada je postojao Jenkins + Helm 2, ali sam morao da razvijem sopstveni alat da eliminišem copy-paste i unesem uniformnost u životni ciklus softvera.
Ops tim ne piše kanale za programere, ali može savjetovati o svim problemima u njihovom pisanju (neki još uvijek imaju Helm 3).
DevOps
Što se tiče DevOps-a, vidimo ga ovako:
Dev timovi pišu kod, izbacuju ga preko Confer to dev -> qa/stage -> prod. Odgovornost je Dev i Ops timova da osiguraju da se kod ne usporava i ne stvara greške. Danju, dežurni iz Ops tima treba da odgovori na incident svojom aplikacijom, a uveče i noću dežurni administrator (Ops) treba da probudi dežurnog programera ako sigurno zna da problem nije u infrastrukturi. Sve metrike i upozorenja u praćenju pojavljuju se automatski ili poluautomatski.
Područje odgovornosti Ops-a počinje od trenutka kada je aplikacija puštena u produkciju, ali odgovornost Dev-a tu ne prestaje - radimo jednu stvar i u istom smo čamcu.
Programeri savjetuju administratore ako im je potrebna pomoć pri pisanju admin mikroservisa (na primjer, Go backend + HTML5), a administratori savjetuju programere o svim problemima vezanim za infrastrukturu ili k8s.
Inače, mi uopšte nemamo monolit, već samo mikroservise. Njihov broj do sada varira između 900 i 1000 u grupi prod k8s, ako se mjeri brojem raspoređivanje. Broj mahuna varira između 1700 i 2000. Mahuna u grozdovima sadnica je oko 2000.
Ne mogu dati tačne brojke, jer pratimo nepotrebne mikroservise i izrezujemo ih u poluautomatskom režimu. Praćenje nepotrebnih entiteta u k8s nam pomaže što štedi resurse i novac.
Upravljanje resursima
Monitoring
Kompetentno izgrađen i informativan monitoring postaje kamen temeljac u radu velikog klastera. Još nismo pronašli univerzalno rješenje koje bi pokrilo 100% svih potreba za praćenjem, pa periodično zakivamo različita prilagođena rješenja u ovom okruženju.
- Zabbix. Stari dobri monitoring, koji je prvenstveno dizajniran za praćenje ukupnog stanja infrastrukture. Govori nam kada čvor umre po procesoru, memoriji, diskovima, mreži itd. Ništa natprirodno, ali imamo i poseban DaemonSet agenata, uz pomoć kojih, na primjer, pratimo DNS stanje u klasteru: tražimo glupe coredns podove, provjeravamo dostupnost vanjskih hostova. Čini se da zašto da se mučite zbog toga, ali na velikim količinama saobraćaja ova komponenta predstavlja ozbiljnu tačku kvara. Ranije jesam kako se borio sa performansama DNS-a u klasteru.
- Prometheus Operator. Skup različitih izvoznika daje sjajan pregled svih komponenti klastera. Zatim sve ovo vizualiziramo na velikim kontrolnim pločama u Grafani i koristimo alertmanager za obavijesti.
Još jedan koristan alat za nas je . Napisali smo to nakon što smo nekoliko puta naišli na situaciju da je jedan tim svojim putanjama preklapao Ingress drugog tima, što je uzrokovalo 50x grešaka. Sada, prije implementacije u produkciju, programeri provjeravaju da neće nikoga povrijediti, a za moj tim je ovo dobar alat za početnu dijagnozu problema sa Ingresses-ima. Smiješno je što je isprva pisana za administratore i izgledala je prilično “nezgrapno”, ali nakon što su se dev timovi zaljubili u alat, dosta se promijenio i počeo da ne izgleda kao da je “admin napravio web lice za administratore” . Uskoro ćemo napustiti ovaj alat i takve situacije će biti potvrđene čak i prije nego što plinovod bude pokrenut.
Timski resursi u "Cube"
Prije nego što nastavimo s primjerima, vrijedno je objasniti kako imamo alokaciju resursa mikrousluge.
Da shvatite koji timovi i u kojim količinama ih koriste resursa (procesor, memorija, lokalni SSD), sami dodjeljujemo namespace u "Cube" i ograničiti njegove maksimalne mogućnosti u pogledu procesora, memorije i diska, nakon što smo prethodno razgovarali o potrebama timova. Shodno tome, jedna naredba, u opštem slučaju, neće blokirati cijeli klaster za implementaciju, dodjeljujući hiljade jezgri i terabajta memorije za sebe. Pristup imenskom prostoru se izdaje preko AD (koristimo RBAC). Prostori imena i njihova ograničenja se dodaju putem zahtjeva za povlačenjem u GIT spremište, a zatim se sve automatski izbacuje putem Ansible pipeline-a.
Primjer raspodjele resursa po timu:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Zahtjevi i ograničenja
kockasto" zahtjev je broj zagarantovanih rezervisanih resursa pod pod (jedan ili više docker kontejnera) u klasteru. Limit je nezagarantovani maksimum. Često možete vidjeti na grafikonima kako je neki tim sebi postavio previše zahtjeva za sve svoje aplikacije i ne može primijeniti aplikaciju na "Kocku", jer su pod njihovim imenskim prostorom svi zahtjevi već "potrošeni".
Ispravan izlaz iz ove situacije je da se pogleda stvarna potrošnja resursa i uporedi sa traženim iznosom (Zahtjev).
Gornji snimci ekrana pokazuju da su "zatraženi" (zatraženi) CPU-ovi odabrani na pravi broj niti, a ograničenja mogu premašiti stvarni broj CPU-ova =)
Sada pogledajmo pobliže neki imenski prostor (ja sam izabrao imenski prostor kube-system - sistemski imenski prostor za komponente same "Kocke") i vidimo omjer stvarno korištenog vremena procesora i memorije prema traženom:
Očigledno je da je za sistemske usluge rezervisano mnogo više memorije i CPU-a nego što se stvarno koristi. U slučaju kube-sistema, ovo je opravdano: desilo se da nginx ingress kontroler ili nodelocaldns na vrhuncu počivaju na CPU-u i pojedu mnogo RAM-a, pa je ovdje takva margina opravdana. Osim toga, ne možemo se osloniti na grafikone za posljednja 3 sata: poželjno je vidjeti istorijske metrike u dužem vremenskom periodu.
Razvijen je sistem "preporuka". Na primjer, ovdje možete vidjeti za koje resurse bi bilo bolje da se podignu "ograničenja" (gornja dozvoljena traka) kako ne bi došlo do "prigušenja": trenutak kada je pod već potrošio CPU ili memoriju za dodijeljeni kvantni vremenski period i čeka da se "odmrzne":
A evo i mahuna koje bi im trebale ublažiti apetit:
na prigušivanje + resursi za praćenje, možete napisati više od jednog članka, pa postavljajte pitanja u komentarima. U nekoliko riječi, mogu reći da je zadatak automatizacije ovakvih metrika vrlo težak i zahtijeva puno vremena i balansiranja sa „prozorskim“ funkcijama i „CTE“ Prometheus / VictoriaMetrics (ovi pojmovi su pod navodnicima, jer postoji skoro ništa slično ovome u PromQL-u, i morate ograđivati zastrašujuće upite na nekoliko ekrana teksta i optimizirati ih).
Kao rezultat toga, programeri imaju alate za nadgledanje svojih imenskih prostora u "Cube", i oni su u mogućnosti da odaberu gdje i u koje vrijeme koje aplikacije mogu "rezati" resurse, a kojim podovima se može dati cijeli CPU cijelu noć.
Metodologije
U društvu kao sada moderan, pridržavamo se DevOps- i SRE-praktičar Kada kompanija ima 1000 mikroservisa, oko 350 programera i 15 administratora za cjelokupnu infrastrukturu, morate biti "moderni": iza svih ovih "buzzwords" krije se hitna potreba za automatizacijom svega i svačega, a administratori ne bi trebali biti usko grlo u procesima.
Kao Ops, pružamo različite metrike i kontrolne ploče za programere u vezi sa brzinom odgovora usluge i greškama u usluzi.
Koristimo metodologije kao što su: , и njihovim kombinovanjem. Pokušavamo da minimiziramo broj nadzornih ploča tako da na prvi pogled bude jasno koja usluga trenutno degradira (na primjer, kodovi odgovora u sekundi, vrijeme odgovora na 99. percentilu) i tako dalje. Čim neke nove metrike za opće nadzorne ploče postanu potrebne, odmah ih crtamo i dodajemo.
Već mjesec dana ne crtam grafike. Ovo je vjerovatno dobar znak: to znači da je većina „želja“ već realizovana. Dešavalo se da nedelju dana bar jednom dnevno crtam neki novi grafikon.
Rezultirajući rezultat je vrijedan jer sada programeri rijetko idu kod administratora s pitanjima „gdje vidjeti neku vrstu metrike“.
Implementacija Service Mesh je odmah iza ugla i trebao bi svima olakšati život, kolege iz Tools-a su već blizu implementacije apstraktnog “Istio of a zdrave osobe”: životni ciklus svakog HTTP(s) zahtjeva bit će vidljiv u praćenju, a uvijek će se moći razumjeti „u kojoj fazi se sve pokvarilo“ u međuservisnoj (i ne samo) interakciji. Pretplatite se na vijesti iz DomClick čvorišta. =)
Podrška za Kubernetes infrastrukturu
Istorijski gledano, koristimo zakrpljenu verziju Kubespray - Moguća uloga za postavljanje, proširenje i ažuriranje Kubernetesa. U nekom trenutku, podrška za ne-kubeadm instalacije je uklonjena iz glavne grane, a proces tranzicije na kubeadm nije predložen. Kao rezultat toga, Southbridge je napravio vlastitu viljušku (sa podrškom za kubeadm i brzim rješenjem za kritične probleme).
Proces nadogradnje za sve k8s klastere izgleda ovako:
- Uzmi Kubespray iz Southbridgea, provjerite u našoj poslovnici, merjim.
- Uvođenje ažuriranja za stres- "Kocka".
- Uvodimo ažuriranje jedan po jedan čvor (u Ansibleu ovo je "serial: 1"). Dev- "Kocka".
- Ažuriranje štap u subotu uveče, jedan po jedan čvor.
U budućnosti se planira zamjena Kubespray na nešto brže i idi na kubeadm.
Ukupno imamo tri "Kocke": Stress, Dev i Prod. Planiramo pokrenuti još jednuhot standby) Produkt - "Kocka" u drugom data centru. stres и Dev žive u virtuelnim mašinama (oVirt za Stress i VMWare cloud za Dev). štap- "Kocka" živi na "golom metalu" (golom metalu): to su isti čvorovi sa 32 CPU niti, 64-128 GB memorije i 300 GB SSD RAID 10 - ukupno ih je 50. Tri "tanka" čvora posvećena su "majstorima" štap- "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 krade vreme. A složenost administracije se povećava za otprilike polovinu u slučaju in-house OpenStack-a.
Za CI/CD Cubic i druge infrastrukturne komponente koristimo poseban GIT server, Helm 3 atomski), Jenkins, Ansible i Docker. Volimo grane funkcija i implementaciju u različita okruženja iz istog spremišta.
zaključak
Ovako, generalno gledano, izgleda DevOps proces u DomClicku sa strane operativnog inženjera. Ispostavilo se da je članak manje tehnički nego što sam očekivao: stoga, pratite vijesti DomClick-a na Habréu: bit će više “hardcore” članaka o Kubernetesu i još mnogo toga.
izvor: www.habr.com