Krav för att utveckla en applikation i Kubernetes

Idag tänker jag prata om hur man skriver ansökningar och vilka krav som krävs för att din ansökan ska fungera bra i Kubernetes. Så att det inte finns någon huvudvärk med applikationen, så att du inte behöver uppfinna och bygga några "spår" runt den - och allt fungerar som Kubernetes själv tänkt.

Denna föreläsning är en del av "Slurm Night School på Kubernetes" Du kan se Kvällsskolans öppna teoretiska föreläsningar på Youtube, grupperade i en spellista. För dem som föredrar text snarare än video har vi förberett den här artikeln.

Jag heter Pavel Selivanov, för närvarande är jag den ledande DevOps-ingenjören på Mail.ru Cloud Solutions, vi gör moln, vi gör management-kubernetes och så vidare. Mina arbetsuppgifter inkluderar nu assistans vid utveckling, utrullning av dessa moln, utrullning av de applikationer som vi skriver och direktutveckling av de verktyg som vi tillhandahåller våra användare.

Jag har gjort DevOps, tror jag de senaste tre åren. Men i princip har jag gjort vad DevOps gör i ungefär fem år nu. Innan dess var jag mest involverad i admin-grejer. Jag började jobba med Kubernetes för länge sedan - det har säkert gått ungefär fyra år sedan jag började jobba med det.

I allmänhet började jag när Kubernetes var version 1.3, förmodligen, och kanske 1.2 - när det fortfarande var i sin linda. Nu är det inte längre i sin linda – och det är uppenbart att det finns en enorm efterfrågan på marknaden på ingenjörer som skulle vilja kunna göra Kubernetes. Och företag har en mycket stor efterfrågan på sådana människor. Därför dök faktiskt denna föreläsning upp.

Om vi ​​talar enligt planen för vad jag ska prata om, ser det ut så här, inom parentes står det (TL;DR) - "för länge; läs inte". Min presentation idag kommer att bestå av oändliga listor.

Faktum är att jag själv inte gillar sådana presentationer när de görs, men det här är ett sådant ämne att när jag förberedde den här presentationen kom jag helt enkelt inte på hur jag skulle organisera denna information annorlunda.

För i stort sett är denna information "ctrl+c, ctrl+v", från bland annat vår Wiki i DevOps-sektionen, där vi har skrivna krav på utvecklare: "killar, så att vi lanserar din applikation i Kubernetes, det borde vara så här."

Det är därför presentationen visade sig vara en så stor lista. Förlåt. Jag ska försöka berätta så mycket som möjligt så att det inte blir tråkigt om möjligt.

Vad vi ska titta på nu:

• dessa är, för det första, loggar (applikationsloggar?), vad ska man göra med dem i Kubernetes, vad man ska göra med dem, vad de ska vara;
• vad man ska göra med konfigurationer i Kubernetes, vilka är de bästa och sämsta sätten att konfigurera en applikation för Kubernetes;
• Låt oss prata om vad tillgänglighetskontroller är i allmänhet, hur de ska se ut;
• låt oss prata om vad en graciös avstängning är;
• låt oss prata om resurser igen;
• Låt oss återigen beröra ämnet datalagring;
• och i slutet kommer jag att berätta vad termen för denna mystiska molnbaserade applikation är. Cloudnativeness, som ett adjektiv för denna term.

Loggar

Jag föreslår att man börjar med loggarna - med var dessa stockar måste skjutas in i Kubernetes. Nu har du startat en applikation i Kubernetes. Enligt klassikerna skrev tidigare applikationer alltid loggar någonstans i en fil. Dåliga applikationer skrev loggar till en fil i hemkatalogen för utvecklaren som startade applikationen. Bra applikationer skrev loggar till en fil någonstans i /var/log.

Följaktligen hade bra administratörer dessutom vissa saker konfigurerade i sina infrastrukturer som dessa loggar kunde rotera - samma rsyslog, som tittar på dessa loggar och när något händer med dem, det finns många av dem, den skapar säkerhetskopior, lägger loggar där , raderar gamla filer, mer än en vecka, sex månader och några till. I teorin borde vi ha bestämmelser så att utrymmet på produktionsservrarna (stridsservrarna?) inte tar slut bara för att applikationen skriver loggar. Och följaktligen stannade inte hela produktionen på grund av stockarna.

När vi flyttar till Kubernetes-världen och kör samma sak där, är det första du kan uppmärksamma det faktum att människor, när de skrev loggar i en fil, fortsätter att skriva dem.

Det visar sig att om vi pratar om Kubernetes, är rätt ställe att skriva loggar någonstans från en dockningsbehållare helt enkelt att skriva dem från applikationen till den så kallade Stdout/Stderr, det vill säga operativsystemets standardutgångsströmmar, standardfel utgång . Detta är det mest korrekta, enklaste och mest logiska sättet att lägga loggar i princip i Docker och specifikt i Kubernetis. För om din applikation skriver loggar till Stdout/Stderr, är det upp till Docker och Kubernetes-tillägget att bestämma vad de ska göra med dessa loggar. Docker kommer som standard att bygga sina specialfiler i JSON-format.

Här uppstår frågan, vad ska du göra härnäst med dessa loggar? Det enklaste sättet är tydligt, vi har förmågan att göra kubectl logs och titta på dessa loggar över dessa "pods". Men förmodligen är detta inte ett särskilt bra alternativ - något annat måste göras med loggarna.

För nu, låt oss prata samtidigt, eftersom vi berörde ämnet loggar, om en sådan sak som loggar ska se ut. Det vill säga, detta gäller inte direkt för Kubernetes, men när vi börjar fundera på vad vi ska göra med loggar skulle det vara bra att tänka på detta också.

Vi behöver något slags verktyg, på ett vänskapligt sätt, som tar dessa loggar som vår hamnarbetare lägger in i sina filer och skickar dem någonstans. I det stora hela brukar vi lansera någon form av agent inne i Kubernetes i form av ett DaemonSet – en loggsamlare, som helt enkelt får veta var loggarna som Docker samlar in finns. Och den här insamlingsagenten tar dem helt enkelt, kanske till och med på något sätt analyserar dem på vägen, kanske berikar dem med lite extra metainformation och, i slutändan, skickar dem för lagring någonstans. Variationer är redan möjliga där. Det vanligaste är nog Elasticsearch, där du kan lagra loggar och du kan bekvämt hämta dem därifrån. Sedan, med hjälp av en begäran, med hjälp av Kibana, till exempel, bygga grafer baserade på dem, skapa varningar baserade på dem, och så vidare.

Den viktigaste idén, jag vill upprepa det igen, är att inuti Docker, i synnerhet inuti Kubernetes, är det en mycket dålig idé att lagra dina loggar i en fil.

