Hej alle! Mit navn er Pavel Agaletsky. Jeg arbejder som teamleder i et team, der udvikler Lamoda leveringssystemet. I 2018 talte jeg på HighLoad ++ konferencen, og i dag vil jeg præsentere et udskrift af min rapport.

Mit emne er dedikeret til vores virksomheds erfaring med at implementere systemer og tjenester til forskellige miljøer. Startende fra vores forhistoriske tid, hvor vi implementerede alle systemer til almindelige virtuelle servere, og sluttede med en gradvis overgang fra Nomad til Kubernetes-implementering. Jeg vil fortælle dig, hvorfor vi gjorde det, og hvilke problemer vi havde i processen.

Implementer applikationer til VM

Lad os starte med det faktum, at for 3 år siden blev alle virksomhedens systemer og tjenester installeret på almindelige virtuelle servere. Teknisk var det organiseret på en sådan måde, at al koden til vores systemer lå og blev samlet ved hjælp af automatiske montageværktøjer, ved hjælp af jenkins. Ved hjælp af Ansible var det allerede rullet ud fra vores versionskontrolsystem til virtuelle servere. På samme tid blev hvert system, der var i vores virksomhed, installeret på mindst 2 servere: en af ​​dem - på hovedet, den anden - på halen. Disse to systemer var fuldstændig identiske med hinanden i alle deres indstillinger, effekt, konfiguration og så videre. Den eneste forskel mellem dem var, at head modtog brugertrafik, mens tail aldrig modtog brugertrafik for sig selv.

Hvad var det til?

Da vi implementerede nye udgivelser af vores applikation, ønskede vi at sikre muligheden for problemfri implementering, det vil sige uden mærkbare konsekvenser for brugerne. Dette blev opnået på grund af det faktum, at den næste kompilerede udgivelse ved hjælp af Ansible blev rullet ud til hale. Der kunne de personer, der var involveret i udrulningen, tjekke og sikre sig, at alt er i orden: alle målinger, sektioner og applikationer virker; de nødvendige scripts lanceres. Først efter at de var overbevist om, at alt var i orden, skiftede trafikken. Han begyndte at gå til serveren, der var hale før. Og den, der tidligere var hovedet, forblev uden brugertrafik, mens den tidligere version af vores applikation var tilgængelig på den.

Så det var problemfrit for brugerne. Fordi skiftet er øjeblikkeligt, da det kun er en balancer kobling. Det er meget nemt at rulle tilbage til den tidligere version ved blot at skifte balanceren tilbage. Vi kunne også sikre os, at applikationen var klar til produktion, allerede inden brugertrafikken gik til den, hvilket var ret praktisk.

Hvilke dyder ser vi i alt dette?

1. Først og fremmest er det nok virker bare. Alle forstår, hvordan sådan en implementeringsplan fungerer, fordi de fleste mennesker nogensinde har installeret til almindelige virtuelle servere.
2. Dette er nok pålideligt, da implementeringsteknologien er enkel, testet af tusindvis af virksomheder. Millioner af servere er installeret på denne måde. Det er svært at bryde noget.
3. Og endelig kunne vi få det atomarter. Implementeringer, der sker samtidigt for brugere, uden et mærkbart skift mellem den gamle version og den nye.

Men vi så også flere mangler i det hele:

1. Ud over produktionsmiljøet, udviklingsmiljøet, er der andre miljøer. For eksempel qa og præproduktion. På det tidspunkt havde vi mange servere og omkring 60 tjenester. Af denne grund måtte det for hver tjeneste skal du vedligeholde den seneste version for den virtuel maskine. Desuden, hvis du vil opdatere biblioteker eller installere nye afhængigheder, skal du gøre dette i alle miljøer. Det var også nødvendigt at synkronisere det tidspunkt, hvor du vil implementere den næste nye version af din applikation, med det tidspunkt, hvor devops udfører de nødvendige miljøindstillinger. I dette tilfælde er det let at komme i en situation, hvor vores miljø vil være noget anderledes på én gang i alle miljøer i træk. For eksempel vil der i et QA-miljø være nogle versioner af biblioteker, og i produktionen - andre, hvilket vil føre til problemer.
2. Svært ved at opdatere afhængigheder din ansøgning. Det afhænger ikke af dig, men af ​​det andet hold. Nemlig fra devops-teamet, der vedligeholder serverne. Du bør give dem en passende opgave og beskrive, hvad du vil gøre.
3. På det tidspunkt ville vi også dele de store store monolitter, vi havde, op i separate små tjenester, da vi forstod, at der ville blive flere og flere af dem. På det tidspunkt havde vi allerede mere end 100. Det var nødvendigt at lave en separat ny virtuel maskine for hver ny tjeneste, som også skulle serviceres og installeres. Derudover behøver du ikke én bil, men mindst to. Til dette er alt tilføjet et QA-miljø. Dette giver problemer og gør det sværere for dig at bygge og køre nye systemer. kompleks, omkostningsfuld og langvarig proces.

Derfor besluttede vi, at det ville være mere bekvemt at gå fra at implementere almindelige virtuelle maskiner til at implementere vores applikationer i en docker-container. Hvis du har docker, har du brug for et system, der kan køre applikationen i en klynge, da du ikke bare sådan kan hæve en container. Normalt vil man gerne have styr på, hvor mange containere der løftes, så de løftes automatisk. Af denne grund var vi nødt til at vælge et kontrolsystem.

Vi tænkte længe over, hvilken vi skulle tage. Faktum er, at på det tidspunkt var denne udrulningsstak til almindelige virtuelle servere noget forældet, da der ikke var de nyeste versioner af operativsystemer. På et tidspunkt var selv FreeBSD der, hvilket ikke var særlig bekvemt at vedligeholde. Vi forstod, at vi skulle migrere til docker så hurtigt som muligt. Vores devops så på deres erfaringer med forskellige løsninger og valgte et system som Nomad.

Skifter til Nomad

Nomad er et produkt af HashiCorp. De er også kendt for deres andre løsninger:

Konsul er et værktøj til serviceopdagelse.

"Terraform" - et system til styring af servere, der giver dig mulighed for at konfigurere dem gennem en konfiguration, den såkaldte infrastruktur-som-en-kode.

Vagrant giver dig mulighed for at implementere virtuelle maskiner lokalt eller i skyen gennem specifikke konfigurationsfiler.

Nomad virkede på det tidspunkt som en ret simpel løsning, som man hurtigt kan skifte til uden at ændre hele infrastrukturen. Derudover er det ret nemt at lære. Derfor valgte vi det som filtreringssystem til vores container.

Hvad har du brug for for rent faktisk at implementere dit system i Nomad?

1. Først og fremmest har du brug for docker billede din ansøgning. Du skal bygge den og lægge den i docker-billedbutikken. I vores tilfælde er dette artifactory - et system, der giver dig mulighed for at skubbe forskellige artefakter af forskellige typer ind i det. Det kan gemme arkiver, docker-billeder, PHP-komponistpakker, NPM-pakker og så videre.
2. Også nødvendig konfigurationsfil, som vil fortælle Nomad hvad, hvor og hvor meget du vil implementere.

Når vi taler om Nomad, bruger den HCL-sproget som et informationsfilformat, som står for HashiCorp konfigurationssprog. Det er et supersæt af Yaml, der giver dig mulighed for at beskrive din tjeneste i form af Nomad.

Det giver dig mulighed for at sige, hvor mange containere du vil implementere, fra hvilke billeder du skal overføre forskellige parametre til dem under implementeringen. Så du fodrer denne fil til Nomad, og den starter containere til produktion i henhold til den.

I vores tilfælde indså vi, at bare at skrive nøjagtig de samme, identiske HCL-filer for hver tjeneste ikke ville være særlig praktisk, fordi der er mange tjenester, og nogle gange vil du opdatere dem. Det sker, at en tjeneste ikke bliver implementeret i én instans, men i en række forskellige. For eksempel har et af de systemer, vi har i produktionen, over 100 instanser i produktionen. De kører fra de samme billeder, men adskiller sig i konfigurationsindstillinger og konfigurationsfiler.

