Numele meu este Viktor Yagofarov și dezvolt platforma Kubernetes la DomClick ca manager de dezvoltare tehnică în echipa de operațiuni (operare). Aș dori să vorbesc despre structura proceselor noastre Dev Ops, despre caracteristicile operațiunii unuia dintre cele mai mari clustere k8s din Rusia, precum și despre practicile DevOps/SRE pe care le aplică echipa noastră.
Echipa de operațiuni
Echipa Ops are în prezent 15 persoane. Trei dintre ei sunt responsabili de birou, doi lucrează într-un fus orar diferit și sunt disponibili, inclusiv pe timp de noapte. Astfel, cineva de la Ops este mereu la monitor și gata să răspundă unui incident de orice complexitate. Nu avem ture de noapte, ceea ce ne păstrează psihicul și oferă tuturor posibilitatea de a dormi suficient și de a petrece timpul liber nu numai la computer.
Fiecare are competențe diferite: rețele, DBA, specialiști în stivă ELK, administratori/dezvoltatori Kubernetes, monitorizare, virtualizare, specialiști hardware etc. Un lucru îi unește pe toți - toată lumea poate să ne înlocuiască pe oricare dintre noi într-o oarecare măsură: de exemplu, introduceți noi noduri în clusterul k8s, actualizați PostgreSQL, scrieți o conductă CI/CD + Ansible, automatizați ceva în Python/Bash/Go, conectați hardware-ul la Centru de date. Competențele puternice în orice domeniu nu vă împiedică să vă schimbați direcția de activitate și să începeți să vă îmbunătățiți în alt domeniu. De exemplu, m-am alăturat unei companii ca specialist PostgreSQL, iar acum principala mea zonă de responsabilitate sunt clusterele Kubernetes. În echipă, orice înălțime este binevenită și simțul pârghiei este foarte dezvoltat.
Apropo, vânăm. Cerințele pentru candidați sunt destul de standard. Pentru mine personal, este important ca o persoană să se încadreze în echipă, să nu fie conflictuală, dar să știe și să-și apere punctul de vedere, să vrea să se dezvolte și să nu se teamă să facă ceva nou, să-și ofere ideile. De asemenea, sunt necesare abilități de programare în limbaje de scripting, cunoașterea elementelor de bază ale Linux și engleză. Limba engleză este necesară pur și simplu pentru ca o persoană, în cazul unui fakap, să poată căuta pe Google o soluție la problemă în 10 secunde, și nu în 10 minute. Acum este foarte greu să găsești specialiști cu cunoștințe profunde despre Linux: este amuzant, dar doi din trei candidați nu pot răspunde la întrebarea „Ce este Load Average? Din ce este făcută?”, iar întrebarea „Cum să asamblați o haldă de miez dintr-un program C” este considerată ceva din lumea supraoamenilor... sau a dinozaurilor. Trebuie să suportăm asta, deoarece de obicei oamenii au alte competențe foarte dezvoltate, dar vom preda Linux. Răspunsul la întrebarea „de ce un inginer DevOps trebuie să știe toate acestea în lumea modernă a norilor” va trebui lăsat în afara domeniului de aplicare al articolului, dar în trei cuvinte: toate acestea sunt necesare.
Instrumente de echipă
Echipa Tools joacă un rol important în automatizare. Sarcina lor principală este să creeze instrumente grafice și CLI convenabile pentru dezvoltatori. De exemplu, dezvoltarea noastră internă Confer vă permite să lansați literalmente o aplicație în Kubernetes cu doar câteva clicuri de mouse, să îi configurați resursele, cheile din seif etc. Anterior, a existat Jenkins + Helm 2, dar a trebuit să-mi dezvolt propriul instrument pentru a elimina copy-paste și a aduce uniformitate ciclului de viață al software-ului.
Echipa Ops nu scrie pipeline pentru dezvoltatori, dar poate sfătui cu privire la orice probleme în scrierea lor (unii oameni au încă Helm 3).
DevOps
În ceea ce privește DevOps, o vedem așa:
Echipele de dezvoltare scriu cod, îl lansează prin Confer to dev -> qa/stage -> prod. Responsabilitatea pentru a se asigura că codul nu încetinește și nu conține erori revine echipelor Dev și Ops. În timpul zilei, persoana de serviciu din echipa Ops ar trebui în primul rând să răspundă unui incident cu aplicația sa, iar seara și noaptea, administratorul de serviciu (Ops) ar trebui să trezească dezvoltatorul de serviciu dacă știe de sigur că problema nu este în infrastructură. Toate valorile și alertele din monitorizare apar automat sau semi-automat.
Zona de responsabilitate a lui Ops începe din momentul în care aplicația este lansată în producție, dar responsabilitatea lui Dev nu se termină aici - facem același lucru și suntem în aceeași barcă.
Dezvoltatorii sfătuiesc administratorii dacă au nevoie de ajutor pentru scrierea unui microserviciu de administrare (de exemplu, Go backend + HTML5), iar administratorii sfătuiesc dezvoltatorii cu privire la orice problemă de infrastructură sau probleme legate de k8s.
Apropo, nu avem deloc un monolit, doar microservicii. Numărul lor fluctuează până acum între 900 și 1000 în clusterul prod k8s, dacă este măsurat prin număr implementări. Numărul de păstăi fluctuează între 1700 și 2000. În prezent există aproximativ 2000 de păstăi în grupul de produse.
Nu pot da numere exacte, deoarece monitorizăm microservicii inutile și le decupăm semi-automat. K8s ne ajută să ținem evidența entităților inutile , care economisește o mulțime de resurse și bani.
Managementul resurselor
monitorizarea
Monitorizarea bine structurată și informativă devine piatra de temelie în funcționarea unui cluster mare. Nu am găsit încă o soluție universală care să acopere 100% din toate nevoile de monitorizare, așa că creăm periodic diferite soluții personalizate în acest mediu.
- Zabbix. Monitorizare veche bună, care este destinată în primul rând să urmărească starea generală a infrastructurii. Ne spune când un nod moare în termeni de procesare, memorie, discuri, rețea și așa mai departe. Nimic supranatural, dar avem și un DaemonSet separat de agenți, cu ajutorul căruia, de exemplu, monitorizăm starea DNS-ului din cluster: căutăm pod-uri de coredns stupide, verificăm disponibilitatea gazdelor externe. S-ar părea că de ce să vă deranjați cu asta, dar cu volume mari de trafic această componentă este un punct grav de eșec. Anterior eu deja , cum m-am luptat cu performanța DNS într-un cluster.
- Operator Prometheus. Un set de exportatori diferiți oferă o imagine de ansamblu largă asupra tuturor componentelor clusterului. Apoi, vizualizăm toate acestea pe tablouri de bord mari în Grafana și folosim alertmanager pentru alerte.
Un alt instrument util pentru noi a fost . Am scris-o după ce de mai multe ori am întâlnit o situație în care o echipă a suprapus căile de intrare ale altei echipe, rezultând erori de 50 de ori. Acum, înainte de implementarea în producție, dezvoltatorii verifică că nimeni nu va fi afectat, iar pentru echipa mea acesta este un instrument bun pentru diagnosticarea inițială a problemelor cu Ingresses. Este amuzant că la început a fost scris pentru admini și părea destul de „neîndemânatic”, dar după ce echipele de dezvoltatori s-au îndrăgostit de instrument, s-a schimbat mult și a început să nu arate ca „un admin a făcut o față web pentru admin. ” În curând vom abandona acest instrument și astfel de situații vor fi validate chiar înainte ca conducta să fie lansată.
Resurse de echipă în Cub
Înainte de a intra în exemple, merită să explicăm cum alocam resursele microservicii.
Pentru a înțelege ce echipe și în ce cantități le folosesc resurse (procesor, memorie, SSD local), alocam fiecare comanda proprie Spațiu de nume în „Cub” și să-și limiteze capacitățile maxime în ceea ce privește procesorul, memoria și discul, după ce au discutat anterior nevoile echipelor. În consecință, o comandă, în general, nu va bloca întregul cluster pentru implementare, alocând mii de nuclee și terabytes de memorie. Accesul la spațiul de nume este acordat prin AD (folosim RBAC). Spațiile de nume și limitele lor sunt adăugate printr-o cerere de extragere la depozitul GIT, iar apoi totul este lansat automat prin conducta Ansible.
Un exemplu de alocare a resurselor unei echipe:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Cereri și limite
Cuburi" Cerere este numărul de resurse garantate rezervate pentru păstaie (unul sau mai multe containere docker) într-un cluster. Limita este un maxim negarantat. Puteți vedea adesea pe grafice cum o echipă și-a stabilit prea multe solicitări pentru toate aplicațiile sale și nu poate implementa aplicația în „Cub”, deoarece toate cererile din spațiul lor de nume au fost deja „cheltuite”.
Modul corect de ieșire din această situație este să priviți consumul real de resurse și să îl comparați cu suma solicitată (Solicitare).
În capturile de ecran de mai sus puteți vedea că procesoarele „Solicitate” sunt potrivite cu numărul real de fire de execuție, iar Limitele pot depăși numărul real de fire de execuție CPU =)
Acum să ne uităm la un spațiu de nume în detaliu (am ales spațiul de nume kube-system - spațiul de nume de sistem pentru componentele „Cubului” în sine) și să vedem raportul dintre timpul și memoria procesorului utilizat efectiv față de cel solicitat:
Este evident că pentru serviciile de sistem sunt rezervate mult mai multă memorie și procesor decât este folosit de fapt. În cazul sistemului kube, acest lucru este justificat: s-a întâmplat ca controlerul de intrare nginx sau nodelocaldns să lovească CPU-ul și să consume multă memorie RAM, așa că aici o astfel de rezervă este justificată. În plus, nu ne putem baza pe graficele din ultimele 3 ore: este de dorit să vedem valori istorice pe o perioadă mare de timp.
A fost dezvoltat un sistem de „recomandări”. De exemplu, aici puteți vedea care resurse ar fi mai bine să ridice „limitele” (bara superioară permisă) astfel încât să nu aibă loc „accelerarea”: momentul în care o resursă a cheltuit deja CPU sau memorie în intervalul de timp alocat și așteaptă până când va fi „dezghețat”:
Și iată păstăile care ar trebui să-și reducă pofta de mâncare:
despre stropit + monitorizarea resurselor, puteți scrie mai mult de un articol, așa că puneți întrebări în comentarii. În câteva cuvinte, pot spune că sarcina de a automatiza astfel de metrici este foarte dificilă și necesită mult timp și acțiune de echilibrare cu funcțiile „fereastră” și „CTE” Prometheus / VictoriaMetrics (acești termeni sunt între ghilimele, deoarece există aproape nimic de genul acesta în PromQL și trebuie să împărțiți interogările înfricoșătoare în mai multe ecrane de text și să le optimizați).
Ca rezultat, dezvoltatorii au instrumente pentru monitorizarea spațiilor de nume în Cube și pot alege singuri unde și la ce oră ce aplicații își pot „tai” resursele și care servere pot primi întregul procesor toată noaptea.
Metodologii
În companie așa cum este acum la modă, aderăm la DevOps- și EOA-practicant Când o companie are 1000 de microservicii, aproximativ 350 de dezvoltatori și 15 admini pentru întreaga infrastructură, trebuie să „fii la modă”: în spatele tuturor acestor „baswords” există o nevoie urgentă de a automatiza totul și pe toată lumea, iar administratorii nu ar trebui să fie un blocaj. în procese.
În calitate de Ops, oferim diferite valori și tablouri de bord pentru dezvoltatori legate de ratele de răspuns și erorile de serviciu.
Folosim metodologii precum: , и prin combinarea lor împreună. Încercăm să minimizăm numărul de tablouri de bord, astfel încât dintr-o privire să fie clar care serviciu se degradează în prezent (de exemplu, coduri de răspuns pe secundă, timpul de răspuns cu percentila 99) și așa mai departe. De îndată ce unele valori noi devin necesare pentru tablourile de bord generale, le desenăm și le adăugăm imediat.
Nu am desenat grafice de o lună. Acesta este probabil un semn bun: înseamnă că majoritatea „dorințelor” au fost deja realizate. S-a întâmplat ca în timpul săptămânii să desenez un grafic nou cel puțin o dată pe zi.
Rezultatul rezultat este valoros, deoarece acum dezvoltatorii merg destul de rar la administratori cu întrebări „unde să se uite la un fel de măsurătoare”.
introducerea Service Mesh este chiar după colț și ar trebui să ușureze viața tuturor, colegii de la Tools sunt deja aproape de implementarea abstractului „Istio of a healthy person”: ciclul de viață al fiecărei solicitări HTTP(e) va fi vizibil în monitorizare și va fi întotdeauna posibil să înțelegeți „în ce stadiu s-a stricat totul” în timpul interacțiunii inter-servicii (și nu numai). Abonați-vă la știri din hub-ul DomClick. =)
Suport pentru infrastructura Kubernetes
Din punct de vedere istoric, folosim versiunea corectată Kubespray — Rol ansible pentru implementarea, extinderea și actualizarea Kubernetes. La un moment dat, suportul pentru instalațiile non-kubeadm a fost tăiat din ramura principală, iar procesul de trecere la kubeadm nu a fost propus. Drept urmare, compania Southbridge și-a creat propria furcă (cu suport kubeadm și o remediere rapidă pentru problemele critice).
Procesul de actualizare a tuturor clusterelor k8s arată astfel:
- lua Kubespray din Southbridge, verifică cu firul nostru, Merjim.
- Lansăm actualizarea către Stres- "Cub".
- Lansăm actualizarea câte un nod (în Ansible acesta este „serial: 1”) în dev- "Cub".
- Actualizăm Prod sâmbătă seara câte un nod.
Există planuri de înlocuire a acestuia în viitor Kubespray pentru ceva mai rapid și du-te la kubeadm.
În total avem trei „Cuburi”: Stress, Dev și Prod. Avem de gând să lansăm altul (standby fierbinte) Prod-„Cube” în al doilea centru de date. Stres и dev trăiesc în „mașini virtuale” (oVirt for Stress și VMWare cloud for Dev). Prod- „Cube” trăiește pe „bare metal”: acestea sunt noduri identice cu 32 de fire CPU, 64-128 GB de memorie și 300 GB SSD RAID 10 - sunt 50 în total. Trei noduri „subțiri” sunt dedicate „maeștrilor” Prod- „Cuba”: 16 GB de memorie, 12 fire CPU.
Pentru vânzări, preferăm să folosim „metal gol” și să evităm straturi inutile precum OpenStack: nu avem nevoie de „vecini zgomotoși” și CPU fura timp. Iar complexitatea administrării se dublează aproximativ în cazul OpenStack-ului intern.
Pentru CI/CD „Cubic” și alte componente de infrastructură folosim un server GIT separat, Helm 3 (a fost o tranziție destul de dureroasă de la Helm 2, dar suntem foarte mulțumiți de opțiuni). atomic), Jenkins, Ansible și Docker. Ne plac ramurile de caracteristici și implementarea în diferite medii dintr-un singur depozit.
Concluzie
Acesta este, în termeni generali, cum arată procesul DevOps la DomClick din perspectiva unui inginer operațional. Articolul s-a dovedit a fi mai puțin tehnic decât mă așteptam: de aceea, urmăriți știrile DomClick pe Habré: vor fi mai multe articole „hardcore” despre Kubernetes și nu numai.
Sursa: www.habr.com