Hei alle sammen! Mitt navn er Pavel Agaletsky. Jeg jobber som teamleder i et team som utvikler Lamoda leveringssystem. I 2018 talte jeg på HighLoad++-konferansen, og i dag vil jeg presentere en transkripsjon av rapporten min.

Emnet mitt er dedikert til selskapets erfaring med å distribuere systemer og tjenester til forskjellige miljøer. Fra vår forhistoriske tid, da vi distribuerte alle systemer til vanlige virtuelle servere, og endte med den gradvise overgangen fra Nomad til distribusjon i Kubernetes. Jeg skal fortelle deg hvorfor vi gjorde det og hvilke problemer vi hadde i prosessen.

Distribuere applikasjoner til VM

La oss starte med det faktum at for 3 år siden ble alle selskapets systemer og tjenester distribuert på vanlige virtuelle servere. Teknisk sett var det organisert på en slik måte at all koden for systemene våre ble lagret og satt sammen ved hjelp av automatiske monteringsverktøy, ved bruk av jenkins. Ved å bruke Ansible ble den rullet ut fra vårt versjonskontrollsystem til virtuelle servere. Dessuten ble hvert system som selskapet vårt hadde distribuert til minst 2 servere: en av dem på hodet, den andre på halen. Disse to systemene var helt identiske med hverandre i alle innstillinger, kraft, konfigurasjon osv. Den eneste forskjellen mellom dem var at head mottok brukertrafikk, mens tail aldri mottok brukertrafikk.

Hva var det for?

Da vi implementerte nye utgivelser av applikasjonen vår, ønsket vi å sikre en sømløs utrulling, det vil si uten merkbare konsekvenser for brukerne. Dette ble oppnådd på grunn av det faktum at den neste kompilerte utgivelsen med Ansible ble rullet ut til hale. Der kunne personene som var involvert i utplasseringen sjekke og sørge for at alt var i orden: alle beregninger, seksjoner og applikasjoner fungerte; de nødvendige skriptene lanseres. Først etter at de var overbevist om at alt var i orden, ble trafikken byttet. Det begynte å gå til serveren som tidligere var hale. Og den som tidligere var hodet forble uten brukertrafikk, mens den fortsatt hadde den forrige versjonen av applikasjonen vår på seg.

Så det var sømløst for brukerne. Fordi vekslingen er øyeblikkelig, siden den ganske enkelt veksler balanseren. Du kan veldig enkelt rulle tilbake til forrige versjon ved ganske enkelt å bytte balanseren tilbake. Vi kunne også bekrefte at applikasjonen var i stand til å produsere allerede før den mottok brukertrafikk, noe som var ganske praktisk.

Hvilke fordeler så vi i alt dette?

1. Først og fremst er det nok det bare fungerer. Alle forstår hvordan en slik distribusjonsordning fungerer, fordi de fleste noen gang har distribuert til vanlige virtuelle servere.
2. Dette er nok pålitelig, siden distribusjonsteknologien er enkel, testet av tusenvis av selskaper. Millioner av servere er distribuert på denne måten. Det er vanskelig å bryte noe.
3. Og endelig kunne vi få atomutplasseringer. Implementeringer som skjer samtidig for brukere, uten et merkbart trinn med å bytte mellom den gamle versjonen og den nye.

Men vi så også flere mangler ved alt dette:

1. I tillegg til produksjonsmiljøet, utviklingsmiljøet, er det andre miljøer. For eksempel qa og preproduksjon. På den tiden hadde vi mange servere og rundt 60 tjenester. Av denne grunn var det nødvendig oppretthold den nyeste versjonen for hver tjeneste virtuell maskin. Dessuten, hvis du vil oppdatere biblioteker eller installere nye avhengigheter, må du gjøre dette i alle miljøer. Du trengte også å synkronisere tidspunktet når du skal distribuere den neste nye versjonen av applikasjonen din med tiden når devops utfører de nødvendige miljøinnstillingene. I dette tilfellet er det lett å komme i en situasjon hvor miljøet vårt vil være noe annerledes i alle miljøer samtidig. For eksempel vil det i et QA-miljø være noen versjoner av biblioteker, og i et produksjonsmiljø vil det være forskjellige, noe som vil føre til problemer.
2. Vanskeligheter med å oppdatere avhengigheter din søknad. Det avhenger ikke av deg, men på det andre laget. Nemlig fra devops-teamet som vedlikeholder serverne. Du må gi dem en passende oppgave og en beskrivelse av hva du vil gjøre.
3. På den tiden ønsket vi også å dele de store store monolittene vi hadde i separate små tjenester, siden vi forsto at det ville bli flere og flere av dem. På det tidspunktet hadde vi allerede mer enn 100. For hver nye tjeneste var det nødvendig å lage en egen ny virtuell maskin, som også måtte vedlikeholdes og distribueres. I tillegg trenger du ikke én bil, men minst to. I tillegg til alt dette er QA-miljøet. Dette skaper problemer og gjør det vanskeligere for deg å bygge og kjøre nye systemer. kompleks, kostbar og langvarig prosess.

Derfor bestemte vi oss for at det ville være mer praktisk å gå fra å distribuere vanlige virtuelle maskiner til å distribuere applikasjonene våre i en docker-container. Hvis du har docker, trenger du et system som kan kjøre applikasjonen i en klynge, siden du ikke bare kan heve en container. Vanligvis ønsker man å holde styr på hvor mange containere som løftes slik at de løftes automatisk. Av denne grunn måtte vi velge et kontrollsystem.

Vi tenkte lenge på hvilken vi kunne ta. Faktum er at på den tiden var denne distribusjonsstabelen på vanlige virtuelle servere noe utdatert, siden de ikke hadde de nyeste versjonene av operativsystemer. På et tidspunkt var det til og med FreeBSD, som ikke var veldig praktisk å støtte. Vi forsto at vi måtte migrere til docker så raskt som mulig. Våre devops så på deres eksisterende erfaring med forskjellige løsninger og valgte et system som Nomad.

Bytt til Nomad

Nomad er et produkt fra HashiCorp. De er også kjent for sine andre løsninger:

"Konsul" er et verktøy for tjenesteoppdagelse.

"Terraform" - et system for å administrere servere som lar deg konfigurere dem gjennom konfigurasjon, såkalt infrastruktur-som-en-kode.

"Vagrant" lar deg distribuere virtuelle maskiner lokalt eller i skyen via spesifikke konfigurasjonsfiler.

Nomad virket på den tiden som en ganske enkel løsning som raskt kunne byttes til uten å endre hele infrastrukturen. I tillegg er det ganske enkelt å lære. Det er derfor vi valgte det som filtreringssystem for containeren vår.

Hva trenger du for å distribuere systemet ditt til Nomad?

1. Først og fremst trenger du docker-bilde din søknad. Du må bygge den og plassere den i docker-bildelageret. I vårt tilfelle er dette en artifactory - et system som lar deg skyve forskjellige artefakter av forskjellige typer inn i den. Den kan lagre arkiver, docker-bilder, komponerende PHP-pakker, NPM-pakker og så videre.
2. Også nødvendig konfigurasjonsfil, som vil fortelle Nomad hva, hvor og i hvilken mengde du ønsker å distribuere.

Når vi snakker om Nomad, bruker den HCL-språket som informasjonsfilformat, som står for HashiCorp konfigurasjonsspråk. Dette er et supersett av Yaml som lar deg beskrive tjenesten din i Nomad-termer.

Den lar deg si hvor mange containere du vil distribuere, fra hvilke bilder du skal sende ulike parametere til dem under distribusjon. Dermed mater du denne filen til Nomad, og den lanserer containere i produksjon i henhold til den.

I vårt tilfelle innså vi at det å skrive helt identiske HCL-filer for hver tjeneste ikke ville være veldig praktisk, fordi det er mange tjenester, og noen ganger vil du oppdatere dem. Det hender at én tjeneste blir distribuert ikke i én instans, men i en rekke forskjellige. For eksempel har et av systemene vi har i produksjon mer enn 100 instanser i produksjon. De kjører fra de samme bildene, men er forskjellige i konfigurasjonsinnstillinger og konfigurasjonsfiler.

