Den här historien handlar om hur vi använder containrar i produktionsmiljö, särskilt under Kubernetes. Artikeln handlar om insamling av metrik och loggar från containrar, samt byggande av bilder.

Vi kommer från fintech-företaget Exness, som utvecklar tjänster för onlinehandel och fintech-produkter för B2B och B2C. I vår R&D finns det många olika team, och avdelningen för utveckling har över 100 anställda.

Vi representerar teamet som ansvarar för plattformen för insamling och körning av kod av våra utvecklare. Specifikt ansvarar vi för insamling, lagring och tillhandahållande av metrik, loggar och händelser från applikationer. För närvarande hanterar vi cirka tre tusen Docker-containrar i produktionsmiljö, upprätthåller vårt big data-lager på 50 TB och tillhandahåller arkitekturlösningar som byggs runt vår infrastruktur: Kubernetes, Rancher och olika offentliga molnleverantörer. 

Vår motivation

Vad brinner? Ingen kan svara. Var är fokus? Svårt att förstå. När började det brinna? Det går att ta reda på, men inte omedelbart. 

Varför står vissa containrar stilla medan andra har fallit? Vilken container orsakade det? Utifrån verkar containrarna likadana, men inuti har varje sin egen Neo.

Våra utvecklare är kompetenta personer. De skapar bra tjänster som ger företaget vinst. Men det uppstår också problem när containrarna med applikationerna sprider sig. En container förbrukar för mycket CPU, en annan nätverk, en tredje I/O-operationer, och en fjärde gör överhuvudtaget oklara saker med sockets. Allt detta faller och skeppet sjunker. 

Agenter

För att förstå vad som händer inuti beslutade vi att installera agenter direkt i containrarna.

Dessa agenter är kontrollprogram som håller containrarna i ett sådant tillstånd så att de inte förstör varandra. Agenterna är standardiserade, vilket gör att vi kan standardisera tillvägagångssättet för underhåll av containrar. 

I vårt fall måste agenterna tillhandahålla loggar i ett standardformat, taggade och med throttling. Dessutom måste de ge oss standardiserade metrik som är utbyggbara ur affärsapplikationernas perspektiv.

Under agenter avser vi också verktyg för drift och underhåll som kan fungera i olika orkestreringssystem, och stöder olika images (Debian, Alpine, Centos osv.).

Äntligen måste agenter stödja en enkel CI/CD som inkluderar Docker-filer. Annars kommer skeppet att gå sönder eftersom containrarna börjar levereras på "sneda" spår.

Byggprocess och uppbyggnad av målimagen

För att allt ska vara standardiserat och hanterbart måste vi följa en standardiserad byggprocess. Därför har vi beslutat att bygga containrar med hjälp av containrar - sådan är vår rekursion.

Här representeras containrarna med solida konturer. Vi bestämde oss för att lägga in distributionerna i dem, så att "livet inte kändes som en dans på rosor". Varför detta gjordes, kommer vi att berätta nedan.
 
Resultatet blev ett verktyg för byggande - en container av viss version som refererar till specifika versioner av distributionerna och specifika versioner av skripten.

Hur använder vi det? Vi har en Docker Hub där containern finns. Vi speglar den in i vårt eget system för att bli av med externa beroenden. Vi fick en container som markerats med gult. Vi skapar en mall för att installera alla nödvändiga distributioner och skript i containern. Därefter bygger vi en fullständig bild som är redo för drift: utvecklarna lägger in sin kod och vissa egna specifika beroenden. 

Vad är fördelarna med ett sådant tillvägagångssätt? 

• För det första, komplett versionskontroll av byggverktyg - byggcontainer, versioner av skript och distributioner. 
• För det andra, har vi uppnått standardisering: vi skapar mallar, mellanliggande och driftsklara bilder på samma sätt. 
• För det tredje ger containrarna oss portabilitet. Idag använder vi Gitlab, och imorgon byter vi till TeamCity eller Jenkins och kan på samma sätt köra våra containrar. 
• För det fjärde, minimering av beroenden. Vi har inte av en slump lagt distributioner i containern, eftersom detta gör att vi inte behöver ladda ner dem varje gång från Internet. 
• För det femte, har hastigheten på byggprocessen ökat - tillgången på lokala kopior av bilder gör att vi inte behöver lägga tid på nedladdningar, 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 alla containrar med fullständig versionering. 

Hur fungerar vår byggprocess?

Byggandet startar med ett kommando och processen körs i en bild (markerad med röd). Utvecklaren har en Docker-fil (markerad med gul), som vi renderar genom att byta ut variabler mot värden. Samtidigt lägger vi till header och footer - detta är våra agenter. 

Headern lägger till distributioner från motsvarande bilder. Och footern installerar våra tjänster, konfigurerar belastningsstart, loggning och andra agenter, byter ut entrypoint osv. 

Vi övervägde länge om vi skulle använda en supervisor. Till slut bestämde vi att vi behövde en. Vi valde S6. Supervisorn möjliggör hantering av containern: den gör det möjligt att ansluta till den om huvudprocessen kraschar och ger manuell kontroll över containern utan att behöva återskapa den. Loggar och mätvärden är processer som körs inuti containern. Vi måste också kontrollera dem, och det gör vi med hjälp av supervisorn. Slutligen tar S6 hand om housekeeping, signalbearbetning och andra uppgifter.