Derfor besluttede vi, at det ville være praktisk for os at gemme alle vores konfigurationsfiler til udrulning i ét fælles lager. På den måde blev de synlige: De var nemme at vedligeholde, og man kunne se, hvad det er for nogle systemer, vi har. Hvis det er nødvendigt, er det også nemt at opdatere eller ændre noget. Tilføjelse af et nyt system er heller ikke svært - tilføj blot en konfigurationsfil i den nye mappe. Inde i den er filerne: service.hcl, som indeholder en beskrivelse af vores tjeneste, og nogle env-filer, der gør det muligt at konfigurere netop denne tjeneste, der er implementeret i produktionen.

Nogle af vores systemer implementeres dog i produktionen ikke i én kopi, men i flere på én gang. Derfor besluttede vi, at det ville være praktisk for os ikke at gemme konfigurationer i deres rene form, men deres skabelonform. Og som det skabelonsprog, vi har valgt jinja 2. I dette format gemmer vi både konfigurationerne af selve tjenesten og de nødvendige env-filer.

Derudover har vi placeret et deployment-script, der er fælles for alle projekter, i lageret, som giver dig mulighed for at starte og implementere din service i produktionen, i det rigtige miljø, i det rigtige mål. I det tilfælde, hvor vi forvandlede vores HCL-konfiguration til en skabelon, så begyndte HCL-filen, som før det var den sædvanlige Nomad-konfiguration, i dette tilfælde at se lidt anderledes ud.

Det vil sige, at vi har erstattet nogle config place-variabler med variable inserts, der er taget fra env-filer eller fra andre kilder. Derudover fik vi muligheden for at bygge HCL-filer dynamisk, det vil sige, at vi ikke kun kan bruge de sædvanlige variable inserts. Da jinja understøtter cyklusser og betingelser, kan du også lægge konfigurationsfiler der, som ændrer sig afhængigt af, hvor præcis du implementerer dine applikationer.

For eksempel vil du implementere din service til præproduktion og produktion. Lad os sige, at du i præproduktion ikke ønsker at køre cron-scripts, men blot vil se tjenesten på et separat domæne for at sikre, at den kører. For alle, der implementerer en tjeneste, er processen meget enkel og gennemsigtig. Det er nok at udføre filen deploy.sh, specificere hvilken tjeneste du vil installere og til hvilket mål. For eksempel vil du installere et eller andet system til Rusland, Hviderusland eller Kasakhstan. For at gøre dette skal du blot ændre en af ​​parametrene, og du vil have den korrekte konfigurationsfil.

Når Nomad-tjenesten allerede er implementeret i din klynge, ser det sådan ud.

Til at begynde med har du brug for noget load balancer udefra, som vil tage al brugertrafik ind i sig selv. Det vil arbejde sammen med Consul og lære af det, hvor, på hvilken node, på hvilken IP-adresse en bestemt tjeneste er placeret, hvilket svarer til et bestemt domænenavn. Services i Consul kommer fra Nomad selv. Da disse er produkter fra samme virksomhed, er de godt forbundet. Vi kan sige, at Nomad ud af boksen er i stand til at registrere alle tjenester, der er lanceret i den inde i Consul.

Når din eksterne balancer ved, hvilken tjeneste den skal sende trafik til, omdirigerer den den til den relevante container eller flere containere, der matcher din applikation. Det er naturligvis også nødvendigt at tænke på sikkerheden. Selvom alle tjenester kører på de samme virtuelle maskiner i containere, kræver dette normalt, at enhver tjeneste nægtes fri adgang til enhver anden. Det opnåede vi gennem segmentering. Hver tjeneste blev lanceret i sit eget virtuelle netværk, hvorpå routingregler og regler for at tillade/nægte adgang til andre systemer og tjenester blev skrevet. De kunne være både inde i denne klynge og uden for den. Hvis du for eksempel vil forhindre en tjeneste i at oprette forbindelse til en bestemt database, kan dette gøres ved at segmentere på netværksniveau. Det vil sige, at du selv ved en fejl ikke kan oprette forbindelse fra testmiljøet til din produktionsbase.

