Hej alla! Jag heter Pavel Agaletsky. Jag arbetar som teamleader i ett team som utvecklar Lamodas leveranssystem. Under 2018 talade jag på HighLoad++-konferensen och idag skulle jag vilja presentera en utskrift av min rapport.

Mitt ämne är tillägnat vårt företags erfarenhet av att distribuera system och tjänster till olika miljöer. Från vår förhistoriska tid, när vi distribuerade alla system till vanliga virtuella servrar, slutade med den gradvisa övergången från Nomad till distribution i Kubernetes. Jag ska berätta varför vi gjorde det och vilka problem vi hade under processen.

Distribuera applikationer till VM

Låt oss börja med att för 3 år sedan distribuerades alla företagets system och tjänster på vanliga virtuella servrar. Tekniskt sett var det organiserat på ett sådant sätt att all kod för våra system lagrades och monterades med hjälp av automatiska monteringsverktyg, med jenkins. Med Ansible rullades den ut från vårt versionskontrollsystem till virtuella servrar. Dessutom distribuerades varje system som vårt företag hade till minst två servrar: en av dem på huvudet, den andra på svansen. Dessa två system var absolut identiska med varandra i alla sina inställningar, kraft, konfiguration etc. Den enda skillnaden mellan dem var att head fick användartrafik, medan tail aldrig fick användartrafik.

Vad var det för?

När vi implementerade nya versioner av vår applikation ville vi säkerställa en sömlös utrullning, det vill säga utan märkbara konsekvenser för användarna. Detta uppnåddes på grund av det faktum att nästa kompilerade utgåva med Ansible rullades ut. Där kunde personerna som var involverade i utplaceringen kontrollera och se till att allt var bra: alla mätvärden, avsnitt och applikationer fungerade; de nödvändiga skripten lanseras. Först efter att de var övertygade om att allt var ok, lades trafiken om. Det började gå till servern som tidigare var svans. Och den som tidigare var huvudet förblev utan användartrafik, medan den fortfarande hade den tidigare versionen av vår applikation på sig.

Så det var sömlöst för användarna. Eftersom växlingen sker omedelbart, eftersom den helt enkelt växlar balanseraren. Du kan mycket enkelt rulla tillbaka till den tidigare versionen genom att helt enkelt byta tillbaka balanseringen. Vi kunde också verifiera att applikationen kunde produceras redan innan den fick användartrafik, vilket var ganska bekvämt.

Vilka fördelar såg vi i allt detta?

1. Först och främst räcker det det bara fungerar. Alla förstår hur ett sådant distributionsschema fungerar, eftersom de flesta någonsin har distribuerat till vanliga virtuella servrar.
2. Detta räcker tillförlitligt, eftersom implementeringstekniken är enkel, testad av tusentals företag. Miljontals servrar distribueras på detta sätt. Det är svårt att bryta något.
3. Och äntligen kunde vi få atominstallationer. Implementeringar som sker samtidigt för användare, utan ett märkbart steg för att byta mellan den gamla versionen och den nya.

Men vi såg också flera brister i allt detta:

1. Utöver produktionsmiljön, utvecklingsmiljön, finns det andra miljöer. Till exempel qa och förproduktion. På den tiden hade vi många servrar och ett 60-tal tjänster. Av denna anledning var det nödvändigt för varje tjänst, underhåll den senaste versionen för den virtuell maskin. Dessutom, om du vill uppdatera bibliotek eller installera nya beroenden måste du göra detta i alla miljöer. Du behövde också synkronisera tiden när du ska distribuera nästa nya version av din applikation med tiden när devops utför de nödvändiga miljöinställningarna. I det här fallet är det lätt att hamna i en situation där vår miljö blir något annorlunda i alla miljöer samtidigt. Till exempel, i en QA-miljö kommer det att finnas vissa versioner av bibliotek, och i en produktionsmiljö kommer det att finnas olika, vilket kommer att leda till problem.
2. Svårigheter att uppdatera beroenden din ansökan. Det beror inte på dig, utan på det andra laget. Nämligen från devops-teamet som underhåller servrarna. Du måste ge dem en lämplig uppgift och en beskrivning av vad du vill göra.
3. På den tiden ville vi också dela upp de stora stora monoliterna vi hade i separata små tjänster, eftersom vi förstod att det skulle bli fler och fler av dem. Vid den tiden hade vi redan mer än 100. För varje ny tjänst var det nödvändigt att skapa en separat ny virtuell maskin, som också behövde underhållas och driftsättas. Dessutom behöver du inte en bil, utan minst två. Till allt detta kommer QA-miljön. Detta skapar problem och gör det svårare för dig att bygga och köra nya system. komplex, dyr och lång process.