För det första är det svårt att få in stockarna i behållaren i en fil. Du måste först gå in i behållaren, köra där och sedan titta på loggarna. Nästa punkt är att om du har loggar i en fil så har behållarna oftast en minimalistisk miljö och det finns inga verktyg som vanligtvis behövs för normalt arbete med loggar. Begrav dem, titta på dem, öppna dem i en textredigerare. Nästa ögonblick är när vi har loggar i en fil inuti en behållare, om den här behållaren raderas, förstår du, kommer loggarna att dö tillsammans med den. Följaktligen innebär varje omstart av behållaren att det inte finns fler loggar. Återigen, dåligt alternativ.

Och den sista punkten är att inne i containrar har du vanligtvis din ansökan och det är allt - det är vanligtvis den enda processen som körs. Det talas inte alls om någon process som skulle rotera filer med dina loggar. Så fort loggarna börjar skrivas till en fil betyder det att vi, ursäkta, kommer att börja förlora produktionsservern. För det första är de svåra att hitta, ingen spårar dem, plus att ingen kontrollerar dem - följaktligen växer filen oändligt tills utrymmet på servern helt enkelt tar slut. Därför säger jag igen att det är en dålig idé att logga in i Docker, särskilt i Kubernetes, till en fil.

Nästa punkt, här vill jag prata om detta igen - eftersom vi berör ämnet loggar skulle det vara bra att prata om hur stockar ska se ut för att göra det bekvämt att arbeta med dem. Ämnet är som sagt inte direkt relaterat till Kubernetes, men det relaterar väldigt bra till ämnet DevOps. På ämnet utvecklingskultur och vänskap mellan dessa två olika avdelningar - Dev och Ops, så att alla är bekväma.

Detta innebär att loggar helst bör skrivas i JSON-format idag. Om du har någon egen obegriplig applikation, som skriver loggar i obegripliga format för att du sätter in någon form av tryck eller liknande, då är det dags att googla på någon form av ramverk, någon form av omslag som låter dig implementera normal loggning; aktivera loggningsparametrar i JSON där, eftersom JSON är ett enkelt format, är det enkelt att analysera det.

Om din JSON inte fungerar enligt vissa kriterier, ingen vet vad, så skriv åtminstone loggar i ett format som går att tolka. Här är det snarare värt att tänka på det faktum att om du till exempel kör ett gäng containrar eller bara processer med nginx, och var och en har sina egna loggningsinställningar, så verkar det förmodligen vara väldigt obekvämt för dig att analysera dem. För för varje ny nginx-instans måste du skriva din egen parser, eftersom de skriver loggar på olika sätt. Återigen var det förmodligen värt att tänka på att se till att alla dessa nginx-instanser hade samma loggningskonfiguration och skrev alla sina loggar absolut enhetligt. Detsamma gäller absolut alla applikationer.

I slutändan vill jag också lägga bränsle på elden för att helst bör man undvika loggar i flerradsformat. Här är grejen, om du någonsin har arbetat med stockinsamlare, så har du troligen sett vad de lovar dig, att de kan arbeta med flerradiga loggar, vet hur man samlar in dem, och så vidare. I själva verket, enligt min mening, kan inte en enda samlare idag samla flerradiga loggar normalt, fullständigt och utan fel. På ett mänskligt sätt, så att det är bekvämt och felfritt.

Men stack trace är alltid flerradiga loggar och hur man undviker dem. Frågan här är att en logg är en registrering av en händelse, och stactrace är egentligen inte en logg. Om vi ​​samlar in loggar och lägger dem någonstans i Elasticsearch och sedan ritar grafer från dem, bygger några rapporter om användaraktivitet på din sida, så när du får en stackspårning betyder det att något oväntat händer, en ohanterad situation i din applikation. Och det är vettigt att automatiskt ladda upp en stackspårning någonstans till ett system som kan spåra dem.

Detta är programvara (samma Sentry) som är gjord speciellt för att fungera med stack trace. Det kan omedelbart skapa automatiserade uppgifter, tilldela dem till någon, varna när stacttraces inträffar, gruppera dessa stacttraces efter en typ, och så vidare. I princip är det inte mycket meningsfullt att prata om stactraces när vi pratar om stockar, eftersom det trots allt är olika saker med olika syften.

konfiguration

Därefter pratar vi om konfiguration i Kubernetes: vad man ska göra med den och hur applikationer inuti Kubernetes ska konfigureras. Generellt brukar jag säga att Docker inte handlar om containrar. Alla vet att Docker handlar om containrar, även de som inte har arbetat mycket med Docker. Jag upprepar, Docker handlar inte om containrar.

Docker, enligt min mening, handlar om standarder. Och det finns standarder för praktiskt taget allt: standarder för att bygga din applikation, standarder för att installera din applikation.

Och den här saken - vi använde den förut, den blev bara särskilt populär med tillkomsten av behållare - den här saken kallas ENV (miljö) variabler, det vill säga miljövariabler som finns i ditt operativsystem. Detta är generellt sett ett idealiskt sätt att konfigurera din applikation, för om du har applikationer i JAVA, Python, Go, Perl, Gud förbjude, och de alla kan läsa databasvärden, databasanvändaren, databasens lösenordsvariabler, så är det idealiskt. Du har applikationer på fyra olika språk konfigurerade i databasplanen på samma sätt. Det finns inga fler olika konfigurationer.

Allt kan konfigureras med ENV-variabler. När vi pratar om Kubernetes finns det ett utmärkt sätt att deklarera ENV-variabler direkt i Deployment. Följaktligen, om vi talar om hemliga data, så kan vi omedelbart skjuta hemlig data från ENV-variabler (lösenord till databaser, etc.) till en hemlighet, skapa ett hemligt kluster och ange i ENV-beskrivningen i Deployment att vi inte direkt deklarerar värdet på denna variabel och värdet på denna databaslösenordsvariabel kommer att läsas från hemligheten. Detta är Kubernetes standardbeteende. Och detta är det mest idealiska alternativet för att konfigurera dina applikationer. Bara på kodnivå, återigen gäller detta utvecklare. Om du är DevOps kan du fråga: "Killar, snälla lär din applikation att läsa miljövariabler. Och vi kommer alla att vara glada."

Om alla i företaget läser samma namngivna miljövariabler, så är det bra. Så att det inte händer att vissa väntar på postgres-databasen, andra väntar på databasnamnet, andra väntar på något annat, andra väntar på en dbn av något slag, så att det följaktligen blir enhetlighet.

Problemet kommer när du har så många miljövariabler att du bara öppnar Deployment - och det finns femhundra rader med miljövariabler. I det här fallet har du helt enkelt vuxit ur miljövariabler - och du behöver inte längre tortera dig själv. I det här fallet skulle det vara vettigt att börja använda konfigurationer. Det vill säga träna din applikation att använda konfigurationer.

