Hierdie storie handel oor hoe ons houers in 'n produksie-omgewing gebruik, spesifiek Kubernetes. Die artikel word gewy aan die insameling van statistieke en logboeke uit houers, sowel as die bou van beelde.

Ons is van die fintech-maatskappy Exness, wat dienste vir aanlyn handel en fintech-produkte vir B2B en B2C ontwikkel. Ons R&D het baie verskillende spanne, die ontwikkelingsafdeling het 100+ werknemers.

Ons verteenwoordig die span wat verantwoordelik is vir die platform vir ons ontwikkelaars om kode te versamel en uit te voer. Ons is veral verantwoordelik vir die insameling, berging en verslagdoening van maatstawwe, logboeke en gebeure van toepassings. Ons bedryf tans ongeveer drieduisend Docker-houers in 'n produksie-omgewing, hou ons 50 TB grootdataberging in stand en verskaf argitektoniese oplossings wat rondom ons infrastruktuur gebou is: Kubernetes, Rancher en verskeie openbare wolkverskaffers. 

Ons motivering

Wat brand? Niemand kan antwoord nie. Waar is die vuurherd? Dis moeilik om te verstaan. Wanneer het dit aan die brand geslaan? Jy kan uitvind, maar nie dadelik nie. 

Hoekom staan ​​sommige houers terwyl ander geval het? Watter houer was te blameer? Die buitekant van die houers is immers dieselfde, maar binne het elkeen sy eie Neo.

Ons ontwikkelaars is bekwame ouens. Hulle lewer goeie dienste wat wins na die maatskappy bring. Maar daar is mislukkings wanneer houers met toepassings dwaal. Een houer verbruik te veel SVE, 'n ander verbruik die netwerk, 'n derde verbruik I/O-operasies, en die vierde is heeltemal onduidelik wat dit met voetstukke doen. Dit val alles en die skip sink. 

Agente

Om te verstaan ​​wat binne gebeur, het ons besluit om agente direk in houers te plaas.

Hierdie middels is beperkende programme wat houers in so 'n toestand hou dat hulle mekaar nie breek nie. Agente is gestandaardiseer, en dit maak voorsiening vir 'n gestandaardiseerde benadering tot die diens van houers. 

In ons geval moet agente logs in 'n standaardformaat verskaf, gemerk en versmoor. Hulle moet ons ook voorsien van gestandaardiseerde maatstawwe wat uit 'n besigheidstoepassingsperspektief uitbreibaar is.

Agente beteken ook nutsprogramme vir bedryf en instandhouding wat in verskillende orkestrasiestelsels kan werk wat verskillende beelde ondersteun (Debian, Alpine, Centos, ens.).

Ten slotte moet agente eenvoudige CI/CD ondersteun wat Docker-lêers insluit. Andersins sal die skip uitmekaar val, want houers sal langs “skewe” relings afgelewer word.

Bou proses en teiken beeld toestel

Om alles gestandaardiseer en hanteerbaar te hou, moet 'n soort standaardbouproses gevolg word. Daarom het ons besluit om houers vir houers te versamel – dit is rekursie.

Hier word die houers deur soliede buitelyne voorgestel. Terselfdertyd het hulle besluit om verspreidingsstelle daarin te plaas sodat "die lewe nie soos frambose lyk nie." Hoekom dit gedoen is, sal ons hieronder verduidelik.
 
Die resultaat is 'n bouhulpmiddel - 'n weergawe-spesifieke houer wat verwys na spesifieke verspreidingsweergawes en spesifieke skrifweergawes.

Hoe gebruik ons ​​dit? Ons het 'n Docker Hub wat 'n houer bevat. Ons weerspieël dit binne ons stelsel om van eksterne afhanklikhede ontslae te raak. Die resultaat is 'n houer wat in geel gemerk is. Ons skep 'n sjabloon om al die verspreidings en skrifte wat ons benodig in die houer te installeer. Daarna stel ons 'n gereed-vir-gebruik beeld saam: ontwikkelaars plaas kode en sommige van hul eie spesiale afhanklikhede daarin. 

Wat is goed aan hierdie benadering? 

