Mitt navn er Viktor Yagofarov, og jeg utvikler Kubernetes-plattformen hos DomClick som teknisk utviklingssjef i Ops (operasjons)-teamet. Jeg vil gjerne snakke om strukturen til våre Dev <-> Ops-prosesser, om funksjonene ved drift av en av de største k8s-klyngene i Russland, samt om DevOps / SRE-praksisen som teamet vårt bruker.
Team Ops
Ops-teamet har for tiden 15 personer. Tre av dem har ansvar for kontoret, to jobber i en annen tidssone og er tilgjengelig, også om natten. Dermed er noen fra Ops alltid ved monitoren og er klare til å svare på en hendelse av enhver kompleksitet. Vi har ikke nattevakter, noe som bevarer mentaliteten vår og gir alle mulighet til å få nok søvn og tilbringe fritiden ikke bare ved datamaskinen.
Alle har forskjellig kompetanse: nettverkere, DBA-er, ELK-stackspesialister, Kubernetes-administratorer/utviklere, overvåking, virtualisering, maskinvarespesialister, etc. En ting forener alle - alle kan erstatte hvem som helst av oss til en viss grad: for eksempel introdusere nye noder i k8s-klyngen, oppdatere PostgreSQL, skrive en CI / CD + Ansible-pipeline, automatisere noe i Python / Bash / Go, koble til et stykke av maskinvare til DPC. Sterk kompetanse på noe område forstyrrer ikke å endre aktivitetsretningen og begynne å pumpe på et annet område. For eksempel fikk jeg jobb i et selskap som PostgreSQL-spesialist, og nå er mitt hovedansvarsområde Kubernetes-klynger. I teamet er enhver vekst bare velkommen og en følelse av skulder er veldig utviklet.
Vi jakter forresten. Kravene til kandidater er ganske standard. For meg personlig er det viktig at en person passer inn i teamet, er ikke-konflikt, men også vet å forsvare synspunktet sitt, ønsker å utvikle seg og ikke er redd for å gjøre noe nytt, for å tilby sine ideer. Dessuten kreves programmeringsferdigheter i skriptspråk, kunnskap om grunnleggende Linux og engelsk. Engelsk er nødvendig bare slik at en person i tilfelle av en fakap kan google løsningen på problemet på 10 sekunder, og ikke på 10 minutter. Med spesialister med dyp kunnskap om Linux er det nå veldig vanskelig: morsomt, men to av tre kandidater kan ikke svare på spørsmålet "Hva er belastningsgjennomsnitt? Hva består det av?", Og spørsmålet" Hvordan samle en kjernedump fra et sish-program "betraktes som noe fra supermenneskenes verden ... eller dinosaurene. Vi må tåle dette, siden folk vanligvis har høyt utviklet annen kompetanse, og vi skal undervise i Linux. Svaret på spørsmålet "hvorfor trenger en DevOps-ingeniør å vite alt dette i den moderne skyverdenen" må ligge utenfor rammen av artikkelen, men i tre ord: alt dette er nødvendig.
Verktøy kommando
Tools-teamet spiller en betydelig rolle i automatisering. Hovedoppgaven deres er å lage praktiske grafiske og CLI-verktøy for utviklere. For eksempel lar vår interne utvikling av Confer deg rulle ut en applikasjon til Kubernetes med bare noen få museklikk, konfigurere ressursene, nøkler fra hvelv, etc. Det pleide å være Jenkins + Helm 2, men jeg måtte utvikle mitt eget verktøy for å eliminere copy-paste og bringe ensartethet til programvarens livssyklus.
Ops-teamet skriver ikke pipelines for utviklere, men kan gi råd om eventuelle problemer ved å skrive dem (noen har fortsatt Helm 3).
DevOps
Når det gjelder DevOps, ser vi det slik:
Utviklerteam skriver kode, ruller den ut via Confer to dev -> qa/stage -> prod. Det er Dev- og Ops-teamenes ansvar å sikre at koden ikke bremser ned og ikke gir feil. På dagtid bør vakthavende fra Ops-teamet svare på en hendelse med søknaden sin, og på kvelden og natten bør vakthavende admin (Ops) vekke vakthavende utvikler hvis han vet med sikkerhet at problemet ikke er i infrastrukturen. Alle beregninger og varsler i overvåking vises automatisk eller halvautomatisk.
Ansvarsområdet til Ops begynner fra det øyeblikket applikasjonen rulles ut til produksjonen, men ansvaret til Dev slutter ikke der - vi gjør én ting og er i samme båt.
Utviklere gir råd til administratorer hvis de trenger hjelp til å skrive en admin-mikrotjeneste (for eksempel Go backend + HTML5), og administratorer gir råd til utviklere om eventuelle infrastruktur- eller k8s-relaterte problemer.
Forresten, vi har ikke en monolitt i det hele tatt, bare mikrotjenester. Antallet deres så langt svinger mellom 900 og 1000 i prod k8s-klyngen, hvis det måles med tallet distribusjoner. Antall pods svinger mellom 1700 og 2000. Podene i prod-klyngen er nå rundt 2000.
Jeg kan ikke gi eksakte tall, siden vi overvåker unødvendige mikrotjenester og kutter dem ut i en halvautomatisk modus. Å holde styr på unødvendige enheter i k8s hjelper oss som sparer ressurser og penger.
Ressursforvaltning
overvåking
Kompetent bygget og informativ overvåking blir hjørnesteinen i driften av en stor klynge. Vi har ennå ikke funnet en universalløsning som vil dekke 100 % av alle overvåkingsbehov, så vi nagler med jevne mellomrom forskjellige tilpassede løsninger i dette miljøet.
- Zabbix. God gammel overvåking, som først og fremst er designet for å overvåke den generelle tilstanden til infrastrukturen. Den forteller oss når en node dør av prosessor, minne, disker, nettverk og så videre. Ikke noe overnaturlig, men vi har også et eget DaemonSet med agenter, ved hjelp av dette overvåker vi for eksempel DNS-tilstanden i klyngen: vi ser etter dumme coredns-poder, vi sjekker tilgjengeligheten til eksterne verter. Det ser ut til at hvorfor bry seg for det, men på store mengder trafikk er denne komponenten et alvorlig feilpunkt. Tidligere har jeg hvordan slet med DNS-ytelse i klyngen.
- Prometheus-operatør. Et sett med forskjellige eksportører gir en flott oversikt over alle klyngekomponenter. Deretter visualiserer vi alt dette på store dashbord i Grafana, og bruker alertmanager for varsler.
Et annet nyttig verktøy for oss er . Vi skrev det etter at vi flere ganger møtte en situasjon der ett lag overlappet et annet lags Ingress med sine baner, noe som forårsaket 50x feil. Nå, før de distribueres til produksjon, sjekker utviklere at de ikke vil skade noen, og for teamet mitt er dette et godt verktøy for den første diagnosen av problemer med Ingresses. Det er morsomt at det først ble skrevet for administratorer, og det så ganske "klossete ut", men etter at utviklerteamene ble forelsket i verktøyet, endret det seg mye og begynte å se ut som "admin laget et nettfjes for administratorer" . Snart vil vi forlate dette verktøyet og slike situasjoner vil bli validert selv før rørledningen rulles ut.
Teamressurser i "Cube"
Før vi går videre med eksemplene er det verdt å forklare hvordan vi har ressursallokering til mikrotjenester.
For å forstå hvilke lag og i hvilke mengder bruker deres ресурсы (prosessor, minne, lokal SSD), tildeler vi vår egen namespace i "kuben" og begrense dens maksimale evner når det gjelder prosessor, minne og disk, etter å ha diskutert behovene til lagene tidligere. Følgelig vil en kommando, i det generelle tilfellet, ikke blokkere hele klyngen for distribusjon, og tildele tusenvis av kjerner og terabyte med minne til seg selv. Tilgang til navneområdet utstedes gjennom AD (vi bruker RBAC). Navneområder og deres grenser legges til via en pull-forespørsel til GIT-depotet, og deretter rulles alt automatisk ut via Ansible-rørledningen.
Et eksempel på ressursallokering per team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Forespørsler og begrensninger
terninger" Be er antall garanterte reserverte ressurser under pod (en eller flere docker-containere) i en klynge. Grensen er et ikke-garantert maksimum. Du kan ofte se på diagrammene hvordan et team har angitt for mange forespørsler for alle applikasjonene sine og ikke kan distribuere applikasjonen til "kuben", siden alle forespørsler allerede er "brukt" under navneområdet.
Den riktige veien ut av denne situasjonen er å se på det faktiske ressursforbruket og sammenligne det med det forespurte beløpet (Request).
Skjermbildene ovenfor viser at de "forespurte" (Forespurte) CPUene er valgt til det reelle antallet tråder, og grensene kan overskride det reelle antallet CPU-tråder =)
La oss nå se nærmere på noe navneområde (jeg valgte navneområdet kube-system - systemnavneområdet for komponentene i selve "kuben") og se forholdet mellom den faktisk brukte prosessortiden og minnet til den forespurte:
Det er åpenbart at det er mye mer minne og CPU reservert for systemtjenester enn det som faktisk brukes. I tilfellet med kube-systemet er dette berettiget: det hendte at nginx-inngangskontrolleren eller nodelocaldns på toppen hvilte på CPU-en og spiste mye RAM, så her er en slik margin berettiget. I tillegg kan vi ikke stole på diagrammer for de siste 3 timene: det er ønskelig å se historiske beregninger over en lang tidsperiode.
Et system med "anbefalinger" ble utviklet. Her kan du for eksempel se hvilke ressurser det er bedre å heve "grensene" (den øvre tillatte linjen) slik at "struping" ikke oppstår: øyeblikket når poden allerede har brukt CPU eller minne i den tildelte tidskvanten og venter til den skal "oppfryses":
Og her er belgene som bør moderere appetitten:
Про struping + overvåkingsressurser, du kan skrive mer enn én artikkel, så still spørsmål i kommentarfeltet. Med noen få ord kan jeg si at oppgaven med å automatisere slike beregninger er svært vanskelig og krever mye tid og balansegang med "vindu"-funksjoner og "CTE" Prometheus / VictoriaMetrics (disse termene er i anførselstegn, siden det er nesten ingenting som dette i PromQL, og du må skjerme skumle spørsmål på flere tekstskjermer og optimalisere dem).
Som et resultat av dette har utviklere verktøy for å overvåke navneområdene sine i «kuben», og de kan velge hvor og når hvilke applikasjoner kan «kutte» ressurser, og hvilke poder som kan gis hele CPUen hele natten.
Metoder
I selskap som nå fasjonable, følger vi DevOps- og SRE-utøver Når et selskap har 1000 mikrotjenester, rundt 350 utviklere og 15 administratorer for hele infrastrukturen, må du "være moteriktig": bak alle disse "buzzwords" er det et presserende behov for å automatisere alt og alt, og administratorer bør ikke være en flaskehals i prosesser.
Som Ops tilbyr vi ulike beregninger og dashbord for utviklere relatert til responstiden til tjenestene og deres feil.
Vi bruker metoder som: , и ved å kombinere dem. Vi prøver å minimere antall dashboards slik at det med et øyeblikk er tydelig hvilken tjeneste som for øyeblikket er forringende (for eksempel svarkoder per sekund, responstid på 99. persentilen) og så videre. Så snart noen nye beregninger for generelle dashboards blir nødvendige, tegner og legger vi dem umiddelbart til.
Jeg har ikke tegnet grafikk på en måned nå. Dette er sannsynligvis et godt tegn: det betyr at de fleste "ønsker" allerede er implementert. Det hendte at jeg i en uke tegnet et nytt diagram minst en gang om dagen.
Det resulterende resultatet er verdifullt ved at nå utviklere sjelden går til administratorer med spørsmål "hvor de kan se noen slags beregninger".
Gjennomføring Service Mesh er rett rundt hjørnet og burde gjøre livet mye enklere for alle, kolleger fra Tools er allerede i nærheten av å implementere det abstrakte «Istio of a sunn person»: livssyklusen til hver HTTP(er)-forespørsel vil være synlig i overvåkingen, og det vil alltid være mulig å forstå "på hvilket stadium alt brøt sammen" ved interservice (og ikke bare) interaksjon. Abonner på nyheter fra DomClick-huben. =)
Kubernetes infrastrukturstøtte
Historisk sett bruker vi den lappede versjonen Kubespray - Ansible rolle for distribusjon, utvidelse og oppdatering av Kubernetes. På et tidspunkt ble støtte for ikke-kubeadm-installasjoner kuttet fra hovedgrenen, og overgangsprosessen til kubeadm ble ikke foreslått. Som et resultat laget Southbridge sin egen gaffel (med støtte for kubeadm og en rask løsning for kritiske problemer).
Oppgraderingsprosessen for alle k8s-klynger ser slik ut:
- ta Kubespray fra Southbridge, sjekk med vår filial, merjim.
- Ruller ut oppdateringen til Stress- "Kube".
- Vi ruller ut oppdateringen en node om gangen (i Ansible er dette "seriell: 1") i dev- "Kube".
- Oppdaterer Prod på lørdag kveld, én node om gangen.
I fremtiden er det planer om å erstatte Kubespray til noe raskere og gå til kubeadm.
Totalt har vi tre «kuber»: Stress, Dev og Prod. Vi planlegger å lansere en annenvarm standby) Prod- "Cube" i det andre datasenteret. Stress и dev live i virtuelle maskiner (oVirt for Stress og VMWare cloud for Dev). Prod– «Cube» lever på «bare metal» (bare metal): dette er de samme nodene med 32 CPU-tråder, 64-128 GB minne og 300 GB SSD RAID 10 – det er 50 av dem totalt. Tre "tynne" noder er dedikert til "mestere" Prod- "Cuba": 16 GB minne, 12 CPU-tråder.
For salg foretrekker vi å bruke "bart metall" og unngå unødvendige lag som Openstack: vi trenger ikke "støyende naboer" og CPU stjele tid. Og kompleksiteten i administrasjonen øker med omtrent halvparten i tilfellet med intern OpenStack.
For CI/CD Cubic og andre infrastrukturkomponenter bruker vi en egen GIT-server, Helm 3 atomic), Jenkins, Ansible og Docker. Vi elsker funksjonsgrener og distribuerer til forskjellige miljøer fra samme depot.
Konklusjon
Slik ser DevOps-prosessen på DomClick generelt ut fra siden til en driftsingeniør. Artikkelen viste seg å være mindre teknisk enn jeg forventet: følg derfor DomClick-nyhetene på Habré: det vil komme flere "hardcore" artikler om Kubernetes og mer.
Kilde: www.habr.com