Jag heter Viktor Yagofarov, och jag utvecklar Kubernetes-plattformen på DomClick som teknisk utvecklingschef i Ops (drift)-teamet. Jag skulle vilja prata om strukturen för våra Dev <-> Ops-processer, funktionerna för att driva ett av de största k8s-klustren i Ryssland, såväl som DevOps/SRE-praxis som vårt team tillämpar.
Ops Team
Ops-teamet har för närvarande 15 personer. Tre av dem ansvarar för kontoret, två arbetar i en annan tidszon och är tillgängliga, även på natten. Således är någon från Ops alltid vid monitorn och redo att svara på en incident av vilken komplexitet som helst. Vi har inga nattpass, vilket bevarar vårt psyke och ger alla möjlighet att få tillräckligt med sömn och spendera fritid, inte bara vid datorn.
Alla har olika kompetenser: nätverkare, DBA:er, ELK stackspecialister, Kubernetes administratörer/utvecklare, övervakning, virtualisering, hårdvaruspecialister, etc. En sak förenar alla - alla kan ersätta vem som helst av oss till viss del: till exempel introducera nya noder i k8s-klustret, uppdatera PostgreSQL, skriva en CI/CD + Ansible pipeline, automatisera något i Python/Bash/Go, ansluta hårdvara till Datacenter. Starka kompetenser inom något område hindrar dig inte från att ändra din aktivitetsriktning och börja förbättra dig inom något annat område. Till exempel gick jag med i ett företag som PostgreSQL-specialist, och nu är mitt huvudsakliga ansvarsområde Kubernetes-kluster. I laget är alla höjder välkomna och känslan av hävstång är mycket utvecklad.
Förresten, vi jagar. Krav på kandidater är ganska standard. För mig personligen är det viktigt att en person passar in i teamet, är konfliktfri, men också vet hur han ska försvara sin synpunkt, vill utvecklas och inte är rädd för att göra något nytt, erbjuder sina idéer. Dessutom krävs programmeringskunskaper i skriptspråk, kunskap om grunderna i Linux och engelska. Engelska behövs helt enkelt för att en person i händelse av en fakap ska kunna googla en lösning på problemet på 10 sekunder, och inte på 10 minuter. Det är nu väldigt svårt att hitta specialister med djup kunskap om Linux: det är roligt, men två av tre kandidater kan inte svara på frågan "Vad är belastningsgenomsnittet? Vad är den gjord av?”, och frågan ”Hur man monterar en kärndump från ett C-program” anses vara något från supermännens värld... eller dinosaurierna. Vi får stå ut med detta, eftersom folk vanligtvis har högt utvecklade andra kompetenser, men vi kommer att lära ut Linux. Svaret på frågan "varför behöver en DevOps-ingenjör veta allt detta i den moderna molnvärlden" måste lämnas utanför artikelns ram, men i tre ord: allt detta behövs.
Teamverktyg
Tools-teamet spelar en viktig roll inom automatisering. Deras huvudsakliga uppgift är att skapa praktiska grafiska och CLI-verktyg för utvecklare. Till exempel låter vår interna utveckling Confer dig bokstavligen rulla ut en applikation till Kubernetes med bara några musklick, konfigurera dess resurser, nycklar från valvet, etc. Tidigare fanns Jenkins + Helm 2, men jag var tvungen att utveckla mitt eget verktyg för att eliminera copy-paste och skapa enhetlighet i mjukvarans livscykel.
Ops-teamet skriver inte pipelines för utvecklare, men kan ge råd om eventuella problem när de skriver (vissa har fortfarande Helm 3).
DevOps
När det gäller DevOps ser vi det så här:
Utvecklarteam skriver kod, rullar ut den via Confer to dev -> qa/stage -> prod. Ansvaret för att se till att koden inte saktar ner och inte innehåller fel ligger hos Dev- och Ops-teamen. På dagtid ska vakthavande från Ops-teamet först och främst svara på en incident med sin ansökan och på kvällen och natten ska vakthavande handläggare (Ops) väcka den jourhavande utvecklaren om han vet för säker på att problemet inte finns i infrastrukturen. Alla mätvärden och varningar i övervakning visas automatiskt eller halvautomatiskt.
Ops ansvarsområde börjar från det att applikationen rullas ut i produktion, men Devs ansvar slutar inte där – vi gör samma sak och är i samma båt.
Utvecklare ger råd till administratörer om de behöver hjälp med att skriva en administratörsmikrotjänst (till exempel Go backend + HTML5), och administratörer ger råd till utvecklare om infrastrukturproblem eller problem relaterade till k8s.
Förresten, vi har ingen monolit alls, bara mikrotjänster. Deras antal fluktuerar hittills mellan 900 och 1000 i prod k8s-klustret, om de mäts med antal distributioner. Antalet baljor varierar mellan 1700 och 2000. Det finns för närvarande cirka 2000 baljor i prodklustret.
Jag kan inte ge exakta siffror, eftersom vi övervakar onödiga mikrotjänster och skär ut dem halvautomatiskt. K8s hjälper oss att hålla reda på onödiga enheter , vilket sparar mycket resurser och pengar.
Resurshantering
övervakning
Välstrukturerad och informativ övervakning blir hörnstenen i driften av ett stort kluster. Vi har ännu inte hittat en universell lösning som skulle täcka 100 % av alla övervakningsbehov, så vi skapar med jämna mellanrum olika skräddarsydda lösningar i den här miljön.
- Zabbix. Gammal god övervakning, som i första hand syftar till att spåra infrastrukturens övergripande skick. Den talar om för oss när en nod dör när det gäller bearbetning, minne, diskar, nätverk och så vidare. Inget övernaturligt, men vi har också en separat DaemonSet av agenter, med hjälp av vilka vi till exempel övervakar DNS-tillståndet i klustret: vi letar efter dumma coredns-pods, vi kontrollerar tillgängligheten för externa värdar. Det verkar som varför bry sig om detta, men med stora trafikvolymer är denna komponent ett allvarligt misslyckande. Tidigare har jag redan , hur jag kämpade med DNS-prestanda i ett kluster.
- Prometheus operatör. En uppsättning olika exportörer ger en stor översikt över alla komponenter i klustret. Därefter visualiserar vi allt detta på stora instrumentpaneler i Grafana och använder alertmanager för varningar.
Ett annat användbart verktyg för oss var . Vi skrev det efter att vi flera gånger stött på en situation där ett lag överlappade ett annat lags Ingress-vägar, vilket resulterade i 50x fel. Nu innan de distribueras till produktion kontrollerar utvecklarna att ingen kommer att påverkas, och för mitt team är detta ett bra verktyg för den första diagnosen av problem med Ingresses. Det är roligt att det till en början var skrivet för administratörer och det såg ganska "klumpigt ut", men efter att utvecklarteamen blev förälskade i verktyget förändrades det mycket och började inte se ut som "en administratör gjorde ett webbansikte för administratörer. ” Snart kommer vi att överge detta verktyg och sådana situationer kommer att valideras redan innan pipelinen rullas ut.
Teamresurser i kuben
Innan vi går in på exemplen är det värt att förklara hur vi allokerar resurser till mikrotjänster.
För att förstå vilka lag och i vilka mängder som använder sina Resurser (processor, minne, lokal SSD), tilldelar vi varje kommando sitt eget namespace i "kuben" och begränsa dess maximala kapacitet när det gäller processor, minne och disk, efter att tidigare diskuterat teamens behov. Följaktligen kommer ett kommando i allmänhet inte att blockera hela klustret för utplacering, och allokera tusentals kärnor och terabyte minne. Tillgång till namnutrymmet ges genom AD (vi använder RBAC). Namnutrymmen och deras gränser läggs till via en pull-begäran till GIT-förvaret, och sedan rullas allt automatiskt ut genom Ansible-pipelinen.
Ett exempel på att allokera resurser till ett team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Förfrågningar och gränser
Kubbad" FÖRFRÅGAN är antalet garanterade reserverade resurser för pod (en eller flera hamnarcontainrar) i ett kluster. Gränsen är ett icke-garanterat maximum. Du kan ofta se på graferna hur ett team har ställt in för många förfrågningar för alla sina applikationer och inte kan distribuera applikationen till "kuben", eftersom alla förfrågningar under deras namnområde redan har "förbrukats".
Den korrekta vägen ur denna situation är att titta på den faktiska resursförbrukningen och jämföra den med den begärda mängden (Request).
I skärmdumparna ovan kan du se att "begärda" CPU:er matchas till det verkliga antalet trådar, och gränser kan överskrida det verkliga antalet CPU-trådar =)
Låt oss nu titta på lite namnutrymme i detalj (jag valde namnutrymme kube-system - systemnamnområdet för komponenterna i själva "kuben") och se förhållandet mellan faktiskt använd processortid och minne till den begärda:
Det är uppenbart att mycket mer minne och CPU är reserverat för systemtjänster än vad som faktiskt används. I fallet med kube-systemet är detta motiverat: det hände att nginx ingress controller eller nodelocaldns vid sin topp träffade CPU:n och förbrukade mycket RAM, så här är en sådan reserv berättigad. Dessutom kan vi inte lita på diagram för de senaste 3 timmarna: det är önskvärt att se historiska mätvärden över en lång tidsperiod.
Ett system med "rekommendationer" utvecklades. Här kan du till exempel se vilka resurser som skulle vara bättre att höja "gränserna" (den övre tillåtna stapeln) så att "strypning" inte inträffar: det ögonblick då en resurs redan har spenderat CPU eller minne i den tilldelade tidsdelen och väntar tills den kommer att "uppfrysas":
Och här är baljorna som borde dämpa deras aptit:
Про strypning + resursövervakning, du kan skriva mer än en artikel, så ställ frågor i kommentarerna. Med några få ord kan jag säga att uppgiften att automatisera sådana mätvärden är mycket svår och kräver mycket tid och balansgång med "fönster"-funktioner och "CTE" Prometheus / VictoriaMetrics (dessa termer står inom citattecken, eftersom det nästan finns inget liknande i PromQL, och du måste dela upp läskiga frågor i flera textskärmar och optimera dem).
Som ett resultat har utvecklare verktyg för att övervaka sina namnområden i Cube, och de kan själva välja var och vid vilken tidpunkt vilka applikationer som kan få sina resurser "kapade" och vilka servrar som kan få hela CPU:n hela natten.
Metoder
I företaget som det är nu modern, följer vi DevOps- och SRE-praktiker När ett företag har 1000 mikrotjänster, cirka 350 utvecklare och 15 administratörer för hela infrastrukturen, måste du "vara på modet": bakom alla dessa "baswords" finns det ett akut behov av att automatisera allt och alla, och administratörer ska inte vara en flaskhals i processer.
Som Ops tillhandahåller vi olika mätvärden och instrumentpaneler för utvecklare relaterade till servicesvarsfrekvenser och fel.
Vi använder metoder som: , и genom att kombinera dem. Vi försöker minimera antalet instrumentpaneler så att det vid ett ögonkast är tydligt vilken tjänst som för närvarande försämras (till exempel svarskoder per sekund, svarstid med 99:e percentilen) och så vidare. Så snart några nya mätvärden blir nödvändiga för allmänna instrumentpaneler, ritar vi omedelbart och lägger till dem.
Jag har inte ritat grafer på en månad. Detta är förmodligen ett gott tecken: det betyder att de flesta av "önskningarna" redan har förverkligats. Det hände att jag under veckan ritade någon ny graf minst en gång om dagen.
Det resulterande resultatet är värdefullt eftersom utvecklare nu ganska sällan går till administratörer med frågor "var man kan titta på någon form av mätvärde."
införande av Service Mesh är precis runt hörnet och borde göra livet mycket enklare för alla, kollegor från Tools är redan nära att implementera det abstrakta "Istio för en frisk person": livscykeln för varje HTTP-förfrågan kommer att synas i övervakningen, och det kommer alltid att vara möjligt att förstå "i vilket skede allt gick sönder" under inter-service (och inte bara) interaktion. Prenumerera på nyheter från DomClick-hubben. =)
Kubernetes infrastrukturstöd
Historiskt sett använder vi den korrigerade versionen Kubespray — Ansible roll för att distribuera, utöka och uppdatera Kubernetes. Vid något tillfälle skars stödet för icke-kubeadm-installationer bort från huvudgrenen, och processen att byta till kubeadm föreslogs inte. Som ett resultat gjorde Southbridge-företaget sin egen gaffel (med kubeadm-stöd och en snabb lösning för kritiska problem).
Processen för att uppdatera alla k8s-kluster ser ut så här:
- ta Kubespray från Southbridge, kolla med vår tråd, Merjim.
- Vi rullar ut uppdateringen till Belastning- "Kub".
- Vi rullar ut uppdateringen en nod i taget (i Ansible är detta "seriell: 1") i dev- "Kub".
- Vi uppdaterar Prod på lördag kväll en nod i taget.
Det finns planer på att ersätta den i framtiden Kubespray för något snabbare och gå till kubeadm.
Totalt har vi tre "kuber": Stress, Dev och Prod. Vi planerar att lansera ytterligare en (varm standby) Prod-"Cube" i det andra datacentret. Belastning и dev live i "virtuella maskiner" (oVirt for Stress och VMWare cloud for Dev). Prod- "Cube" lever på "bar metal": det här är identiska noder med 32 CPU-trådar, 64-128 GB minne och 300 GB SSD RAID 10 - det finns 50 av dem totalt. Tre "tunna" noder är dedikerade till "mästare" Prod- "Kuba": 16 GB minne, 12 CPU-trådar.
För försäljning föredrar vi att använda "bar metall" och undvika onödiga lager som Openstack: vi behöver inte "bullriga grannar" och CPU stjäla tid. Och administrationens komplexitet fördubblas ungefär i fallet med intern OpenStack.
För CI/CD "Cubic" och andra infrastrukturkomponenter använder vi en separat GIT-server, Helm 3 (det var en ganska smärtsam övergång från Helm 2, men vi är mycket nöjda med alternativen atom), Jenkins, Ansible och Docker. Vi älskar funktionsgrenar och distribution till olika miljöer från ett arkiv.
Slutsats
Detta är generellt sett hur DevOps-processen ser ut hos DomClick ur en driftingenjörs perspektiv. Artikeln visade sig vara mindre teknisk än jag förväntade mig: följ därför DomClick-nyheterna på Habré: det kommer att finnas fler "hardcore" artiklar om Kubernetes och mer.
Källa: will.com