Därför beslutade vi att det skulle vara bekvämare att gå från att distribuera vanliga virtuella maskiner till att distribuera våra applikationer i en dockningscontainer. Om du har docker behöver du ett system som kan köra programmet i ett kluster, eftersom du inte bara kan höja en container. Oftast vill man ha koll på hur många containrar som lyfts så att de lyfter automatiskt. Av denna anledning behövde vi välja ett kontrollsystem.

Vi funderade länge på vilken vi kunde ta. Faktum är att vid den tidpunkten var denna distributionsstack på vanliga virtuella servrar något föråldrad, eftersom de inte hade de senaste versionerna av operativsystem. Vid något tillfälle fanns det till och med FreeBSD, vilket inte var särskilt bekvämt att stödja. Vi förstod att vi behövde migrera till docker så snabbt som möjligt. Våra devops tittade på sin befintliga erfarenhet av olika lösningar och valde ett system som Nomad.

Byt till Nomad

Nomad är en produkt från HashiCorp. De är också kända för sina andra lösningar:

"Konsul" är ett verktyg för att upptäcka tjänster.

"Terraform" - ett system för att hantera servrar som låter dig konfigurera dem genom konfiguration, den så kallade infrastrukturen-som-en-kod.

"Luffare" låter dig distribuera virtuella maskiner lokalt eller i molnet via specifika konfigurationsfiler.

Nomad verkade på den tiden som en ganska enkel lösning som man snabbt kunde byta till utan att förändra hela infrastrukturen. Dessutom är det ganska lätt att lära sig. Det är därför vi valde det som filtreringssystem för vår container.

Vad behöver du för att distribuera ditt system till Nomad?

1. Först och främst behöver du docker-bild din ansökan. Du måste bygga den och placera den i docker-bildförrådet. I vårt fall är detta en artifactory - ett system som låter dig trycka in olika artefakter av olika typer i den. Det kan lagra arkiv, dockningsbilder, PHP-komponeringspaket, NPM-paket och så vidare.
2. Behövs också konfigurationsfil, som kommer att berätta för Nomad vad, var och i vilken mängd du vill distribuera.

När vi pratar om Nomad använder den HCL-språket som sitt informationsfilformat, vilket står för HashiCorp Configuration Language. Detta är en superset av Yaml som låter dig beskriva din tjänst i Nomad-termer.

Det låter dig säga hur många behållare du vill distribuera, från vilka bilder du ska skicka olika parametrar till dem under distributionen. Således matar du den här filen till Nomad, och den startar behållare i produktion enligt den.

I vårt fall insåg vi att det inte skulle vara särskilt bekvämt att skriva helt identiska HCL-filer för varje tjänst, eftersom det finns många tjänster och ibland vill du uppdatera dem. Det händer att en tjänst distribueras inte i en instans, utan i en mängd olika. Till exempel har ett av de system som vi har i produktion mer än 100 instanser i produktion. De körs från samma bilder, men skiljer sig i konfigurationsinställningar och konfigurationsfiler.

Därför bestämde vi oss för att det skulle vara bekvämt för oss att lagra alla våra konfigurationsfiler för distribution i ett gemensamt arkiv. På så sätt var de synliga: de var lätta att underhålla och vi kunde se vilka system vi hade. Vid behov är det också enkelt att uppdatera eller ändra något. Att lägga till ett nytt system är inte heller svårt - du behöver bara skapa en konfigurationsfil i den nya katalogen. Inuti den finns följande filer: service.hcl, som innehåller en beskrivning av vår tjänst, och några env-filer som gör att just den här tjänsten, som distribueras i produktionen, kan konfigureras.

Vissa av våra system distribueras dock i produktion inte i ett exemplar, utan i flera samtidigt. Därför bestämde vi oss för att det skulle vara bekvämt för oss att lagra inte konfigurationerna i deras rena form, utan deras mallform. Och vi valde jinja 2. I det här formatet lagrar vi både konfigurationerna för själva tjänsten och de env-filer som behövs för den.

Dessutom har vi placerat ett distributionsskript som är gemensamt för alla projekt i arkivet, vilket gör att du kan lansera och distribuera din tjänst i produktion, in i den önskade miljön, i det önskade målet. I fallet när vi gjorde om vår HCL-konfiguration till en mall, då började HCL-filen, som tidigare var en vanlig Nomad-konfiguration, i det här fallet se lite annorlunda ut.