Derfor bestemte vi oss for at det ville være praktisk for oss å lagre alle våre konfigurasjonsfiler for distribusjon i ett felles depot. På denne måten var de synlige: de var enkle å vedlikeholde og vi kunne se hvilke systemer vi hadde. Om nødvendig er det også enkelt å oppdatere eller endre noe. Å legge til et nytt system er heller ikke vanskelig - du trenger bare å lage en konfigurasjonsfil i den nye katalogen. Inne i den er følgende filer: service.hcl, som inneholder en beskrivelse av tjenesten vår, og noen env-filer som gjør at nettopp denne tjenesten, som blir distribuert i produksjon, kan konfigureres.

Noen av systemene våre er imidlertid distribuert i produksjon ikke i ett eksemplar, men i flere samtidig. Derfor bestemte vi oss for at det ville være praktisk for oss å lagre ikke konfigurasjonene i deres rene form, men deres malte form. Og vi valgte jinja 2. I dette formatet lagrer vi både konfigurasjonene til selve tjenesten og env-filene som trengs for den.

I tillegg har vi plassert i depotet et distribusjonsskript som er felles for alle prosjekter, som lar deg lansere og distribuere tjenesten din i produksjon, inn i ønsket miljø, til ønsket mål. I tilfellet da vi gjorde om HCL-konfigurasjonen vår til en mal, begynte HCL-filen, som før var en vanlig Nomad-konfigurasjon, i dette tilfellet å se litt annerledes ut.

Det vil si at vi erstattet noen konfigurasjonsplasseringsvariabler med innsatte variabler som er hentet fra env-filer eller andre kilder. I tillegg fikk vi muligheten til å samle HCL-filer dynamisk, det vil si at vi ikke bare kan bruke vanlige variabelinnsettinger. Siden jinja støtter looper og betingelser, kan du også lage konfigurasjonsfiler der, som endres avhengig av hvor nøyaktig du distribuerer applikasjonene dine.

Du vil for eksempel distribuere tjenesten til pre-produksjon og produksjon. La oss si at du i pre-produksjon ikke vil kjøre cron-skript, men bare vil se tjenesten på et eget domene for å være sikker på at den fungerer. For alle som distribuerer tjenesten, ser prosessen veldig enkel og gjennomsiktig ut. Alt du trenger å gjøre er å kjøre filen deploy.sh, spesifisere hvilken tjeneste du vil distribuere og til hvilket mål. For eksempel vil du distribuere et bestemt system til Russland, Hviterussland eller Kasakhstan. For å gjøre dette, endre ganske enkelt en av parameterne, og du vil ha den riktige konfigurasjonsfilen.

Når Nomad-tjenesten allerede er distribuert til klyngen din, ser det slik ut.

Først trenger du en slags balanserer utenfor, som vil motta all brukertrafikk. Den vil jobbe sammen med Consul og finne ut fra den hvor, på hvilken node, på hvilken IP-adresse en spesifikk tjeneste ligger som tilsvarer et bestemt domenenavn. Tjenester i Consul kommer fra Nomad selv. Siden dette er produkter fra samme firma er de ganske i slekt med hverandre. Vi kan si at Nomad ut av boksen kan registrere alle tjenestene som er lansert i den inne i Consul.

Når front-lastbalanseren din vet hvilken tjeneste den skal sende trafikk til, videresender den den til riktig container eller flere containere som samsvarer med applikasjonen din. Naturligvis er det også nødvendig å tenke på sikkerhet. Selv om alle tjenester kjører på de samme virtuelle maskinene i containere, krever dette vanligvis å forhindre fri tilgang fra en hvilken som helst tjeneste til en hvilken som helst annen. Dette oppnådde vi gjennom segmentering. Hver tjeneste ble lansert i sitt eget virtuelle nettverk, hvor det ble foreskrevet rutingsregler og regler for å tillate/nekte tilgang til andre systemer og tjenester. De kan være plassert både inne i denne klyngen og utenfor den. Hvis du for eksempel ønsker å forhindre at en tjeneste kobles til en bestemt database, kan dette gjøres gjennom segmentering på nettverksnivå. Det vil si at selv ved en feil kan du ikke koble fra testmiljøet til produksjonsdatabasen ved et uhell.