Hvor meget kostede overgangen os i form af menneskelige ressourcer?

Cirka 5-6 måneder tog overgangen af ​​hele virksomheden til Nomad. Vi flyttede service-for-service, men i et ret hurtigt tempo. Hvert team skulle lave deres egne servicecontainere.

Vi har valgt en sådan tilgang, at hvert team er ansvarligt for docker-billederne af deres systemer uafhængigt. Devops, på den anden side, leverer den generelle infrastruktur, der er nødvendig for udrulning, det vil sige support til selve klyngen, support til CI-systemet og så videre. Og på det tidspunkt fik vi flyttet mere end 60 systemer til Nomad, hvilket viste sig at være omkring 2 tusinde containere.

DevOps er ansvarlig for den overordnede infrastruktur af alt relateret til udrulning, med servere. Og hvert udviklingsteam er til gengæld ansvarligt for at implementere containere til deres specifikke system, da det er teamet, der ved, hvad det generelt har brug for i en bestemt container.

Årsager til at forlade Nomad

Hvilke fordele fik vi ved også at skifte til implementering ved hjælp af Nomad og docker?

1. Vi forudsat samme betingelser til alle miljøer. I udvikling, QA-miljø, præproduktion, produktion, bruges de samme containerbilleder, med samme afhængigheder. Derfor har du praktisk talt ingen chance for, at noget andet end det, du tidligere har testet lokalt eller i et testmiljø, vil vise sig i produktionen.
2. Vi fandt også ud af, at det er nok nemt at tilføje en ny tjeneste. Alle nye systemer med hensyn til udrulning lanceres meget enkelt. Det er nok at gå til depotet, der gemmer konfigurationerne, tilføje den næste konfiguration for dit system der, og du er klar. Du kan implementere dit system til produktion uden ekstra indsats fra devops.
3. Alle konfigurationsfiler i ét fælles lager viste sig at være overset. I det øjeblik, hvor vi implementerede vores systemer ved hjælp af virtuelle servere, brugte vi Ansible, hvor konfigurationerne var i det samme lager. For de fleste udviklere var dette dog lidt sværere at arbejde med. Her er mængden af ​​konfigurationer og kode, som du skal tilføje for at implementere tjenesten, blevet meget mindre. Plus for devops er det meget nemt at reparere eller ændre det. Ved overgange til for eksempel en ny version af Nomad kan de tage og massivt opdatere alle de driftsfiler, der ligger samme sted.

Men vi stødte også på flere ulemper:

Det viste sig, at vi ikke opnåede problemfri implementeringer i tilfældet Nomad. Ved udrulning af containere fra forskellige forhold kunne det vise sig, at den viste sig at køre, og Nomad opfattede den som en container klar til at modtage trafik. Dette skete allerede før applikationen inde i den nåede at starte. Af denne grund begyndte systemet at udstede 500 fejl i kort tid, fordi trafikken begyndte at gå til containeren, som endnu ikke var klar til at acceptere den.

Vi er stødt på nogle ved moserne. Den mest markante fejl er, at Nomad ikke håndterer en stor klynge særlig godt, hvis du har mange systemer og containere. Når du vil tage en af ​​de servere, som er inkluderet i Nomad-klyngen i drift, er der ret stor sandsynlighed for, at klyngen ikke vil føles særlig god og falde fra hinanden. Nogle containere kan for eksempel falde og ikke hæve sig - det vil koste dig meget senere, hvis alle dine systemer i produktion er placeret i en Nomad-styret klynge.

Så vi besluttede at tænke over, hvor vi skulle tage hen næste gang. På det tidspunkt blev vi meget mere bevidste om, hvad vi vil opnå. Nemlig: vi vil have pålidelighed, lidt flere funktioner end Nomad giver, og et mere modent, mere stabilt system.