• Eerstens, volledige weergawebeheer van bougereedskap - bou houer-, skrif- en verspreidingsweergawes. 
• Tweedens het ons standaardisering bereik: ons skep sjablone, intermediêre en gereed-vir-gebruik beeld op dieselfde manier. 
• Derdens gee houers ons oordraagbaarheid. Vandag gebruik ons ​​Gitlab, en môre sal ons oorskakel na TeamCity of Jenkins en ons sal ons houers op dieselfde manier kan laat loop. 
• Vierdens, die vermindering van afhanklikhede. Dit was nie toevallig dat ons verspreidingsstelle in die houer gesit het nie, want dit laat ons toe om dit nie elke keer van die internet af te laai nie. 
• Vyfdens het die bouspoed toegeneem - die teenwoordigheid van plaaslike kopieë van beelde laat jou toe om tyd te mors op aflaai, aangesien daar 'n plaaslike beeld is. 

Met ander woorde, ons het 'n beheerde en buigsame monteringsproses bereik. Ons gebruik dieselfde gereedskap om enige volledig weergawe van houers te bou. 

Hoe ons bouprosedure werk

Die samestelling word met een opdrag van stapel gestuur, die proses word in die prent uitgevoer (in rooi uitgelig). Die ontwikkelaar het 'n Docker-lêer (in geel uitgelig), ons lewer dit weer en vervang veranderlikes met waardes. En langs die pad voeg ons kop- en voettekste by – dit is ons agente. 

Header voeg verspreidings van die ooreenstemmende beelde by. En voetskrif installeer ons dienste binne, stel die bekendstelling van werklading, logboek en ander agente op, vervang toegangspunt, ens. 

Ons het lank gedink of ons 'n toesighouer moet installeer. Op die ou end het ons besluit dat ons hom nodig het. Ons het S6 gekies. Die toesighouer verskaf houerbestuur: laat jou toe om daaraan te koppel as die hoofproses ineenstort en verskaf handmatige bestuur van die houer sonder om dit te herskep. Logs en metrieke is prosesse wat binne die houer loop. Hulle moet ook op een of ander manier beheer word, en ons doen dit met die hulp van 'n toesighouer. Laastens sorg die S6 vir huishouding, seinverwerking en ander take.

Aangesien ons verskillende orkestrasiestelsels gebruik, moet die houer na gebou en hardloop verstaan ​​in watter omgewing dit is en volgens die situasie optree. Byvoorbeeld:
Dit stel ons in staat om een ​​beeld te bou en dit in verskillende orkestrasiestelsels te laat loop, en dit sal bekendgestel word met inagneming van die besonderhede van hierdie orkestrasiestelsel.

 

Vir dieselfde houer kry ons verskillende prosesbome in Docker en Kubernetes:

Die loonvrag word uitgevoer onder toesig van S6. Gee aandag aan versamelaar en gebeure - dit is ons agente wat verantwoordelik is vir logs en metrieke. Kubernetes het dit nie, maar Docker het. Hoekom? 

As ons kyk na die spesifikasie van die "peul" (hierna - Kubernetes-peul), sal ons sien dat die gebeurtenishouer in 'n peul uitgevoer word, wat 'n aparte versamelhouer het wat die funksie verrig om metrieke en logs te versamel. Ons kan die vermoëns van Kubernetes gebruik: hou houers in een peul, in 'n enkele proses en/of netwerkruimte. Stel u agente eintlik bekend en voer sommige funksies uit. En as dieselfde houer in Docker bekendgestel word, sal dit dieselfde vermoëns as uitvoer ontvang, dit wil sê, dit sal logs en statistieke kan lewer, aangesien die agente intern geloods sal word. 

Metrieke en logs

Die lewering van statistieke en logs is 'n komplekse taak. Daar is verskeie aspekte aan haar besluit.
Die infrastruktuur word geskep vir die uitvoering van die loonvrag, en nie vir massa-aflewering van stompe nie. Dit wil sê, hierdie proses moet uitgevoer word met minimale houerhulpbronvereistes. Ons streef daarna om ons ontwikkelaars te help: "Kry 'n Docker Hub-houer, voer dit uit en ons kan die logs aflewer." 