Frågan är bara att konfigurationer inte är vad du tror. Config.pi är inte en konfiguration som är bekväm att använda. Eller någon config i ditt eget format, alternativt begåvad - det är inte heller den config jag menar.

Det jag pratar om är konfiguration i acceptabla format, det vill säga den överlägset mest populära standarden är .yaml-standarden. Det är tydligt hur man läser det, det är läsbart för människor, det är tydligt hur man läser det från applikationen.

Följaktligen kan du förutom YAML även till exempel använda JSON, parsning är ungefär lika bekvämt som YAML när det gäller att läsa applikationskonfigurationen därifrån. Det är märkbart mer obekvämt för folk att läsa. Du kan prova formatet, a la ini. Det är ganska bekvämt att läsa, ur mänsklig synvinkel, men det kan vara obekvämt att bearbeta det automatiskt, i den meningen att om du någonsin vill skapa dina egna konfigurationer, kan ini-formatet redan vara obekvämt att generera.

Men i vilket fall som helst, vilket format du än väljer, är poängen att det ur Kubernetes synvinkel är väldigt bekvämt. Du kan placera hela din konfiguration i Kubernetes, i ConfigMap. Och ta sedan den här configmap och be den att monteras inuti din pod i någon specifik katalog, där din applikation kommer att läsa konfigurationen från denna configmap som om det bara vore en fil. Detta är faktiskt vad som är bra att göra när du har många konfigurationsalternativ i din applikation. Eller så är det bara någon form av komplex struktur, det finns häckning.

Om du har en configmap kan du mycket väl lära din applikation att till exempel automatiskt spåra ändringar i filen där configmap är monterad, och även automatiskt ladda om din applikation när konfigurationerna ändras. Detta skulle i allmänhet vara ett idealiskt alternativ.

Återigen, jag har redan pratat om detta - hemlig information finns inte i configmap, hemlig information finns inte i variabler, hemlig information finns inte i hemligheter. Därifrån kopplar du denna hemliga information till diplomati. Vanligtvis lagrar vi alla beskrivningar av Kubernetes-objekt, distributioner, configmaps, tjänster i git. Att lägga lösenordet till databasen i git, även om det är din git, som du har internt i företaget, är därför en dålig idé. För git kommer åtminstone ihåg allt och att helt enkelt ta bort lösenord därifrån är inte så lätt.

Hälsokontroll

Nästa punkt är det här som kallas Health check. I allmänhet är en hälsokontroll helt enkelt att kontrollera att din applikation fungerar. Samtidigt pratar vi oftast om vissa webbapplikationer, för vilka det, ur hälsokontrollsynpunkt (det är bättre att inte översätta här och längre), kommer att vara en speciell URL, som de bearbetar som en standard brukar de göra /health.

När vi kommer åt den här webbadressen säger vår applikation antingen "ja, okej, allt är bra med mig, 200" eller "nej, allt är inte bra med mig, ungefär 500." Följaktligen, om vår applikation inte är http, inte en webbapplikation, talar vi nu om någon slags demon, vi kan ta reda på hur man gör hälsokontroller. Dvs det är inte nödvändigt, om applikationen inte är http så fungerar allt utan hälsokontroll och detta kan inte göras på något sätt. Du kan med jämna mellanrum uppdatera viss information i filen, du kan komma med något speciellt kommando för din demon, som, daemon status, som kommer att säga "ja, allt är bra, demonen fungerar, den lever."

Vad är det för? Det första och mest uppenbara är nog varför det behövs en hälsokontroll – för att förstå att applikationen fungerar. Jag menar, det är bara dumt, när det är uppe nu ser det ut som att det fungerar, så du kan vara säker på att det fungerar. Och det visar sig att applikationen körs, behållaren körs, instansen fungerar, allt är bra - och sedan har användarna redan stängt av alla telefonnummer från teknisk support och sagt "vad är du..., du somnade, ingenting fungerar.”

En hälsokontroll är bara ett sådant sätt att se från användarens synvinkel att det fungerar. En av metoderna. Låt oss uttrycka det så här. Ur Kubernetes synvinkel är detta också ett sätt att förstå när applikationen startar, eftersom vi förstår att det är skillnad på när behållaren lanserades, skapades och startade, och när applikationen lanserades direkt i denna behållare. För om vi tar en genomsnittlig java-applikation och försöker starta den i dockan, så kan den börja i fyrtio sekunder, eller till och med en minut, eller till och med tio, bra. I det här fallet kan du åtminstone knacka på dess portar, det kommer inte att svara där, det vill säga det är ännu inte redo att ta emot trafik.

Återigen, med hjälp av en hälsokontroll och med hjälp av det faktum att vi vänder oss hit, kan vi förstå i Kubernetes att inte bara behållaren har stigit i applikationen, utan själva applikationen har startat, den svarar redan på hälsokontroll, vilket innebär att vi kan skicka trafik dit.

Det jag pratar om nu kallas Readiness/Liveness-tester inom Kubernetes; följaktligen är våra beredskapstester ansvariga för tillgängligheten av applikationen i balansering. Det vill säga, om beredskapstester utförs i applikationen så är allt ok, klienttrafiken går till applikationen. Om beredskapstester inte utförs deltar helt enkelt inte applikationen, just den här instansen deltar inte i balansering, den tas bort från balansering, klienttrafik flyter inte. Följaktligen behövs Liveness-tester inom Kubernetes så att om applikationen fastnar kan den startas om. Om liveness-testet inte fungerar för en applikation som deklareras i Kubernetes, så tas inte applikationen bara bort från balansering, den startas om.

Och här är en viktig punkt som jag skulle vilja nämna: ur praktisk synvinkel används beredskapstestet oftast oftare och behövs oftare än livlighetstestet. Det vill säga att helt enkelt tanklöst deklarera både beredskaps- och livlighetstester, eftersom Kubernetes kan göra det, och låt oss använda allt det kan göra, är inte en särskilt bra idé. Jag ska förklara varför. För punkt nummer två i testning är att det skulle vara en bra idé att kontrollera den underliggande tjänsten i dina hälsokontroller. Det betyder att om du har en webbapplikation som ger ut en del information, som den i sin tur naturligtvis måste ta någonstans ifrån. I en databas till exempel. Tja, den sparar informationen som kommer in i detta REST API i samma databas. Sedan, om din hälsokontroll svarar helt enkelt som kontaktad slashhealth, säger applikationen "200, okej, allt är bra", och samtidigt är din applikations databas otillgänglig, och hälsokontrollapplikationen säger "200, okej, allt är bra ” – Det här är en dålig hälsokontroll. Det är inte så det ska fungera.

