Denne historie handler om, hvordan vi bruger containere i et produktionsmiljø, specifikt Kubernetes. Artiklen er helliget indsamling af metrikker og logfiler fra containere samt bygning af billeder.

Vi er fra fintech-virksomheden Exness, som udvikler tjenester til online handel og fintech-produkter til B2B og B2C. Vores R&D har mange forskellige teams, udviklingsafdelingen har 100+ ansatte.

Vi repræsenterer det team, der er ansvarlig for platformen for vores udviklere til at indsamle og køre kode. Vi er især ansvarlige for at indsamle, opbevare og rapportere metrics, logfiler og hændelser fra applikationer. Vi driver i øjeblikket cirka tre tusinde Docker-containere i et produktionsmiljø, vedligeholder vores 50 TB big data-lagring og leverer arkitektoniske løsninger, der er bygget op omkring vores infrastruktur: Kubernetes, Rancher og forskellige offentlige cloud-udbydere. 

Vores motivation

Hvad brænder? Ingen kan svare. Hvor er ildstedet? Det er svært at forstå. Hvornår brød den i brand? Det kan du finde ud af, men ikke med det samme. 

Hvorfor står nogle containere, mens andre er faldet? Hvilken container havde skylden? Ydersiden af ​​beholderne er trods alt den samme, men indeni har hver sin Neo.

Vores udviklere er kompetente fyre. De laver gode tjenester, der bringer overskud til virksomheden. Men der er fejl, når containere med applikationer kommer på afveje. En container bruger for meget CPU, en anden bruger netværket, den tredje bruger I/O-operationer, og den fjerde er fuldstændig uklar, hvad den gør med sockets. Det hele falder, og skibet synker. 

Agenter

For at forstå, hvad der sker indeni, besluttede vi at placere agenter direkte i containere.

Disse midler er begrænsningsprogrammer, der holder beholdere i en sådan tilstand, at de ikke knækker hinanden. Agenter er standardiserede, og det giver mulighed for en standardiseret tilgang til servicering af containere. 

I vores tilfælde skal agenter levere logfiler i et standardformat, tagget og droslet. De bør også give os standardiserede målinger, der kan udvides fra et forretningsapplikationsperspektiv.

Agenter betyder også hjælpeprogrammer til drift og vedligeholdelse, der kan fungere i forskellige orkestreringssystemer, der understøtter forskellige billeder (Debian, Alpine, Centos osv.).

Endelig skal agenter understøtte simpel CI/CD, der inkluderer Docker-filer. Ellers vil skibet falde fra hinanden, fordi containere begynder at blive leveret langs "skæve" skinner.

Byg proces- og målbilledenhed

For at holde alting standardiseret og overskueligt, skal en eller anden form for standard byggeproces følges. Derfor besluttede vi at samle containere for containere - det er rekursion.

Her er beholderne repræsenteret med solide omrids. Samtidig besluttede de at lægge distributionssæt i dem, så "livet ikke ser ud som hindbær." Hvorfor dette blev gjort, vil vi forklare nedenfor.
 
Resultatet er et byggeværktøj - en versionsspecifik container, der refererer til specifikke distributionsversioner og specifikke scriptversioner.

Hvordan bruger vi det? Vi har en Docker Hub, der indeholder en container. Vi spejler det inde i vores system for at slippe af med eksterne afhængigheder. Resultatet er en beholder markeret med gult. Vi opretter en skabelon til at installere alle de distributioner og scripts, vi har brug for, i containeren. Derefter samler vi et billede, der er klar til brug: udviklere lægger kode og nogle af deres egne specielle afhængigheder ind i det. 

Hvad er godt ved denne tilgang? 

• Først fuld versionskontrol af byggeværktøjer - byg container-, script- og distributionsversioner. 
• For det andet har vi opnået standardisering: vi opretter skabeloner, mellemliggende og klar til brug på samme måde. 
• For det tredje giver containere os portabilitet. I dag bruger vi Gitlab, og i morgen skifter vi til TeamCity eller Jenkins, og vi vil kunne køre vores containere på samme måde. 
• For det fjerde, minimering af afhængigheder. Det var ikke tilfældigt, at vi lagde distributionssæt i containeren, for det giver os mulighed for at undgå at downloade dem fra internettet hver gang. 
• For det femte er byggehastigheden steget - tilstedeværelsen af ​​lokale kopier af billeder giver dig mulighed for at undgå at spilde tid på at downloade, da der er et lokalt billede. 

Vi har med andre ord opnået en kontrolleret og fleksibel montageproces. Vi bruger de samme værktøjer til at bygge alle fuldt versionerede containere. 

Sådan fungerer vores byggeprocedure

Forsamlingen startes med én kommando, processen udføres i billedet (fremhævet med rødt). Udvikleren har en Docker-fil (fremhævet i gult), vi gengiver den, og erstatter variabler med værdier. Og undervejs tilføjer vi sidehoveder og sidefødder – det er vores agenter. 

Header tilføjer distributioner fra de tilsvarende billeder. Og footer installerer vores tjenester inde, konfigurerer lanceringen af ​​arbejdsbelastning, logning og andre agenter, erstatter entrypoint osv. 

Vi har længe overvejet, om vi skulle installere en supervisor. Til sidst besluttede vi, at vi havde brug for ham. Vi valgte S6. Supervisoren sørger for containerstyring: giver dig mulighed for at oprette forbindelse til den, hvis hovedprocessen går ned og giver manuel administration af containeren uden at genskabe den. Logfiler og metrics er processer, der kører inde i containeren. De skal også på en eller anden måde kontrolleres, og det gør vi med hjælp fra en vejleder. Endelig tager S6 sig af husholdning, signalbehandling og andre opgaver.

