Mit navn er Viktor Yagofarov, og jeg udvikler Kubernetes-platformen hos DomClick som teknisk udviklingschef i Ops (drift)-teamet. Jeg vil gerne tale om strukturen af vores Dev <-> Ops-processer, funktionerne ved at drive en af de største k8s-klynger i Rusland, samt DevOps/SRE-praksis, som vores team anvender.
Ops Team
Ops-teamet har i øjeblikket 15 personer. Tre af dem er ansvarlige for kontoret, to arbejder i en anden tidszone og er til rådighed, også om natten. En person fra Ops er således altid ved skærmen og klar til at reagere på en hændelse af enhver kompleksitet. Vi har ikke nattevagter, hvilket bevarer vores psyke og giver alle mulighed for at få nok søvn og bruge fritiden ikke kun ved computeren.
Alle har forskellige kompetencer: netværkere, DBA'er, ELK stack specialister, Kubernetes administratorer/udviklere, overvågning, virtualisering, hardware specialister osv. Én ting forener alle - alle kan erstatte enhver af os til en vis grad: for eksempel introducere nye noder i k8s-klyngen, opdatere PostgreSQL, skrive en CI/CD + Ansible pipeline, automatisere noget i Python/Bash/Go, tilslutte hardware til Datacenter. Stærke kompetencer inden for ethvert område forhindrer dig ikke i at ændre din aktivitetsretning og begynde at forbedre dig på et andet område. For eksempel kom jeg til en virksomhed som PostgreSQL-specialist, og nu er mit hovedansvarsområde Kubernetes-klynger. I teamet er enhver højde velkommen, og følelsen af løftestang er meget udviklet.
Vi er i øvrigt på jagt. Krav til kandidater er ret standard. For mig personligt er det vigtigt, at en person passer ind i teamet, er ikke-konflikt, men også forstår at forsvare sit synspunkt, vil udvikle sig og ikke er bange for at lave noget nyt, byder på sine ideer. Også programmeringsfærdigheder i scriptsprog, kendskab til det grundlæggende i Linux og engelsk er påkrævet. Engelsk er nødvendig simpelthen for at en person i tilfælde af en fakap kan google en løsning på problemet på 10 sekunder, og ikke på 10 minutter. Det er nu meget svært at finde specialister med dyb viden om Linux: det er sjovt, men to ud af tre kandidater kan ikke svare på spørgsmålet "Hvad er belastningsgennemsnit? Hvad er det lavet af?”, og spørgsmålet “Hvordan samler man en kernedump fra et C-program” betragtes som noget fra supermændenes verden... eller dinosaurerne. Det må vi affinde os med, da folk normalt har højt udviklede andre kompetencer, men vi vil undervise i Linux. Svaret på spørgsmålet "hvorfor har en DevOps-ingeniør brug for at vide alt dette i den moderne verden af skyer" skal efterlades uden for artiklens rammer, men i tre ord: alt dette er nødvendigt.
Teamværktøjer
Værktøjsteamet spiller en væsentlig rolle i automatisering. Deres hovedopgave er at skabe praktiske grafiske og CLI-værktøjer til udviklere. For eksempel giver vores interne udvikling Confer dig mulighed for bogstaveligt talt at rulle en applikation ud til Kubernetes med blot et par museklik, konfigurere dens ressourcer, nøgler fra vault osv. Tidligere var der Jenkins + Helm 2, men jeg var nødt til at udvikle mit eget værktøj til at eliminere copy-paste og bringe ensartethed til softwarens livscyklus.
Ops-teamet skriver ikke pipelines til udviklere, men kan rådgive om eventuelle problemer i deres skrivning (nogle mennesker har stadig Helm 3).
DevOps
Hvad angår DevOps, ser vi det sådan her:
Dev-teams skriver kode, ruller den ud via Confer to dev -> qa/stage -> prod. Ansvaret for at sikre, at koden ikke bremser og ikke indeholder fejl, ligger hos Dev- og Ops-teamene. I dagtimerne skal den vagthavende fra Ops-teamet først og fremmest reagere på en hændelse med sin ansøgning, og om aftenen og natten skal vagthavende administrator (Ops) vække vagthavende udvikler, hvis han ved for sikker på, at problemet ikke er i infrastrukturen. Alle målinger og advarsler i overvågning vises automatisk eller semi-automatisk.
Ops' ansvarsområde begynder fra det øjeblik, applikationen rulles ud i produktionen, men Dev's ansvar slutter ikke der - vi gør det samme og er i samme båd.
Udviklere rådgiver administratorer, hvis de har brug for hjælp til at skrive en administratormikrotjeneste (for eksempel Go backend + HTML5), og administratorer rådgiver udviklere om infrastrukturproblemer eller problemer relateret til k8s.
I øvrigt har vi slet ikke en monolit, kun mikrotjenester. Deres antal svinger indtil videre mellem 900 og 1000 i prod k8s-klyngen, hvis målt efter antal implementeringer. Antallet af bælg svinger mellem 1700 og 2000. Der er i øjeblikket omkring 2000 bælg i prod-klyngen.
Jeg kan ikke give nøjagtige tal, da vi overvåger unødvendige mikrotjenester og skærer dem halvautomatisk ud. K8s hjælper os med at holde styr på unødvendige enheder , hvilket sparer mange ressourcer og penge.
Ressourcestyring
overvågning
Velstruktureret og informativ overvågning bliver hjørnestenen i driften af en stor klynge. Vi har endnu ikke fundet en universel løsning, der dækker 100 % af alle overvågningsbehov, så vi skaber med jævne mellemrum forskellige tilpassede løsninger i dette miljø.
- Zabbix. God gammel overvågning, som primært har til formål at spore den overordnede tilstand af infrastrukturen. Den fortæller os, hvornår en node dør med hensyn til behandling, hukommelse, diske, netværk og så videre. Intet overnaturligt, men vi har også et separat DaemonSet af agenter, ved hjælp af hvilket vi for eksempel overvåger tilstanden af DNS i klyngen: vi leder efter dumme coredns-pods, vi tjekker tilgængeligheden af eksterne værter. Det ser ud til, at hvorfor bekymre sig om dette, men med store mængder trafik er denne komponent en alvorlig fejl. jeg allerede , hvordan jeg kæmpede med DNS-ydeevne i en klynge.
- Prometheus operatør. Et sæt af forskellige eksportører giver et stort overblik over alle komponenter i klyngen. Dernæst visualiserer vi alt dette på store dashboards i Grafana og bruger alertmanager til advarsler.
Et andet nyttigt værktøj for os var . Vi skrev det, efter at vi flere gange stødte på en situation, hvor et hold overlappede et andet holds Ingress-stier, hvilket resulterede i 50x fejl. Inden de implementeres til produktion, kontrollerer udviklere, at ingen vil blive berørt, og for mit team er dette et godt værktøj til den indledende diagnose af problemer med Ingresses. Det er sjovt, at det først var skrevet til administratorer, og det så ret "klodt ud", men efter at udviklerholdene blev forelsket i værktøjet, ændrede det sig meget og begyndte ikke at ligne "en administrator lavede et webansigt til administratorer. ” Snart vil vi opgive dette værktøj, og sådanne situationer vil blive valideret, selv før pipelinen rulles ud.
Teamressourcer i terningen
Før vi kommer ind på eksemplerne, er det værd at forklare, hvordan vi allokerer ressourcer til mikrotjenester.
For at forstå hvilke hold og i hvilke mængder der bruger deres ресурсы (processor, hukommelse, lokal SSD), tildeler vi hver kommando sin egen navnerum i "Terningen" og begrænse dens maksimale muligheder i form af processor, hukommelse og disk, efter at have tidligere diskuteret holdenes behov. Følgelig vil en kommando generelt ikke blokere hele klyngen for udrulning, idet den allokerer tusindvis af kerner og terabyte hukommelse. Adgang til navneområde gives gennem AD (vi bruger RBAC). Navneområder og deres grænser tilføjes via en pull-anmodning til GIT-lageret, og så rulles alt automatisk ud gennem Ansible-pipelinen.
Et eksempel på tildeling af ressourcer til et team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Anmodninger og begrænsninger
terninger" Anmod om er antallet af garanterede reserverede ressourcer til Pod (en eller flere docker-containere) i en klynge. Grænsen er et ikke-garanteret maksimum. Du kan ofte se på graferne, hvordan nogle team har sat sig for mange anmodninger til alle sine applikationer og ikke kan implementere applikationen til "kuben", da alle anmodninger under deres navneområde allerede er blevet "brugt".
Den korrekte vej ud af denne situation er at se på det faktiske ressourceforbrug og sammenligne det med det ønskede beløb (Request).
I skærmbillederne ovenfor kan du se, at "anmodede" CPU'er matches til det reelle antal tråde, og grænser kan overstige det reelle antal CPU-tråde =)
Lad os nu se på noget navneområde i detaljer (jeg valgte navneområde kube-system - systemnavneområdet for komponenterne i selve "kuben") og se forholdet mellem faktisk brugt processortid og hukommelse til den anmodede:
Det er indlysende, at meget mere hukommelse og CPU er reserveret til systemtjenester, end der faktisk bruges. I tilfældet med kube-systemet er dette berettiget: det skete, at nginx ingress controller eller nodelocaldns på deres højeste ramte CPU'en og forbrugte en masse RAM, så her er en sådan reserve berettiget. Derudover kan vi ikke stole på diagrammer for de sidste 3 timer: det er ønskeligt at se historiske målinger over en længere periode.
Et system med "anbefalinger" blev udviklet. For eksempel kan du her se, hvilke ressourcer der ville være bedre stillet ved at hæve "grænserne" (den øverste tilladte bjælke), så "throttling" ikke forekommer: det øjeblik, hvor en ressource allerede har brugt CPU eller hukommelse i det tildelte tidsudsnit og venter, indtil den bliver "frosset op":
Og her er de bælg, der bør dæmpe deres appetit:
Про drosling + ressourceovervågning, du kan skrive mere end én artikel, så stil spørgsmål i kommentarerne. Med få ord kan jeg sige, at opgaven med at automatisere sådanne metrikker er meget vanskelig og kræver meget tid og balancegang med "vindue"-funktioner og "CTE" Prometheus / VictoriaMetrics (disse udtryk er i anførselstegn, da der næsten er intet lignende i PromQL, og du skal opdele skræmmende forespørgsler i flere tekstskærme og optimere dem).
Som følge heraf har udviklere værktøjer til at overvåge deres navneområder i Cube, og de er i stand til selv at vælge, hvor og på hvilket tidspunkt, hvilke applikationer der kan få deres ressourcer "skåret", og hvilke servere der kan få hele CPU'en hele natten lang.
Metoder
I virksomheden, som den er nu på mode, vi overholder DevOps- og SRE-praktiserende læge Når en virksomhed har 1000 mikrotjenester, omkring 350 udviklere og 15 administratorer til hele infrastrukturen, skal du "være moderigtigt": bag alle disse "baswords" er der et presserende behov for at automatisere alt og alle, og administratorer bør ikke være en flaskehals i processer.
Som Ops leverer vi forskellige metrics og dashboards til udviklere relateret til serviceresponsrater og fejl.
Vi bruger metoder som: , и ved at kombinere dem. Vi forsøger at minimere antallet af dashboards, så det med et øjeblik er tydeligt, hvilken tjeneste der i øjeblikket er nedværdigende (f.eks. svarkoder pr. sekund, svartid med 99. percentil) og så videre. Så snart nogle nye målinger bliver nødvendige for generelle dashboards, tegner og tilføjer vi dem straks.
Jeg har ikke tegnet grafer i en måned. Dette er sandsynligvis et godt tegn: det betyder, at de fleste "ønsker" allerede er blevet realiseret. Det skete, at jeg i løbet af ugen tegnede en ny graf mindst en gang om dagen.
Det resulterende resultat er værdifuldt, fordi udviklere nu ret sjældent går til administratorer med spørgsmål "hvor man kan se på en slags metrisk."
indførelsen af Service Mesh er lige om hjørnet og burde gøre livet meget lettere for alle, kolleger fra Tools er allerede tæt på at implementere det abstrakte "Istio of a sund person": livscyklussen for hver HTTP(er)-anmodning vil være synlig i overvågningen, og det vil altid være muligt at forstå "på hvilket stadium alt gik i stykker" under inter-service (og ikke kun) interaktion. Abonner på nyheder fra DomClick-hubben. =)
Kubernetes infrastruktur support
Historisk set bruger vi den lappede version Kubespray — Ansible rolle for implementering, udvidelse og opdatering af Kubernetes. På et tidspunkt blev støtten til ikke-kubeadm-installationer skåret fra hovedgrenen, og processen med at skifte til kubeadm blev ikke foreslået. Som et resultat lavede Southbridge-virksomheden sin egen gaffel (med kubeadm-understøttelse og en hurtig løsning til kritiske problemer).
Processen til opdatering af alle k8s-klynger ser sådan ud:
- tage Kubespray fra Southbridge, tjek med vores tråd, Merjim.
- Vi udruller opdateringen til Stress- "Terning".
- Vi udruller opdateringen én node ad gangen (i Ansible er dette "seriel: 1") i dev- "Terning".
- Vi opdaterer Prod lørdag aften én node ad gangen.
Der er planer om at udskifte den i fremtiden Kubespray for noget hurtigere og gå til kubeadm.
I alt har vi tre "kuber": Stress, Dev og Prod. Vi planlægger at lancere endnu en (varm standby) Prod-“Cube” i det andet datacenter. Stress и dev live i "virtuelle maskiner" (oVirt for Stress og VMWare cloud for Dev). Prod- "Cube" lever af "bart metal": det er identiske noder med 32 CPU-tråde, 64-128 GB hukommelse og 300 GB SSD RAID 10 - der er 50 af dem i alt. Tre "tynde" noder er dedikeret til "mestre" Prod- "Cuba": 16 GB hukommelse, 12 CPU-tråde.
Til salg foretrækker vi at bruge "bart metal" og undgå unødvendige lag som OpenStack: vi har ikke brug for "støjende naboer" og CPU stjæle tid. Og kompleksiteten af administrationen fordobles tilnærmelsesvis i tilfælde af in-house OpenStack.
Til CI/CD "Cubic" og andre infrastrukturkomponenter bruger vi en separat GIT-server, Helm 3 (det var en ret smertefuld overgang fra Helm 2, men vi er meget tilfredse med mulighederne atomare), Jenkins, Ansible og Docker. Vi elsker funktionsgrene og udrulning til forskellige miljøer fra ét lager.
Konklusion
Dette er generelt, hvordan DevOps-processen ser ud hos DomClick fra en driftsingeniørs perspektiv. Artiklen viste sig at være mindre teknisk, end jeg havde forventet: følg derfor DomClick-nyhederne på Habré: der vil være flere "hardcore" artikler om Kubernetes og mere.
Kilde: www.habr.com