Det vill säga din ansökan, när en förfrågan kommer till den /health, den svarar inte bara "200, ok", den går först till till exempel databasen, försöker ansluta till den, gör något väldigt grundläggande där, som att välja en, kontrollerar bara att det finns en anslutning i databasen och du kan fråga databasen. Om allt detta lyckades är svaret "200, ok." Om det inte lyckas står det att det finns ett fel, databasen är inte tillgänglig.

Därför, i detta avseende, återkommer jag igen till beredskaps-/livetesterna - varför du med största sannolikhet behöver ett beredskapstest, men ett livhetstest är i fråga. För om du beskriver hälsokontroller precis som jag nyss sa, så kommer det att visa sig att det inte är tillgängligt i instansdelenв или со всех instancei en databas till exempel. När du deklarerade ett beredskapstest började våra hälsokontroller misslyckas, och följaktligen stängs alla applikationer från vilka databasen inte är tillgänglig, de helt enkelt avstängda från balansering och "hänger" i själva verket bara i ett försummat tillstånd och väntar på att deras databaser ska arbete.

Om vi ​​har deklarerat ett livhetstest, tänk dig att vår databas har gått sönder, och i din Kubernetes börjar hälften av allt att starta om eftersom livenesstestet misslyckas. Det betyder att du måste starta om. Det här är inte alls vad du vill, jag hade till och med personlig erfarenhet i praktiken. Vi hade en chattapplikation som skrevs i JS och matades in i en Mongo-databas. Och problemet var att det var i början av mitt arbete med Kubernetes, vi beskrev beredskapen, livligheten av tester på principen att Kubernetes kan göra det, så vi kommer att använda det. Följaktligen blev Mongo vid något tillfälle lite "tråkig" och provet började misslyckas. Följaktligen, enligt regntestet, började baljorna "döda".

Som du förstår, när de "dödas", är detta en chatt, det vill säga det finns många kopplingar från klienter som hänger på den. De är också "dödade" - nej, inte klienter, bara anslutningar - inte alla samtidigt, och på grund av att de inte dödas samtidigt, vissa tidigare, vissa senare, börjar de inte samtidigt tid. Plus standard slumpmässigt, vi kan inte förutsäga med millisekunders noggrannhet starttiden för applikationen varje gång, så de gör det en instans i taget. En infospot reser sig, läggs till i balanseringen, alla klienter kommer dit, den klarar inte en sådan belastning, eftersom den är ensam, och grovt sett är det ett dussin av dem som jobbar där, och det faller. Nästa reser sig, hela lasset ligger på honom, han faller också. Tja, de här fallen fortsätter bara att falla. Till slut, hur detta löstes - vi var bara tvungna att strikt stoppa användartrafiken till den här applikationen, låta alla instanser stiga och sedan starta all användartrafik på en gång så att den redan var fördelad på alla tio instanser.

Om det inte vore för att det här livenesstestet tillkännagavs, vilket skulle tvinga det hela att starta om, skulle applikationen ha klarat det bra. Men allt från balansering är inaktiverat för oss, eftersom databaserna är otillgängliga och alla användare har "fallit av". Sedan, när denna databas blir tillgänglig, ingår allt i balanseringen, men applikationer behöver inte starta om, och det finns ingen anledning att slösa tid och resurser på detta. De är alla redan här, de är redo för trafik, så trafiken bara öppnar, allt är bra - applikationen är på plats, allt fortsätter att fungera.

Därför är beredskaps- och livhetstest olika, dessutom kan man teoretiskt göra olika hälsokontroller, en typ radier, en typ liv till exempel och kolla olika saker. Under beredskapstester, kontrollera dina backends. Och på ett livhetstest, till exempel, kontrollerar man inte ur synvinkeln att livenesstestet i allmänhet bara är en applikation som svarar, om den överhuvudtaget kan svara.

Eftersom livlighetstestet i stort sett är när vi "fastnar". En oändlig loop har startat eller något annat - och inga fler förfrågningar behandlas. Därför är det vettigt att till och med separera dem - och implementera olika logik i dem.

Angående vad man behöver svara på när man har prov, när man gör hälsokontroller. Det är bara riktigt jobbigt. De som är bekanta med detta kommer förmodligen att skratta - men seriöst, jag har sett tjänster i mitt liv som svarar "200" i XNUMX% av fallen. Det vill säga vem som är framgångsrik. Men samtidigt skriver de i själva svaret "ett sådant och sådant fel."

Det vill säga, svarsstatusen kommer till dig - allt är framgångsrikt. Men samtidigt måste du analysera kroppen, eftersom kroppen säger "förlåt, begäran slutade med ett fel" och detta är bara verkligheten. Jag såg det här i verkligheten.

Och så att vissa människor inte tycker att det är roligt, och andra tycker att det är väldigt smärtsamt, är det fortfarande värt att följa en enkel regel. I hälsokontroller, och i princip när man arbetar med webbapplikationer.

Om allt gick bra, svara då med det tvåhundrade svaret. I princip kommer vilket tvåhundradelssvar som helst att passa dig. Om du läser raggy mycket bra och vet att vissa svarsstatusar skiljer sig från andra, svara med lämpliga: 204, 5, 10, 15, vad som helst. Om det inte är särskilt bra, då bara "två noll noll." Om allt går dåligt och hälsokontrollen inte svarar, svara då med valfri femhundradel. Återigen, om du förstår hur du ska svara, hur olika svarsstatusar skiljer sig från varandra. Om du inte förstår är 502 ditt alternativ att svara på hälsokontroller om något går fel.

Det här är en annan punkt, jag vill återkomma lite om att kontrollera de underliggande tjänsterna. Om du till exempel börjar kolla alla underliggande tjänster som står bakom din ansökan – allt i stort. Vad vi får ur mikrotjänstarkitekturens synvinkel har vi ett sådant koncept som "låg koppling" - det vill säga när dina tjänster är minimalt beroende av varandra. Om en av dem misslyckas kommer alla andra utan denna funktion helt enkelt att fortsätta att fungera. En del av funktionerna fungerar helt enkelt inte. Följaktligen, om du knyter alla hälsokontroller till varandra, kommer du att sluta med att en sak faller i infrastrukturen, och eftersom den föll, börjar alla hälsokontroller av alla tjänster också misslyckas - och det finns mer infrastruktur i allmänhet för hela mikrotjänstarkitekturen nr. Allt blev mörkt där.

Därför vill jag upprepa detta igen att du behöver kontrollera de underliggande tjänsterna, de utan vilka din ansökan i hundra procent av fallen inte kan göra sitt jobb. Det vill säga, det är logiskt att om du har ett REST API genom vilket användaren sparar till databasen eller hämtar från databasen, så kan du i frånvaro av en databas inte garantera arbete med dina användare.