Hvor mye kostet overgangen oss i form av menneskelige ressurser?

Overgangen av hele selskapet til Nomad tok cirka 5-6 måneder. Vi flyttet på en tjeneste-for-tjeneste basis, men i et ganske høyt tempo. Hvert team måtte lage sine egne containere for tjenestene.

Vi har tatt i bruk en slik tilnærming at hvert team er ansvarlig for docker-bilder av systemene sine uavhengig. DevOps gir den generelle infrastrukturen som er nødvendig for distribusjon, det vil si støtte for selve klyngen, støtte for CI-systemet, og så videre. Og på den tiden fikk vi flyttet mer enn 60 systemer til Nomad, som utgjorde omtrent 2 tusen containere.

Devops er ansvarlig for den generelle infrastrukturen til alt relatert til distribusjon og servere. Og hvert utviklingsteam er på sin side ansvarlig for å implementere containere for sitt spesifikke system, siden det er teamet som vet hva det generelt trenger i en bestemt container.

Grunner til å forlate Nomad

Hvilke fordeler fikk vi ved å bytte til distribusjon ved å bruke blant annet Nomad og docker?

1. Vi gitt like vilkår for alle miljøer. I utvikling, QA-miljø, pre-produksjon, produksjon, brukes de samme beholderbildene, med de samme avhengighetene. Følgelig har du praktisk talt ingen sjanse for at det som ender i produksjon ikke er det du tidligere har testet lokalt eller i ditt testmiljø.
2. Vi fant også ut at det er nok enkelt å legge til en ny tjeneste. Fra et distribusjonssynspunkt lanseres alle nye systemer veldig enkelt. Bare gå til depotet som lagrer konfigurasjoner, legg til en annen konfigurasjon for systemet ditt der, og du er klar. Du kan distribuere systemet til produksjon uten ekstra innsats fra devops.
3. Alle konfigurasjonsfiler i ett felles depot viste seg å være under vurdering. På det tidspunktet da vi distribuerte systemene våre ved hjelp av virtuelle servere, brukte vi Ansible, der konfigurasjonene var i samme depot. For de fleste utviklere var dette imidlertid litt vanskeligere å jobbe med. Her har volumet av konfigurasjoner og kode som du må legge til for å distribuere tjenesten blitt mye mindre. I tillegg er det veldig enkelt for devops å fikse eller endre det. Ved overganger, for eksempel til en ny versjon av Nomad, kan de ta og masseoppdatere alle driftsfilene som ligger på samme sted.

Men vi møtte også flere ulemper:

Det viste seg at vi kunne ikke oppnå sømløse distribusjoner i tilfellet Nomad. Ved utrulling av containere under ulike forhold kunne den vise seg å gå, og Nomad oppfattet den som en container klar til å ta imot trafikk. Dette skjedde før applikasjonen inne i den hadde en sjanse til å starte. Av denne grunn begynte systemet å produsere 500 feil i en kort periode, fordi trafikken begynte å gå til en container som ennå ikke var klar til å akseptere den.

Vi møtte noen ved myrene. Den viktigste feilen er at Nomad ikke håndterer en stor klynge så godt hvis du har mange systemer og containere. Når du ønsker å ta ut en av serverne som inngår i Nomad-klyngen for vedlikehold, er det ganske stor sannsynlighet for at klyngen ikke vil føles særlig bra og faller fra hverandre. Noen containere kan for eksempel falle og ikke stige - dette vil koste deg veldig mye senere hvis alle produksjonssystemene dine er plassert i en klynge administrert av Nomad.

