Moje ime je Viktor Yagofarov in razvijam platformo Kubernetes pri DomClicku kot vodja tehničnega razvoja v ekipi Ops (operacija). Rad bi spregovoril o strukturi naših procesov Dev <-> Ops, značilnostih delovanja enega največjih gruč k8s v Rusiji, pa tudi o praksah DevOps/SRE, ki jih uporablja naša ekipa.
Operativna ekipa
Ekipa Ops trenutno šteje 15 ljudi. Trije so odgovorni za pisarno, dva delata v drugem časovnem pasu in sta dosegljiva tudi ponoči. Tako je nekdo iz Opsa vedno pri monitorju in pripravljen odgovoriti na incident katere koli zahtevnosti. Nimamo nočnih izmen, kar ohranja našo psiho in daje vsem možnost, da dovolj spijo in preživijo prosti čas ne le za računalnikom.
Vsakdo ima različne kompetence: omrežniki, skrbniki baze podatkov, strokovnjaki za sklade ELK, skrbniki/razvijalci Kubernetes, strokovnjaki za spremljanje, virtualizacijo, strojno opremo itd. Ena stvar združuje vse – vsak lahko do neke mere nadomesti kogar koli od nas: na primer uvede nova vozlišča v gručo k8s, posodobi PostgreSQL, napiše cevovod CI/CD + Ansible, avtomatizira nekaj v Python/Bash/Go, poveže strojno opremo z Podatkovno središče. Močne kompetence na kateremkoli področju vam ne preprečujejo, da bi spremenili smer delovanja in se začeli izboljševati na kakšnem drugem področju. Na primer, pridružil sem se podjetju kot specialist za PostgreSQL, zdaj pa so moje glavno področje odgovornosti gruče Kubernetes. V ekipi je vsaka višina dobrodošla in občutek za vzvod je zelo razvit.
Mimogrede, lovimo se. Zahteve za kandidate so precej standardne. Osebno mi je pomembno, da se človek vklopi v kolektiv, je nekonfliktnost, a zna zagovarjati svoje stališče, se želi razvijati in se ne boji narediti nekaj novega ter ponuja svoje ideje. Zahtevano je tudi znanje programiranja v skriptnih jezikih, poznavanje osnov Linuxa in angleščine. Angleščina je potrebna preprosto zato, da lahko človek v primeru fakapa googla rešitev problema v 10 sekundah, ne pa v 10 minutah. Zdaj je zelo težko najti strokovnjake z globokim znanjem o Linuxu: smešno je, vendar dva od treh kandidatov ne znata odgovoriti na vprašanje »Kaj je povprečna obremenitev? Iz česa je narejen?«, vprašanje »Kako sestaviti core dump iz programa C« pa velja za nekaj iz sveta supermenov... ali dinozavrov. S tem se moramo sprijazniti, saj imajo običajno ljudje visoko razvite druge kompetence, vendar bomo učili Linux. Odgovor na vprašanje »zakaj mora DevOps inženir vedeti vse to v sodobnem svetu oblakov« bo treba pustiti izven okvira članka, a v treh besedah: vse to je potrebno.
Orodja ekipe
Skupina Tools igra pomembno vlogo pri avtomatizaciji. Njihova glavna naloga je ustvariti priročna grafična in CLI orodja za razvijalce. Na primer, naš notranji razvoj Confer vam omogoča, da dobesedno uvedete aplikacijo v Kubernetes s samo nekaj kliki miške, konfigurirate njene vire, ključe iz trezorja itd. Prej je obstajal Jenkins + Helm 2, vendar sem moral razviti lastno orodje za odpravo kopiraj-prilepi in poenotiti življenjski cikel programske opreme.
Ekipa Ops ne piše cevovodov za razvijalce, lahko pa svetuje glede kakršnih koli težav v njihovem pisanju (nekateri ljudje še vedno imajo Helm 3).
DevOps
Kar zadeva DevOps, vidimo takole:
Skupine razvijalcev napišejo kodo, jo uvedejo prek Confer to dev -> qa/stage -> prod. Odgovornost za zagotavljanje, da se koda ne upočasni in ne vsebuje napak, je v rokah ekip Dev in Ops. Podnevi naj se dežurni iz Ops ekipe najprej odzove na incident s svojo aplikacijo, zvečer in ponoči pa naj dežurni administrator (Ops) zbudi dežurnega razvijalca, če ve za prepričani, da težava ni v infrastrukturi. Vse metrike in opozorila v spremljanju se prikažejo samodejno ali polavtomatsko.
Področje odgovornosti Ops se začne od trenutka, ko je aplikacija uvedena v produkcijo, vendar se Devova odgovornost ne konča pri tem – delamo isto in smo v istem čolnu.
Razvijalci svetujejo skrbnikom, če potrebujejo pomoč pri pisanju skrbniške mikrostoritve (na primer Go backend + HTML5), skrbniki pa svetujejo razvijalcem o kakršnih koli infrastrukturnih težavah ali težavah, povezanih s k8s.
Mimogrede, sploh nimamo monolita, samo mikrostoritve. Njihovo število se doslej giblje med 900 in 1000 v gruči prod k8s, če jih merimo po številu. razmestitve. Število strokov se giblje med 1700 in 2000. Trenutno je v proizvodnem grozdu okoli 2000 strokov.
Natančnih številk ne morem podati, saj spremljamo nepotrebne mikrostoritve in jih polavtomatsko izrezujemo. K8s nam pomaga slediti nepotrebnim entitetam , kar prihrani veliko sredstev in denarja.
Upravljanje virov
Spremljanje
Dobro strukturiran in informativen monitoring postane temelj delovanja velikega grozda. Univerzalne rešitve, ki bi 100% pokrila vse potrebe po spremljanju, še nismo našli, zato v tem okolju občasno ustvarjamo različne rešitve po meri.
- Zabbix. Dobri stari monitoring, ki je namenjen predvsem spremljanju celotnega stanja infrastrukture. Pove nam, kdaj vozlišče umre v smislu obdelave, pomnilnika, diskov, omrežja itd. Nič nadnaravnega, imamo pa tudi ločen DaemonSet agentov, s pomočjo katerega na primer spremljamo stanje DNS v gruči: iščemo neumne coredns pode, preverjamo razpoložljivost zunanjih gostiteljev. Zdi se, zakaj bi se obremenjevali s tem, toda pri velikem obsegu prometa je ta komponenta resna točka napake. Sem že , kako sem se boril z zmogljivostjo DNS v gruči.
- Operater Prometheus. Nabor različnih izvoznikov daje velik pregled nad vsemi komponentami grozda. Nato vse to vizualiziramo na velikih nadzornih ploščah v Grafani, za opozorila pa uporabimo alertmanager.
Drugo koristno orodje za nas je bilo . Napisali smo ga potem, ko smo večkrat naleteli na situacijo, ko je ena ekipa prekrivala vstopne poti druge ekipe, kar je povzročilo 50-kratne napake. Pred uvedbo v produkcijo razvijalci preverijo, da to ne bo vplivalo na nikogar, in za mojo ekipo je to dobro orodje za začetno diagnozo težav z Ingresses. Hecno je, da je bilo sprva napisano za skrbnike in je izgledalo precej »nerodno«, potem ko so se razvijalske ekipe zaljubile v orodje, pa se je zelo spremenilo in začelo izgledati ne tako, kot da je »admin skrbnikom naredil spletno faco«. ” Kmalu bomo opustili to orodje in takšne situacije bodo potrjene, še preden bo cevovod uveden.
Ekipni viri v kocki
Preden se lotimo primerov, je vredno razložiti, kako dodeljujemo sredstva za mikrostoritve.
Da bi razumeli, katere ekipe in v kakšnih količinah uporabljajo svoje ресурсы (procesor, pomnilnik, lokalni SSD), vsakemu ukazu dodelimo svojega imenski prostor v »Cube« in omejite njegove največje zmogljivosti v smislu procesorja, pomnilnika in diska, po predhodnem pogovoru o potrebah ekip. V skladu s tem en ukaz na splošno ne bo blokiral celotne gruče za uvajanje, dodelil bo na tisoče jeder in terabajtov pomnilnika. Dostop do imenskega prostora je omogočen preko AD (uporabljamo RBAC). Imenski prostori in njihove omejitve so dodani prek zahteve za vlečenje v repozitorij GIT, nato pa se vse samodejno uvede prek cevovoda Ansible.
Primer dodeljevanja sredstev ekipi:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Zahteve in omejitve
Na kocke" Zahteva je število zajamčenih rezerviranih virov za pod (enega ali več docker vsebnikov) v gruči. Limit je nezajamčen maksimum. Pogosto lahko na grafih vidite, kako si je neka ekipa nastavila preveč zahtev za vse svoje aplikacije in aplikacije ne more razmestiti v “Cube”, saj so vse zahteve pod njihovim imenskim prostorom že “porabljene”.
Pravilen izhod iz te situacije je, da pogledamo dejansko porabo virov in jo primerjamo z zahtevano količino (Zahteva).
Na zgornjih posnetkih zaslona lahko vidite, da se »zahtevani« procesorji ujemajo z dejanskim številom niti, omejitve pa lahko presežejo dejansko število niti procesorja =)
Zdaj pa si podrobneje oglejmo nekaj imenskega prostora (izbral sem imenski prostor kube-system - sistemski imenski prostor za komponente same »Cube«) in poglejmo razmerje med dejansko uporabljenim procesorskim časom in pomnilnikom ter zahtevanim:
Očitno je, da je veliko več pomnilnika in procesorja rezerviranega za sistemske storitve, kot se dejansko uporablja. V primeru sistema kube je to upravičeno: zgodilo se je, da je vstopni krmilnik nginx ali nodelocaldns na vrhuncu zadel CPE in porabil veliko RAM-a, zato je tukaj takšna rezerva upravičena. Poleg tega se ne moremo zanašati na grafikone za zadnje 3 ure: zaželeno je videti zgodovinske meritve v daljšem časovnem obdobju.
Razvit je bil sistem »priporočil«. Tukaj lahko na primer vidite, za katere vire bi bilo bolje dvigniti »omejitve« (zgornjo dovoljeno vrstico), da ne pride do »zmanjševanja«: trenutek, ko je vir že porabil CPU ali pomnilnik v dodeljeni časovni rezini in čaka, da se "odmrzne":
In tukaj so stroki, ki bi morali omejiti njihov apetit:
na dušenje + spremljanje virov, lahko napišete več kot en članek, zato postavite vprašanja v komentarjih. Z nekaj besedami lahko rečem, da je naloga avtomatizacije takšnih metrik zelo težka in zahteva veliko časa in uravnavanja s funkcijami »oken« in »CTE« Prometheus / VictoriaMetrics (ti izrazi so v narekovajih, saj obstaja skoraj nič takega v PromQL, strašljive poizvedbe pa morate razdeliti na več zaslonov besedila in jih optimizirati).
Posledično imajo razvijalci orodja za spremljanje svojih imenskih prostorov v Cubeu in lahko sami izbirajo, kje in ob kateri uri se lahko kateri aplikaciji "rezejo" viri in kateri strežniki lahko celo noč dobijo celoten CPU.
Metodologije
V podjetju, kot je zdaj modno, se držimo DevOps- in SRE- praktik Ko ima podjetje 1000 mikroservisov, okoli 350 razvijalcev in 15 skrbnikov za celotno infrastrukturo, moraš biti »moden«: za vsemi temi »bazbami« je nujno avtomatizirati vse in vsakogar, skrbniki pa ne smejo biti ozko grlo. v procesih.
Kot Ops nudimo različne meritve in nadzorne plošče za razvijalce, povezane s stopnjami odziva storitev in napakami.
Uporabljamo metodologije, kot so: , и tako, da jih združite skupaj. Trudimo se zmanjšati število nadzornih plošč, tako da je na prvi pogled jasno, katera storitev trenutno slabša (na primer odzivne kode na sekundo, odzivni čas za 99. percentil) itd. Takoj, ko postanejo potrebne nove metrike za splošne nadzorne plošče, jih takoj narišemo in dodamo.
Že en mesec nisem risal grafov. To je verjetno dober znak: pomeni, da je večina »želj« že uresničenih. Zgodilo se je, da sem med tednom vsaj enkrat na dan narisal kakšen nov graf.
Dobljeni rezultat je dragocen, ker zdaj razvijalci precej redko gredo k skrbnikom z vprašanjem, "kje pogledati kakšno metriko."
Izvajanje Storitvena mreža je tik za vogalom in bi moralo olajšati življenje vsem, kolegi iz Tools so že blizu implementacije abstraktnega »Istio zdravega človeka«: življenjski cikel vsake zahteve HTTP(s) bo viden v nadzoru in vedno bo mogoče razumeti, "na kateri stopnji se je vse zlomilo" med interakcijo med službami (in ne le). Naročite se na novice središča DomClick. =)
Infrastrukturna podpora Kubernetes
Zgodovinsko gledano uporabljamo popravljeno različico Kubespray — Možna vloga za uvajanje, razširitev in posodabljanje Kubernetesa. Na neki točki je bila podpora za namestitve, ki niso kubeadm, izrezana iz glavne veje in postopek prehoda na kubeadm ni bil predlagan. Posledično je podjetje Southbridge izdelalo svojo vilico (s podporo kubeadm in hitrim popravkom za kritične težave).
Postopek posodabljanja vseh gruč k8s izgleda takole:
- Vzemi Kubespray iz Southbridgea, preverite v naši temi, Merjim.
- Uvajamo posodobitev za Stres- "Kocka".
- Posodobitev uvajamo eno vozlišče naenkrat (v Ansibleu je to »serijski: 1«) v dev- "Kocka".
- Posodabljamo Prod v soboto zvečer eno vozlišče naenkrat.
Obstajajo načrti za zamenjavo v prihodnosti Kubespray za nekaj hitrejšega in pojdite na kubeadm.
Skupaj imamo tri "kocke": Stress, Dev in Prod. Načrtujemo lansiranje še enega (vroča pripravljenost) Prod-»Cube« v drugem podatkovnem centru. Stres и dev živijo v »virtualnih strojih« (oVirt za Stress in VMWare cloud za Dev). Prod- "Cube" živi na "goli kovini": to so identična vozlišča z 32 CPU niti, 64-128 GB pomnilnika in 300 GB SSD RAID 10 - skupaj jih je 50. Tri "tanka" vozlišča so namenjena "mojstrom" Prod- “Cuba”: 16 GB pomnilnika, 12 CPU niti.
Pri prodaji raje uporabljamo "golo kovino" in se izogibamo nepotrebnim slojem, kot je npr OpenStack: ne potrebujemo "hrupnih sosedov" in procesorja krasti čas. In kompleksnost administracije se približno podvoji v primeru lastnega OpenStacka.
Za CI/CD "Cubic" in druge komponente infrastrukture uporabljamo ločen strežnik GIT, Helm 3 (prehod s Helm 2 je bil precej boleč, vendar smo zelo zadovoljni z možnostmi atomsko), Jenkins, Ansible in Docker. Obožujemo veje funkcij in uvajanje v različna okolja iz enega repozitorija.
Zaključek
Tako je na splošno videti proces DevOps v DomClicku z vidika operativnega inženirja. Članek se je izkazal za manj tehničnega, kot sem pričakoval: zato spremljajte novice DomClick na Habréju: več bo "hardcore" člankov o Kubernetesu in še več.
Vir: www.habr.com