Men om dina användare, när du tar ut dem ur databasen, dessutom berikas med lite annan metadata, från en annan backend, som du anger innan du skickar ett svar till frontend - och denna backend inte är tillgänglig, betyder det att du ger din svara utan någon del av metadata.

Därefter har vi också ett av de smärtsamma problemen när vi startar applikationer.

Faktum är att detta inte bara gäller Kubernetes i stort sett, det hände sig att kulturen med någon form av massutveckling och DevOps i synnerhet började spridas ungefär samtidigt som Kubernetes. Därför visar det sig i stort sett att du behöver stänga ner din applikation på ett graciöst sätt utan Kubernetes. Redan innan Kubernetes gjorde folk detta, men med tillkomsten av Kubernetes började vi prata om det i massor.

Graciös avstängning

I allmänhet, vad är Graceful Shutdown och varför behövs det? Det här handlar om när din applikation kraschar av någon anledning måste du göra app stop – eller så får du till exempel en signal från operativsystemet, din applikation måste förstå det och göra något åt ​​det. Det värsta scenariot är naturligtvis när din ansökan får en SIGTERM och är som "SIGTERM, låt oss hänga på, jobba, gör ingenting." Detta är ett rent dåligt alternativ.

Ett nästan lika dåligt alternativ är när din applikation får en SIGTERM och är som "de sa segterm, det betyder att vi slutar, jag har inte sett, jag känner inte till några användarförfrågningar, jag vet inte vilken typ av förfrågningar jag jobbar på just nu, sa de SIGTERM, det betyder att vi slutar " Detta är också ett dåligt alternativ.

Vilket alternativ är bra? Den första punkten är att ta hänsyn till slutförandet av operationer. Ett bra alternativ är att din server fortfarande tar hänsyn till vad den gör om den tar emot en SIGTERM.

SIGTERM är en mjuk avstängning, den är specialdesignad, den kan avlyssnas på kodnivå, den kan bearbetas, säg att nu, vänta, vi kommer först att avsluta det arbete vi har, sedan kommer vi att avsluta.

Ur ett Kubernetes-perspektiv är det så här det ser ut. När vi säger till en pod som körs i ett Kubernetes-kluster, "snälla sluta, gå iväg", eller en omstart sker, eller en uppdatering sker när Kubernetes återskapar podarna, skickar Kubernetes precis samma SIGTERM-meddelande till podden, väntar på lite tid, och , det här är tiden som han väntar, den är också konfigurerad, det finns en sådan speciell parameter i diplom och den kallas Graceful ShutdownTimeout. Som du förstår heter det inte så för ingenting, och det är inte för inte som vi pratar om det nu.

Där kan vi specifikt säga hur länge vi behöver vänta mellan det att vi skickar SIGTERM till applikationen och när vi förstår att applikationen verkar ha blivit galen för något eller har "fastnat" och inte kommer att avslutas - och vi måste skicka det SIGKILL, det vill säga hårt slutföra sitt arbete. Det vill säga, följaktligen har vi någon form av demon igång, den bearbetar operationer. Vi förstår att våra operationer som demonen arbetar med i genomsnitt inte varar mer än 30 sekunder åt gången. Följaktligen, när SIGTERM anländer förstår vi att vår demon högst kan sluta 30 sekunder efter SIGTERM. Vi skriver det till exempel 45 sekunder för säkerhets skull och säger att SIGTERM. Efter det väntar vi 45 sekunder. I teorin borde demonen under denna tid ha slutfört sitt arbete och tagit slut. Men om det plötsligt inte kunde, betyder det att det med största sannolikhet har fastnat – det behandlar inte längre våra förfrågningar normalt. Och på 45 sekunder kan du faktiskt säkert spika fast honom.

Och här kan faktiskt även 2 aspekter beaktas. För det första, förstå att om du fick en förfrågan började du arbeta med den på något sätt och gav inget svar till användaren, men du fick till exempel SIGTERM. Det är vettigt att förfina det och ge ett svar till användaren. Detta är punkt nummer ett i detta avseende. Punkt nummer två här är att om du skriver din egen applikation, i allmänhet bygger arkitekturen på ett sådant sätt att du får en förfrågan om din applikation, så börjar du lite arbete, börjar ladda ner filer någonstans, laddar ner en databas och sånt. - Den där. I allmänhet, din användare, din förfrågan hänger i en halvtimme och väntar på att du ska svara honom - då måste du troligen arbeta med arkitekturen. Det vill säga, ta bara hänsyn till sunt förnuft att om dina operationer är korta, så är det vettigt att ignorera SIGTERM och modifiera det. Om dina operationer är långa, är det ingen mening att ignorera SIGTERM i det här fallet. Det är vettigt att göra om arkitekturen för att undvika så långa operationer. Så att användarna inte bara hänger och väntar. Jag vet inte, gör någon form av websocket där, gör reverse hooks som din server redan kommer att skicka till klienten, något annat, men tvinga inte användaren att hänga i en halvtimme och bara vänta på en session tills du svara honom. För det är oförutsägbart var det kan gå sönder.

När din ansökan avslutas bör du ange en lämplig exit-kod. Det vill säga, om din ansökan ombads att stänga, stoppa, och den kunde stoppa sig själv normalt, så behöver du inte returnera någon form av exit-kod 1,5,255 och så vidare. Allt som inte är nollkod, åtminstone i Linux-system, jag är säker på detta, anses misslyckat. Dvs det anses att din ansökan i detta fall slutade med ett fel. Följaktligen, på ett vänskapligt sätt, om din ansökan slutfördes utan ett fel, säger du 0 på utgången. Om din applikation misslyckas av någon anledning säger du icke-0 i utgången. Och du kan arbeta med denna information.

Och det sista alternativet. Det är dåligt när din användare skickar en förfrågan och hänger sig i en halvtimme medan du bearbetar den. Men generellt skulle jag också vilja säga om vad som generellt är värt det från kundens sida. Det spelar ingen roll om du har en mobilapplikation, front-end, etc. Det är nödvändigt att ta hänsyn till att i allmänhet kan användarens session avslutas, vad som helst kan hända. En förfrågan kan skickas, till exempel underbehandlad och inget svar returneras. Ditt gränssnitt eller din mobilapplikation - vilket gränssnitt som helst i allmänhet, låt oss uttrycka det så - bör ta hänsyn till detta. Om du arbetar med websockets är detta i allmänhet den värsta smärtan jag någonsin har haft.