Så vi bestemte oss for å tenke på hvor vi skulle gå videre. På det tidspunktet ble vi mye mer bevisste på hva vi ønsket å oppnå. Nemlig: vi ønsker pålitelighet, litt flere funksjoner enn Nomad gir, og et mer modent, mer stabilt system.

I denne forbindelse falt valget vårt på Kubernetes som den mest populære plattformen for å lansere klynger. Spesielt gitt at størrelsen og antallet på våre containere var store nok. For slike formål så Kubernetes ut til å være det mest passende systemet vi kunne se på.

Overgang til Kubernetes

Jeg skal fortelle deg litt om de grunnleggende konseptene til Kubernetes og hvordan de skiller seg fra Nomad.

Først av alt, det mest grunnleggende konseptet i Kubernetes er konseptet pod. Pod er en gruppe av en eller flere containere som alltid kjører sammen. Og de fungerer alltid som strengt tatt på én virtuell maskin. De er tilgjengelige for hverandre via IP 127.0.0.1 på forskjellige porter.

La oss anta at du har en PHP-applikasjon som består av nginx og php-fpm – det klassiske opplegget. Mest sannsynlig vil du holde både nginx- og php-fpm-beholdere sammen til enhver tid. Kubernetes lar deg oppnå dette ved å beskrive dem som én felles pod. Dette er akkurat det vi ikke kunne få med Nomad.

Det andre konseptet er distribusjon. Faktum er at selve poden er en flyktig ting; den starter og forsvinner. Vil du først drepe alle de tidligere beholderne dine, og deretter lansere nye versjoner på en gang, eller vil du rulle dem ut gradvis? Dette er prosessen som konseptet med distribusjon er ansvarlig for. Den beskriver hvordan du distribuerer podene dine, i hvilken mengde og hvordan du oppdaterer dem.

Det tredje konseptet er tjeneste. Tjenesten din er faktisk systemet ditt, som mottar en del trafikk og deretter videresender den til en eller flere pods som tilsvarer tjenesten din. Det vil si at det lar deg si at all innkommende trafikk til en slik og en tjeneste med et slikt og et slikt navn må sendes til disse spesifikke podene. Og samtidig gir den deg trafikkbalansering. Det vil si at du kan starte to pods av applikasjonen din, og all innkommende trafikk vil være jevnt balansert mellom podene relatert til denne tjenesten.

Og det fjerde grunnleggende konseptet er Ingress. Dette er en tjeneste som kjører på en Kubernetes-klynge. Den fungerer som en ekstern lastbalanser som tar over alle forespørsler. Ved å bruke Kubernetes API kan Ingress bestemme hvor disse forespørslene skal sendes. Dessuten gjør han dette veldig fleksibelt. Du kan si at alle forespørsler til denne verten og slik og slik URL sendes til denne tjenesten. Og disse forespørslene som kommer til denne verten og til en annen URL sendes til en annen tjeneste.

Det kuleste fra synspunktet til en som utvikler en applikasjon er at du klarer å administrere alt selv. Ved å sette Ingress-konfigurasjonen kan du sende all trafikk som kommer til en slik og en API til separate containere skrevet for eksempel i Go. Men denne trafikken, som kommer til samme domene, men til en annen URL, skal sendes til containere skrevet i PHP, hvor det er mye logikk, men de er ikke veldig raske.

Hvis vi sammenligner alle disse konseptene med Nomad, kan vi si at de tre første konseptene er alle sammen Service. Og det siste konseptet er fraværende i selve Nomad. Vi brukte en ekstern balanserer som det: det kan være haproxy, nginx, nginx+ og så videre. Når det gjelder en kube, trenger du ikke introdusere dette tilleggskonseptet separat. Men hvis du ser på Ingress internt, er det enten nginx, haproxy eller traefik, men på en måte innebygd i Kubernetes.

Alle konseptene jeg beskrev er faktisk ressurser som finnes i en Kubernetes-klynge. For å beskrive dem i kuben, brukes et yaml-format, som er mer lesbart og kjent enn HCL-filer i tilfellet med Nomad. Men strukturelt beskriver de det samme når det gjelder for eksempel pod. De sier – jeg vil sette ut sånne og sånne poder der, med sånne og sånne bilder, i sånne og sånne mengder.

