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 applikation afsluttes, skal du returnere en form for rimelig exit-kode. Det vil sige, hvis din applikation blev bedt om at lukke, stoppe, og den var i stand til at stoppe normalt af sig selv, sÄ er der ingen grund til at returnere en form for exit-kode som 1, 5, 255 osv. Alt, der ikke er nul, i hvert fald ikke i Linux I systemer er jeg helt sikker pÄ, at det betragtes som mislykket. Det vil sige, at din applikation anses for at vÊre afsluttet med en fejl. Hvis din applikation derfor afsluttedes uden en fejl, ville du rapportere en exit pÄ 0. Hvis din applikation afsluttedes med en fejl af en eller anden grund, ville du ikke rapportere en exit pÄ 0. 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