Die tweede aspek is om die volume logs te beperk. As 'n toename in die volume logs in verskeie houers voorkom (die toepassing voer 'n stapelspoor in 'n lus uit), neem die las op die SVE, kommunikasiekanale en logverwerkingstelsel toe, en dit beïnvloed die werking van die gasheer as 'n hele en ander houers op die gasheer, dan lei dit soms tot "val" van die gasheer. 

Die derde aspek is dat dit nodig is om soveel as moontlik metrieke-insamelingsmetodes uit die boks te ondersteun. Van die lees van lêers en peiling van Prometheus-eindpunt tot die gebruik van toepassingspesifieke protokolle.

En die laaste aspek is om hulpbronverbruik te minimaliseer.

Ons het 'n oopbron Go-oplossing genaamd Telegraf gekies. Dit is 'n universele aansluiting wat meer as 140 soorte invoerkanale (invoerproppe) en 30 soorte uitsetkanale (uitsetproppe) ondersteun. Ons het dit gefinaliseer en nou sal ons jou vertel hoe ons dit gebruik deur Kubernetes as voorbeeld te gebruik. 

Kom ons sê 'n ontwikkelaar ontplooi 'n werklading en Kubernetes ontvang 'n versoek om 'n peul te skep. Op hierdie stadium word 'n houer genaamd Collector outomaties vir elke peul geskep (ons gebruik mutasie webhook). Versamelaar is ons agent. Aan die begin konfigureer hierdie houer homself om met Prometheus en die loginsamelingstelsel te werk.

• Om dit te doen, gebruik dit peulaantekeninge, en, afhangende van die inhoud daarvan, skep dit, sê, 'n Prometheus-eindpunt; 
• Op grond van die peulspesifikasie en spesifieke houerinstellings, besluit dit hoe om logs af te lewer.

Ons versamel logs via die Docker API: ontwikkelaars hoef dit net in stdout of stderr te plaas, en Collector sal dit uitsorteer. Logs word in stukke versamel met 'n mate van vertraging om moontlike gasheeroorlading te voorkom. 

Metrieke word oor werkladingsgevalle (prosesse) in houers versamel. Alles word gemerk: naamruimte, onder, ensovoorts, en dan omgeskakel na Prometheus-formaat - en word beskikbaar vir versameling (behalwe vir logs). Ons stuur ook logs, statistieke en gebeure na Kafka en verder:

• Logs is beskikbaar in Graylog (vir visuele ontleding);
• Logs, statistieke, gebeure word na Clickhouse gestuur vir langtermynberging.

Alles werk presies dieselfde in AWS, net ons vervang Graylog met Kafka met Cloudwatch. Ons stuur die logs daarheen, en alles blyk baie gerieflik: dit is dadelik duidelik aan watter groep en houer hulle behoort. Dieselfde geld vir Google Stackdriver. Dit wil sê, ons skema werk beide op die perseel met Kafka en in die wolk. 

As ons nie Kubernetes met peule het nie, is die skema 'n bietjie meer ingewikkeld, maar dit werk op dieselfde beginsels.

Dieselfde prosesse word binne die houer uitgevoer, hulle word georkestreer met behulp van S6. Al dieselfde prosesse loop binne dieselfde houer.

Uiteindelik

Ons het 'n volledige oplossing geskep vir die bou en bekendstelling van beelde, met opsies vir die versameling en aflewering van logs en metrieke:

• Ons het 'n gestandaardiseerde benadering tot die samestelling van beelde ontwikkel, en op grond daarvan het ons CI-sjablone ontwikkel;
• Data-insamelingsagente is ons Telegraf-uitbreidings. Ons het hulle goed in produksie getoets;
• Ons gebruik mutasie webhaak om houers met middels in peule te implementeer; 
• Geïntegreer in die Kubernetes/Rancher-ekosisteem;
• Ons kan dieselfde houers in verskillende orkestrasiestelsels uitvoer en die resultaat kry wat ons verwag;
• Het 'n heeltemal dinamiese houerbestuurkonfigurasie geskep. 

Mede-outeur: Ilya Prudnikov

Bron: will.com