I tillegg innså vi at vi ikke ønsket å lage hver enkelt ressurs for hånd: distribusjon, tjenester, Ingress, etc. I stedet ønsket vi å beskrive hvert av systemene våre i form av Kubernetes under utrulling, slik at vi ikke måtte manuelt gjenskape alle nødvendige ressursavhengigheter i riktig rekkefølge. Helm ble valgt som systemet som tillot oss å gjøre dette.

Grunnleggende begreper i Helm

Helm er pakkeansvarlig for Kubernetes. Det er veldig likt hvordan pakkebehandlere i programmeringsspråk fungerer. De lar deg lagre en tjeneste bestående av for eksempel deployment nginx, deployment php-fpm, config for Ingress, configmaps (dette er en enhet som lar deg sette env og andre parametere for systemet ditt) i form av so- kalt diagrammer. Samtidig Helm går på toppen av Kubernetes. Det vil si at dette ikke er et slags system som står til side, men bare en annen tjeneste lansert inne i kuben. Du samhandler med den via API-en via en konsollkommando. Dens bekvemmelighet og skjønnhet er at selv om roret går i stykker eller du fjerner det fra klyngen, vil ikke tjenestene dine forsvinne, siden roret i hovedsak bare tjener til å starte systemet. Kubernetes selv er da ansvarlig for ytelsen og tilstanden til tjenestene.

Det skjønte vi også maling, som vi tidligere ble tvunget til å gjøre selv ved å introdusere jinja i konfigurasjonene våre, er en av hovedfunksjonene til helm. Alle konfigurasjonene du oppretter for systemene dine er lagret i helm i form av maler, litt lik jinja, men faktisk ved å bruke malen til Go-språket, der helm er skrevet, som Kubernetes.

Helm legger til noen flere konsepter for oss.

Figur - dette er en beskrivelse av tjenesten din. I andre pakkeadministratorer vil det bli kalt en pakke, bunt eller noe lignende. Her heter det diagram.

Verdier er variablene du vil bruke for å bygge konfigurasjonene dine fra maler.

Slipp. Hver gang en tjeneste som distribueres ved hjelp av ror mottar en inkrementell versjon av utgivelsen. Helm husker hva tjenestekonfigurasjonen var i forrige utgivelse, utgivelsen før det, og så videre. Derfor, hvis du trenger å rulle tilbake, bare kjør kommandoen for tilbakeringing av roret, og pek den til forrige utgivelsesversjon. Selv om den tilsvarende konfigurasjonen i depotet ditt ikke er tilgjengelig på tilbakeføringstidspunktet, vil helm fortsatt huske hva det var og vil tilbakestille systemet til tilstanden det var i den forrige utgivelsen.

I tilfellet når vi bruker helm, blir vanlige konfigurasjoner for Kubernetes også til maler der det er mulig å bruke variabler, funksjoner og bruke betingede setninger. På denne måten kan du samle inn tjenestekonfigurasjonen din avhengig av miljøet.

I praksis bestemte vi oss for å gjøre ting litt annerledes enn vi gjorde med Nomad. Hvis i Nomad både distribusjonskonfigurasjoner og n-variabler som var nødvendig for å distribuere tjenesten vår ble lagret i ett depot, her bestemte vi oss for å dele dem inn i to separate depoter. "Deploy"-repositoriet lagrer bare n-variabler som trengs for distribusjon, og "helm"-repositoriet lagrer konfigurasjoner eller diagrammer.

Hva ga dette oss?

Til tross for at vi ikke lagrer noen virkelig sensitive data i selve konfigurasjonsfilene. For eksempel passord til databaser. De er lagret som hemmeligheter i Kubernetes, men likevel er det fortsatt visse ting der som vi ikke ønsker å gi alle tilgang til. Derfor er tilgangen til «deploy»-depotet mer begrenset, og «helm»-depotet inneholder ganske enkelt en beskrivelse av tjenesten. Av denne grunn kan den nås trygt av et bredere spekter av mennesker.