Det vill säga, vi ersatte vissa konfigurationsplatsvariabler med infogade variabler som är hämtade från env-filer eller andra källor. Dessutom fick vi möjlighet att samla in HCL-filer dynamiskt, det vill säga att vi inte bara kan använda vanliga variabelinfogningar. Eftersom jinja stöder loopar och villkor kan du även skapa konfigurationsfiler där, som ändras beroende på exakt var du distribuerar dina applikationer.

Till exempel vill du distribuera din tjänst till förproduktion och produktion. Låt oss säga att du i förproduktion inte vill köra cron-skript, utan bara vill se tjänsten på en separat domän för att se till att den fungerar. För alla som distribuerar tjänsten ser processen väldigt enkel och transparent ut. Allt du behöver göra är att köra filen deploy.sh, ange vilken tjänst du vill distribuera och till vilket mål. Till exempel vill du distribuera ett visst system till Ryssland, Vitryssland eller Kazakstan. För att göra detta, ändra helt enkelt en av parametrarna, så får du rätt konfigurationsfil.

När Nomad-tjänsten redan är distribuerad till ditt kluster ser det ut så här.

Först behöver du någon form av balanserare utanför, som tar emot all användartrafik. Den kommer att arbeta tillsammans med Consul och ta reda på var, på vilken nod, på vilken IP-adress en specifik tjänst finns som motsvarar ett visst domännamn. Tjänster i Consul kommer från Nomad själv. Eftersom det är produkter från samma företag är de ganska släkt med varandra. Vi kan säga att Nomad out of the box kan registrera alla tjänster som lanseras i den inuti Consul.

När din front-end lastbalanserare vet vilken tjänst den ska skicka trafik till, vidarebefordrar den den till lämplig container eller flera containrar som matchar din applikation. Det är naturligtvis också nödvändigt att tänka på säkerheten. Även om alla tjänster körs på samma virtuella maskiner i behållare, kräver detta vanligtvis att man förhindrar fri åtkomst från någon tjänst till någon annan. Detta har vi uppnått genom segmentering. Varje tjänst lanserades i sitt eget virtuella nätverk, på vilket routingregler och regler för att tillåta/neka åtkomst till andra system och tjänster föreskrivs. De kan vara placerade både inuti detta kluster och utanför det. Om du till exempel vill hindra en tjänst från att ansluta till en specifik databas kan detta göras genom segmentering på nätverksnivå. Det vill säga, även av misstag kan du inte av misstag ansluta från testmiljön till din produktionsdatabas.

Hur mycket kostade omställningen oss i form av mänskliga resurser?

Övergången av hela företaget till Nomad tog cirka 5-6 månader. Vi flyttade på tjänst för tjänst, men i ganska hög takt. Varje team fick skapa sina egna behållare för tjänsterna.

Vi har antagit ett sådant tillvägagångssätt att varje team är ansvarigt för docker-bilder av sina system oberoende. DevOps tillhandahåller den allmänna infrastruktur som krävs för distribution, det vill säga stöd för själva klustret, stöd för CI-systemet och så vidare. Och vid den tiden hade vi flyttat mer än 60 system till Nomad, vilket uppgick till cirka 2 tusen containrar.

Devops ansvarar för den allmänna infrastrukturen för allt relaterat till driftsättning och servrar. Och varje utvecklingsteam är i sin tur ansvarigt för att implementera containrar för sitt specifika system, eftersom det är teamet som vet vad det generellt behöver i en viss container.

Anledningar till att överge Nomad

Vilka fördelar fick vi genom att byta till driftsättning med hjälp av bland annat Nomad och docker?

1. Vi förutsatt lika villkor för alla miljöer. Vid utveckling, QA-miljö, förproduktion, produktion, används samma containerbilder, med samma beroenden. Följaktligen har du praktiskt taget ingen chans att det som kommer att hamna i produktionen inte är det du tidigare testat lokalt eller i din testmiljö.
2. Vi fann också att det räcker enkelt att lägga till en ny tjänst. Ur implementeringssynpunkt lanseras alla nya system väldigt enkelt. Gå bara till arkivet som lagrar konfigurationer, lägg till ytterligare en konfiguration för ditt system där, så är du klar. Du kan distribuera ditt system till produktion utan ytterligare ansträngning från devops.
3. Alla konfigurationsfiler i ett gemensamt förråd visade sig vara under granskning. När vi distribuerade våra system med virtuella servrar använde vi Ansible, där konfigurationerna fanns i samma arkiv. Men för de flesta utvecklare var detta lite svårare att arbeta med. Här har volymen av konfigurationer och kod som du behöver lägga till för att distribuera tjänsten blivit mycket mindre. Dessutom är det väldigt lätt för devops att fixa eller ändra det. Vid övergångar, till exempel till en ny version av Nomad, kan de ta och massuppdatera alla operativa filer som finns på samma plats.