När utvecklarna av vissa vanliga chattar inte vet det, visar det sig att webbsocket kan gå sönder. För dem, när något händer vid proxyn, ändrar vi bara konfigurationen och den laddar om. Naturligtvis slits alla långlivade sessioner i detta fall. Utvecklare kommer springande till oss och säger: "Gubbar, vad gör ni, chatten har gått sönder för alla våra kunder!" Vi säger till dem: "Vad gör ni? Kan dina kunder inte återansluta? De säger: "Nej, vi behöver att sessionerna inte slits sönder." Kort sagt, detta är faktiskt nonsens. Kundsidan måste beaktas. Speciellt, som jag säger, med långlivade sessioner som websockets kan den gå sönder och obemärkt för användaren måste du kunna installera om sådana sessioner. Och då är allt perfekt.

Ресурсы

Egentligen, här ska jag bara berätta en rak historia. Återigen från verkliga livet. Det sjukaste jag någonsin hört om resurser.

Resurser i det här fallet, jag menar, någon form av förfrågningar, gränser som du kan sätta på poddar i dina Kubernetes-kluster. Det roligaste jag hörde från en utvecklare... En av mina andra utvecklare på en tidigare arbetsplats sa en gång: "Min applikation startar inte i klustret." Jag tittade för att se att det inte startade, men antingen passade det inte in i resurserna, eller så hade de satt väldigt små gränser. Kort sagt, applikationen kan inte starta på grund av resurser. Jag säger: "Det kommer inte att starta på grund av resurser, du bestämmer hur mycket du behöver och sätter ett adekvat värde." Han säger: "Vilken typ av resurser?" Jag började förklara för honom att Kubernetes, gränser för förfrågningar och bla, bla, bla måste ställas. Mannen lyssnade i fem minuter, nickade och sa: "Jag kom hit för att jobba som utvecklare, jag vill inte veta något om några resurser. Jag kom hit för att skriva kod och det är allt." Det är sorgligt. Detta är ett väldigt tråkigt koncept ur en utvecklares synvinkel. Särskilt i den moderna världen, så att säga, av progressiva devops.

Varför behövs resurser överhuvudtaget? Det finns två typer av resurser i Kubernetes. Vissa kallas för förfrågningar, andra kallas gränser. Med resurser förstår vi att det i princip alltid bara finns två grundläggande begränsningar. Det vill säga CPU-tidsgränser och RAM-gränser för en behållare som körs i Kubernetes.

En gräns sätter en övre gräns för hur en resurs kan användas i din applikation. Det vill säga, följaktligen, om du säger 1 GB RAM i gränserna, kommer din applikation inte att kunna använda mer än 1 GB RAM. Och om han plötsligt vill och försöker göra detta, kommer en process som kallas oom killer, utan minne, det vill säga, att komma och döda din applikation - det vill säga, den kommer helt enkelt att starta om. Applikationer startar inte om baserat på CPU. När det gäller CPU, om ett program försöker använda mycket, mer än vad som anges i gränserna, kommer CPU:n helt enkelt att väljas strikt. Detta leder inte till omstarter. Detta är gränsen - detta är den övre gränsen.

Och det finns en begäran. En begäran är hur Kubernetes förstår hur noderna i ditt Kubernetes-kluster är fyllda med applikationer. Det vill säga, en begäran är ett slags commit av din ansökan. Det står vad jag vill använda: "Jag skulle vilja att du reserverar så mycket CPU och så mycket minne åt mig." Så enkel analogi. Tänk om vi har en nod som har, jag vet inte, 8 processorer totalt. Och en pod kommer dit, vars förfrågningar säger 1 CPU, vilket betyder att noden har 7 CPU:er kvar. Det vill säga, följaktligen, så snart 8 pods anländer till denna nod, som var och en har 1 CPU i sina förfrågningar, har noden, som om från Kubernetes synvinkel, slut på CPU och fler pods med förfrågningar kan inte startas på denna nod. Om alla noder tar slut på CPU, kommer Kubernetes att börja säga att det inte finns några lämpliga noder i klustret för att köra dina pods eftersom CPU:n har tagit slut.

Varför behövs förfrågningar och varför utan förfrågningar, jag tror att det inte finns något behov av att lansera något i Kubernetes? Låt oss föreställa oss en hypotetisk situation. Du startar din applikation utan förfrågningar, Kubernetes vet inte hur mycket av det du har, vilka noder du kan pusha den till. Tja, han trycker, knuffar, knuffar på noderna. Vid något tillfälle kommer du att börja få trafik till din applikation. Och en av applikationerna börjar plötsligt använda resurser upp till de gränser som den har enligt gränserna. Det visar sig att det finns en annan applikation i närheten och den behöver också resurser. Noden börjar faktiskt få slut på resurser, till exempel OP. Noden börjar faktiskt få slut på resurser, till exempel RAM (Random Access Memory). När en nod får slut på ström slutar dockern först svara, sedan kuben och sedan operativsystemet. De kommer helt enkelt att bli medvetslösa och ALLT kommer definitivt att sluta fungera för dig. Det vill säga, detta kommer att leda till att din nod fastnar och du måste starta om den. Kort sagt, läget är inte särskilt bra.

Och när du har förfrågningar är gränserna inte särskilt olika, åtminstone inte många gånger mer än gränserna eller förfrågningarna, då kan du ha en sådan normal, rationell fyllning av ansökningar över noderna i Kubernetes-kluster. Samtidigt är Kubernetes ungefär medveten om hur mycket av det man lägger var, hur mycket av det som används var. Det vill säga, det är bara ett sådant ögonblick. Det är viktigt att förstå det. Och det är viktigt att kontrollera att detta indikeras.

Datalagring

Vår nästa punkt handlar om datalagring. Vad ska man göra med dem och i allmänhet vad man ska göra med uthållighet i Kubernetes?

Jag tror, ​​återigen, inom vår Kvällskola, det fanns ett ämne om databasen i Kubernetes. Och det verkar för mig som att jag till och med ungefär vet vad dina kollegor sa till dig när de frågade: "Är det möjligt att köra en databas i Kubernetes?" Av någon anledning verkar det som om dina kollegor borde ha sagt till dig att om du ställer frågan om det är möjligt att köra en databas i Kubernetes, så är det omöjligt.

Logiken här är enkel. För säkerhets skull, jag ska förklara ännu en gång, om du är en riktigt cool kille som kan bygga ett ganska feltolerant system för distribuerad nätverkslagring, förstå hur man passar in en databas i det här fallet, hur cloud native i behållare ska fungera i en databas i allmänhet. Troligtvis har du inga frågor om hur du kör det. Om du har en sådan fråga, och du vill försäkra dig om att det hela utspelar sig och står rätt till döden i produktionen och aldrig faller, så händer det inte. Du kommer garanterat att skjuta dig själv i foten med detta tillvägagångssätt. Så det är bättre att låta bli.

Vad ska vi göra med den data som vår applikation skulle vilja lagra, några bilder som användare laddar upp, några saker som vår applikation genererar under driften, till exempel vid uppstart? Vad ska man göra med dem i Kubernetes?