Da vi bruger forskellige orkestreringssystemer, skal containeren efter bygning og drift forstå, hvilket miljø den er i og agere i forhold til situationen. For eksempel:
Dette giver os mulighed for at bygge ét billede og køre det i forskellige orkestreringssystemer, og det vil blive lanceret under hensyntagen til dette orkestreringssystems særlige forhold.

 

For den samme container får vi forskellige procestræer i Docker og Kubernetes:

Nyttelasten udføres under opsyn af S6. Vær opmærksom på indsamler og begivenheder - det er vores agenter, der er ansvarlige for logfiler og metrikker. Kubernetes har dem ikke, men Docker har dem. Hvorfor? 

Hvis vi ser på specifikationen af ​​"poden" (herefter - Kubernetes pod), vil vi se, at hændelsesbeholderen udføres i en pod, som har en separat opsamlerbeholder, der udfører funktionen med at indsamle metrikker og logfiler. Vi kan bruge mulighederne i Kubernetes: køre containere i én pod, i en enkelt proces og/eller netværksrum. Introducer faktisk dine agenter og udfør nogle funktioner. Og hvis den samme container lanceres i Docker, vil den modtage alle de samme muligheder som output, det vil sige, at den vil være i stand til at levere logfiler og metrics, da agenterne vil blive lanceret internt. 

Metrikker og logfiler

At levere metrics og logfiler er en kompleks opgave. Der er flere aspekter af hendes beslutning.
Infrastrukturen er skabt til udførelse af nyttelasten og ikke til masselevering af logfiler. Det vil sige, at denne proces skal udføres med minimale krav til containerressourcer. Vi stræber efter at hjælpe vores udviklere: "Få en Docker Hub-container, kør den, og vi kan levere logfilerne." 

Det andet aspekt er at begrænse mængden af ​​logfiler. Hvis der opstår en stigning i mængden af ​​logfiler i flere containere (applikationen udsender en stack-trace i en løkke), øges belastningen på CPU'en, kommunikationskanalerne og logbehandlingssystemet, og dette påvirker driften af ​​værten som en hele og andre beholdere på værten, så fører dette nogle gange til "fald" af værten. 

Det tredje aspekt er, at det er nødvendigt at understøtte så mange metrikindsamlingsmetoder som muligt ud af boksen. Fra læsning af filer og polling af Prometheus-slutpunkt til brug af applikationsspecifikke protokoller.

Og det sidste aspekt er at minimere ressourceforbruget.

Vi valgte en open source Go-løsning kaldet Telegraf. Dette er et universelt stik, der understøtter mere end 140 typer inputkanaler (input plugins) og 30 typer output kanaler (output plugins). Vi har færdiggjort det, og nu vil vi fortælle dig, hvordan vi bruger det ved at bruge Kubernetes som eksempel. 

Lad os sige, at en udvikler implementerer en arbejdsbelastning, og Kubernetes modtager en anmodning om at oprette en pod. På dette tidspunkt oprettes der automatisk en beholder kaldet Collector for hver pod (vi bruger mutation webhook). Collector er vores agent. Ved starten konfigurerer denne container sig selv til at arbejde med Prometheus og logindsamlingssystemet.

• For at gøre dette bruger den pod-annoteringer, og afhængigt af indholdet skaber den f.eks. et Prometheus-slutpunkt; 
• Baseret på pod-specifikationen og specifikke containerindstillinger beslutter den, hvordan logfiler skal leveres.

Vi indsamler logfiler via Docker API: Udviklere skal bare lægge dem i stdout eller stderr, og Collector vil ordne det. Logfiler samles i bidder med en vis forsinkelse for at forhindre mulig overbelastning af værten. 

Metrics indsamles på tværs af arbejdsbelastningsinstanser (processer) i containere. Alt er tagget: navneområde, under og så videre, og konverteres derefter til Prometheus-format - og bliver tilgængeligt til indsamling (undtagen logfiler). Vi sender også logfiler, målinger og hændelser til Kafka og yderligere:

• Logfiler er tilgængelige i Graylog (til visuel analyse);
• Logfiler, metrics, hændelser sendes til Clickhouse til langtidsopbevaring.

Alt fungerer nøjagtigt det samme i AWS, kun vi erstatter Graylog med Kafka med Cloudwatch. Vi sender logfilerne dertil, og alt viser sig meget praktisk: det er straks klart, hvilken klynge og container de tilhører. Det samme gælder for Google Stackdriver. Det vil sige, at vores ordning fungerer både on-premise med Kafka og i skyen. 

Hvis vi ikke har Kubernetes med pods, er ordningen lidt mere kompliceret, men den fungerer efter de samme principper.

De samme processer udføres inde i containeren, de orkestreres ved hjælp af S6. Alle de samme processer kører i den samme container.

Som følge heraf

Vi har skabt en komplet løsning til opbygning og lancering af billeder med muligheder for at indsamle og levere logfiler og metrics:

• Vi udviklede en standardiseret tilgang til at samle billeder, og ud fra den udviklede vi CI-skabeloner;
• Dataindsamlingsagenter er vores Telegraf-udvidelser. Vi testede dem godt i produktionen;
• Vi bruger mutation webhook til at implementere containere med agenter i pods; 
• Integreret i Kubernetes/Rancher-økosystemet;
• Vi kan udføre de samme containere i forskellige orkestreringssystemer og få det resultat, vi forventer;
• Oprettet en fuldstændig dynamisk containerstyringskonfiguration. 

Medforfatter: Ilya Prudnikov

Kilde: www.habr.com