Eftersom vi använder olika orkestreringssystem, efter byggandet och startandet av containern, måste den förstå i vilken miljö den befinner sig och agera utifrån situationen. Till exempel:
Detta gör att vi kan bygga en bild och köra den i olika orkestreringssystem, där den kommer att startas med hänsyn till specifika krav från detta orkestreringssystem.

 

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

Nyttolasten körs under supervisorn S6. Observera collector och events - detta är våra agenter som ansvarar för loggar och mätvärden. I Kubernetes finns de inte, men i Docker finns de. Varför? 

Om vi ser på specifikationen för ‘pod’ (härefter Kubernetes pod) kommer vi att se att containern events körs i en pod där det finns en separat container collector som utför funktionen av att samla mätvärden och loggar. Vi kan använda Kubernetes-funktioner: köra containrar i samma pod, i samma process- och/eller nätverksutrymmen. Faktiskt införa våra agenter och utföra vissa funktioner. Och om samma container startas i Docker får den alla samma möjligheter, det vill säga kan leverera loggar och mätvärden, eftersom agenterna kommer att köras inuti. 

Mätvärden och loggar

Leverans av mätvärden och loggar är en komplex uppgift. Det finns flera aspekter kopplade till dess lösning.
Infrastrukturen skapas för att hantera nyttolast, inte för massdistribution av loggar. Det vill säga att denna process bör utföras med minimala resurskrav för containrarna. Vi strävar efter att hjälpa våra utvecklare: "Ta en Docker Hub-container, starta den, så kan vi leverera loggar." 

Den andra aspekten är begränsningen av loggvolymen. Om flera containrar genererar en ökning av loggvolymen (t.ex. en applikation som i en loop skriver stacktrace), ökar belastningen på CPU, kommunikationskanaler och logghanteringssystemet, vilket påverkar värdenheten och andra containrar på värdenheten, och ibland leder detta till att värdenheten "fallerar". 

Den tredje aspekten är att stödja så många metoder för insamling av mätvärden som möjligt direkt från starten. Från att läsa filer och fråga Prometheus-endpoint till att använda specifika applikationsprotokoll.

Och den sista aspekten är att minimera resursförbrukningen.

Vi har valt en open-source-lösning i Go kallad Telegraf. Det är en universell koppling som stödjer över 140 typer av ingångskanaler (input plugins) och 30 typer av utgångskanaler (output plugins). Vi har vidareutvecklat den och nu ska vi berätta hur den används i vårt fall med Kubernetes. 

Anta att en utvecklare deployar en belastning, och Kubernetes får en begäran om att skapa en pod. Vid detta ögonblick skapas automatiskt en container med namnet Collector för varje pod (vi använder mutation webhook). Collector är vår agent. Vid start konfigurerar denna container sig själv för att arbeta med Prometheus och logginsamlingssystemet.

• För detta använder den pod-annoteringar, och beroende på innehållet skapar den till exempel en slutpunkt för Prometheus. 
• Baserat på pod-specifikationen och specifika konfigurationer för containrar beslutar den hur loggar ska levereras.

Loggar samlas in via Docker API: utvecklarna behöver bara skriva dem till stdout eller stderr, och sedan tar Collector hand om resten. Loggarna samlas in i chunkar med viss fördröjning för att förhindra eventuell överbelastning av värdenheten. 

Mätvärden samlas in per instans av arbetsbelastningar (rocesser) i containrar. Allt märks med taggar: namespace, pod och så vidare, och konverteras sedan till Prometheus-format - och blir tillgängligt för insamling (förutom loggar). Dessutom skickar vi loggar, mätvärden och händelser till Kafka och vidare:

• Loggar är tillgängliga i Graylog (för visuell analys);
• Loggar, mätningar och händelser skickas till Clickhouse för långsiktig lagring.

På samma sätt fungerar allt i AWS, endast att vi byter ut Graylog med Kafka mot Cloudwatch. Vi skickar loggar dit, och allt blir mycket bekvämt: det är direkt klart vilket kluster och vilken container de hör till. Detsamma gäller för Google Stackdriver. Så vår lösning fungerar både on-premise med Kafka och i molnet. 

Om vi inte har Kubernetes med pods, blir systemet något mer komplicerat, men det fungerar enligt samma principer.

Inuti containern körs samma processer, de orkestreras med hjälp av S6. Samma processer har startats inuti en och samma container.

I slutändan

Vi har skapat en helhetslösning för att bygga och köra bilder i produktion, med alternativ för insamling och leverans av loggar och mätningar:

• Vi har utvecklat en standardiserad metod för att bygga bilder och utifrån den har vi utvecklat CI-mallar;
• Agenter för datainsamling är våra Telegraf-tillägg. Vi har testat dem ordentligt i produktion;
• Vi använder mutation webhook för att integrera containrar med agenter i pods; 
• Vi har integrerat oss i Kubernetes/Rancher-ekosystemet;
• Vi kan köra identiska containrar i olika orkestreringssystem och få det resultat vi förväntar oss;
• Vi har skapat en helt dynamisk konfiguration för hantering av containrar. 

Medförfattare: Ilja Prudnikov

Källa: habr.com