Jmenuji se Viktor Yagofarov a vyvíjím platformu Kubernetes ve společnosti DomClick jako manažer technického vývoje v týmu Ops (provoz). Chtěl bych mluvit o struktuře našich procesů Dev <-> Ops, funkcích provozování jednoho z největších clusterů k8s v Rusku a také o postupech DevOps/SRE, které náš tým používá.
Operační tým
Operační tým má v současnosti 15 lidí. Tři z nich zodpovídají za kancelář, dva pracují v jiném časovém pásmu a jsou k dispozici i v noci. Někdo z Ops je tedy vždy u monitoru a připraven reagovat na incident jakékoli složitosti. Nemáme noční směny, což šetří naši psychiku a dává každému možnost se dostatečně vyspat a trávit volný čas nejen u počítače.
Každý má jiné kompetence: síťaři, DBA, specialisté na zásobníky ELK, administrátoři/vývojáři Kubernetes, monitoring, virtualizace, hardwaroví specialisté atd. Jedno všechny spojuje – každý může do určité míry nahradit kohokoli z nás: například zavést nové uzly do clusteru k8s, aktualizovat PostgreSQL, napsat pipeline CI/CD + Ansible, automatizovat něco v Pythonu/Bash/Go, připojit hardware k Datové centrum. Silné kompetence v jakékoli oblasti vám nebrání změnit směr činnosti a začít se zlepšovat v nějaké jiné oblasti. Například jsem nastoupil do společnosti jako specialista na PostgreSQL a nyní mám hlavní oblast odpovědnosti za clustery Kubernetes. V týmu je vítána jakákoliv výška a smysl pro páku je velmi rozvinutý.
Mimochodem, lovíme. Požadavky na kandidáty jsou celkem standardní. Pro mě osobně je důležité, aby člověk zapadl do kolektivu, byl nekonfliktní, ale také si uměl obhájit svůj pohled, chtěl se rozvíjet a nebál se dělat něco nového, nabízel své nápady. Dále je nutná znalost programování ve skriptovacích jazycích, znalost základů Linuxu a angličtiny. Angličtina je potřeba prostě proto, aby si člověk v případě fakapu vygooglil řešení problému za 10 sekund a ne za 10 minut. Nyní je velmi obtížné najít specialisty s hlubokými znalostmi Linuxu: je to legrační, ale dva ze tří kandidátů nedokážou odpovědět na otázku „Co je průměrná zátěž? Z čeho je to vyrobeno?“, a otázka „Jak sestavit jádrový výpis z programu C“ je považována za něco ze světa supermanů... nebo dinosaurů. Musíme se s tím smířit, protože obvykle mají lidé vysoce rozvinuté jiné kompetence, ale Linux naučíme. Odpověď na otázku „proč to všechno potřebuje vědět inženýr DevOps v moderním světě cloudů“ bude třeba ponechat mimo rámec článku, ale třemi slovy: to vše je potřeba.
Týmové nástroje
Tým nástrojů hraje významnou roli v automatizaci. Jejich hlavním úkolem je vytvářet pohodlné grafické a CLI nástroje pro vývojáře. Například naše interní vývojová konference vám umožňuje doslova zavést aplikaci do Kubernetes pomocí několika kliknutí myší, nakonfigurovat její prostředky, klíče z trezoru atd. Dříve existoval Jenkins + Helm 2, ale musel jsem vyvinout svůj vlastní nástroj, který eliminuje kopírování a vkládání a přináší jednotnost životního cyklu softwaru.
Tým Ops nepíše pro vývojáře pipeline, ale může poradit s jakýmikoli problémy při psaní (někteří lidé stále mají Helm 3).
devops
Pokud jde o DevOps, vidíme to takto:
Vývojářské týmy napíší kód, zavedou ho přes Confer to dev -> qa/stage -> prod. Odpovědnost za to, že se kód nezpomaluje a neobsahuje chyby, leží na týmech Dev a Ops. Ve dne by měl člověk ve službě z Ops týmu nejprve reagovat na incident svojí aplikací a večer a v noci by měl službu konající správce (Ops) vzbudit ve službě vývojáře, pokud ví, jistý, že problém není v infrastruktuře. Všechny metriky a výstrahy v monitorování se zobrazují automaticky nebo poloautomaticky.
Oblast odpovědnosti Ops začíná od okamžiku, kdy je aplikace uvedena do výroby, ale odpovědnost Dev tím nekončí – děláme to samé a jsme na stejné lodi.
Vývojáři radí správcům, pokud potřebují pomoc s psaním mikroslužby pro správu (například Go backend + HTML5), a správci radí vývojářům ohledně jakýchkoli problémů s infrastrukturou nebo problémů souvisejících s k8s.
Mimochodem, nemáme vůbec monolit, pouze mikroslužby. Jejich počet zatím kolísá mezi 900 a 1000 ve shluku prod k8s, pokud se měří počtem nasazení. Počet lusků kolísá mezi 1700 a 2000. V současné době je ve shluku plodů asi 2000 lusků.
Nemohu uvést přesná čísla, protože sledujeme zbytečné mikroslužby a poloautomaticky je vypínáme. K8s nám pomáhá sledovat nepotřebné entity , což šetří spoustu prostředků a peněz.
Управление ресурсами
Sledování
Dobře strukturovaný a informativní monitoring se stává základním kamenem provozu velkého clusteru. Dosud jsme nenašli univerzální řešení, které by pokrylo 100 % všech potřeb monitorování, proto v tomto prostředí pravidelně vytváříme různá vlastní řešení.
- Zabbix. Starý dobrý monitoring, který je určen především ke sledování celkového stavu infrastruktury. Říká nám, kdy uzel zemře, pokud jde o zpracování, paměť, disky, síť a tak dále. Nic nadpřirozeného, ale máme i samostatnou DaemonSet agentů, s jejichž pomocí například sledujeme stav DNS v clusteru: hledáme stupidní coredns pody, kontrolujeme dostupnost externích hostitelů. Zdálo by se, že proč se tím zabývat, ale při velkém objemu provozu je tato komponenta vážným bodem selhání. Už jsem , jak jsem bojoval s výkonem DNS v clusteru.
- Operátor Prometheus. Sada různých exportérů poskytuje velký přehled o všech složkách clusteru. Dále to vše vizualizujeme na velkých dashboardech v Grafaně a pro upozornění používáme alertmanager.
Dalším užitečným nástrojem pro nás byl . Napsali jsme to poté, co jsme několikrát narazili na situaci, kdy jeden tým překrýval cesty vstupu jiného týmu, což vedlo k 50x chybám. Nyní před nasazením do produkce vývojáři zkontrolují, že to nikoho neovlivní, a pro můj tým je to dobrý nástroj pro počáteční diagnostiku problémů s Ingresses. Je legrační, že zpočátku to bylo napsané pro administrátory a vypadalo to dost „nemotorně“, ale poté, co se vývojářské týmy do nástroje zamilovaly, se to hodně změnilo a začalo to nevypadat jako „admin udělal webovou tvář pro adminy. “ Brzy tento nástroj opustíme a takové situace budou ověřeny ještě před spuštěním potrubí.
Týmové prostředky v kostce
Než se pustíme do příkladů, stojí za to vysvětlit, jak přidělujeme zdroje mikroslužby.
Abychom pochopili, které týmy a v jakém množství je používají ресурсы (procesor, paměť, lokální SSD), každému příkazu přidělujeme vlastní jmenný prostor v „Cube“ a omezit jeho maximální možnosti, pokud jde o procesor, paměť a disk, po předchozí diskusi o potřebách týmů. V souladu s tím jeden příkaz obecně nezablokuje celý cluster pro nasazení a přidělí tisíce jader a terabajtů paměti. Přístup k jmennému prostoru je poskytován prostřednictvím AD (používáme RBAC). Jmenné prostory a jejich limity jsou přidány prostřednictvím požadavku na stažení do úložiště GIT a poté je vše automaticky zavedeno prostřednictvím kanálu Ansible.
Příklad přidělení zdrojů týmu:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Požadavky a limity
Krychlový" Žádost je počet garantovaných rezervovaných zdrojů pro pod (jeden nebo více ukotvitelných kontejnerů) v clusteru. Limit je negarantované maximum. Na grafech je často vidět, jak si některý tým nastavil příliš mnoho požadavků pro všechny své aplikace a nemůže aplikaci nasadit do „Cube“, protože všechny požadavky pod jejich jmenným prostorem již byly „utraceny“.
Správným východiskem z této situace je podívat se na skutečnou spotřebu zdrojů a porovnat ji s požadovanou částkou (Požadavek).
Na snímcích výše můžete vidět, že „požadované“ procesory odpovídají skutečnému počtu vláken a limity mohou překročit skutečný počet vláken procesoru =)
Nyní se podíváme na nějaký jmenný prostor podrobně (vybral jsem jmenný prostor kube-system - systémový jmenný prostor pro komponenty samotné „Cube“) a podívejme se na poměr skutečně použitého času procesoru a paměti k požadovanému:
Je zřejmé, že pro systémové služby je vyhrazeno mnohem více paměti a CPU, než je ve skutečnosti využito. V případě kube-systému je to oprávněné: stalo se, že nginx ingress controller nebo nodelocaldns na své špičce zasáhly CPU a spotřebovaly hodně RAM, takže zde je taková rezerva oprávněná. Navíc se nemůžeme spoléhat na grafy za poslední 3 hodiny: je žádoucí vidět historické metriky za velké časové období.
Byl vyvinut systém „doporučení“. Zde můžete například vidět, u kterých zdrojů by bylo lepší zvýšit „limity“ (horní povolená lišta), aby nedocházelo k „omezování“: okamžik, kdy zdroj již spotřeboval CPU nebo paměť v přiděleném časovém úseku a čeká na „rozmrazení“:
A zde jsou lusky, které by měly omezit jejich chutě:
O škrcení + monitorování zdrojů, můžete napsat více než jeden článek, takže se ptejte v komentářích. V několika slovech mohu říci, že úloha automatizace takových metrik je velmi obtížná a vyžaduje spoustu času a vyvažování funkcí „okna“ a „CTE“ Prometheus / VictoriaMetrics (tyto termíny jsou v uvozovkách, protože existuje téměř nic takového v PromQL a děsivé dotazy musíte rozdělit na několik obrazovek textu a optimalizovat je).
Výsledkem je, že vývojáři mají nástroje pro monitorování svých jmenných prostorů v Cube a mohou si sami vybrat, kde a v jakou dobu mohou mít aplikace „uříznuté“ své zdroje a kterým serverům lze dát celý CPU na celou noc.
Metodiky
Ve společnosti, jaká je nyní módní, dodržujeme DevOps- a SRE-praktik Když má společnost 1000 mikroslužeb, asi 350 vývojářů a 15 správců pro celou infrastrukturu, musíte „být v módě“: za všemi těmito „baswords“ je naléhavá potřeba automatizovat všechno a všechny a správci by neměli být úzkým hrdlem. v procesech.
Jako Ops poskytujeme různé metriky a řídicí panely pro vývojáře týkající se míry odezvy služeb a chyb.
Používáme metodiky jako: , и jejich spojením dohromady. Snažíme se minimalizovat počet dashboardů, aby bylo na první pohled jasné, která služba aktuálně degraduje (například kódy odpovědí za sekundu, doba odezvy na 99. percentil) a tak dále. Jakmile se pro obecné dashboardy stanou potřeba nějaké nové metriky, okamžitě je nakreslíme a přidáme.
Už měsíc jsem nekreslil grafy. To je pravděpodobně dobré znamení: znamená to, že většina „přání“ již byla splněna. Stávalo se, že jsem během týdne alespoň jednou denně nakreslil nějaký nový graf.
Výsledný výsledek je cenný, protože nyní vývojáři velmi zřídka chodí na administrátory s otázkami „kde se podívat na nějakou metriku“.
Vdědření Servisní síť je hned za rohem a měl by všem výrazně usnadnit život, kolegové z Tools jsou již blízko implementaci abstraktního „Istio zdravého člověka“: životní cyklus každého požadavku HTTP(s) bude viditelný v monitorování a bude vždy možné porozumět tomu, „v jaké fázi se vše rozbilo“ během meziútvarové (nejen) interakce. Přihlaste se k odběru novinek z centra DomClick. =)
Podpora infrastruktury Kubernetes
Historicky používáme opravenou verzi Kubespray — Možnost role pro nasazení, rozšiřování a aktualizaci Kubernetes. V určitém okamžiku byla z hlavní větve odstraněna podpora pro instalace bez kubeadm a proces přechodu na kubeadm nebyl navržen. Výsledkem je, že společnost Southbridge vytvořila vlastní vidlici (s podporou kubeadm a rychlou opravou kritických problémů).
Proces aktualizace všech clusterů k8s vypadá takto:
- Vezmi Kubespray ze Southbridge, mrkni na naše vlákno, Merjime.
- Zavádíme aktualizaci na Stres- "Krychle".
- Aktualizaci zavádíme jeden uzel po druhém (v Ansible je to „serial: 1“) v dev- "Krychle".
- Aktualizace Podněcovat v sobotu večer jeden uzel po druhém.
V budoucnu se plánuje její nahrazení Kubespray pro něco rychlejšího a jít do kubeadm.
Celkem máme tři „kostky“: Stress, Dev a Prod. Plánujeme spustit další (horký pohotovostní režim) Prod-„Cube“ ve druhém datovém centru. Stres и dev žít ve „virtuálních strojích“ (oVirt pro stres a cloud VMWare pro vývojáře). Podněcovat- „Cube“ žije z „holého kovu“: jedná se o identické uzly s 32 vlákny CPU, 64–128 GB paměti a 300 GB SSD RAID 10 – celkem jich je 50. Tři „tenké“ uzly jsou věnovány „pánům“ Podněcovat- „Kuba“: 16 GB paměti, 12 vláken CPU.
Pro prodej dáváme přednost použití „holého kovu“ a vyhýbáme se zbytečným vrstvám jako OpenStack: nepotřebujeme „hlučné sousedy“ a CPU ukrást čas. A složitost správy se v případě in-house OpenStacku přibližně zdvojnásobuje.
Pro CI/CD „Cubic“ a další komponenty infrastruktury používáme samostatný GIT server Helm 3 (byl to poměrně bolestivý přechod z Helm 2, ale s možnostmi jsme velmi spokojeni atomový), Jenkins, Ansible a Docker. Milujeme větve funkcí a nasazení do různých prostředí z jednoho úložiště.
Závěr
Takto obecně vypadá proces DevOps v DomClick z pohledu provozního inženýra. Článek se ukázal být méně technický, než jsem čekal: sledujte proto novinky DomClick na Habré: bude více „hardcore“ článků o Kubernetes a další.
Zdroj: www.habr.com