I allmänhet, idealiskt, ja, naturligtvis, är Kubernetes mycket väl utformad och var i allmänhet tänkt för statslösa applikationer. Det vill säga för de applikationer som inte lagrar information alls. Detta är idealiskt.

Men det ideala alternativet finns naturligtvis inte alltid. Än sen då? Den första och enklaste punkten är att ta någon form av S3, bara inte en hemmagjord, som också är oklart hur den fungerar, utan från någon leverantör. En bra, normal leverantör - och lär din applikation att använda S3. Det vill säga när din användare vill ladda upp en fil, säg "här, snälla, ladda upp den till S3." När han vill ta emot det, säg: "Här är en länk till S3 tillbaka och ta den härifrån." Detta är idealiskt.

Om det här idealiska alternativet plötsligt av någon anledning inte är lämpligt, du har en applikation som du inte skrev, du inte utvecklar, eller så är det något slags hemskt arv, det kan inte använda S3-protokollet, utan måste fungera med lokala kataloger i lokala mappar. Ta något mer eller mindre enkelt, distribuera Kubernetes. Det vill säga att omedelbart fäkta Ceph för några minimala uppgifter, förefaller det mig, är en dålig idé. För Ceph är förstås bra och moderiktig. Men om du inte riktigt förstår vad du gör, när du väl har lagt något på Ceph, kan du mycket enkelt och helt enkelt aldrig få det därifrån igen. Eftersom, som ni vet, lagrar Ceph data i sitt kluster i binär form, och inte i form av enkla filer. Därför, om plötsligt Ceph-klustret går sönder, så är det en fullständig och hög sannolikhet att du aldrig kommer att få din data därifrån igen.

Vi ska ha en kurs om Ceph, det kan du bekanta dig med programmet och skicka in en ansökan.

Därför är det bättre att göra något enkelt som en NFS-server. Kubernetes kan arbeta med dem, du kan montera en katalog under en NFS-server - din applikation är precis som en lokal katalog. Samtidigt måste du förstås förstå att du återigen måste göra något med din NFS, du måste förstå att den ibland kan bli otillgänglig och överväga frågan om vad du kommer att göra i det här fallet. Kanske borde säkerhetskopieras någonstans på en separat maskin.

Nästa punkt jag pratade om är vad du ska göra om din applikation genererar några filer under drift. Till exempel, när den startar, genererar den någon statisk fil, som är baserad på viss information som applikationen får först vid starttillfället. Vilket ögonblick. Om det inte finns mycket sådan data, behöver du inte bry dig alls, installera bara den här applikationen för dig själv och arbeta. Den enda frågan här är vad, titta. Mycket ofta, alla möjliga äldre system, som WordPress och så vidare, speciellt med modifierade någon form av smarta plugins, smarta PHP-utvecklare, de vet ofta hur de ska göra det så att de genererar någon form av fil för sig själva. Följaktligen genererar en en fil, den andra genererar en andra fil. De är olika. Balansering sker i kundernas Kubernetes-kluster helt enkelt av en slump. Följaktligen visar det sig att de till exempel inte vet hur de ska samarbeta. Den ena ger en information, den andra ger användaren en annan information. Detta är något du bör undvika. Det vill säga, i Kubernetes kommer allt du lanserar garanterat att kunna fungera i flera instanser. Eftersom Kubernetes är en grej som rör sig. Följaktligen kan han flytta vad som helst, när han vill, utan att fråga någon alls. Därför måste du räkna med detta. Allt som lanseras i en instans kommer förr eller senare att misslyckas. Ju fler reservationer du har, desto bättre. Men återigen, säger jag, om du har några sådana filer, då kan du lägga dem direkt under dig, de väger en liten mängd. Om det finns lite fler av dem bör du förmodligen inte trycka in dem i behållaren.

Jag skulle råda dig att det finns en sådan underbar sak i Kubernetes, du kan använda volym. I synnerhet finns det en volym av typen tom dir. Det vill säga, det är bara så att Kubernetes automatiskt skapar en katalog i sina tjänstkataloger på servern där du började. Och han kommer att ge det till dig så att du kan använda det. Det finns bara en viktig punkt. Det vill säga, dina data kommer inte att lagras inuti behållaren, utan snarare på den värd som du kör på. Dessutom kan Kubernetes kontrollera sådana tomma kataloger under normal konfiguration och kan kontrollera deras maximala storlek och inte tillåta att den överskrids. Den enda poängen är att det du har skrivit i tom dir inte går förlorat under omstarter av podden. Det vill säga, om din pod faller av misstag och reser sig igen, kommer informationen i den tomma katalogen inte att gå någonstans. Han kan använda den igen vid en ny start - och det är bra. Om din pod lämnar någonstans, så kommer han naturligtvis att lämna utan data. Det vill säga, så snart podden från noden där den lanserades med tom dir försvinner, raderas tom dir.

Vad mer är bra med tom dir? Den kan till exempel användas som en cache. Låt oss föreställa oss att vår applikation genererar något i farten, ger det till användarna och gör det under lång tid. Därför genererar applikationen till exempel och ger den till användarna, och lagrar den samtidigt någonstans, så att nästa gång användaren kommer för samma sak kommer det att gå snabbare att ge den omedelbart genererad. Tom katalog kan uppmanas Kubernetes att skapa i minnet. Och därmed kan dina cachar i allmänhet fungera blixtsnabbt - när det gäller diskåtkomsthastighet. Det vill säga, du har en tom dir i minnet, i OS är den lagrad i minnet, men för dig, för användaren inuti podden, ser det ut som bara en lokal katalog. Du behöver inte appen för att specifikt lära ut någon magi. Du tar bara direkt och lägger din fil i en katalog, men i själva verket i minnet på operativsystemet. Detta är också en mycket bekväm funktion när det gäller Kubernetes.

Vilka problem har Minio? Det största problemet med Minio är att för att den här saken ska fungera måste den köras någonstans, och det måste finnas något slags filsystem, det vill säga lagring. Och här möter vi samma problem som Ceph har. Det vill säga att Minio måste lagra sina filer någonstans. Det är helt enkelt ett HTTP-gränssnitt till dina filer. Funktionaliteten är dessutom klart sämre än hos Amazons S3. Tidigare kunde den inte auktorisera användaren korrekt. Nu kan den, så vitt jag vet, redan skapa hinkar med olika behörigheter, men återigen, det verkar för mig som att huvudproblemet så att säga är det underliggande lagringssystemet åtminstone.

