Det här är en berättelse om hur vi använder containrar i produktion, särskilt under Kubernetes. Artikeln handlar om att samla in mätvärden och loggar från containrar, samt att bygga avbildningar.

Vi kommer från fintech-företaget Exness, som utvecklar tjänster för onlinehandel och fintech-produkter för B2B och B2C. Vår FoU har många olika team, och utvecklingsavdelningen har över 100 anställda.

Vi är teamet som ansvarar för plattformen där våra utvecklare kan samla in och köra kod. Mer specifikt ansvarar vi för att samla in, lagra och leverera mätvärden, loggar och händelser från applikationer. Vi driver för närvarande cirka 50 XNUMX Docker-containrar i produktion, underhåller vår XNUMX TB stora datalagring och tillhandahåller arkitekturlösningar som är byggda kring vår infrastruktur: Kubernetes, Rancher och olika publika molnleverantörer. 

Vår motivation

Vad brinner? Ingen kan svara. Var är källan? Det är svårt att förstå. När fattade det eld? Det går att ta reda på det, men inte direkt. 

Varför står vissa containrar, medan andra har fallit? Vilken container var skyldig? Containrarna är trots allt identiska på utsidan, men var och en har sin egen Neo på insidan.

Våra utvecklare är smarta killar. De skapar bra tjänster som ger företaget vinst. Men det blir problem när containrar med applikationer går i kras. En container förbrukar för mycket CPU, en annan - nätverket, den tredje - I/O-operationer, den fjärde är helt oklar vad den gör med sockets. Allt detta kraschar, och skeppet sjunker. 

Agenter

För att förstå vad som försiggick inuti bestämde vi oss för att placera agenter direkt i containrarna.

Dessa agenter är de inneslutningsprogram som håller containrar i ett tillstånd som förhindrar att de bryter sönder varandra. Agenterna är standardiserade, vilket möjliggör en standardiserad metod för containrarunderhåll. 

I vårt fall bör agenter tillhandahålla loggar i ett standardformat, taggade och begränsade. De bör också förse oss med standardiserade mätvärden som är utökningsbara ur ett affärsapplikationsperspektiv.

Под агентами также подразумеваются утилиты для эксплуатации и обслуживания, умеющие работать  в разных системах оркестрирования, поддерживающие разные images (Debian, alpina, Centos och så vidare).

Slutligen måste agenter stödja enkla CI/CD-filer som inkluderar Dockerfiles. Annars kommer fartyget att falla isär eftersom containrar börjar levereras på "snedvändiga" räls.

Monteringsprocessen och målbildens enhet

För att hålla allt standardiserat och hanterbart behöver man följa någon standardiserad byggprocess. Så vi bestämde oss för att bygga container för container – det är rekursion.

Här representeras behållarna av heldragna konturer. Samtidigt bestämde vi oss för att placera fördelningar i dem, så att "livet inte känns som en dans på rosor". Vi kommer att berätta nedan varför detta gjordes.
 
Resultatet är ett byggverktyg – en behållare för en specifik version som refererar till specifika versioner av distributioner och specifika versioner av skript.

Hur använder vi det? Vi har en Docker Hub, där containern finns. Vi speglar den inuti vårt system för att bli av med externa beroenden. Resultatet är en container markerad med gult. Vi skapar en mall för att installera alla distributioner och skript vi behöver i containern. Därefter bygger vi en färdig avbildning: utvecklare lägger in kod och några av sina speciella beroenden i den. 

Vad är bra med den här metoden? 

• För det första, fullständig versionskontroll av byggverktyg – byggbehållare, versioner av skript och distributioner. 
• För det andra har vi uppnått standardisering: vi skapar mallar, mellanliggande och färdiga bilder på samma sätt. 
• För det tredje ger containrar oss portabilitet. Idag använder vi Gitlab, och imorgon byter vi till TeamCity eller Jenkins och vi kan köra våra containrar på samma sätt. 
• För det fjärde, minimering av beroenden. Det är inte av en slump att vi placerar distributioner i en container, eftersom det gör att vi inte behöver ladda ner dem från internet varje gång. 
• För det femte har monteringshastigheten ökat - närvaron av lokala kopior av bilder gör att du inte slösar tid på nedladdning, eftersom det finns en lokal bild. 

Med andra ord har vi uppnått en kontrollerad och flexibel byggprocess. Vi använder samma verktyg för att bygga vilken container som helst med fullständig versionshantering. 

Så här fungerar vår monteringsprocess

Bygget startas med ett kommando, processen körs i bilden (markerad i rött). Utvecklaren har en Docker-fil (markerad i gult), vi renderar den och ersätter variabler med värden. Och längs vägen lägger vi till sidhuvuden och sidfot – dessa är våra agenter. 

Sidhuvudet lägger till distributioner från motsvarande avbildningar. Och sidfoten installerar våra tjänster inuti, konfigurerar starten av arbetsbelastningen, loggning och andra agenter, ersätter startpunkten etc. 

Vi funderade länge på om vi skulle installera en supervisor. Till slut bestämde vi oss för att vi behövde en. Vi valde S6. Supervisorn tillhandahåller containerhantering: den låter dig ansluta till den om huvudprocessen kraschar och ger manuell kontroll över containern utan att återskapa den. Loggar och mätvärden är processer som körs inuti containern. De måste också kontrolleras på något sätt, och vi gör detta med hjälp av supervisorn. Slutligen tar S6 hand om hushållning, signalbehandling och andra uppgifter.