I denne henseende faldt vores valg på Kubernetes som den mest populære platform til at køre klynger. Især i betragtning af at størrelsen og antallet af vores containere var stort nok. Til sådanne formål syntes Kubernetes at være det mest egnede system af dem, vi kunne se på.

Flytter til Kubernetes

Jeg vil tale lidt om, hvad de grundlæggende begreber i Kubernetes er, og hvordan de adskiller sig fra Nomad.

Først og fremmest er det mest grundlæggende koncept i Kubernetes konceptet pod. Pod er en gruppe af en eller flere containere, der altid starter sammen. Og de arbejder som om altid strengt taget på den samme virtuelle maskine. De er tilgængelige for hinanden via IP-adresse 127.0.0.1 på forskellige porte.

Lad os sige, at du har et PHP-program, der består af nginx og php-fpm - det klassiske mønster. Mest sandsynligt vil du have, at både nginx- og php-fpm-containere altid skal være sammen. Kubernetes giver dig mulighed for at opnå dette ved at beskrive dem som én fælles pod. Det er præcis, hvad vi ikke kunne få med Nomad.

Det andet koncept er implementering. Pointen er, at poden i sig selv er en flygtig ting, den starter og forsvinder. Uanset om du først vil dræbe alle dine tidligere containere og derefter lancere nye versioner med det samme, eller du vil rulle dem ud gradvist - det er netop implementeringskonceptet, der er ansvarlig for denne proces. Den beskriver, hvordan du implementerer dine pods, hvor mange, og hvordan du opdaterer dem.

Det tredje koncept er tjeneste. Din tjeneste er faktisk dit system, der tager noget trafik og derefter dirigerer den til en eller flere pods, der svarer til din tjeneste. Det vil sige, at det giver dig mulighed for at sige, at al indgående trafik til sådan og sådan en tjeneste med sådan og sådan et navn skal sendes til disse specifikke pods. Og samtidig giver det dig trafikafbalancering. Det vil sige, at du kan køre to pods af din applikation, og al indkommende trafik vil være jævnt afbalanceret mellem pods, der er relateret til denne tjeneste.

Og det fjerde grundlæggende koncept - Ingress. Dette er en tjeneste, der kører på en Kubernetes-klynge. Den fungerer som en ekstern load balancer, der overtager alle anmodninger. Via Kubernetes API kan Ingress bestemme, hvor disse anmodninger skal sendes. Og han gør det meget fleksibelt. Du kan sige, at alle anmodninger om denne vært og sådan og sådan en URL sendes til denne tjeneste. Og disse anmodninger, der kommer til denne vært og til en anden URL, sendes til en anden tjeneste.

Det fedeste set fra en, der udvikler en applikation, er, at du er i stand til at styre det hele selv. Ved at indstille Ingress-konfigurationen kan du sende al trafik, der kommer til sådan og sådan en API til separate containere, registreret for eksempel i Go. Men denne trafik, der kommer til det samme domæne, men til en anden URL, sendes til containere skrevet i PHP, hvor der er meget logik, men de er ikke særlig hurtige.

Hvis vi sammenligner alle disse begreber med Nomad, så kan vi sige, at de første tre begreber alle sammen er Service. Og det sidste koncept er fraværende i selve Nomad. Vi brugte en ekstern balancer som det: det kan være haproxy, nginx, nginx + og så videre. I tilfælde af en terning behøver du ikke at introducere dette ekstra koncept separat. Men hvis du ser på Ingress inde, så er det enten nginx eller haproxy eller traefik, men så at sige indbygget i Kubernetes.

Alle de begreber, jeg har beskrevet, er i virkeligheden ressourcer, der findes inde i en Kubernetes-klynge. For at beskrive dem i kuben bruges yaml-formatet, som er mere læsbart og velkendt end HCL-filer i tilfældet med Nomad. Men strukturelt beskriver de det samme i tilfældet med for eksempel en pod. De siger - jeg vil placere sådan og sådan pods der, med sådanne og sådanne billeder, i sådan og sådan mængde.

