Volám sa Viktor Yagofarov a vyvíjam platformu Kubernetes v spoločnosti DomClick ako manažér technického rozvoja v tíme Ops (prevádzky). Chcel by som hovoriť o štruktúre našich procesov Dev <-> Ops, o funkciách prevádzky jedného z najväčších klastrov k8s v Rusku, ako aj o postupoch DevOps / SRE, ktoré používa náš tím.
Tímové operácie
Operačný tím má momentálne 15 ľudí. Traja z nich zodpovedajú za úrad, dvaja pracujú v inom časovom pásme a sú k dispozícii aj v noci. Niekto z Ops je teda vždy pri monitore a je pripravený reagovať na incident akejkoľvek zložitosti. Nemáme nočné zmeny, čo zachováva našu mentalitu a dáva každému možnosť dostatočne sa vyspať a tráviť voľný čas nielen pri počítači.
Každý má iné kompetencie: networkers, DBA, ELK stack špecialisti, Kubernetes administrátori / vývojári, monitoring, virtualizácia, hardvéroví špecialisti atď. Jedna vec spája všetkých - každý môže do určitej miery nahradiť kohokoľvek z nás: napríklad zaviesť nové uzly do klastra k8s, aktualizovať PostgreSQL, napísať CI / CD + Ansible pipeline, automatizovať niečo v Pythone / Bash / Go, pripojiť kus hardvéru do DPC. Silné kompetencie v akejkoľvek oblasti nezasahujú do zmeny smeru činnosti a začatia pumpovania v nejakej inej oblasti. Napríklad som dostal prácu v spoločnosti ako špecialista na PostgreSQL a teraz sú mojou hlavnou oblasťou zodpovednosti klastre Kubernetes. V tíme je akýkoľvek rast len vítaný a zmysel pre rameno je veľmi rozvinutý.
Mimochodom, lovíme. Požiadavky na kandidátov sú pomerne štandardné. Pre mňa osobne je dôležité, aby človek zapadol do kolektívu, bol nekonfliktný, ale vedel si obhájiť aj svoj pohľad, chcel sa rozvíjať a nebál sa robiť niečo nové, ponúkať svoje nápady. Taktiež je potrebná znalosť programovania v skriptovacích jazykoch, znalosť základov Linuxu a angličtiny. Angličtina je potrebná práve na to, aby si človek v prípade fakapa vygooglil riešenie problému za 10 sekúnd, a nie za 10 minút. So špecialistami s hlbokými znalosťami Linuxu je to teraz veľmi ťažké: zábavné, ale dvaja z troch kandidátov nevedia odpovedať na otázku „Čo je priemerná záťaž? Z čoho pozostáva? “, A otázka„ Ako zhromaždiť jadrovú skládku z programu sish “, sa považuje za niečo zo sveta nadľudí ... alebo dinosaurov. Musíme sa s tým zmieriť, pretože ľudia majú zvyčajne vysoko rozvinuté iné kompetencie a Linux naučíme. Odpoveď na otázku „prečo to všetko potrebuje vedieť inžinier DevOps v modernom svete cloudov“ bude musieť zostať mimo rámec článku, ale tromi slovami: toto všetko je potrebné.
Príkaz Tools
Tím Tools hrá významnú úlohu v automatizácii. Ich hlavnou úlohou je vytvárať pohodlné grafické a CLI nástroje pre vývojárov. Napríklad náš interný vývoj Confer vám umožňuje zaviesť aplikáciu do Kubernetes len niekoľkými kliknutiami myšou, nakonfigurovať jej zdroje, kľúče z trezoru atď. Kedysi existoval Jenkins + Helm 2, ale musel som vyvinúť vlastný nástroj na odstránenie kopírovania a prilepenia a vniesť jednotnosť do životného cyklu softvéru.
Tím Ops nepíše kanály pre vývojárov, ale môže poradiť s akýmikoľvek problémami pri ich písaní (niektorí majú stále Helm 3).
DevOps
Pokiaľ ide o DevOps, vidíme to takto:
Vývojárske tímy napíšu kód, zavedú ho cez Confer to dev -> qa/stage -> prod. Je zodpovednosťou tímov Dev a Ops zabezpečiť, aby sa kód nespomalil a nevyvolával chyby. Cez deň by mal služobný dôstojník z tímu Ops reagovať na incident svojou aplikáciou a večer a v noci by mal služobný administrátor (Ops) zobudiť vývojára v službe, ak s istotou vie, že problém nie je v infraštruktúre. Všetky metriky a upozornenia v monitorovaní sa zobrazujú automaticky alebo poloautomaticky.
Oblasť zodpovednosti Ops začína od okamihu, keď je aplikácia zavedená do výroby, ale zodpovednosť Dev tam nekončí - robíme jednu vec a sme na jednej lodi.
Vývojári radia správcom, ak potrebujú pomoc s písaním mikroslužby správcu (napríklad Go backend + HTML5), a správcovia radia vývojárom v prípade akýchkoľvek problémov súvisiacich s infraštruktúrou alebo k8s.
Mimochodom, nemáme vôbec monolit, iba mikroslužby. Ich počet zatiaľ kolíše medzi 900 a 1000 v zhluku prod k8s, ak sa meria počtom nasadenia. Počet strukov kolíše medzi 1700 a 2000. Struky v zhluku plodov sú teraz okolo 2000.
Nemôžem poskytnúť presné čísla, pretože monitorujeme nepotrebné mikroslužby a vypíname ich v poloautomatickom režime. Sledovanie nepotrebných entít v k8 nám pomáha čo šetrí zdroje a peniaze.
Riadenie zdrojov
monitorovanie
Kompetentne vybudovaný a informatívny monitoring sa stáva základným kameňom fungovania veľkého klastra. Zatiaľ sme nenašli univerzálne riešenie, ktoré by pokrylo 100 % všetkých potrieb monitorovania, preto v tomto prostredí pravidelne nitujeme rôzne vlastné riešenia.
- Zabbix. Starý dobrý monitoring, ktorý je určený predovšetkým na sledovanie celkového stavu infraštruktúry. Hovorí nám, kedy uzol zanikne, podľa procesora, pamäte, diskov, siete atď. Nič nadprirodzené, ale máme aj samostatnú DaemonSet agentov, pomocou ktorých napríklad monitorujeme stav DNS v klastri: hľadáme hlúpe coredns pody, kontrolujeme dostupnosť externých hostiteľov. Zdalo by sa, že prečo sa obťažovať, ale pri veľkých objemoch prevádzky je tento komponent vážnym bodom zlyhania. Predtým som mal ako zápasil s výkonom DNS v klastri.
- Operátor Prometheus. Súbor rôznych exportérov poskytuje skvelý prehľad o všetkých komponentoch klastra. Ďalej to všetko vizualizujeme na veľkých informačných paneloch v Grafane a na upozornenia používame správcu výstrah.
Ďalším užitočným nástrojom pre nás je . Napísali sme ho po tom, čo sme sa niekoľkokrát stretli so situáciou, keď jeden tím svojimi cestami prekrýval Ingress iného tímu, čo spôsobilo 50x chýb. Teraz, pred nasadením do produkcie, vývojári skontrolujú, či nikomu neublížia, a pre môj tím je to dobrý nástroj na počiatočnú diagnostiku problémov s Ingresses. Je smiešne, že najprv bol napísaný pre administrátorov a vyzeral dosť „nemotorne“, ale potom, čo sa vývojárske tímy do tohto nástroja zamilovali, veľmi sa zmenil a začal vyzerať ako „admin vytvoril webovú tvár pre adminov“ . Čoskoro opustíme tento nástroj a takéto situácie budú overené ešte pred spustením potrubia.
Tímové zdroje v "Kocke"
Predtým, ako budeme pokračovať s príkladmi, stojí za to vysvetliť, ako máme prideľovať zdroje mikroslužby.
Aby sme pochopili, ktoré tímy a v akom množstve ich používajú zdrojov (procesor, pamäť, lokálne SSD), alokujeme vlastné namespace v „Kocke“ a obmedziť jej maximálne možnosti, pokiaľ ide o procesor, pamäť a disk, pričom predtým diskutovali o potrebách tímov. V súlade s tým jeden príkaz vo všeobecnom prípade nezablokuje celý klaster na nasadenie a pridelí si tisíce jadier a terabajtov pamäte. Prístupy do menného priestoru sú vydávané prostredníctvom AD (používame RBAC). Priestory názvov a ich limity sa pridávajú prostredníctvom požiadavky na stiahnutie do úložiska GIT a potom sa všetko automaticky zavádza prostredníctvom potrubia Ansible.
Príklad rozdelenia zdrojov na tím:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Požiadavky a limity
Kocky" žiadosť je počet garantovaných rezervovaných zdrojov pod struk (jeden alebo viac kontajnerov ukotvenia) v klastri. Limit je negarantované maximum. Na grafoch často vidíte, ako si niektorý tím nastavil príliš veľa požiadaviek na všetky svoje aplikácie a nemôže aplikáciu nasadiť do „Kocky“, keďže pod ich menným priestorom už boli všetky požiadavky „spotrebované“.
Správnym východiskom z tejto situácie je pozrieť sa na skutočnú spotrebu zdrojov a porovnať ju s požadovaným množstvom (Žiadosť).
Snímky obrazovky vyššie ukazujú, že „požadované“ (požadované) CPU sú vybrané podľa skutočného počtu vlákien a limity môžu prekročiť skutočný počet vlákien CPU =)
Teraz sa pozrime bližšie na nejaký menný priestor (vybral som si menný priestor kube-system - systémový menný priestor pre komponenty samotnej "kocky") a pozrime si pomer skutočne použitého času procesora a pamäte k požadovanému:
Je zrejmé, že pre systémové služby je vyhradených oveľa viac pamäte a CPU, ako sa skutočne využíva. V prípade systému kube je to opodstatnené: stalo sa, že nginx ingress controller alebo nodelocaldns na špičke spočívali na CPU a jedli veľa RAM, takže tu je takáto rezerva opodstatnená. Okrem toho sa nemôžeme spoliehať na grafy za posledné 3 hodiny: je žiaduce vidieť historické metriky za veľké časové obdobie.
Bol vyvinutý systém „odporúčaní“. Napríklad tu môžete vidieť, pri ktorých zdrojoch by bolo lepšie zvýšiť „limity“ (horná povolená lišta), aby nenastalo „obmedzenie“: moment, keď modul už spotreboval CPU alebo pamäť na pridelené množstvo času. a čaká, kým sa „rozmrazí“:
A tu sú struky, ktoré by mali zmierniť ich apetít:
o škrtenie + monitorovanie zdrojov, môžete napísať viac ako jeden článok, takže sa pýtajte v komentároch. V niekoľkých slovách môžem povedať, že úloha automatizácie takýchto metrík je veľmi náročná a vyžaduje si veľa času a vyváženia s funkciami „okna“ a „CTE“ Prometheus / VictoriaMetrics (tieto výrazy sú v úvodzovkách, pretože existuje takmer nič také v PromQL a strašidelné dopyty musíte šermovať na niekoľkých obrazovkách textu a optimalizovať ich).
Výsledkom je, že vývojári majú nástroje na monitorovanie svojich menných priestorov v „kocke“ a môžu si vybrať, kde a v akom čase, ktoré aplikácie môžu „ukrajovať“ zdroje a ktorým modulom možno dať celý procesor na celú noc.
Metodiky
V spoločnosti ako teraz módne, dodržiavame DevOps- a SRE- praktizujúci Keď má spoločnosť 1000 350 mikroslužieb, približne 15 vývojárov a XNUMX správcov pre celú infraštruktúru, musíte byť „v móde“: za všetkými týmito „módnymi slovami“ je naliehavá potreba automatizovať všetko a všetko a správcovia by nemali byť prekážkou. v procesoch.
Ako Ops poskytujeme rôzne metriky a dashboardy pre vývojárov súvisiace s dobou odozvy služieb a ich chybami.
Používame metódy ako: , и ich spojením. Snažíme sa minimalizovať počet dashboardov, aby bolo na prvý pohľad jasné, ktorá služba momentálne degraduje (napríklad kódy odpovedí za sekundu, čas odozvy na 99. percentile) atď. Akonáhle budú potrebné nejaké nové metriky pre všeobecné informačné panely, okamžite ich nakreslíme a pridáme.
Už mesiac nekreslím grafiku. Toto je pravdepodobne dobré znamenie: znamená to, že väčšina „prianí“ už bola implementovaná. Stalo sa, že týždeň som aspoň raz za deň kreslil nejaký nový graf.
Výsledný výsledok je cenný v tom, že teraz vývojári zriedka chodia na administrátorov s otázkami „kde vidieť nejaké metriky“.
Implementácia Servisná sieť je hneď za rohom a mal by všetkým výrazne uľahčiť život, kolegovia z Tools sú už blízko k implementácii abstraktného „Istio zdravého človeka“: životný cyklus každej HTTP(s) požiadavky bude viditeľný v monitoringu a vždy bude možné pochopiť, „v akom štádiu sa všetko pokazilo“ pri interakcii medzi službami (nielen). Prihláste sa na odber noviniek z centra DomClick. =)
Podpora infraštruktúry Kubernetes
Historicky používame opravenú verziu Kubespray - Použiteľná rola pre nasadenie, rozšírenie a aktualizáciu Kubernetes. V určitom bode bola podpora pre inštalácie bez kubeadm prerušená z hlavnej vetvy a proces prechodu na kubeadm nebol navrhnutý. Výsledkom je, že Southbridge vytvoril svoj vlastný fork (s podporou pre kubeadm a rýchlou opravou kritických problémov).
Proces inovácie pre všetky klastre k8s vyzerá takto:
- trvať Kubespray zo Southbridge, overte si to u našej pobočky, merjim.
- Spustenie aktualizácie na Stres- "Kocka".
- Aktualizáciu spúšťame po jednom uzle (v Ansible je to „sériové: 1“) dev- "Kocka".
- Aktualizuje sa Podnecovať v sobotu večer po jednom uzle.
V budúcnosti sa plánuje výmena Kubespray na niečo rýchlejšie a ísť do kubeadm.
Celkovo máme tri "kocky": Stress, Dev a Prod. Plánujeme spustiť ďalšiuhorúci pohotovostný režim) Prod- "Kocka" v druhom dátovom centre. Stres и dev žiť vo virtuálnych strojoch (oVirt for Stress a VMWare cloud pre Dev). Podnecovať- "Cube" žije z "holého kovu" (holého kovu): sú to rovnaké uzly s 32 vláknami CPU, 64-128 GB pamäte a 300 GB SSD RAID 10 - celkovo je ich 50. Tri „tenké“ uzly sú venované „majstrom“ Podnecovať- "Kuba": 16 GB pamäte, 12 vlákien CPU.
Pri predaji uprednostňujeme použitie „holého kovu“ a vyhýbame sa zbytočným vrstvám ako napr OpenStack: nepotrebujeme "hlučných susedov" a CPU ukradnúť čas. A náročnosť administrácie sa v prípade in-house OpenStacku zvyšuje približne o polovicu.
Pre CI/CD Cubic a ďalšie komponenty infraštruktúry používame samostatný GIT server Helm 3 atómový), Jenkins, Ansible a Docker. Milujeme vetvy funkcií a ich nasadenie do rôznych prostredí z rovnakého úložiska.
Záver
Takto vo všeobecnosti vyzerá proces DevOps v spoločnosti DomClick zo strany prevádzkového inžiniera. Článok sa ukázal byť menej technický, ako som očakával: sledujte preto novinky DomClick na Habré: bude tam viac „hardcore“ článkov o Kubernetes a ďalšie.
Zdroj: hab.com