Men vi stötte också på flera nackdelar:

Det visade sig att vi kunde inte uppnå sömlösa distributioner i fallet med Nomad. Vid utrullning av containrar under olika förhållanden kunde den visa sig vara igång, och Nomad uppfattade den som en container redo att ta emot trafik. Detta hände innan applikationen inuti den ens hade en chans att starta. Av denna anledning började systemet producera 500 fel under en kort tidsperiod, eftersom trafiken började gå till en container som ännu inte var redo att acceptera den.

Vi stötte på några vid myrarna. Den viktigaste buggen är att Nomad inte hanterar ett stort kluster särskilt bra om du har många system och containrar. När du vill ta ut en av servrarna som ingår i Nomad-klustret för underhåll är det en ganska stor sannolikhet att klustret inte kommer att må särskilt bra och faller sönder. Vissa containrar kan till exempel falla och inte stiga – det kommer att kosta dig väldigt mycket senare om alla dina produktionssystem finns i ett kluster som hanteras av Nomad.

Så vi bestämde oss för att fundera på vart vi skulle gå härnäst. Vid det laget blev vi mycket mer medvetna om vad vi ville uppnå. Nämligen: vi vill ha tillförlitlighet, lite fler funktioner än vad Nomad tillhandahåller och ett mognare, stabilare system.

I detta avseende föll vårt val på Kubernetes som den mest populära plattformen för att lansera kluster. Speciellt med tanke på att storleken och antalet på våra containrar var tillräckligt stora. För sådana ändamål verkade Kubernetes vara det mest lämpliga systemet vi kunde titta på.

Övergång till Kubernetes

Jag ska berätta lite om de grundläggande koncepten för Kubernetes och hur de skiljer sig från Nomad.

Först och främst är det mest grundläggande konceptet i Kubernetes konceptet pod. Pod är en grupp av en eller flera containrar som alltid löper tillsammans. Och de fungerar alltid som strikt på en virtuell maskin. De är tillgängliga för varandra via IP 127.0.0.1 på olika portar.

Låt oss anta att du har en PHP-applikation som består av nginx och php-fpm - det klassiska schemat. Troligtvis kommer du att vilja hålla både nginx- och php-fpm-behållare tillsammans hela tiden. Kubernetes låter dig uppnå detta genom att beskriva dem som en gemensam pod. Detta är precis vad vi inte kunde få med Nomad.

Det andra konceptet är utplacering. Faktum är att själva kapseln är en tillfällig sak, den startar och försvinner. Vill du först döda alla dina tidigare behållare och sedan lansera nya versioner på en gång, eller vill du rulla ut dem gradvis? Det är den här processen som konceptet med implementering är ansvarig för. Den beskriver hur du distribuerar dina poddar, i vilken mängd och hur du uppdaterar dem.

Det tredje konceptet är service. Din tjänst är egentligen ditt system, som tar emot lite trafik och sedan vidarebefordrar den till en eller flera pods som motsvarar din tjänst. Det vill säga, det låter dig säga att all inkommande trafik till en sådan och en tjänst med ett sådant och ett sådant namn måste skickas till dessa specifika poddar. Och samtidigt ger den dig trafikbalansering. Det vill säga, du kan starta två pods av din applikation, och all inkommande trafik kommer att balanseras jämnt mellan podarna som är relaterade till denna tjänst.

Och det fjärde grundkonceptet är Ingress. Detta är en tjänst som körs på ett Kubernetes-kluster. Den fungerar som en extern lastbalanserare som tar över alla förfrågningar. Med hjälp av Kubernetes API kan Ingress bestämma vart dessa förfrågningar ska skickas. Dessutom gör han detta mycket flexibelt. Du kan säga att alla förfrågningar till denna värd och sådan och sådan URL skickas till denna tjänst. Och dessa förfrågningar som kommer till denna värd och till en annan URL skickas till en annan tjänst.