Derudover indså vi, at vi ikke ønskede at oprette hver enkelt ressource manuelt: implementering, tjenester, Ingress og så videre. I stedet ønskede vi at beskrive vores hvert system i form af Kubernetes under udrulningen, så vi ikke manuelt skulle genskabe alle de nødvendige ressourceafhængigheder i den rigtige rækkefølge. Helm blev valgt som et sådant system, der gjorde det muligt for os at gøre dette.

Grundlæggende begreber i Helm

Helm er pakkeansvarlig for Kubernetes. Det minder meget om, hvordan pakkeadministratorer arbejder i programmeringssprog. De giver dig mulighed for at gemme en service bestående af for eksempel deployment nginx, deployment php-fpm, config for Ingress, configmaps (dette er en enhed, der giver dig mulighed for at indstille env og andre parametre for dit system) i form af så- kaldet diagrammer. Samtidig, Helm løber oven på Kubernetes. Det vil sige, at dette ikke er en form for system, der står til side, men blot endnu en service, der kører inde i kuben. Du interagerer med den via dens API via en konsolkommando. Dens bekvemmelighed og charme er, at selvom roret går i stykker, eller du fjerner det fra klyngen, forsvinder dine tjenester ikke, da roret stort set kun tjener til at starte systemet. Kubernetes er desuden selv ansvarlig for tjenesternes sundhed og tilstand.

Det indså vi også skabeloner, som vi indtil da skulle gøre på egen hånd gennem introduktionen af ​​jinja i vores konfigurationer, er en af ​​hovedfunktionerne ved helm. Alle de konfigurationer, du opretter til dine systemer, gemmes i helm som skabeloner, lidt ligesom jinja, men bruger faktisk skabelonen af ​​Go-sproget, som helm er skrevet på, ligesom Kubernetes.

Helm tilføjer et par ekstra koncepter til os.

Chart er en beskrivelse af din service. I andre pakkeadministratorer ville det hedde bundle, bundle eller noget lignende. Her hedder det diagram.

Værdier er de variabler du vil bruge til at bygge dine konfigurationer fra skabeloner.

Slip. Hver gang en tjeneste, der implementeres med ror, får en trinvis version af udgivelsen. Helm husker, hvad servicekonfigurationen var for den forrige udgivelse, året før, og så videre. Derfor, hvis du har brug for at rulle tilbage, skal du bare køre kommandoen til tilbagekald af roret og pege den til den tidligere version af udgivelsen. Selvom den tilsvarende konfiguration i dit lager ikke er tilgængelig på tidspunktet for tilbagerulningen, vil helm stadig huske, hvad det var og rulle dit system tilbage til den tilstand, det var i den forrige udgivelse.

I det tilfælde, hvor vi bruger helm, bliver de sædvanlige konfigurationer for Kubernetes også til skabeloner, hvor det er muligt at bruge variabler, funktioner og anvende betingede udsagn. Således kan du indsamle konfigurationen af ​​din tjeneste afhængigt af miljøet.

I praksis besluttede vi os for at gøre tingene lidt anderledes, end vi gjorde med Nomad. Hvis Nomad lagrede både implementeringskonfigurationer og n-variabler, der er nødvendige for at implementere vores service i ét lager, så besluttede vi her at opdele dem i to separate lagre. "Deploy"-lageret gemmer kun de n-variabler, der er nødvendige for implementering, mens "helm"-lageret gemmer konfigurationer eller diagrammer.

Hvad gav det os?

På trods af at vi ikke gemmer nogen virkelig følsomme data i selve konfigurationsfilerne. For eksempel databaseadgangskoder. De er gemt som hemmeligheder i Kubernetes, men ikke desto mindre er der stadig separate ting, som vi ikke ønsker at give adgang til alle i træk. Derfor er adgangen til "deploy"-depotet mere begrænset, og "helm"-depotet indeholder kun en beskrivelse af tjenesten. Af denne grund kan det gives adgang sikkert til en større kreds af mennesker.