Hur påverkar Empty dir i minnet gränserna? Påverkar inte gränserna på något sätt. Det ligger i värdens minne och inte i minnet av din behållare. Det vill säga, din behållare ser inte den tomma katalogen i minnet som en del av dess upptagna minne. Värden ser detta. Följaktligen, ja, ur kubernetes synvinkel, när du börjar använda detta, skulle det vara bra att förstå att du ägnar en del av ditt minne till tomma dir. Och därför förstå att minnet kan ta slut inte bara på grund av applikationer, utan också för att någon skriver till dessa tomma dirs.

Cloudnativeness

Och det sista underämnet är vad Cloudnative är. Varför behövs det? Cloudnativeness och så vidare.

Det vill säga de applikationer som är kapabla och skrivna för att fungera i en modern molninfrastruktur. Men i själva verket har Cloudnative en annan sådan aspekt. Att detta inte bara är en applikation som tar hänsyn till alla krav som en modern molninfrastruktur ställer, utan också vet hur man arbetar med denna moderna molninfrastruktur, dra nytta av fördelarna och nackdelarna med att det fungerar i dessa moln. Gå inte bara överbord och arbeta i molnen, utan dra nytta av fördelarna med att arbeta i molnet.

Låt oss bara ta Kubernetes som ett exempel. Din applikation körs i Kubernetes. Din applikation kan alltid, eller snarare administratörerna för din applikation, alltid skapa ett tjänstekonto. Det vill säga ett konto för auktorisering i Kubernetes själv på sin server. Lägg till några rättigheter som vi behöver där. Och du kan komma åt Kubernetes från din applikation. Vad kan du göra på det här sättet? Till exempel, från applikationen, ta emot data om var dina andra applikationer, andra liknande instanser finns, och tillsammans på något sätt klustera ovanpå Kubernetes, om det finns ett sådant behov.

Återigen, vi hade bokstavligen ett fall nyligen. Vi har en kontrollant som övervakar kön. Och när några nya uppgifter dyker upp i den här kön går den till Kubernetes - och inne i Kubernetes skapar den en ny pod. Ger denna pod en ny uppgift och inom ramen för denna pod utför podden uppgiften, skickar ett svar till kontrollenheten själv, och kontrollenheten gör sedan något med denna information. Till exempel lägger den ihop en databas. Det vill säga, återigen, detta är ett plus med det faktum att vår applikation körs i Kubernetes. Vi kan använda själva den inbyggda Kubernetes-funktionaliteten för att på något sätt utöka och göra funktionaliteten i vår applikation mer bekväm. Det vill säga, dölj inte någon form av magi om hur man startar en applikation, hur man startar en arbetare. I Kubernetes skickar du helt enkelt en förfrågan i appen om applikationen är skriven i Python.

Detsamma gäller om vi går bortom Kubernetes. Vi har våra Kubernetes igång någonstans - det är bra om det är i något slags moln. Återigen, vi kan använda, och till och med bör, tror jag, använda funktionerna i själva molnet där vi kör. Från de elementära saker som molnet ger oss. Balansering, det vill säga vi kan skapa molnbalanserare och använda dem. Detta är en direkt fördel med vad vi kan använda. Eftersom molnbalansering, för det första, helt enkelt dumt tar bort ansvaret från oss för hur det fungerar, hur det är konfigurerat. Dessutom är det väldigt bekvämt, eftersom vanliga Kubernetes kan integreras med moln.

Detsamma gäller skalning. Vanliga Kubernetes kan integreras med molnleverantörer. Vet hur man förstår att om klustret tar slut på noder, det vill säga nodutrymmet har tagit slut, då måste du lägga till - Kubernetes kommer själv att lägga till nya noder till ditt kluster och börja starta pods på dem. Det vill säga när din last kommer börjar antalet härdar att öka. När noderna i klustret tar slut för dessa pods, lanserar Kubernetes nya noder och följaktligen kan antalet pods fortfarande öka. Och det är väldigt bekvämt. Detta är en direkt möjlighet att skala klustret i farten. Inte särskilt snabbt, i den meningen att det inte är en sekund, det är mer som en minut för att lägga till nya noder.

Men av min erfarenhet, igen, är det det coolaste jag någonsin sett. När Cloudnative-klustret skalade baserat på tid på dygnet. Det var en backend-tjänst som användes av personer i backoffice. Det vill säga, de kommer till jobbet klockan 9, börjar logga in i systemet, och följaktligen börjar Cloudnative-klustret, där allt är igång, att svälla och lanserar nya pods så att alla som kommer till jobbet kan arbeta med applikationen. När de lämnar jobbet klockan 8 eller 6 märker Kubernetes-klustren att ingen längre använder programmet och börjar krympa. Besparingar på upp till 30 procent garanteras. Det fungerade i Amazon vid den tiden; på den tiden fanns det ingen i Ryssland som kunde göra det så bra.

Jag ska säga dig rakt av, besparingarna är 30 procent helt enkelt för att vi använder Kubernetes och drar fördel av molnets möjligheter. Nu kan detta göras i Ryssland. Jag kommer inte att annonsera för någon, naturligtvis, men låt oss bara säga att det finns leverantörer som kan göra detta, tillhandahålla det direkt ur lådan med en knapp.

Det finns en sista punkt som jag också skulle vilja fästa er uppmärksamhet på. För att din applikation, din infrastruktur ska vara Cloudnative, är det vettigt att äntligen börja anpassa tillvägagångssättet som kallas Infrastructure as a Code. Det betyder att din applikation, eller snarare din infrastruktur, behövs på exakt samma sätt som kod Beskriv din applikation, din affärslogik i form av kod. Och arbeta med den som kod, det vill säga testa den, rulla ut den, lagra den i git, applicera CICD på den.

Och det är just detta som gör att du, för det första, alltid kan ha kontroll över din infrastruktur, att alltid förstå vilket tillstånd den är i. För det andra, undvik manuella operationer som orsakar fel. För det tredje, undvik helt enkelt det som kallas omsättning, när du hela tiden behöver utföra samma manuella uppgifter. För det fjärde låter det dig återhämta dig mycket snabbare i händelse av ett fel. I Ryssland, varje gång jag pratar om detta, finns det alltid ett stort antal människor som säger: "Ja, det är klart, men du har tillvägagångssätt, kort sagt, det finns inget behov av att fixa någonting." Men det är sant. Om något är trasigt i din infrastruktur är det enklare ur Cloudnatives synvinkel och ur infrastrukturen som en kod, snarare än att fixa det, gå till servern, ta reda på vad som är trasigt och fixa det. för att ta bort servern och skapa den igen. Och jag kommer att få allt detta återställt.

Alla dessa frågor diskuteras mer ingående på Kubernetes videokurser: Junior, Basic, Mega. Genom att följa länken kan du bekanta dig med programmet och villkoren. Det bekväma är att du kan bemästra Kubernetes genom att studera hemifrån eller arbeta 1-2 timmar om dagen.

Källa: will.com