Det häftigaste ur synvinkeln för någon som utvecklar en applikation är att du kan hantera allt själv. Genom att ställa in Ingress-konfigurationen kan du skicka all trafik som kommer till ett sådant och ett API till separata behållare skrivna till exempel i Go. Men den här trafiken, som kommer till samma domän, men till en annan URL, ska skickas till behållare skrivna i PHP, där det finns mycket logik, men de är inte särskilt snabba.

Om vi ​​jämför alla dessa begrepp med Nomad kan vi säga att de tre första begreppen är alla tillsammans Service. Och det sista konceptet saknas i själva Nomad. Vi använde en extern balanserare som det: det kan vara haproxy, nginx, nginx+ och så vidare. När det gäller en kub behöver du inte introducera detta ytterligare koncept separat. Men om du tittar på Ingress internt är det antingen nginx, haproxy eller traefik, men typ inbyggt i Kubernetes.

Alla begrepp jag beskrev är i själva verket resurser som finns inom ett Kubernetes-kluster. För att beskriva dem i kuben används ett yaml-format, som är mer läsbart och bekant än HCL-filer i fallet med Nomad. Men strukturellt beskriver de samma sak i fallet med till exempel pod. De säger - jag vill placera ut sådana och sådana poddar där, med sådana och sådana bilder, i sådana och sådana mängder.

Dessutom insåg vi att vi inte ville skapa varje enskild resurs för hand: driftsättning, tjänster, Ingress, etc. Istället ville vi beskriva vart och ett av våra system i termer av Kubernetes under driftsättning, så att vi inte skulle behöva manuellt återskapa alla nödvändiga resursberoenden i rätt ordning. Helm valdes som det system som gjorde det möjligt för oss att göra detta.

Grundläggande begrepp i Helm

Helm är pakethanterare för Kubernetes. Det är väldigt likt hur pakethanterare i programmeringsspråk fungerar. De låter dig lagra en tjänst bestående av till exempel deployment nginx, deployment php-fpm, config for Ingress, configmaps (detta är en enhet som låter dig ställa in env och andra parametrar för ditt system) i form av så- kallas diagram. Samtidigt Helm körs ovanpå Kubernetes. Det vill säga, detta är inte något slags system som står åt sidan, utan bara en annan tjänst som lanseras inuti kuben. Du interagerar med den via dess API via ett konsolkommando. Dess bekvämlighet och skönhet är att även om rodret går sönder eller du tar bort det från klustret, kommer dina tjänster inte att försvinna, eftersom rodret i princip bara tjänar till att starta systemet. Kubernetes ansvarar då själv för prestanda och tillstånd för tjänsterna.

Det insåg vi också mallbildning, som vi tidigare tvingades göra själva genom att introducera jinja i våra konfigurationer, är en av huvudfunktionerna i helm. Alla konfigurationer som du skapar för dina system lagras i rodret i form av mallar, lite likt jinja, men i själva verket använder man mallen för Go-språket, där rod är skrivet, som Kubernetes.

Helm lägger till några fler koncept åt oss.

Diagram - detta är en beskrivning av din tjänst. I andra pakethanterare skulle det kallas ett paket, paket eller något liknande. Här heter det diagram.

Värden är de variabler som du vill använda för att bygga dina konfigurationer från mallar.

Släpp. Varje gång en tjänst som distribueras med hjälp av rodret får en inkrementell version av utgåvan. Helm kommer ihåg vad tjänstens konfiguration var i den tidigare versionen, versionen innan dess och så vidare. Därför, om du behöver återställa, kör bara kommandot för återuppringning av rodret och pekar på den tidigare versionen. Även om motsvarande konfiguration i ditt arkiv inte är tillgänglig vid tidpunkten för återställningen, kommer helm fortfarande att komma ihåg vad det var och kommer att återställa ditt system till det tillstånd det var i den tidigare utgåvan.

I fallet när vi använder helm, förvandlas vanliga konfigurationer för Kubernetes också till mallar där det är möjligt att använda variabler, funktioner och tillämpa villkorliga uttalanden. På så sätt kan du samla in din tjänstekonfiguration beroende på miljön.

I praktiken bestämde vi oss för att göra saker lite annorlunda än vad vi gjorde med Nomad. Om i Nomad både distributionskonfigurationer och n-variabler som behövdes för att distribuera vår tjänst lagrades i ett arkiv, här bestämde vi oss för att dela upp dem i två separata arkiv. "Deploy"-förvaret lagrar endast n-variabler som behövs för distribution, och "helm"-förvaret lagrar konfigurationer eller diagram.