Da vi ikke kun har produktion, men også andre miljøer, takket være denne opdeling, kan vi genbruge vores styrekort til at implementere tjenester ikke kun til produktion, men også for eksempel til et QA-miljø. Selv at implementere dem lokalt ved hjælp af Minikube - det er sådan noget for at køre Kubernetes lokalt.

Inde i hvert lager forlod vi opdelingen i separate mapper for hver tjeneste. Det vil sige, inde i hver mappe er der skabeloner relateret til det tilsvarende diagram og beskriver de ressourcer, der skal implementeres for at starte vores system. I "deploy"-depotet efterlod vi kun misundelse. I dette tilfælde brugte vi ikke jinja-skabeloner, fordi ror giver skabeloner ud af æsken - det er en af ​​dens hovedfunktioner.

Vi forlod implementeringsscriptet - deploy.sh, som forenkler og standardiserer lanceringen til implementering ved hjælp af ror. For alle, der ønsker at implementere, ser implementeringsgrænsefladen nøjagtigt det samme ud, som den var i tilfælde af implementering gennem Nomad. Den samme deploy.sh, navnet på din tjeneste, og hvor du vil implementere den. Dette får roret til at køre internt. Til gengæld indsamler han konfigurationer fra skabeloner, erstatter de nødvendige værdifiler i dem, implementerer dem derefter og lancerer dem i Kubernetes.

Fund

Kubernetes-tjenesten ser ud til at være mere kompleks end Nomad.

Det er her, udgående trafik kommer i Ingress. Dette er blot frontcontrolleren, som overtager alle forespørgsler og efterfølgende sender dem til de tjenester, der svarer til forespørgselsdataene. Det bestemmer dem baseret på konfigurationer, der er en del af beskrivelsen af ​​din applikation i ror, og som udviklere indstiller selv. Tjenesten sender på den anden side anmodninger til sine pods, det vil sige specifikke containere, og balancerer indgående trafik mellem alle containere, der hører til denne service. Og selvfølgelig skal vi ikke glemme, at vi ikke skal gå nogen steder fra sikkerhed på netværksniveau. Derfor fungerer segmentering i Kubernetes-klyngen, som er baseret på tagging. Alle tjenester har bestemte tags, hvortil adgangsrettighederne for tjenester til visse eksterne/interne ressourcer i eller uden for klyngen er knyttet.

Da vi skiftede, så vi, at Kubernetes har alle funktionerne i den Nomad, vi har brugt indtil videre, og tilføjer også en masse nye ting. Det kan udvides gennem plugins og faktisk gennem brugerdefinerede ressourcetyper. Det vil sige, at du har mulighed for ikke kun at bruge noget, der følger med Kubernetes ud af boksen, men at skabe din egen ressource og service, der læser din ressource. Dette giver dig flere muligheder for at udvide dit system uden at skulle geninstallere Kubernetes og uden at skulle foretage ændringer.

Et eksempel på sådan brug er Prometheus, som vi kører inde i en Kubernetes-klynge. For at den kan begynde at indsamle metrics fra en bestemt tjeneste, skal vi tilføje en ekstra type ressource til tjenestebeskrivelsen, den såkaldte monitor-tjeneste. Prometheus, på grund af det faktum, at den kan læse, bliver lanceret i Kubernetes, en tilpasset type ressource, automatisk begynder at indsamle metrics fra det nye system. Det er praktisk nok.

Den første implementering, vi foretog i Kubernetes, var i marts 2018. Og i løbet af denne tid har vi aldrig oplevet nogen problemer med ham. Det fungerer ganske stabilt uden væsentlige fejl. Derudover kan vi udvide det yderligere. Til dato har vi nok af de muligheder, som den har, og vi kan virkelig godt lide tempoet i udviklingen af ​​Kubernetes. I øjeblikket er mere end 3000 containere i Kubernetes. Klyngen optager flere noder. Samtidig er den brugbar, stabil og meget kontrollerbar.

Kilde: www.habr.com