Siden vi ikke bare har produksjon, men også andre miljøer, kan vi takket være denne separasjonen gjenbruke rorkartene våre til å distribuere tjenester ikke bare til produksjon, men også for eksempel til et QA-miljø. Til og med å distribuere dem lokalt ved hjelp av Minikube – dette er en greie for å drive Kubernetes lokalt.

Inne i hvert depot la vi en inndeling i separate kataloger for hver tjeneste. Det vil si at inne i hver katalog er det maler relatert til det tilsvarende diagrammet og som beskriver ressursene som må distribueres for å kjøre systemet vårt. Vi la bare envs i "deploy"-depotet. I dette tilfellet brukte vi ikke maler ved å bruke jinja, fordi selve roret gir maling ut av esken - dette er en av hovedfunksjonene.

Vi la igjen et distribusjonsskript - deploy.sh, som forenkler og standardiserer lanseringen for utrulling ved hjelp av roret. Så, for alle som ønsker å distribuere, ser distribusjonsgrensesnittet ut nøyaktig det samme som det gjorde ved distribusjon gjennom Nomad. Den samme deploy.sh, navnet på tjenesten din og hvor du vil distribuere den. Dette fører til at roret starter opp internt. Den samler på sin side inn konfigurasjoner fra maler, setter inn de nødvendige verdifilene i dem, distribuerer dem deretter og lanserer dem i Kubernetes.

Funn

Kubernetes-tjenesten ser ut til å være mer kompleks enn Nomad.

Her kommer utgående trafikk til Ingress. Dette er bare frontkontrolleren, som tar over alle forespørsler og deretter sender dem til tjenestene som tilsvarer forespørselsdataene. Den bestemmer dem basert på konfigurasjoner som er en del av beskrivelsen av applikasjonen din i ror og som utviklere setter på egen hånd. Tjenesten sender forespørsler til sine pods, det vil si spesifikke containere, og balanserer innkommende trafikk mellom alle containere som tilhører denne tjenesten. Og selvfølgelig bør vi ikke glemme at vi ikke bør gå noe sted fra sikkerhet på nettverksnivå. Derfor fungerer segmentering i en Kubernetes-klynge, som er basert på tagging. Alle tjenester har visse tagger som tjenestenes tilgangsrettigheter til visse eksterne/interne ressurser innenfor eller utenfor klyngen er knyttet til.

Da vi gjorde overgangen, så vi at Kubernetes hadde alle egenskapene til Nomad, som vi tidligere hadde brukt, og la også til mange nye ting. Det kan utvides gjennom plugins, og faktisk gjennom tilpassede ressurstyper. Det vil si at du har muligheten til ikke bare å bruke noe som følger med Kubernetes ut av esken, men å lage din egen ressurs og tjeneste som vil lese ressursen din. Dette gir deg flere alternativer for å utvide systemet uten å måtte installere Kubernetes på nytt og uten å kreve endringer.

Et eksempel på slik bruk er Prometheus, som kjører inne i vår Kubernetes-klynge. For at den skal begynne å samle inn beregninger fra en bestemt tjeneste, må vi legge til en ekstra type ressurs, den såkalte tjenestemonitoren, til tjenestebeskrivelsen. Prometheus, på grunn av det faktum at den kan lese en tilpasset ressurstype når den lanseres i Kubernetes, begynner automatisk å samle inn beregninger fra det nye systemet. Det er ganske praktisk.

Den første distribusjonen vi gjorde til Kubernetes var i mars 2018. Og i løpet av denne tiden har vi aldri opplevd noen problemer med det. Det fungerer ganske stabilt uten vesentlige feil. I tillegg kan vi utvide det ytterligere. I dag har vi nok av egenskapene den har, og vi liker veldig godt utviklingstakten til Kubernetes. For tiden er mer enn 3000 containere i Kubernetes. Klyngen opptar flere noder. Samtidig er den brukbar, stabil og svært kontrollerbar.

Kilde: www.habr.com