Vad gav detta oss?

Trots att vi inte lagrar några riktigt känsliga data i själva konfigurationsfilerna. Till exempel lösenord till databaser. De lagras som hemligheter i Kubernetes, men ändå finns det vissa saker där som vi inte vill ge alla tillgång till. Därför är åtkomsten till "deploy"-förvaret mer begränsad, och "helm"-förrådet innehåller helt enkelt en beskrivning av tjänsten. Av denna anledning kan den nås på ett säkert sätt av ett bredare spektrum av människor.

Eftersom vi inte bara har produktion, utan även andra miljöer, kan vi tack vare denna separation återanvända våra styrdiagram för att distribuera tjänster inte bara till produktion, utan även till exempel till en QA-miljö. Till och med att distribuera dem lokalt med hjälp av Minikube – det här är en grej för att köra Kubernetes lokalt.

Inuti varje arkiv lämnade vi en uppdelning i separata kataloger för varje tjänst. Det vill säga, inuti varje katalog finns mallar relaterade till motsvarande diagram och som beskriver de resurser som behöver distribueras för att starta vårt system. Vi lämnade bara envs i "deploy"-förrådet. I det här fallet använde vi inte mall med jinja, eftersom själva rodret tillhandahåller mallar ur lådan - detta är en av dess huvudfunktioner.

Vi lämnade ett distributionsskript - deploy.sh, som förenklar och standardiserar lanseringen för distribution med hjälp av rodret. Så för alla som vill distribuera ser distributionsgränssnittet exakt likadant ut som det gjorde när det distribuerades genom Nomad. Samma deploy.sh, namnet på din tjänst och var du vill distribuera den. Detta gör att rodret startar internt. Den samlar i sin tur in konfigurationer från mallar, infogar de nödvändiga värdefilerna i dem, distribuerar dem sedan och lanserar dem i Kubernetes.

Resultat

Kubernetes-tjänsten verkar vara mer komplex än Nomad.

Här kommer utgående trafik till Ingress. Detta är bara den främre styrenheten, som tar över alla förfrågningar och sedan skickar dem till de tjänster som motsvarar förfrågningsdata. Det bestämmer dem baserat på konfigurationer som är en del av beskrivningen av din applikation i rodret och som utvecklare ställer in på egen hand. Tjänsten skickar förfrågningar till sina pods, det vill säga specifika containrar, och balanserar inkommande trafik mellan alla containrar som tillhör denna tjänst. Och, naturligtvis, bör vi inte glömma att vi inte bör gå någonstans från säkerhet på nätverksnivå. Därför fungerar segmentering i ett Kubernetes-kluster, som är baserat på taggning. Alla tjänster har vissa taggar som tjänsternas åtkomsträttigheter till vissa externa/interna resurser inom eller utanför klustret är kopplade till.

När vi gjorde övergången såg vi att Kubernetes hade alla funktioner som Nomad, som vi tidigare hade använt, och även lagt till en hel del nya saker. Det kan utökas genom plugins, och faktiskt genom anpassade resurstyper. Det vill säga, du har möjlighet att inte bara använda något som kommer med Kubernetes ur lådan, utan att skapa din egen resurs och tjänst som kommer att läsa din resurs. Detta ger dig ytterligare alternativ för att utöka ditt system utan att behöva installera om Kubernetes och utan att kräva ändringar.

Ett exempel på sådan användning är Prometheus, som körs i vårt Kubernetes-kluster. För att den ska börja samla in mätvärden från en viss tjänst behöver vi lägga till ytterligare en typ av resurs, den så kallade servicemonitorn, till tjänstebeskrivningen. Prometheus, på grund av det faktum att den kan läsa en anpassad resurstyp när den lanseras i Kubernetes, börjar automatiskt samla in mätvärden från det nya systemet. Det är ganska bekvämt.

Den första implementeringen vi gjorde till Kubernetes var i mars 2018. Och under den här tiden har vi aldrig upplevt några problem med det. Det fungerar ganska stabilt utan betydande buggar. Dessutom kan vi utöka det ytterligare. Idag har vi tillräckligt med kapaciteten den har, och vi gillar verkligen utvecklingstakten för Kubernetes. För närvarande finns mer än 3000 XNUMX containrar i Kubernetes. Klustret upptar flera noder. Samtidigt är den funktionsduglig, stabil och mycket kontrollerbar.

Källa: will.com