I dag planlægger jeg at tale om, hvordan man skriver ansøgninger, og hvad er kravene til, at din ansøgning fungerer godt i Kubernetes. Så der ikke er hovedpine med applikationen, så du ikke behøver at opfinde og bygge nogen "ræser" omkring den - og alt fungerer som Kubernetes selv havde til hensigt.
Dette foredrag er en del af "" Du kan se Aftenskolens åbne teoretiske foredrag . For dem, der foretrækker tekst frem for video, har vi udarbejdet denne artikel.
Mit navn er Pavel Selivanov, i øjeblikket er jeg den førende DevOps-ingeniør hos Mail.ru Cloud Solutions, vi laver skyer, vi laver administrationskubernetes og så videre. Mine opgaver omfatter nu bistand til udvikling, udrulning af disse skyer, udrulning af de applikationer, som vi skriver, og direkte udvikling af de værktøjer, vi leverer til vores brugere.
Jeg har lavet DevOps, tror jeg i de sidste, sandsynligvis, tre år. Men i princippet har jeg gjort, hvad DevOps gør i nok omkring fem år nu. Før det var jeg mest involveret i admin-ting. Jeg begyndte at arbejde med Kubernetes for længe siden – der er nok gået omkring fire år, siden jeg begyndte at arbejde med det.
Generelt startede jeg, da Kubernetes sandsynligvis var version 1.3, og måske 1.2 - da den stadig var i sin vorden. Nu er den ikke længere i sin vorden – og det er åbenlyst, at der er en kæmpe efterspørgsel på markedet efter ingeniører, der gerne vil kunne lave Kubernetes. Og virksomheder har en meget stor efterspørgsel efter sådanne mennesker. Derfor dukkede dette foredrag faktisk op.
Hvis vi taler om planen for, hvad jeg vil tale om, ser den sådan ud, i parentes står der (TL;DR) - "for lang; læs ikke". Min præsentation i dag vil bestå af uendelige lister.
Faktisk kan jeg ikke selv lide sådanne præsentationer, når de laves, men det er sådan et emne, at da jeg forberedte denne præsentation, fandt jeg simpelthen ikke rigtig ud af, hvordan jeg skulle organisere denne information anderledes.
For i det store og hele er denne information "ctrl+c, ctrl+v", fra blandt andet vores Wiki i DevOps-sektionen, hvor vi har skrevet krav til udviklere: "gutte, så vi starter din applikation i Kubernetes, det skulle være sådan."
Derfor viste præsentationen sig at være så stor en liste. Undskyld. Jeg vil forsøge at fortælle så meget som muligt, så det ikke er kedeligt, hvis det er muligt.
Hvad vi skal se på nu:
- disse er for det første logfiler (applikationslogfiler?), hvad skal man gøre med dem i Kubernetes, hvad skal man gøre med dem, hvad skal de være;
- hvad skal man gøre med konfigurationer i Kubernetes, hvad er de bedste og værste måder at konfigurere en applikation til Kubernetes på;
- Lad os tale om, hvad tilgængelighedstjek generelt er, hvordan de skal se ud;
- lad os tale om, hvad en yndefuld nedlukning er;
- lad os tale om ressourcer igen;
- Lad os endnu en gang berøre emnet datalagring;
- og til sidst vil jeg fortælle dig, hvad udtrykket denne mystiske cloud-native applikation er. Cloudnativeness, som et adjektiv for dette udtryk.
Logs
Jeg foreslår at starte med logfilerne - med hvor disse logfiler skal skubbes i Kubernetes. Nu har du startet en applikation i Kubernetes. Ifølge klassikerne skrev tidligere applikationer altid logs et sted i en fil. Dårlige applikationer skrev logfiler til en fil i hjemmemappen for den udvikler, der startede applikationen. Gode applikationer skrev logs til en fil et sted i /var/log.
Derfor havde gode administratorer desuden nogle ting konfigureret i deres infrastrukturer, som disse logfiler kunne rotere - den samme rsyslog, som ser på disse logfiler, og når der sker noget med dem, er der mange af dem, den laver sikkerhedskopier, sætter logs der , sletter gamle filer, mere end en uge, seks måneder og nogle mere. I teorien burde vi have bestemmelser, så blot fordi applikationen skriver logs, løber pladsen på produktionsserverne (kampservere?) ikke tør. Og derfor stoppede hele produktionen ikke på grund af træstammerne.
Når vi flytter til Kubernetes-verdenen og kører det samme der, er den første ting, du kan være opmærksom på, det faktum, at folk, mens de skrev logs i en fil, fortsætter med at skrive dem.
Det viser sig, at hvis vi taler om Kubernetes, er det rigtige sted at skrive logs et sted fra en docker-container simpelthen at skrive dem fra applikationen til den såkaldte Stdout/Stderr, det vil sige operativsystemets standard output-streams, standardfejl output. Dette er den mest korrekte, enkleste og mest logiske måde at lægge logs i princippet i Docker og specifikt i Kubernetis. For hvis din applikation skriver logfiler til Stdout/Stderr, så er det op til Docker og Kubernetes-tilføjelsen at beslutte, hvad de skal gøre med disse logfiler. Docker vil som standard bygge sine specielle filer i JSON-format.
Her opstår spørgsmålet, hvad vil du nu gøre med disse logfiler? Den nemmeste måde er klar, vi har evnen til at gøre kubectl logs og se på disse logfiler af disse "bælg". Men sandsynligvis er dette ikke en særlig god mulighed - noget andet skal gøres med logfilerne.
For nu, lad os tale på samme tid, da vi berørte emnet logs, om sådan noget som logs skal se ud. Det vil sige, at dette ikke gælder direkte for Kubernetes, men når vi begynder at tænke på, hvad vi skal gøre med logs, ville det være godt at tænke over dette også.
Vi har brug for en form for værktøj, på en mindelig måde, der vil tage disse logfiler, som vores docker lægger i sine filer, og sende dem et sted hen. I det store hele lancerer vi som regel en form for agent inde i Kubernetes i form af et DaemonSet – en logopsamler, som blot får at vide, hvor de logfiler, Docker indsamler, befinder sig. Og denne indsamlingsagent tager dem simpelthen, måske endda på en eller anden måde analyserer dem undervejs, beriger dem måske med nogle ekstra metainformationer og sender dem i sidste ende til opbevaring et eller andet sted. Variationer er allerede mulige der. Det mest almindelige er nok Elasticsearch, hvor du kan gemme logfiler, og du nemt kan hente dem derfra. Brug derefter en anmodning, brug for eksempel Kibana til at bygge grafer baseret på dem, opbygge advarsler baseret på dem, og så videre.
Den vigtigste idé, jeg vil gerne gentage det igen, er, at inde i Docker, især inde i Kubernetes, er det en meget dårlig idé at gemme dine logfiler i en fil.
For det første er det svært at få logfilerne ind i beholderen i en fil. Du skal først gå ind i containeren, udføre der, og derefter se på logfilerne. Det næste punkt er, at hvis du har logs i en fil, så har containerne som regel et minimalistisk miljø, og der er ingen hjælpeprogrammer, som normalt er nødvendige for normalt arbejde med logs. Begrav dem, se på dem, åbn dem i en teksteditor. Det næste øjeblik er, når vi har logfiler i en fil inde i en container, hvis denne container slettes, forstår du, vil logfilerne dø sammen med den. Enhver genstart af beholderen betyder derfor, at der ikke er flere logfiler. Igen, dårlig mulighed.
Og det sidste punkt er, at inde i containere har du som regel din ansøgning, og det er det - det er normalt den eneste proces, der kører. Der er overhovedet ingen snak om nogen proces, der ville rotere filer med dine logfiler. Så snart logfilerne begynder at blive skrevet til en fil, betyder det, undskyld mig, at vi begynder at miste produktionsserveren. For det første er de svære at finde, ingen sporer dem, plus ingen kontrollerer dem - følgelig vokser filen uendeligt, indtil pladsen på serveren simpelthen løber tør. Derfor siger jeg igen, at det er en dårlig idé at logge på Docker, især i Kubernetes, til en fil.
Det næste punkt, her vil jeg tale om dette igen - da vi berører emnet logs, ville det være godt at tale om, hvordan logs skal se ud for at gøre det praktisk at arbejde med dem. Som sagt er emnet ikke direkte relateret til Kubernetes, men det relaterer sig meget godt til emnet DevOps. Om emnet udviklingskultur og venskab mellem disse to forskellige afdelinger - Dev og Ops, så alle er komfortable.
Dette betyder, at i dag ideelt set bør logs skrives i JSON-format. Hvis du har en eller anden uforståelig applikation af din egen, som skriver logs i uforståelige formater, fordi du indsætter en form for print eller sådan noget, så er det på tide at google en form for framework, en form for wrapper, der giver dig mulighed for at implementere normal logning; aktivere logningsparametre i JSON der, fordi JSON er et simpelt format, er det nemt at analysere det.
Hvis din JSON ikke virker efter nogle kriterier, ingen ved hvad, så skriv i det mindste logs i et format, der kan parses. Her er det snarere værd at tænke over, at hvis du for eksempel kører en masse containere eller bare processer med nginx, og hver har sine egne logningsindstillinger, så ser det nok ud til, at det vil være meget ubelejligt for dig at analysere dem. For for hver ny nginx-instans skal du skrive din egen parser, fordi de skriver logs forskelligt. Igen var det nok værd at tænke på at sikre sig, at alle disse nginx-forekomster havde den samme logningskonfiguration og skrev alle deres logs absolut ensartet. Det samme gælder for absolut alle applikationer.
Til sidst vil jeg også føje brænde til ilden, at man ideelt set bør undgå logfiler i multi-line format. Her er sagen, hvis du nogensinde har arbejdet med log-samlere, så har du højst sandsynligt set, hvad de lover dig, at de kan arbejde med multi-line logs, vide, hvordan man samler dem, og så videre. Faktisk, efter min mening, kan ikke en eneste indsamler i dag indsamle multi-line logs normalt, fuldt ud og uden fejl. På en menneskelig måde, så det er bekvemt og fejlfrit.
Men stack trace er altid multi-line logs, og hvordan man undgår dem. Spørgsmålet her er, at en log er en registrering af en hændelse, og stactrace er faktisk ikke en log. Hvis vi samler logs og lægger dem et sted i Elasticsearch og derefter tegner grafer fra dem, bygger nogle rapporter om brugeraktivitet på dit websted, så når du får et stakspor, betyder det, at der sker noget uventet, en uhåndteret situation i din applikation. Og det giver mening automatisk at uploade et stakspor et sted ind i et system, der kan spore dem.
Dette er software (den samme Sentry), der er lavet specielt til at arbejde med stack trace. Det kan straks oprette automatiserede opgaver, tildele dem til nogen, advare, når stacttraces forekommer, gruppere disse stacttraces efter én type, og så videre. I princippet giver det ikke meget mening at tale om stactraces, når vi taler om logs, for det er trods alt forskellige ting med forskellige formål.
Konfiguration
Dernæst taler vi om konfiguration i Kubernetes: hvad skal man gøre med det, og hvordan applikationer inde i Kubernetes skal konfigureres. Generelt plejer jeg at sige, at Docker ikke handler om containere. Alle ved, at Docker handler om containere, også dem, der ikke har arbejdet meget med Docker. Jeg gentager, Docker handler ikke om containere.
Docker handler efter min mening om standarder. Og der er standarder for stort set alt: standarder for opbygning af din applikation, standarder for installation af din applikation.
Og denne ting - vi brugte den før, den blev bare særlig populær med fremkomsten af containere - denne ting kaldes ENV (miljø) variabler, det vil sige miljøvariabler, der er i dit operativsystem. Dette er generelt en ideel måde at konfigurere din applikation på, for hvis du har applikationer i JAVA, Python, Go, Perl, Gud forbyde det, og de alle kan læse databaseværten, databasebrugeren, databaseadgangskodevariablerne, så er det ideelt. Du har applikationer på fire forskellige sprog konfigureret i databaseplanen på samme måde. Der er ikke flere forskellige konfigurationer.
Alt kan konfigureres ved hjælp af ENV-variabler. Når vi taler om Kubernetes, er der en fantastisk måde at erklære ENV-variabler lige inde i Deployment. Derfor, hvis vi taler om hemmelige data, så kan vi straks skubbe hemmelige data fra ENV-variabler (adgangskoder til databaser osv.) ind i en hemmelighed, oprette en hemmelig klynge og angive i ENV-beskrivelsen i Deployment, at vi ikke direkte erklærer værdien af denne variabel, og værdien af denne databaseadgangskodevariabel vil blive læst fra hemmeligheden. Dette er standard Kubernetes-adfærd. Og dette er den mest ideelle mulighed for at konfigurere dine applikationer. Bare på kodeniveau gælder dette igen for udviklere. Hvis du er DevOps, kan du spørge: "Gunner, lær venligst din applikation at læse miljøvariabler. Og vi vil alle være glade."
Hvis alle i virksomheden læser de samme navngivne miljøvariabler, så er det fantastisk. For at det ikke sker, at nogle venter på postgres-databasen, andre venter på databasenavnet, andre venter på noget andet, andre venter på en dbn af en slags, så der følgelig er ensartethed.
Problemet kommer, når du har så mange miljøvariabler, at du bare åbner Deployment - og der er fem hundrede linjer med miljøvariabler. I dette tilfælde er du simpelthen vokset ud af miljøvariabler - og du behøver ikke længere at torturere dig selv. I dette tilfælde ville det være fornuftigt at begynde at bruge konfigurationer. Det vil sige, træne din applikation til at bruge konfigurationer.
Det eneste spørgsmål er, at konfigurationer ikke er, hvad du tror. Config.pi er ikke en config, der er praktisk at bruge. Eller nogle config i dit eget format, alternativt begavet - det er heller ikke den config, jeg mener.
Det, jeg taler om, er konfiguration i acceptable formater, det vil sige, at langt den mest populære standard er .yaml-standarden. Det er tydeligt, hvordan man læser det, det er menneskeligt, det er tydeligt, hvordan man læser det fra applikationen.
Derfor kan du udover YAML også f.eks. bruge JSON, parsing er omtrent lige så praktisk som YAML i forhold til at læse applikationskonfigurationen derfra. Det er mærkbart mere ubelejligt for folk at læse. Du kan prøve formatet, a la ini. Det er ret praktisk at læse fra et menneskeligt synspunkt, men det kan være ubelejligt at behandle det automatisk i den forstand, at hvis du nogensinde vil generere dine egne konfigurationer, kan ini-formatet allerede være ubelejligt at generere.
Men under alle omstændigheder, uanset hvilket format du vælger, er pointen, at det fra et Kubernetes synspunkt er meget praktisk. Du kan placere hele din konfiguration i Kubernetes i ConfigMap. Og tag så dette configmap og bed det om at blive monteret inde i din pod i en bestemt mappe, hvor din applikation vil læse konfigurationen fra denne configmap, som om det bare var en fil. Dette er faktisk, hvad der er godt at gøre, når du har mange konfigurationsmuligheder i din applikation. Eller det er bare en form for kompleks struktur, der er rede.
Hvis du har et configmap, så kan du meget vel lære din applikation, for eksempel at automatisk spore ændringer i filen, hvor configmap er monteret, og også automatisk genindlæse din applikation, når konfigurationerne ændres. Dette ville generelt være en ideel mulighed.
Igen, jeg har allerede talt om dette - hemmelig information er ikke i configmap, hemmelig information er ikke i variabler, hemmelig information er ikke i hemmeligheder. Derfra skal du forbinde denne hemmelige information med diplomati. Normalt gemmer vi alle beskrivelser af Kubernetes-objekter, implementeringer, configmaps, tjenester i git. Derfor er det en dårlig idé at sætte adgangskoden til databasen i git, selvom det er din git, som du har internt i virksomheden. Fordi git som minimum husker alt, og det er ikke så nemt at fjerne adgangskoder derfra.
Sundhedstjek
Det næste punkt er denne ting, der hedder Sundhedstjek. Generelt er et sundhedstjek blot at kontrollere, at din applikation virker. Samtidig taler vi oftest om bestemte webapplikationer, for hvilke det derfor fra et sundhedstjeksynspunkt (det er bedre ikke at oversætte her og længere) vil være en speciel URL, som de behandler som en standard, gør de normalt /health.
Når vi tilgår denne URL, siger vores applikation derfor enten "ja, okay, alt er fint med mig, 200" eller "nej, alt er ikke fint med mig, omkring 500." Derfor, hvis vores applikation ikke er http, ikke en webapplikation, taler vi nu om en slags dæmon, vi kan finde ud af, hvordan man laver sundhedstjek. Det vil sige, det er ikke nødvendigt, hvis applikationen ikke er http, så fungerer alt uden et sundhedstjek og det kan ikke lade sig gøre på nogen måde. Du kan periodisk opdatere nogle oplysninger i filen, du kan komme med en speciel kommando til din dæmon, som, daemon status, som vil sige "ja, alt er fint, dæmonen virker, den er i live."
Hvad er det for? Det første og mest oplagte er nok, hvorfor et sundhedstjek er nødvendigt – for at forstå, at applikationen virker. Jeg mener, det er bare dumt, når det er oppe nu, ser det ud til, at det virker, så du kan være sikker på, at det virker. Og det viser sig, at applikationen kører, containeren kører, instansen virker, alt er i orden - og så har brugerne allerede afskåret alle telefonnumre fra teknisk support og sagt "hvad er du..., du faldt i søvn, intet virker."
Et sundhedstjek er netop sådan en måde at se fra brugerens synspunkt, at det virker. En af metoderne. Lad os sige det sådan. Fra Kubernetes synspunkt er dette også en måde at forstå, hvornår applikationen starter, fordi vi forstår, at der er forskel på, hvornår beholderen blev lanceret, oprettet og startet, og hvornår applikationen blev lanceret direkte i denne beholder. For hvis vi tager en gennemsnitlig java-applikation og prøver at starte den i docken, så kan den i fyrre sekunder, eller endda et minut eller endda ti, starte helt fint. I dette tilfælde kan du i det mindste banke på dens porte, den vil ikke svare der, det vil sige, at den endnu ikke er klar til at modtage trafik.
Igen, ved hjælp af et sundhedstjek og ved hjælp af det faktum, at vi vender hertil, kan vi forstå i Kubernetes, at ikke kun beholderen er rejst i applikationen, men selve applikationen er startet, den reagerer allerede på sundhedstjek, hvilket betyder, at vi kan sende trafik dertil.
Det, jeg taler om nu, kaldes Readiness/Liveness-tests i Kubernetes; derfor er vores parathedstests ansvarlige for tilgængeligheden af applikationen i balancering. Det vil sige, at hvis der udføres parathedstest i applikationen, så er alt ok, klienttrafik går til applikationen. Hvis der ikke udføres parathedstest, så deltager applikationen simpelthen ikke, denne særlige instans deltager ikke i balancering, den fjernes fra balancering, klienttrafik flyder ikke. Derfor er Liveness-tests i Kubernetes nødvendige, så hvis applikationen sætter sig fast, kan den genstartes. Hvis liveness-testen ikke virker for en applikation, der er deklareret i Kubernetes, fjernes applikationen ikke bare fra balancering, den genstartes.
Og her er en vigtig pointe, som jeg gerne vil nævne: Fra et praktisk synspunkt bruges parathedstesten som regel oftere og er oftere nødvendig end livenesstesten. Det vil sige, at blot tankeløst erklære både paratheds- og livenesstest, fordi Kubernetes kan gøre det, og lad os bruge alt, hvad det kan, er ikke en særlig god idé. Jeg vil forklare hvorfor. For punkt nummer to i test er, at det ville være en god idé at tjekke den underliggende service i dine helbredstjek. Det betyder, at hvis du har en webapplikation, der udsender nogle oplysninger, som den naturligvis skal tage et sted fra. I en database f.eks. Nå, det gemmer de oplysninger, der kommer ind i denne REST API, i den samme database. Så, hvis dit sundhedstjek svarer ganske enkelt som kontaktet slashhealth, siger applikationen "200, okay, alt er i orden", og samtidig er din applikations database utilgængelig, og sundhedstjek-applikationen siger "200, okay, alt er i orden" ” - Det er et dårligt sundhedstjek. Sådan skal det ikke fungere.
Altså din ansøgning, når der kommer en anmodning til den /health, den svarer ikke bare, "200, ok", den går f.eks. først til databasen, forsøger at oprette forbindelse til den, gør noget meget grundlæggende der, som at vælge en, bare tjekker, at der er en forbindelse i databasen, og du kan forespørge databasen. Hvis alt dette lykkedes, så er svaret "200, ok." Hvis det ikke lykkes, står der, at der er en fejl, databasen er ikke tilgængelig.
Derfor vender jeg i den forbindelse igen tilbage til Readiness/Liveness-testene - hvorfor du højst sandsynligt har brug for en parathedstest, men der er tale om en liveness-test. For hvis du beskriver helbredstjek præcis som jeg lige sagde, så vil det vise sig, at det ikke er tilgængeligt i instansdelenв или со всех instancei en database, f.eks. Da du erklærede en parathedstest, begyndte vores sundhedstjek at mislykkes, og derfor er alle de applikationer, hvorfra databasen ikke er tilgængelig, de simpelthen slukket for balancering og faktisk "hænger" bare i en forsømt tilstand og venter på, at deres databaser arbejde.
Hvis vi har erklæret en liveness-test, så forestil dig, at vores database er gået i stykker, og i din Kubernetes begynder halvdelen af alt at genstarte, fordi liveness-testen mislykkes. Det betyder, at du skal genstarte. Det er slet ikke det du ønsker, jeg havde endda personlig erfaring i praksis. Vi havde en chatapplikation, der var skrevet i JS og ført ind i en Mongo-database. Og problemet var, at det var i begyndelsen af mit arbejde med Kubernetes, vi beskrev beredskabet, livligheden af tests ud fra princippet om, at Kubernetes kan gøre det, så vi vil bruge det. Derfor blev Mongo på et tidspunkt lidt "kedeligt", og prøven begyndte at mislykkes. I overensstemmelse hermed begyndte bælgerne ifølge regntesten at "dræbe".
Som du forstår, når de bliver "dræbt", er dette en chat, det vil sige, at der er mange forbindelser fra klienter, der hænger på den. De er også "dræbt" - nej, ikke klienter, kun forbindelser - ikke alle på samme tid, og på grund af det faktum, at de ikke bliver dræbt på samme tid, nogle tidligere, nogle senere, starter de ikke på samme tid tid. Plus standard tilfældig, vi kan ikke forudsige med millisekunders nøjagtighed starttidspunktet for applikationen hver gang, så de gør det en instans ad gangen. Én infospot rejser sig, føjes til balanceringen, alle klienter kommer dertil, den kan ikke holde til sådan en belastning, fordi den er alene, og groft sagt er der en halv snes af dem, der arbejder der, og den falder. Den næste rejser sig, hele læsset er på ham, han falder også. Nå, disse fald fortsætter bare med at vælte. I sidste ende, hvordan dette blev løst - vi skulle bare strengt stoppe brugertrafik til denne applikation, lade alle forekomster stige og derefter starte al brugertrafik på én gang, så den allerede var fordelt på alle ti forekomster.
Hvis det ikke var for, at denne liveness-test blev annonceret, som ville tvinge det hele til at genstarte, ville applikationen have klaret det fint. Men alt fra balancering er deaktiveret for os, fordi databaserne er utilgængelige, og alle brugere er "faldet fra". Når denne database så bliver tilgængelig, er alt inkluderet i balanceringen, men applikationer skal ikke starte igen, og der er ingen grund til at spilde tid og ressourcer på dette. De er alle her allerede, de er klar til trafik, så trafikken åbner bare, alt er i orden - applikationen er på plads, alt fortsætter med at fungere.
Derfor er paratheds- og livhedstests forskellige, og desuden kan man teoretisk lave forskellige sundhedstjek, f.eks én type radier, én type liv og tjekke forskellige ting. Under parathedstest skal du tjekke dine backends. Og på en liveness-test tjekker man for eksempel ikke ud fra det synspunkt, at liveness-testen generelt kun er en ansøgning, der svarer, hvis den overhovedet er i stand til at svare.
Fordi livlighedstesten i det store og hele er, når vi "sidder fast." En endeløs løkke er startet eller noget andet - og der behandles ikke flere anmodninger. Derfor giver det mening selv at adskille dem – og implementere forskellig logik i dem.
Med hensyn til hvad du skal svare når du skal til en test, når du laver sundhedstjek. Det er bare virkelig en smerte. Dem, der er bekendt med dette, vil sikkert grine - men seriøst, jeg har set tjenester i mit liv, der svarer "200" i XNUMX% af tilfældene. Altså hvem der har succes. Men på samme tid i selve svaret skriver de "sådan og sådan en fejl."
Det vil sige, at svarstatus kommer til dig - alt er vellykket. Men samtidig skal du parse kroppen, for kroppen siger "undskyld, anmodningen endte med en fejl", og dette er bare virkeligheden. Jeg så dette i det virkelige liv.
Og for at nogle mennesker ikke finder det sjovt, og andre finder det meget smertefuldt, er det stadig værd at overholde en simpel regel. I sundhedstjek, og i princippet ved arbejde med webapplikationer.
Hvis alt gik godt, så svar med det to hundrede svar. I princippet vil ethvert to hundrededel svar passe dig. Hvis du læser ragsy meget godt og ved, at nogle svarstatusser er forskellige fra andre, så svar med de relevante: 204, 5, 10, 15, uanset hvad. Hvis det ikke er særlig godt, så bare "to nul nul." Hvis alt går dårligt, og sundhedstjekket ikke reagerer, så svar med en hvilken som helst fem hundrededel. Igen, hvis du forstår, hvordan du skal reagere, hvordan forskellige svarstatusser adskiller sig fra hinanden. Hvis du ikke forstår, så er 502 din mulighed for at svare på sundhedstjek, hvis noget går galt.
Dette er et andet punkt, jeg vil vende tilbage lidt om at tjekke de underliggende tjenester. Hvis du for eksempel begynder at tjekke alle de underliggende tjenester, der står bag din ansøgning – alt i det hele taget. Hvad vi får ud fra et mikroservice-arkitekturs synspunkt, har vi sådan et koncept som "low coupling" - altså når dine tjenester er minimalt afhængige af hinanden. Hvis en af dem fejler, vil alle de andre uden denne funktionalitet simpelthen fortsætte med at fungere. Noget af funktionaliteten virker bare ikke. Følgelig, hvis man binder alle sundhedstjek til hinanden, så ender man med, at én ting falder i infrastrukturen, og fordi den faldt, begynder alle sundhedstjek af alle tjenester også at fejle - og der er mere infrastruktur generelt for hele mikroservicearkitektur nr. Alt blev mørkt der.
Derfor vil jeg gerne gentage dette igen, at du skal tjekke de underliggende tjenester, dem uden hvilke din ansøgning i hundrede procent af tilfældene ikke kan klare sit arbejde. Det vil sige, at det er logisk, at hvis du har en REST API, hvorigennem brugeren gemmer til databasen eller henter fra databasen, så kan du i mangel af en database ikke garantere arbejde med dine brugere.
Men hvis dine brugere, når du tager dem ud af databasen, yderligere bliver beriget med nogle andre metadata, fra en anden backend, som du indtaster inden du sender et svar til frontend - og denne backend ikke er tilgængelig, betyder det, at du giver din svar uden nogen del af metadataene.
Dernæst har vi også et af de smertefulde problemer, når vi starter applikationer.
Faktisk gælder dette ikke kun Kubernetes i det store og hele, det skete bare sådan, at kulturen med en form for masseudvikling og især DevOps begyndte at brede sig omkring samme tid som Kubernetes. Derfor viser det sig i det store og hele, at du med ynde skal lukke din applikation ned uden Kubernetes. Selv før Kubernetes gjorde folk dette, men med fremkomsten af Kubernetes begyndte vi at tale om det i massevis.
Yndefuld nedlukning
Generelt, hvad er Graceful Shutdown, og hvorfor er det nødvendigt? Dette handler om, når din applikation går ned af en eller anden grund, du skal gøre app stop - eller du modtager fx et signal fra styresystemet, din applikation skal forstå det og gøre noget ved det. Det værste scenarie er selvfølgelig, når din ansøgning modtager en SIGTERM og er som "SIGTERM, lad os blive ved, arbejde, gør ingenting." Dette er en direkte dårlig mulighed.
En næsten lige så dårlig mulighed er, når din applikation modtager en SIGTERM og er ligesom "de sagde segterm, det betyder, at vi slutter, jeg har ikke set, jeg kender ikke nogen brugeranmodninger, jeg ved ikke hvilken slags anmodninger, jeg arbejder på lige nu, sagde de SIGTERM, det betyder, at vi slutter " Dette er også en dårlig mulighed.
Hvilken mulighed er god? Det første punkt er at tage højde for afslutningen af operationer. En god mulighed er, at din server stadig tager højde for, hvad den gør, hvis den modtager en SIGTERM.
SIGTERM er en blød nedlukning, den er specialdesignet, den kan opsnappes på kodeniveau, den kan behandles, sig, at nu, vent, vil vi først afslutte det arbejde, vi har, så vil vi afslutte.
Fra et Kubernetes-perspektiv ser det sådan ud. Når vi siger til en pod, der kører i Kubernetes-klyngen, "hold venligst op, gå væk", eller vi genstartes, eller der sker en opdatering, når Kubernetes genskaber pods, sender Kubernetes netop den samme SIGTERM-meddelelse til poden, venter på noget tid, og , dette er den tid, han venter, den er også konfigureret, der er sådan en speciel parameter i eksamensbeviser, og den hedder Graceful ShutdownTimeout. Som du forstår, hedder det ikke for ingenting, og det er ikke for ingenting, vi taler om det nu.
Der kan vi specifikt sige, hvor længe vi skal vente mellem det tidspunkt, vi sender SIGTERM til applikationen, og når vi forstår, at applikationen ser ud til at være gået amok for noget eller sidder "fast" og ikke slutter - og vi skal send det SIGKILL, det vil sige hårdt fuldføre sit arbejde. Det vil sige, at vi derfor har en slags dæmon kørende, den behandler operationer. Vi forstår, at vores operationer, som dæmonen arbejder på, i gennemsnit ikke varer mere end 30 sekunder ad gangen. Når SIGTERM ankommer, forstår vi derfor, at vores dæmon højst kan afslutte 30 sekunder efter SIGTERM. Vi skriver det for eksempel 45 sekunder for en sikkerheds skyld og siger at SIGTERM. Derefter venter vi 45 sekunder. I teorien skulle dæmonen i løbet af denne tid have fuldført sit arbejde og afsluttet sig selv. Men hvis det pludselig ikke kunne, betyder det, at det højst sandsynligt sidder fast - det behandler ikke længere vores anmodninger normalt. Og på 45 sekunder kan du sikkert, faktisk, søm ham fast.
Og her kan der faktisk også tages hensyn til 2 aspekter. For det første skal du forstå, at hvis du modtog en anmodning, begyndte du at arbejde med den på en eller anden måde og gav ikke et svar til brugeren, men du modtog for eksempel SIGTERM. Det giver mening at forfine det og give et svar til brugeren. Dette er punkt nummer et i denne henseende. Punkt nummer to her er, at hvis du skriver din egen applikation, bygger du generelt arkitekturen på en sådan måde, at du modtager en forespørgsel på din applikation, så starter du noget arbejde, begynder at downloade filer et sted fra, downloade en database og andet. - At. Generelt hænger din bruger, din anmodning i en halv time og venter på, at du svarer ham - så skal du højst sandsynligt arbejde på arkitekturen. Det vil sige, bare tag hensyn til selv sund fornuft, at hvis dine operationer er korte, så giver det mening at ignorere SIGTERM og ændre det. Hvis dine operationer er lange, giver det ingen mening at ignorere SIGTERM i dette tilfælde. Det giver mening at redesigne arkitekturen for at undgå så lange operationer. Så brugerne ikke bare hænger og venter. Jeg ved det ikke, lav en form for websocket der, lav reverse hooks, som din server allerede sender til klienten, alt andet, men tving ikke brugeren til at hænge i en halv time og bare vente på en session, indtil du svare ham. For det er uforudsigeligt, hvor det kan gå i stykker.
Når din ansøgning afsluttes, skal du angive en passende udgangskode. Det vil sige, at hvis din ansøgning blev bedt om at lukke, stoppe, og den kunne stoppe sig selv normalt, så behøver du ikke returnere en form for udgangskode 1,5,255 og så videre. Alt, der ikke er nulkode, i det mindste i Linux-systemer, er jeg sikker på, anses for mislykket. Det vil sige, at det vurderes, at din ansøgning i dette tilfælde er endt med en fejl. Derfor, på en mindelig måde, hvis din ansøgning blev afsluttet uden en fejl, siger du 0 på outputtet. Hvis din applikation fejler af en eller anden grund, siger du ikke-0 i outputtet. Og du kan arbejde med disse oplysninger.
Og den sidste mulighed. Det er dårligt, når din bruger sender en anmodning og hænger i en halv time, mens du behandler den. Men generelt vil jeg også gerne sige om, hvad der generelt er det værd fra klientens side. Det er lige meget, om du har en mobilapplikation, frontend osv. Det er nødvendigt at tage højde for, at brugerens session generelt kan afsluttes, alt kan ske. En anmodning kan sendes, for eksempel underbehandlet og intet svar returneret. Din frontend eller din mobilapplikation - enhver frontend generelt, lad os sige det sådan - bør tage højde for dette. Hvis du arbejder med websockets, er dette generelt den værste smerte, jeg nogensinde har haft.
Når udviklerne af nogle almindelige chats ikke ved det, viser det sig, at websocket kan gå i stykker. For dem, når der sker noget ved proxyen, ændrer vi bare konfigurationen, og den genindlæser. Naturligvis er alle langvarige sessioner revet i stykker i dette tilfælde. Udviklere kommer løbende hen til os og siger: "Gunner, hvad laver I, chatten er gået i stykker for alle vores kunder!" Vi siger til dem: "Hvad laver du? Kan dine kunder ikke oprette forbindelse igen? De siger: "Nej, vi har brug for, at sessionerne ikke bliver revet i stykker." Kort sagt, det er faktisk noget sludder. Der skal tages hensyn til klientsiden. Især, som jeg siger, med langlivede sessioner såsom websockets, kan den gå i stykker, og ubemærket af brugeren skal du kunne geninstallere sådanne sessioner. Og så er alt perfekt.
ressourcer
Faktisk vil jeg her bare fortælle dig en lige historie. Igen fra det virkelige liv. Det sygeste jeg nogensinde har hørt om ressourcer.
Ressourcer i dette tilfælde, jeg mener, en slags anmodninger, begrænsninger, som du kan sætte på pods i dine Kubernetes-klynger. Det sjoveste, jeg hørte fra en udvikler... En af mine medudviklere på en tidligere arbejdsplads sagde engang: "Min applikation vil ikke starte i klyngen." Jeg kiggede for at se, at det ikke startede, men enten passede det ikke ind i ressourcerne, eller også havde de sat meget små grænser. Kort sagt kan applikationen ikke starte på grund af ressourcer. Jeg siger: "Det starter ikke på grund af ressourcer, du bestemmer, hvor meget du har brug for, og indstiller en passende værdi." Han siger: "Hvilken slags ressourcer?" Jeg begyndte at forklare ham, at Kubernetes, grænser for anmodninger og bla, bla, bla skal sættes. Manden lyttede i fem minutter, nikkede og sagde: "Jeg kom her for at arbejde som udvikler, jeg vil ikke vide noget om nogen ressourcer. Jeg kom her for at skrive kode, og det er det." Det er trist. Dette er et meget trist koncept fra en udviklers synspunkt. Især i den moderne verden, så at sige, af progressive devops.
Hvorfor er der overhovedet brug for ressourcer? Der er 2 typer ressourcer i Kubernetes. Nogle kaldes anmodninger, andre kaldes grænser. Med ressourcer vil vi forstå, at der stort set altid kun er to grundlæggende begrænsninger. Det vil sige CPU-tidsgrænser og RAM-grænser for en container, der kører i Kubernetes.
En grænse sætter en øvre grænse for, hvordan en ressource kan bruges i din applikation. Det vil sige, at hvis du siger 1 GB RAM i grænserne, så vil din applikation ikke være i stand til at bruge mere end 1 GB RAM. Og hvis han pludselig vil og forsøger at gøre dette, så vil en proces kaldet oom killer, ude af hukommelsen, det vil sige, komme og dræbe din ansøgning - det vil sige, den vil simpelthen genstarte. Programmer vil ikke genstarte baseret på CPU. Med hensyn til CPU, hvis en applikation forsøger at bruge meget, mere end angivet i grænserne, vil CPU'en simpelthen blive strengt valgt. Dette fører ikke til genstart. Dette er grænsen - dette er den øvre grænse.
Og der er en anmodning. En anmodning er, hvordan Kubernetes forstår, hvordan noderne i din Kubernetes-klynge er fyldt med applikationer. Det vil sige, at en anmodning er en slags commit af din ansøgning. Det siger, hvad jeg vil bruge: "Jeg vil gerne have, at du reserverer så meget CPU og så meget hukommelse til mig." Sådan en simpel analogi. Hvad hvis vi har en node, der har, jeg ved det ikke, 8 CPU'er i alt. Og en pod ankommer der, hvis anmodninger siger 1 CPU, hvilket betyder, at noden har 7 CPU'er tilbage. Det vil sige, at så snart 8 pods ankommer til denne node, som hver har 1 CPU i deres anmodninger, er noden, som om fra Kubernetes synspunkt, løbet tør for CPU, og flere pods med anmodninger kan ikke lanceret på denne node. Hvis alle noder løber tør for CPU, vil Kubernetes begynde at sige, at der ikke er nogen egnede noder i klyngen til at køre dine pods, fordi CPU'en er løbet tør.
Hvorfor er der behov for anmodninger, og hvorfor uden anmodninger, tror jeg, der ikke er behov for at starte noget i Kubernetes? Lad os forestille os en hypotetisk situation. Du starter din applikation uden anmodninger, Kubernetes ved ikke hvor meget af det du har, hvilke noder du kan skubbe den til. Nå, han skubber, skubber, skubber ind på noderne. På et tidspunkt vil du begynde at få trafik til din applikation. Og en af applikationerne begynder pludselig at bruge ressourcer op til de grænser, den har ifølge grænserne. Det viser sig, at der er en anden applikation i nærheden, og den har også brug for ressourcer. Noden begynder faktisk at løbe tør for ressourcer, for eksempel OP. Noden begynder faktisk at løbe tør for ressourcer, for eksempel RAM (Random Access Memory). Når en node løber tør for strøm, vil docker først og fremmest stoppe med at reagere, derefter cubelet og derefter OS. De vil simpelthen gå bevidstløse og ALT vil helt sikkert holde op med at virke for dig. Det vil sige, at dette vil føre til, at din node sidder fast, og du bliver nødt til at genstarte den. Kort sagt er situationen ikke særlig god.
Og når du har anmodninger, er grænserne ikke meget forskellige, i hvert fald ikke mange gange mere end grænserne eller anmodningerne, så kan du have sådan en normal, rationel udfyldning af ansøgninger på tværs af knudepunkterne i Kubernetes-klynger. Samtidig er Kubernetes omtrent klar over, hvor meget af det, det lægger hvor, hvor meget af det, der bruges hvor. Det vil sige, at det bare er sådan et øjeblik. Det er vigtigt at forstå det. Og det er vigtigt at kontrollere, at dette er angivet.
Data opbevaring
Vores næste punkt handler om datalagring. Hvad skal man gøre med dem og generelt hvad man skal gøre med vedholdenhed i Kubernetes?
Jeg tror igen, inden for vores , der var et emne om databasen i Kubernetes. Og det forekommer mig, at jeg endda nogenlunde ved, hvad dine kolleger fortalte dig, da de blev spurgt: "Er det muligt at køre en database i Kubernetes?" Af en eller anden grund forekommer det mig, at dine kolleger burde have fortalt dig, at hvis du stiller spørgsmålet, om det er muligt at køre en database i Kubernetes, så er det umuligt.
Logikken her er enkel. For en sikkerheds skyld, vil jeg forklare endnu en gang, hvis du er en rigtig sej fyr, der kan bygge et ret fejltolerant system af distribueret netværkslagring, så forstå, hvordan man passer en database ind i denne sag, hvordan cloud native i containere skal fungere i en database generelt. Mest sandsynligt har du ingen spørgsmål om, hvordan du kører det. Hvis du har sådan et spørgsmål, og du vil sikre dig, at det hele folder sig ud og står lige til døden i produktionen og aldrig falder, så sker det ikke. Du vil med garanti skyde dig selv i foden med denne tilgang. Så det er bedre at lade være.
Hvad skal vi gøre med de data, som vores applikation gerne vil gemme, nogle billeder, som brugerne uploader, nogle ting, som vores applikation genererer under driften, for eksempel ved opstart? Hvad skal man gøre med dem i Kubernetes?
Generelt, ideelt set, ja, selvfølgelig er Kubernetes meget godt designet og blev generelt oprindeligt udtænkt til statsløse applikationer. Det vil sige for de applikationer, der slet ikke gemmer information. Dette er ideelt.
Men selvfølgelig eksisterer den ideelle mulighed ikke altid. Og hvad så? Det første og enkleste punkt er at tage en slags S3, bare ikke en hjemmelavet, som også er uklart, hvordan den virker, men fra en eller anden udbyder. En god, normal udbyder - og lær din applikation at bruge S3. Det vil sige, når din bruger vil uploade en fil, skal du sige "her, venligst upload den til S3." Når han vil modtage det, så sig: "Her er et link til S3 tilbage og tag det herfra." Dette er ideelt.
Hvis denne ideelle mulighed pludselig af en eller anden grund ikke er egnet, du har et program, du ikke har skrevet, du ikke udvikler, eller det er en form for frygtelig arv, den kan ikke bruge S3-protokollen, men skal arbejde med lokale mapper i lokale mapper. Tag noget mere eller mindre simpelt, implementer Kubernetes. Det vil sige, at det umiddelbart er en dårlig idé at indhegne Ceph for nogle minimale opgaver, synes jeg. Fordi Ceph selvfølgelig er god og moderigtig. Men hvis du ikke rigtig forstår, hvad du laver, så når du først har sat noget på Ceph, kan du meget nemt og simpelthen aldrig få det ud derfra igen. For som bekendt gemmer Ceph data i sin klynge i binær form og ikke i form af simple filer. Derfor, hvis Ceph-klyngen pludselig bryder sammen, så er der en fuldstændig og stor sandsynlighed for, at du aldrig får dine data derfra igen.
Vi vil have et kursus om Ceph, det kan du .
Derfor er det bedre at gøre noget simpelt som en NFS-server. Kubernetes kan arbejde med dem, du kan montere en mappe under en NFS-server - din applikation er ligesom en lokal mappe. Samtidig skal du naturligvis forstå, at du igen skal gøre noget med din NFS, du skal forstå, at den nogle gange kan blive utilgængelig og overveje spørgsmålet om, hvad du vil gøre i dette tilfælde. Måske skal det sikkerhedskopieres et sted på en separat maskine.
Det næste punkt, jeg talte om, er, hvad du skal gøre, hvis din applikation genererer nogle filer under drift. For eksempel, når den starter, genererer den en statisk fil, som er baseret på nogle oplysninger, som applikationen kun modtager på tidspunktet for lanceringen. Sikke et øjeblik. Hvis der ikke er mange sådanne data, behøver du slet ikke at bekymre dig, bare installer denne applikation for dig selv og arbejde. Det eneste spørgsmål her er hvad, se. Meget ofte, alle mulige legacy-systemer, såsom WordPress og så videre, især med modificerede en slags smarte plugins, kloge PHP-udviklere, ved de ofte, hvordan de skal lave det, så de genererer en form for fil til sig selv. Følgelig genererer man én fil, den anden genererer en anden fil. De er forskellige. Balancering sker i kundernes Kubernetes-klynge ganske enkelt ved en tilfældighed. Derfor viser det sig, at de f.eks. ikke ved, hvordan de skal arbejde sammen. Den ene giver én information, den anden giver brugeren en anden information. Dette er noget, du bør undgå. Det vil sige, at i Kubernetes er alt, hvad du starter, garanteret at kunne fungere i flere tilfælde. Fordi Kubernetes er en bevægende ting. Derfor kan han flytte hvad som helst, når han vil, uden at spørge nogen overhovedet. Derfor skal du regne med dette. Alt lanceret i én instans vil før eller siden mislykkes. Jo flere reservationer du har, jo bedre. Men igen, siger jeg, hvis du har et par sådanne filer, så kan du lægge dem lige under dig, de vejer en lille mængde. Hvis der er lidt flere af dem, bør du nok ikke skubbe dem ind i beholderen.
Jeg vil anbefale, at der er sådan en vidunderlig ting i Kubernetes, du kan bruge volumen. Især er der et volumen af typen tomme dir. Det vil sige, det er bare, at Kubernetes automatisk opretter en mappe i sine servicemapper på den server, hvor du startede. Og han vil give dig det, så du kan bruge det. Der er kun én vigtig pointe. Det vil sige, at dine data ikke bliver gemt inde i containeren, men derimod på den vært, du kører på. Desuden kan Kubernetes kontrollere sådanne tomme dirs under normal konfiguration og er i stand til at kontrollere deres maksimale størrelse og ikke tillade, at den overskrides. Det eneste punkt er, at det, du har skrevet i tom katalog, ikke går tabt under genstart af pod. Det vil sige, at hvis din pod falder ved en fejl og rejser sig igen, vil informationen i den tomme dir ikke gå nogen vegne. Han kan bruge det igen ved en ny start - og det er godt. Hvis din pod forlader et sted, så forlader han naturligvis uden data. Det vil sige, at så snart poden fra noden, hvor den blev lanceret med tom dir, forsvinder, slettes tom dir.
Hvad er ellers godt ved tomme dir? For eksempel kan den bruges som en cache. Lad os forestille os, at vores applikation genererer noget på farten, giver det til brugerne og gør det i lang tid. Derfor genererer og giver applikationen den for eksempel til brugerne, og gemmer den samtidig et sted, så næste gang brugeren kommer efter det samme, vil det være hurtigere at give den straks genereret. Tom mappe kan bedes Kubernetes om at oprette i hukommelsen. Og dermed kan dine caches generelt arbejde lynhurtigt – hvad angår diskadgangshastighed. Det vil sige, at du har en tom dir i hukommelsen, i OS er den gemt i hukommelsen, men for dig, for brugeren inde i poden, ligner det bare en lokal mappe. Du behøver ikke appen for specifikt at undervise i nogen magi. Du tager bare og lægger din fil direkte i en mappe, men faktisk i hukommelsen på operativsystemet. Dette er også en meget praktisk funktion i forhold til Kubernetes.
Hvilke problemer har Minio? Hovedproblemet med Minio er, at for at denne ting skal fungere, skal den køre et sted, og der skal være en form for filsystem, det vil sige lager. Og her støder vi på de samme problemer, som Ceph har. Det vil sige, at Minio skal gemme sine filer et sted. Det er simpelthen en HTTP-grænseflade til dine filer. Desuden er funktionaliteten klart dårligere end Amazons S3. Tidligere var det ikke i stand til at autorisere brugeren korrekt. Nu kan den, så vidt jeg ved, allerede skabe spande med forskellige autorisationer, men igen forekommer det mig, at hovedproblemet så at sige er det underliggende lagersystem som minimum.
Hvordan påvirker Empty dir i hukommelsen grænserne? Påvirker ikke grænser på nogen måde. Det ligger i værtens hukommelse og ikke i din containers hukommelse. Det vil sige, at din beholder ikke ser den tomme mappe i hukommelsen som en del af dens besatte hukommelse. Værten ser dette. Derfor, ja, fra kubernetes synspunkt, når du begynder at bruge dette, ville det være godt at forstå, at du afsætter en del af din hukommelse til tomme dir. Og derfor forstå, at hukommelsen kan løbe tør ikke kun på grund af applikationer, men også fordi nogen skriver til disse tomme dirs.
Cloudnativeness
Og det sidste underemne er, hvad Cloudnative er. Hvorfor er det nødvendigt? Cloudnativeness og så videre.
Det vil sige de applikationer, der er i stand og skrevet til at fungere i en moderne cloud-infrastruktur. Men faktisk har Cloudnative et andet sådant aspekt. At dette ikke kun er en applikation, der tager højde for alle kravene til en moderne cloud-infrastruktur, men også ved, hvordan man arbejder med denne moderne cloud-infrastruktur, udnyt fordele og ulemper ved, at det fungerer i disse skyer. Gå ikke bare overbord og arbejd i skyerne, men udnyt fordelene ved at arbejde i skyen.
Lad os bare tage Kubernetes som et eksempel. Din applikation kører i Kubernetes. Din applikation kan altid, eller rettere sagt administratorerne for din applikation, altid oprette en servicekonto. Det vil sige en konto til autorisation i selve Kubernetes på sin server. Tilføj nogle rettigheder, som vi har brug for der. Og du kan få adgang til Kubernetes fra din applikation. Hvad kan du gøre på denne måde? For eksempel, fra applikationen, modtag data om, hvor dine andre applikationer, andre lignende instanser er placeret, og sammen på en eller anden måde klynge oven på Kubernetes, hvis der er et sådant behov.
Igen havde vi bogstaveligt talt en sag for nylig. Vi har én controller, der overvåger køen. Og når der dukker nogle nye opgaver op i denne kø, går den til Kubernetes – og inde i Kubernetes opretter den en ny pod. Giver denne pod en ny opgave og inden for rammerne af denne pod udfører poden opgaven, sender et svar til controlleren selv, og controlleren gør så noget med denne information. For eksempel tilføjer det en database. Det vil sige, igen, dette er et plus ved, at vores applikation kører i Kubernetes. Vi kan bruge selve den indbyggede Kubernetes-funktionalitet for på en eller anden måde at udvide og gøre funktionaliteten af vores applikation mere bekvem. Det vil sige, skjul ikke en form for magi om, hvordan man starter en applikation, hvordan man starter en arbejder. I Kubernetes sender du blot en anmodning i appen, hvis applikationen er skrevet i Python.
Det samme gælder, hvis vi går ud over Kubernetes. Vi har vores Kubernetes kørende et sted - det er godt, hvis det er i en form for sky. Igen, vi kan bruge, og bør endda, tror jeg, bruge mulighederne i selve skyen, hvor vi kører. Fra de elementære ting, som skyen giver os. Balancering, det vil sige, at vi kan skabe cloud balancere og bruge dem. Dette er en direkte fordel af det, vi kan bruge. Fordi skybalancering for det første simpelthen dumt fjerner ansvaret fra os for, hvordan det fungerer, hvordan det er konfigureret. Plus det er meget praktisk, fordi almindelige Kubernetes kan integreres med skyer.
Det samme gælder for skalering. Almindelige Kubernetes kan integreres med cloud-udbydere. Ved hvordan man forstår, at hvis klyngen løber tør for noder, det vil sige, at nodepladsen er løbet tør, så skal du tilføje - Kubernetes vil selv tilføje nye noder til din klynge og begynde at starte pods på dem. Det vil sige, at når din last kommer, begynder antallet af ildsteder at stige. Når noderne i klyngen løber tør for disse pods, lancerer Kubernetes nye noder, og følgelig kan antallet af pods stadig stige. Og det er meget praktisk. Dette er en direkte mulighed for at skalere klyngen i farten. Ikke særlig hurtigt, i den forstand at det ikke er et sekund, det er mere som et minut for at tilføje nye noder.
Men fra min erfaring er det igen det fedeste, jeg nogensinde har set. Når Cloudnative-klyngen skaleres baseret på tidspunktet på dagen. Det var en backend-tjeneste, som blev brugt af folk i backoffice. Det vil sige, at de kommer på arbejde kl. 9, begynder at logge ind på systemet, og derfor begynder Cloudnative-klyngen, hvor det hele kører, at svulme op og lancerer nye pods, så alle, der kommer på arbejde, kan arbejde med applikationen. Når de forlader arbejdet kl. 8 eller kl. 6, bemærker Kubernetes-klyngerne, at ingen længere bruger applikationen og begynder at skrumpe ind. Besparelser på op til 30 procent er garanteret. Det fungerede i Amazon på det tidspunkt; på det tidspunkt var der ingen i Rusland, der kunne gøre det så godt.
Jeg vil sige dig lige, besparelserne er 30 procent, simpelthen fordi vi bruger Kubernetes og udnytter skyens muligheder. Nu kan dette gøres i Rusland. Jeg vil selvfølgelig ikke reklamere for nogen, men lad os bare sige, at der er udbydere, der kan gøre dette, give det lige ud af boksen med en knap.
Der er et sidste punkt, som jeg også gerne vil henlede Deres opmærksomhed på. For at din applikation, din infrastruktur kan være Cloudnative, giver det mening endelig at begynde at tilpasse tilgangen kaldet Infrastructure as a Code. Det vil sige, at din applikation, eller rettere sagt din infrastruktur, er nødvendig på nøjagtig samme måde som kode Beskriv din ansøgning, din forretningslogik i form af kode. Og arbejd med den som kode, det vil sige test den, rul den ud, gem den i git, anvend CICD på den.
Og det er netop det, der giver dig mulighed for, for det første, altid at have kontrol over din infrastruktur, for altid at forstå, hvilken tilstand den er i. For det andet skal du undgå manuelle handlinger, der forårsager fejl. For det tredje, undgå blot det, der kaldes omsætning, når du konstant skal udføre de samme manuelle opgaver. For det fjerde giver det dig mulighed for at komme dig meget hurtigere i tilfælde af en fejl. I Rusland, hver gang jeg taler om dette, er der altid et stort antal mennesker, der siger: "Ja, det er klart, men du har tilgange, kort sagt, der er ingen grund til at rette noget." Men det er sandt. Hvis noget er brudt i din infrastruktur, så er det fra synspunktet af Cloudnative-tilgangen og fra synspunktet om infrastruktur som en kode, i stedet for at rette det, gå til serveren, finde ud af, hvad der er gået i stykker og rette det, lettere for at slette serveren og oprette den igen. Og jeg vil få alt dette genoprettet.
Alle disse spørgsmål diskuteres mere detaljeret på . Ved at følge linket kan du sætte dig ind i programmet og betingelserne. Det praktiske er, at du kan mestre Kubernetes ved at studere hjemmefra eller arbejde 1-2 timer om dagen.
Kilde: www.habr.com