Eftersom vi använder olika orkestreringssystem måste containern, efter att den byggt och körts, förstå vilken miljö den befinner sig i och agera därefter. Till exempel:
Detta gör att vi kan bygga en avbildning och köra den i olika orkestreringssystem, och den kommer att lanseras med hänsyn till orkestreringssystemets specifika egenskaper.

 

För samma container får vi olika processträd i Docker och Kubernetes:

Nyttolasten exekveras under S6-supervisorn. Notera insamlaren och händelserna – dessa är våra agenter som ansvarar för loggar och mätvärden. Kubernetes har dem inte, men Docker har dem. Varför? 

Om vi ​​tittar på "pod"-specifikationen (nedan kallad Kubernetes pod) ser vi att händelsebehållaren exekveras i en pod, som har en separat insamlarbehållare som utför funktionen att samla in mätvärden och loggar. Vi kan använda Kubernetes funktioner: starta containrar i en pod, i en enda process och/eller nätverksutrymme. Faktum är att vi kan implementera våra agenter och utföra vissa funktioner. Och om samma container startas i Docker kommer den att få samma funktioner vid utgången, det vill säga den kommer att kunna leverera loggar och mätvärden, eftersom agenterna kommer att startas inuti. 

Mätvärden och loggar

Att leverera mätvärden och loggar är en komplex uppgift. Det finns flera aspekter involverade i att lösa den.
Infrastrukturen är byggd för att köra nyttolaster, inte för att leverera loggar i massor. Det betyder att det bör göras med minimala resurskrav för containrar. Vi vill hjälpa våra utvecklare: "Ta en Docker Hub-container, kör den, så kan vi leverera loggar." 

Den andra aspekten är att begränsa loggvolymen. Om en loggvolymstopp inträffar i flera containrar (applikationen matar ut ett stackspår i en loop) ökar belastningen på processorn, kommunikationskanalerna och loggbehandlingssystemet, och detta påverkar driften av värden som helhet och andra containrar på värden, vilket ibland leder till en "krasch" av värden. 

Den tredje aspekten är att stödja så många metoder för mätvärdensinsamling som möjligt direkt från lådan. Från att läsa filer och avfråga Prometheus-slutpunkten till att använda applikationsspecifika protokoll.

Och den sista aspekten är att det är nödvändigt att minimera resursförbrukningen.

Vi valde en öppen källkodslösning på Go som heter Telegraf. Det är en universell koppling som stöder mer än 140 typer av ingångskanaler (ingångsplugins) och 30 typer av utgångsplugins. Vi har förbättrat den och nu ska vi berätta hur vi använder den med Kubernetes som exempel. 

Låt oss säga att en utvecklare distribuerar en arbetsbelastning och Kubernetes får en begäran om att skapa en pod. Vid denna tidpunkt skapas en container som heter Collector automatiskt för varje pod (vi använder en mutationswebhook). Collector är vår agent. Vid start konfigurerar sig containern för att fungera med Prometheus och loggsamlingssystemet.

• För att göra detta använder den pod-annoteringarna, och beroende på deras innehåll skapar den, säg, en Prometheus-slutpunkt; 
• Baserat på Pod-specifikationen och behållarspecifika inställningar, bestämmer hur loggar ska levereras.

Vi samlar in loggar via Docker API: utvecklare behöver bara lägga dem i stdout eller stderr, så sorterar Collector ut det. Loggar samlas in i bitar med viss fördröjning för att förhindra eventuell överbelastning av värddatorn. 

Mätvärden samlas in av arbetsbelastningsinstanser (processer) i containrar. Allt taggas: namnrymd, pod, etc., och konverteras sedan till Prometheus-format - och blir tillgängligt för insamling (förutom loggar). Vi skickar även loggar, mätvärden och händelser till Kafka och vidare:

• Loggar finns tillgängliga i Graylog (för visuell analys);
• Loggar, mätvärden och händelser skickas till Clickhouse för långtidslagring.

Allt fungerar exakt likadant i AWS, bara det att vi ersätter Graylog med Kafka och Cloudwatch. Vi skickar loggar dit, och allt blir väldigt bekvämt: det är omedelbart tydligt vilket kluster och container de tillhör. Detsamma gäller för Google Stackdriver. Det vill säga, vårt schema fungerar både on-premise med Kafka och i molnet. 

Om vi ​​inte har Kubernetes med poddar är schemat lite mer komplicerat, men fungerar enligt samma principer.

Samma processer exekveras inuti containern, de orkestreras med S6. Alla samma processer startas inuti samma container.

Som ett resultat,

Vi har skapat en komplett lösning för att bygga och lansera avbildningar i produktion, med alternativ för att samla in och leverera loggar och mätvärden:

• Vi utvecklade en standardiserad metod för att bygga bilder, och baserat på den utvecklade vi CI-mallar;
• Datainsamlingsagenter är våra Telegraf-tillägg. Vi har testat dem väl i produktion;
• Vi använder mutationswebhook för att injicera behållare med agenter i poddar; 
• Integrerad i Kubernetes/Rancher-ekosystemet;
• Vi kan exekvera samma containrar i olika orkestreringssystem och få det resultat vi förväntar oss;
• Skapade en helt dynamisk konfiguration för containerhantering. 

Medförfattare: Ilja Prudnikov

Källa: will.com