Hjoed plan ik te praten oer hoe't jo applikaasjes skriuwe en wat binne de easken foar jo applikaasje om goed te wurkjen yn Kubernetes. Sadat d'r gjin hoofdpijn binne mei de applikaasje, sadat jo gjin "kraten" der omhinne hoege útfine en te bouwen - en alles wurket lykas Kubernetes sels bedoeld hat.
Dizze lêzing is ûnderdiel fan "" Jo kinne de iepen teoretyske lêzingen fan de Jûnskoalle besjen . Foar dyjingen dy't tekst leaver hawwe as fideo, hawwe wy dit artikel taret.
Myn namme is Pavel Selivanov, op it stuit bin ik de liedende DevOps-yngenieur by Mail.ru Cloud Solutions, wy meitsje wolken, wy meitsje managementkubernetes ensafuorthinne. Myn taken omfetsje no assistinsje by ûntwikkeling, it útrollen fan dizze wolken, it útroljen fan de applikaasjes dy't wy skriuwe en it direkt ûntwikkeljen fan de ark dy't wy foar ús brûkers leverje.
Ik haw DevOps dien, tink ik foar de lêste, wierskynlik, trije jier. Mar, yn prinsipe, haw ik dien wat DevOps no wierskynlik sawat fiif jier docht. Dêrfoar wie ik meast belutsen by admin-saken. Ik begon te wurkjen mei Kubernetes in lange tiid lyn - wierskynlik binne sawat fjouwer jier ferrûn sûnt ik dermei begon te wurkjen.
Yn 't algemien begon ik doe't Kubernetes ferzje 1.3 wie, wierskynlik, en miskien 1.2 - doe't it noch yn' e berneskuon wie. No is it net mear yn 'e berneskuon - en it is fanselssprekkend dat d'r in grutte fraach is op' e merk foar yngenieurs dy't Kubernetes wolle kinne dwaan. En bedriuwen hawwe in tige hege fraach nei sokke minsken. Dêrom ferskynde trouwens dizze lêzing.
As wy prate neffens it plan fan wêr't ik oer prate sil, sjocht it der sa út, tusken heakjes stiet skreaun (TL;DR) - "te lang; net lêze". Myn presintaasje hjoed sil bestean út einleaze listen.
Eins hâld ik sels net fan sokke presintaasjes as se makke wurde, mar dit is sa'n ûnderwerp dat ik doe't ik dizze presintaasje tariede, gewoan net echt útfine hoe't ik dizze ynformaasje oars organisearje.
Om't, yn 't algemien, dizze ynformaasje "ctrl+c, ctrl+v" is, fan ûnder oare ús Wiki yn 'e DevOps-seksje, wêr't wy skreaune easken hawwe foar ûntwikkelders: "jonges, sadat wy jo applikaasje ynstarte yn Kubernetes, it moat sa wêze."
Dêrom waard de presintaasje sa'n grutte list. Sorry. Ik sil besykje safolle mooglik te fertellen sadat it net saai is as it kin.
Wat wy no sille sjen:
- dit binne, earst, logs (applikaasje logs?), wat te dwaan mei harren yn Kubernetes, wat te dwaan mei harren, wat se moatte wêze;
- wat te dwaan mei konfiguraasjes yn Kubernetes, wat binne de bêste en minste manieren om in applikaasje foar Kubernetes te konfigurearjen;
- Lit ús prate oer wat tagonklikheidskontrôles yn 't algemien binne, hoe't se der útsjen moatte;
- lit ús prate oer wat in sierlike shutdown is;
- lit ús nochris oer boarnen prate;
- Litte wy it ûnderwerp fan gegevensopslach nochris oanreitsje;
- en oan it ein sil ik jo fertelle wat de term dizze mysterieuze wolk-native applikaasje is. Cloudnativeness, as in eigenskipswurd fan dizze term.
Logs
Ik stel foar om te begjinnen mei de logs - mei wêr't dizze logs moatte wurde skood yn Kubernetes. No hawwe jo in applikaasje lansearre yn Kubernetes. Neffens de klassiken skreaunen eardere applikaasjes altyd logs earne yn in bestân. Minne applikaasjes skreaunen logs nei in bestân yn 'e thúsmap fan de ûntwikkelder dy't de applikaasje lansearre. Goede applikaasjes skreau logs nei in triem earne yn /var/log.
Fierders hiene goede behearders guon dingen konfigureare yn har ynfrastruktuer dat dizze logs koenen draaie - deselde rsyslog, dy't nei dizze logs sjocht en as der wat mei har bart, binne d'r in protte fan har, it makket reservekopyen , set logs dêr , wisket âlde triemmen, mear as in wike, seis moannen en wat mear. Yn teory moatte wy foarsjenningen hawwe sadat gewoan om't de applikaasje logs skriuwt, de romte op 'e produksjeservers (bestridingsservers?) net útkomt. En sadwaande stoppe de hiele produksje net fanwegen de logs.
As wy nei de wrâld fan Kubernetes ferhúzje en dêr itselde ding útfiere, is it earste ding dat jo omtinken jaan kinne oan it feit dat minsken, sa't se logboeken yn in bestân skriuwe, trochgean mei it skriuwen.
It docht bliken dat as wy prate oer Kubernetes, it goede plak om logs earne te skriuwen fan in docker-container is gewoan om se te skriuwen fan 'e applikaasje nei de saneamde Stdout/Stderr, dat is, it bestjoeringssysteem standert útfierstreamen, standert flater útfier. Dit is de meast korrekte, ienfâldichste en meast logyske manier om logs yn prinsipe te pleatsen yn Docker en spesifyk yn Kubernetis. Want as jo applikaasje logs skriuwt nei Stdout / Stderr, dan is it oan Docker en de Kubernetes-tafoeging om te besluten wat te dwaan mei dizze logs. Docker sil standert syn spesjale bestannen bouwe yn JSON-formaat.
Hjir ûntstiet de fraach, wat sille jo folgjende dwaan mei dizze logs? De maklikste manier is dúdlik, wy hawwe de mooglikheid om te dwaan kubectl logs en sjoch nei dizze logs fan dizze "pods". Mar, wierskynlik, dit is net in heul goede opsje - der moat wat oars dien wurde mei de logs.
Foar no, litte wy tagelyk prate, om't wy it ûnderwerp fan logs oanrekke, oer sa'n ding as logs moatte útsjen. Dat is, dit jildt net direkt foar Kubernetes, mar as wy begjinne te tinken oer wat te dwaan mei logs, soe it goed wêze om hjir ek oer nei te tinken.
Wy hawwe in soarte fan ark nedich, op in freonlike manier, dat dizze logs dy't ús docker yn har bestannen set sil nimme en se earne stjoere. Oer it algemien lansearje wy gewoanlik in soarte fan agint yn Kubernetes yn 'e foarm fan in DaemonSet - in log-samler, dy't gewoan wurdt ferteld wêr't de logs dy't Docker sammelet lizze. En dizze sammelagent nimt se gewoan, miskien sels op ien of oare manier ûnderweis, ferriket se miskien mei wat ekstra meta-ynformaasje en stjoert se úteinlik earne foar opslach. Fariaasjes binne dêr al mooglik. De meast foarkommende is wierskynlik Elasticsearch, wêr't jo logs kinne opslaan en jo kinne se dêr maklik ophelje. Dan, mei help fan in fersyk, mei help fan Kibana, bygelyks, build grafiken basearre op harren, bou warskôgings basearre op harren, ensafuorthinne.
It wichtichste idee, ik wol it nochris werhelje, is dat binnen Docker, benammen binnen Kubernetes, it opslaan fan jo logs yn in bestân in heul min idee is.
Om't it earst lestich is om de logs yn 'e kontener yn in bestân te krijen. Jo moatte earst yn 'e kontener gean, dêr útfiere, en dan nei de logs sjen. It folgjende punt is dat as jo logs yn in bestân hawwe, dan hawwe de konteners normaal in minimalistyske omjouwing en d'r binne gjin nutsbedriuwen dy't normaal nedich binne foar normaal wurk mei logs. Begrave se, besjoch se, iepenje se yn in tekstbewurker. It folgjende momint is as wy logs hawwe yn in bestân yn in kontener, as dizze kontener wiske is, begripe jo, de logs sille dêrmei stjerre. Dêrtroch betsjut elke opstart fan 'e kontener dat d'r gjin logs mear binne. Nochris, minne opsje.
En it lêste punt is dat binnen konteners jo gewoanlik jo applikaasje hawwe en dat is it - it is normaal it ienige proses dat rint. D'r is hielendal gjin praat oer elk proses dat bestannen mei jo logs soe rotearje. Sadree't de logs begjinne te skriuwen nei in bestân, betsjut dit dat, ekskús my, wy sille begjinne te ferliezen de produksje tsjinner. Om't se earst lestich te finen binne, gjinien folget se, plus gjinien kontroleart se - sadwaande groeit it bestân einleas oant de romte op 'e tsjinner gewoan op is. Dêrom sis ik nochris dat ynlogge yn Docker, benammen yn Kubernetes, nei in bestân in min idee is.
It folgjende punt, hjir wol ik hjir nochris oer prate - om't wy it ûnderwerp fan logs oanreitsje, soe it goed wêze om te praten oer hoe't logs moatte útsjen om it handich te meitsjen om mei har te wurkjen. Lykas ik sei, is it ûnderwerp net direkt relatearre oan Kubernetes, mar it ferbynt heul goed mei it ûnderwerp fan DevOps. Op it ûnderwerp fan ûntwikkeling kultuer en freonskip tusken dizze twa ferskillende ôfdielings - Dev en Ops, sadat elkenien is noflik.
Dit betsjut dat by útstek, hjoed, logs moatte wurde skreaun yn JSON-formaat. As jo ien of oare ûnbegryplike tapassing fan jo eigen hawwe, dy't logs yn ûnbegryplike formaten skriuwt, om't jo in soarte fan print of soksawat ynfoegje, dan is it tiid om in soart ramt te googlejen, in soarte fan wrapper wêrmei jo normale logging kinne útfiere; ynskeakelje logging parameters yn JSON dêr, omdat JSON is in ienfâldich formaat, parsing it is ienfâldich.
As jo JSON net wurket neffens guon kritearia, gjinien wit wat, dan op syn minst skriuw logs yn in formaat dat kin wurde parsed. Hjir, leaver, it is it wurdich om nei te tinken oer it feit dat, bygelyks, as jo in boskje konteners útfiere of gewoan prosessen mei nginx, en elk hat syn eigen logynstellingen, dan liket it wierskynlik dat it foar jo heul ûngemaklik sil wêze parse harren. Om't jo foar elke nije nginx-eksimplaar jo eigen parser moatte skriuwe, om't se logs oars skriuwe. Nochris, it wie wierskynlik de muoite wurdich om te tinken oer te soargjen dat al dizze nginx-eksimplaren deselde loggingkonfiguraasje hiene en al har logs absolút unifoarm skreaunen. Itselde jildt foar absolút alle applikaasjes.
Oan 'e ein wol ik ek brânstof oan it fjoer tafoegje dat, ideaal, logs mei meardere rigels opmaak moatte wurde foarkommen. Hjir is it ding, as jo oait wurke hawwe mei log-samlers, dan hawwe jo wierskynlik sjoen wat se jo tasizze, dat se kinne wurkje mei multi-line logs, witte hoe't se se sammelje, ensfh. Yn feite, yn myn miening, net ien samler hjoed kin sammelje multi-line logs normaal, folslein en sûnder flaters. Op in minsklike manier, sadat it handich en flaterfrij is.
Mar stack trace is altyd multi-line logs en hoe om te foarkommen dat se. De fraach hjir is dat in log is in rekord fan in evenemint, en stactrace is net eins in log. As wy logs sammelje en se earne yn Elasticsearch pleatse en dan grafiken fan har tekenje, bouwe wat rapporten fan brûkersaktiviteit op jo side, dan as jo in stapelspoar krije, betsjuttet it dat der in unferwachte situaasje bart yn jo applikaasje. En it makket sin om automatysk in stapelspoar earne op te laden yn in systeem dat se kin folgje.
Dit is software (itselde Sentry) dat is makke spesifyk om te wurkjen mei stack trace. It kin fuortendaliks automatyske taken oanmeitsje, se oan immen tawize, warskôgje as stacttraces foarkomme, dizze stacttraces groepearje op ien type, ensfh. Yn prinsipe hat it net folle sin om oer stactraces te praten as wy oer logs prate, om't dit ommers ferskillende dingen binne mei ferskillende doelen.
Konfiguraasje
Folgjende prate wy oer konfiguraasje yn Kubernetes: wat dermei te dwaan en hoe't applikaasjes binnen Kubernetes moatte wurde konfigureare. Yn 't algemien sis ik normaal dat Docker net oer konteners giet. Elkenien wit dat Docker oer konteners giet, sels dyjingen dy't net folle mei Docker hawwe wurke. Ik werhelje, Docker giet net oer konteners.
Docker giet nei myn miening oer noarmen. En d'r binne noarmen foar praktysk alles: noarmen foar it bouwen fan jo applikaasje, noarmen foar it ynstallearjen fan jo applikaasje.
En dit ding - wy brûkten it earder, it waard gewoan benammen populêr mei de komst fan konteners - dit ding wurdt ENV (miljeu) fariabelen neamd, dat is omjouwingsfariabelen dy't yn jo bestjoeringssysteem binne. Dit is oer it algemien in ideale manier om jo applikaasje te konfigurearjen, want as jo applikaasjes hawwe yn JAVA, Python, Go, Perl, God ferbiede, en se kinne allegear de databankhost, databankbrûker, databankwachtwurdfariabelen lêze, dan is it ideaal. Jo hawwe applikaasjes yn fjouwer ferskillende talen konfigureare yn it databankplan op deselde manier. D'r binne gjin ferskillende konfiguraasjes mear.
Alles kin wurde konfigurearre mei help fan ENV fariabelen. As wy prate oer Kubernetes, is d'r in geweldige manier om ENV-fariabelen direkt binnen Deployment te ferklearjen. As wy it dus oer geheime gegevens hawwe, dan kinne wy geheime gegevens fan ENV-fariabelen (wachtwurden nei databases, ensfh.) fuortendaliks yn in geheim drukke, in geheime kluster meitsje en yn 'e ENV-beskriuwing yn Ynset oanjaan dat wy net direkt ferklearje de wearde fan dizze fariabele, en de wearde fan dizze databank wachtwurd fariabele wurdt lêzen út it geheim. Dit is standert Kubernetes gedrach. En dit is de meast ideale opsje om jo applikaasjes te konfigurearjen. Krekt op it koadenivo jildt dit wer foar ûntwikkelders. As jo DevOps binne, kinne jo freegje: "Jongens, lear asjebleaft jo applikaasje om omjouwingsfariabelen te lêzen. En wy sille allegear bliid wêze."
As elkenien yn it bedriuw deselde neamde omjouwingsfariabelen lêst, dan is dat geweldich. Dat it net bart dat guon op de postgres-databank wachtsje, oaren wachtsje op de databanknamme, oaren wachtsje op wat oars, oaren wachtsje op in dbn fan ien of oare soarte, sadat der sadwaande uniformiteit is.
It probleem komt as jo safolle omjouwingsfariabelen hawwe dat jo gewoan Deployment iepenje - en d'r binne fiifhûndert rigels omjouwingsfariabelen. Yn dit gefal hawwe jo gewoan omjouwingsfariabelen groeid - en jo moatte josels net langer martelje. Yn dit gefal soe it sin wêze om konfiguraasjes te begjinnen. Dat is, traine jo applikaasje om konfiguraasjes te brûken.
De ienige fraach is dat konfiguraasjes net binne wat jo tinke. Config.pi is gjin konfiguraasje dy't handich is om te brûken. Of wat konfiguraasje yn jo eigen formaat, as alternatyf bejeftige - dit is ek net de konfiguraasje dy't ik bedoel.
Wat ik it oer is konfiguraasje yn akseptabele formaten, dat is fierwei de populêrste standert de .yaml standert. It is dúdlik hoe't jo it lêze, it is lêsber foar minsken, it is dúdlik hoe't jo it lêze fan 'e applikaasje.
Dêrnjonken kinne jo, neist YAML, ek bygelyks JSON brûke, parsearjen is sawat like handich as YAML yn termen fan it lêzen fan de applikaasjekonfiguraasje fan dêrút. It is oanmerklik ûngemakliker foar minsken om te lêzen. Jo kinne besykje it formaat, a la ini. It is frij handich om te lêzen, út in minsklik eachpunt, mar it kin ûngemaklik wêze om it automatysk te ferwurkjen, yn 'e sin dat as jo oait jo eigen konfiguraasjes wolle generearje, kin it ini-formaat al ûngemaklik wêze om te generearjen.
Mar yn alle gefallen, hokker formaat jo ek kieze, it punt is dat it út Kubernetes-perspektyf heul handich is. Jo kinne jo hiele konfiguraasje yn Kubernetes pleatse, yn 'e ConfigMap. En nim dan dizze konfiguraasjemap en freegje it om yn jo pod yn in spesifike map te montearjen, wêr't jo applikaasje de konfiguraasje fan dizze konfiguraasjemap sil lêze as wie it gewoan in bestân. Dit is yn feite wat goed is om te dwaan as jo in protte konfiguraasjeopsjes hawwe yn jo applikaasje. Of it is gewoan in soarte fan komplekse struktuer, der is nêst.
As jo in configmap hawwe, dan kinne jo jo applikaasje tige goed leare, bygelyks om automatysk feroaringen te folgjen yn it bestân wêr't de configmap is monteard, en jo applikaasje ek automatysk opnij laden as de konfiguraasjes feroarje. Dit soe oer it algemien in ideale opsje wêze.
Nochris haw ik hjir al oer praat - geheime ynformaasje is net yn 'e konfiguraasjemap, geheime ynformaasje is net yn fariabelen, geheime ynformaasje is net yn geheimen. Fan dêrút ferbine dizze geheime ynformaasje mei diplomasy. Normaal bewarje wy alle beskriuwingen fan Kubernetes-objekten, ynset, konfiguraasjemappen, tsjinsten yn git. Dêrtroch is it pleatsen fan it wachtwurd yn 'e database yn git, sels as it jo git is, dy't jo yntern hawwe yn it bedriuw, in min idee. Om't, op syn minst, git alles ûnthâldt en gewoan wachtwurden derút fuortsmite is net sa maklik.
Sûnens Tsjek
It folgjende punt is dit ding neamd Health check. Yn 't algemien is in sûnenskontrôle gewoan om te kontrolearjen dat jo applikaasje wurket. Tagelyk hawwe wy it meastentiids oer bepaalde webapplikaasjes, wêrfoar't, neffens it eachpunt fan sûnenskontrôle (it is better net hjir en fierder oer te setten) dit in spesjale URL sil wêze, dy't se ferwurkje as in standert, se meastal dwaan /health.
As jo tagong krije ta dizze URL, dan seit ús applikaasje of "ja, goed, alles is goed mei my, 200" of "nee, alles is net goed mei my, sa'n 500." Dêrom, as ús applikaasje net http is, gjin webapplikaasje, prate wy no oer in soarte fan daemon, kinne wy útfine hoe't jo sûnenskontrôles kinne dwaan. Dat is, it is net nedich, as de applikaasje net http is, dan wurket alles sûnder in sûnenskontrôle en dit kin op gjin inkelde manier dien wurde. Jo kinne periodyk wat ynformaasje yn it bestân bywurkje, jo kinne in spesjale kommando foar jo daemon komme, lykas, daemon status, dy't sil sizze "ja, alles is goed, de daemon wurket, it libbet."
Wêr is it foar? It earste en meast foar de hân lizzende ding is wierskynlik wêrom in sûnenskontrôle nedich is - om te begripen dat de applikaasje wurket. Ik bedoel, it is gewoan dom, as it no op is, liket it derop dat it wurket, dus jo kinne der wis fan wêze dat it wurket. En it docht bliken dat de applikaasje rint, de kontener rint, de eksimplaar wurket, alles is goed - en dan hawwe de brûkers al alle telefoannûmers ôfsnien fan technyske stipe en sizze "wat bisto ..., do yn 'e sliep fallen, neat wurket."
In sûnenskontrôle is krekt sa'n manier om út it eachpunt fan 'e brûker te sjen dat it wurket. Ien fan 'e metoaden. Litte wy it sa sizze. Fanút it eachpunt fan Kubernetes is dit ek in manier om te begripen wannear't de applikaasje begjint, om't wy begripe dat d'r in ferskil is tusken wannear't de kontener waard lansearre, makke en begon, en wannear't de applikaasje direkt yn dizze kontener waard lansearre. Want as wy in gemiddelde java-applikaasje nimme en besykje it yn 'e dock te starten, dan kin it sawat fjirtich sekonden, of sels in minút, of sels tsien, gewoan goed begjinne. Yn dit gefal kinne jo op syn minst op syn havens klopje, it sil dêr net antwurdzje, dat is, it is noch net ree om ferkear te ûntfangen.
Nochris, mei help fan in sûnenskontrôle en mei help fan it feit dat wy hjir draaie, kinne wy yn Kubernetes begripe dat net allinich de kontener yn 'e applikaasje opstien is, mar de applikaasje sels is begon, it reagearret al op' e sûnens check, wat betsjut dat wy kinne stjoere ferkear dêr.
Wat ik no praat, hjit Readiness / Liveness tests binnen Kubernetes, dus binne ús reewilligenstests ferantwurdlik foar de beskikberens fan 'e applikaasje yn balânsjen. Dat is, as reewilligenstests wurde útfierd yn 'e applikaasje, dan is alles ok, kliïntferkear giet nei de applikaasje. As reewilligenstests net wurde útfierd, dan docht de applikaasje gewoan net mei, dit bepaalde eksimplaar docht net mei oan balânsjen, it wurdt fuortsmiten fan balânsjen, kliïntferkear streamt net. Dêrnjonken binne Liveness-tests binnen Kubernetes nedich, sadat as de applikaasje fêst sit, it kin wurde opnij starte. As de libbenstest net wurket foar in applikaasje dy't ferklearre is yn Kubernetes, dan wurdt de applikaasje net allinich fuorthelle út balansearjen, it wurdt opnij starte.
En hjir is in wichtich punt dat ik neame wol: praktysk sjoen wurdt de reewilligenstoets meast faker brûkt en is faker nedich as de libbenstoets. Dat is, gewoan gedachteleas ferklearje fan sawol reewilligens as libbenstests, om't Kubernetes dat kin dwaan, en lit ús alles brûke wat it kin dwaan, is net in heul goed idee. Ik sil útlizze wêrom. Want punt nûmer twa yn testen is dat it in goed idee wêze soe om de ûnderlizzende tsjinst te kontrolearjen yn jo sûnenskontrôles. Dit betsjut dat as jo in webapplikaasje hawwe dy't wat ynformaasje jout, dy't it op syn beurt, fansels, earne wei moat nimme. Yn in databank, bygelyks. No, it bewarret de ynformaasje dy't yn dizze REST API komt yn deselde database. Dan, neffens, as jo sûnenscheck gewoan antwurdet lykas kontakt mei slashhealth, seit de applikaasje "200, goed, alles is goed," en tagelyk is de databank fan jo applikaasje net tagonklik, en de sûnenscheck-applikaasje seit "200, goed, alles is goed. ” - Dit is in minne sûnenskontrôle. Dit is net hoe't it moat wurkje.
Dat is, jo oanfraach, as der in fersyk op komt /health, it reagearret net allinich, "200, ok", it giet earst bygelyks nei de databank, besiket dêr ferbining mei te meitsjen, docht dêr wat hiel basis, lykas selektearje ien, kontrolearret gewoan dat der in ferbining is yn 'e databank en jo kinne de databank opfreegje. As dit alles suksesfol wie, dan is it antwurd "200, ok." As it net slagget, seit it dat der in flater is, de databank is net beskikber.
Dêrom kom ik yn dit ferbân nochris werom nei de Readiness/Liveness-tests - wêrom't jo nei alle gedachten in reewilligenstest nedich binne, mar in libbenstest is yn fraach. Want as jo sûnenskontrôles krekt beskriuwe lykas ik krekt sei, dan sil bliken dien dat it net beskikber is yn it eksimplaar dielв или со всех instanceyn in databank, bygelyks. Doe't jo in test foar reewilligens ferklearre, begon ús sûnenskontrôles te mislearjen, en sadwaande wurde alle applikaasjes wêrfan de databank net tagonklik is, se gewoan útskeakele fan balâns en yn feite "hingje" gewoan yn in ferwaarleazge steat en wachtsje op har databases om wurk.
As wy in libbenstest hawwe ferklearre, stel jo dan foar, ús databank is brutsen, en yn jo Kubernetes begjint de helte fan alles opnij te begjinnen, om't de libbenstest mislearret. Dit betsjut dat jo opnij begjinne moatte. Dit is hielendal net wat jo wolle, ik hie sels persoanlike ûnderfining yn 'e praktyk. Wy hienen in petearapplikaasje dy't yn JS waard skreaun en yn in Mongo-database fied. En it probleem wie dat it wie oan it begjin fan myn wurk mei Kubernetes, wy beskreau de reewilligens, liveness fan testen op it prinsipe dat Kubernetes kin dwaan, dus wy sille brûke it. Dêrtroch waard Mongo op in stuit in bytsje "saai" en begon de stekproef te mislearjen. Dêrtroch, neffens de reintest, begûnen de pods te "deadzjen".
As jo begripe, as se "fermoarde" binne, is dit in petear, dat is, d'r hingje in protte ferbiningen fan kliïnten oan. Se wurde ek "fermoarde" - nee, gjin kliïnten, allinich ferbiningen - net allegear tagelyk, en troch it feit dat se net tagelyk wurde fermoarde, guon earder, guon letter, begjinne se net tagelyk tiid. Plus standert willekeurich, wy kinne net foarsizze mei millisekonden krektens de starttiid fan de applikaasje eltse kear, sadat se dogge it ien eksimplaar op in tiid. Ien infospot komt oerein, wurdt tafoege oan it balâns, alle kliïnten komme der, it kin sa'n lêst net ferneare, want it is allinne, en, rûchwei, der wurkje in tsiental fan harren, en it falt. De folgjende komt oerein, de hiele fracht is op him, hy falt ek. No, dizze wetterfallen bliuwe gewoan trochrinne. Uteinlik, hoe't dit waard oplost - wy moasten gewoan brûkersferkear nei dizze applikaasje strikt stopje, alle eksimplaren litte opstean en dan alle brûkersferkear yn ien kear begjinne, sadat it al ferdield wie oer alle tsien eksimplaren.
As it net wie foar dizze libbenstest dy't oankundige waard, wat it allegear soe twinge om opnij te begjinnen, soe de applikaasje it krekt goed hawwe behannele. Mar alles fan balânsjen is foar ús útskeakele, om't de databases net tagonklik binne en alle brûkers binne "ôffallen". Dan, as dizze databank beskikber wurdt, is alles opnommen yn balânsjen, mar applikaasjes hoege net opnij te begjinnen, en d'r is gjin need om tiid en middels te fergrieme. Se binne hjir allegear al, se binne klear foar ferkear, dus it ferkear iepenet gewoan, alles is goed - de applikaasje is yn plak, alles bliuwt wurkje.
Dêrom, reewilligens en liveness tests binne oars, sels boppedat kinne jo teoretysk dwaan ferskillende sûnens kontrôles, ien type radii, ien type liv, bygelyks, en kontrolearje ferskate dingen. Kontrolearje jo backends tidens reeheidstests. En op in liveness-test, bygelyks, kontrolearje jo net út it eachpunt dat de liveness-test oer it algemien gewoan in applikaasje is dy't reagearret, as it überhaupt reagearje kin.
Om't de libbenstest, yn 't algemien, is as wy "fêst sitte." In einleaze loop is begûn of wat oars - en gjin oanfragen mear wurde ferwurke. Dêrom is it logysk om se sels te skieden - en ferskate logika yn te ymplementearjen.
Oangeande wat jo moatte antwurdzje as jo in test hawwe, as jo sûnenskontrôles dogge. It is gewoan in pine. Dejingen dy't dit bekend binne, sille wierskynlik laitsje - mar serieus haw ik tsjinsten yn myn libben sjoen dy't yn 200% fan 'e gefallen "XNUMX" antwurdzje. Dat is, wa is suksesfol. Mar tagelyk skriuwe se yn it lichem fan 'e reaksje "sa en sa'n flater."
Dat is, de reaksjestatus komt nei jo - alles is suksesfol. Mar tagelyk moatte jo it lichem analysearje, om't it lichem seit "sorry, it fersyk einige mei in flater" en dit is gewoan realiteit. Ik seach dit yn it echte libben.
En sadat guon minsken it net grappich fine, en oaren it tige pynlik fine, is it noch altyd wurdich om oan in ienfâldige regel te hâlden. Yn sûnenskontrôles, en yn prinsipe by it wurkjen mei webapplikaasjes.
As alles goed gie, reagearje dan mei it twahûndertste antwurd. Yn prinsipe sil elk twahûndertste antwurd by jo passe. As jo lêze ragsy hiel goed en witte dat guon antwurd statusen binne oars as oaren, antwurdzje mei de passende: 204, 5, 10, 15, wat dan ek. As it net heul goed is, dan gewoan "twa nul nul." As alles ferkeard giet en de sûnenskontrôle net reagearret, antwurdzje dan mei elk fiifhûndertste. Nochris, as jo begripe hoe't jo moatte reagearje, hoe't ferskillende antwurdstatusen fan elkoar ferskille. As jo it net begripe, dan is 502 jo opsje om te reagearjen op sûnenskontrôles as der wat mis giet.
Dit is in oar punt, ik wol in bytsje weromkomme oer it kontrolearjen fan de ûnderlizzende tsjinsten. As jo bygelyks begjinne te kontrolearjen fan alle ûnderlizzende tsjinsten dy't efter jo applikaasje steane - alles yn 't algemien. Wat wy krije út it eachpunt fan microservice arsjitektuer, wy hawwe sa'n konsept as "lege coupling" - dat is, as jo tsjinsten binne minimaal ôfhinklik fan elkoar. As ien fan har mislearret, sille alle oaren sûnder dizze funksjonaliteit gewoan trochgean te wurkjen. Guon fan 'e funksjonaliteit wurket gewoan net. As jo dus alle sûnenskontrôles oan elkoar bine, dan sille jo einigje dat ien ding yn 'e ynfrastruktuer falt, en om't it foel, begjinne alle sûnenskontrôles fan alle tsjinsten ek te mislearjen - en d'r is mear ynfrastruktuer yn 't algemien foar de hiele microservice-arsjitektuer No. Alles gyng dêr tsjuster.
Dêrom wol ik dit nochris werhelje dat jo de ûnderlizzende tsjinsten moatte kontrolearje, dejingen sûnder dat jo applikaasje yn hûndert prosint fan 'e gefallen har wurk net kin dwaan. Dat is, it is logysk dat as jo in REST API hawwe wêrmei't de brûker yn 'e databank bewarret of ophelje út' e databank, dan by it ûntbrekken fan in databank kinne jo wurk mei jo brûkers net garandearje.
Mar as jo brûkers, as jo se út 'e databank nimme, ekstra ferrike wurde mei wat oare metadata, fan in oare backend, dy't jo ynfiere foardat jo in antwurd ferstjoere nei it frontend - en dizze backend is net beskikber, betsjut dit dat jo jo jo jouwe antwurdzje sûnder in diel fan 'e metadata.
Dêrnei hawwe wy ek ien fan 'e pynlike problemen by it starten fan applikaasjes.
Yn feite, dit jildt net allinnich foar Kubernetes troch en it krekt sa barde dat de kultuer fan in soarte fan massa ûntwikkeling en DevOps yn it bysûnder begûn te fersprieden om deselde tiid as Kubernetes. Dêrom, yn 't algemien, docht bliken dat jo jo applikaasje graceful moatte ôfslute sûnder Kubernetes. Noch foar Kubernetes diene minsken dit, mar mei de komst fan Kubernetes begûnen wy der massaal oer te praten.
Graceful Shutdown
Yn 't algemien, wat is Graceful Shutdown en wêrom is it nedich? Dit is oer wannear't jo applikaasje om ien of oare reden crasht, moatte jo dwaan app stop - of jo ûntfange bygelyks in sinjaal fan it bestjoeringssysteem, jo applikaasje moat it begripe en der wat oan dwaan. It slimste senario is fansels as jo applikaasje in SIGTERM ûntfangt en is lykas "SIGTERM, lit ús hingje, wurkje, neat dwaan." Dit is in regelmjittich minne opsje.
In hast like minne opsje is as jo applikaasje in SIGTERM ûntfangt en is lykas "se seine segterm, dat betsjut dat wy einigje, ik haw net sjoen, ik wit gjin brûkersoanfragen, ik wit net wat foar oanfragen dêr't ik op it stuit oan wurkje, seine se SIGTERM, dat betsjut dat wy einigje " Dit is ek in minne opsje.
Hokker opsje is goed? It earste punt is om rekken te hâlden mei it foltôgjen fan operaasjes. In goede opsje is dat jo tsjinner noch rekken hâldt mei wat it docht as it in SIGTERM ûntfangt.
SIGTERM is in sêfte shutdown, it is spesjaal ûntworpen, it kin wurde ûnderskept op it koadenivo, it kin wurde ferwurke, sis dat no, wachtsje, wy sille earst it wurk dat wy hawwe ôfmeitsje, dan sille wy útgean.
Ut in Kubernetes perspektyf, dit is hoe't it liket. As wy sizze tsjin in pod dy't rint yn it Kubernetes-kluster, "stopje asjebleaft, gean fuort," of wy wurde opnij starte, of der komt in update as Kubernetes de pods opnij oanmakket, stjoert Kubernetes krekt itselde SIGTERM-berjocht nei de pod, wachtet op wat tiid, en , dit is de tiid dat er wachtet, it is ek ynsteld, der is sa'n spesjale parameter yn diploma's en it hjit Graceful ShutdownTimeout. Sa't jo begripe, wurdt it net foar neat neamd, en it is net foar neat dat wy it no oer hawwe.
Dêr kinne wy spesifyk sizze hoe lang wy moatte wachtsje tusken de tiid dat wy SIGTERM nei de applikaasje stjoere en wannear't wy begripe dat de applikaasje liket te wêzen gek wurden foar wat of "plakt" is en net sil einigje - en wy moatte stjoer it SIGKILL, dat is, hurd foltôgje syn wurk. Dat is, neffens, hawwe wy in soarte fan daemon dy't rint, it ferwurket operaasjes. Wy begripe dat yn trochsneed ús operaasjes wêrop de daemon wurket net mear as 30 sekonden tagelyk duorje. Dêrom, as SIGTERM oankomt, begripe wy dat ús daemon op syn heechst 30 sekonden nei SIGTERM kin einigje. Wy skriuwe it, bygelyks, 45 sekonden krekt yn gefal en sizze dat SIGTERM. Dêrnei wachtsje wy 45 sekonden. Yn teory soe de demon yn dizze tiid syn wurk moatte foltôgje en himsels einigje. Mar as it ynienen net koe, betsjut it dat it nei alle gedachten fêst sit - it ferwurket ús oanfragen net mear normaal. En yn 45 sekonden kinne jo him feilich spikere.
En hjir kinne yn feite sels 2 aspekten yn rekken brocht wurde. Begryp earst dat as jo in fersyk krigen hawwe, jo op ien of oare manier begon te wurkjen en jo hawwe gjin antwurd jûn oan 'e brûker, mar jo hawwe bygelyks SIGTERM krigen. It makket sin om it te ferfine en in antwurd te jaan oan de brûker. Dit is punt nûmer ien yn dit ferbân. Punt nûmer twa hjir is dat as jo jo eigen applikaasje skriuwe, de arsjitektuer yn 't algemien op sa'n manier bouwe dat jo in fersyk foar jo applikaasje krije, dan begjinne jo wat wurk, begjinne jo bestannen fan earne te downloaden, in databank te downloaden, en wat noch - Dat. Yn 't algemien, jo brûker, jo fersyk hinget foar in heal oere en wachtet foar jo om him te beantwurdzjen - dan, nei alle gedachten, moatte jo wurkje oan' e arsjitektuer. Dat is, nim mar rekken mei sels sûn ferstân dat as jo operaasjes koart binne, dan makket it sin om SIGTERM te negearjen en it te feroarjen. As jo operaasjes lang binne, dan makket it gjin sin om SIGTERM yn dit gefal te negearjen. It makket sin om de arsjitektuer opnij te ûntwerpen om sokke lange operaasjes te foarkommen. Sadat brûkers net gewoan hingje en wachtsje. Ik wit it net, meitsje dêr in soarte fan websocket, meitsje omkearde haken dy't jo tsjinner al nei de klant stjoert, wat oars, mar twinge de brûker net in healoere te hingjen en wachtsje gewoan op in sesje oant jo antwurdzje him. Om't it ûnfoarspelber is wêr't it brekke kin.
As jo applikaasje beëiniget, moatte jo wat passende útgongskoade leverje. Dat is, as jo applikaasje waard frege om te sluten, stopje, en it koe himsels normaal stopje, dan hoege jo net in soarte fan útgongskoade 1,5,255 ensafuorthinne werom te jaan. Alles dat net nul koade is, teminsten yn Linux-systemen, ik bin der wis fan, wurdt beskôge as mislearre. Dat is, it wurdt beskôge dat jo applikaasje yn dit gefal einige mei in flater. As jo applikaasje foltôge is sûnder in flater, sizze jo op in freonlike manier 0 op 'e útfier. As jo applikaasje om ien of oare reden mislearret, sizze jo net-0 yn 'e útfier. En jo kinne wurkje mei dizze ynformaasje.
En de lêste opsje. It is slim as jo brûker in fersyk stjoert en in healoere hinget wylst jo it ferwurkje. Mar yn it algemien wol ik ek sizze oer wat it oer it algemien wurdich is fan 'e kant fan 'e kliïnt. It makket net út as jo in mobile applikaasje, front-end, ensfh. It is needsaaklik om te rekkenjen dat yn 't algemien de sesje fan' e brûker kin wurde beëinige, alles kin barre. In fersyk kin stjoerd wurde, bygelyks, underferwurke en gjin antwurd werom. Jo frontend as jo mobile applikaasje - elke frontend yn 't algemien, litte wy it sa sizze - moatte dit yn rekken hâlde. As jo wurkje mei websockets, dit is oer it algemien de slimste pine Ik haw ea hie.
As de ûntwikkelders fan guon gewoane petearen dat net witte, docht bliken dat de websocket brekke kin. Foar harren, as der wat bart by de proxy, feroarje wy gewoan de konfiguraasje, en it docht in opnij laden. Fansels, yn dit gefal binne alle lange-libben sesjes skuord. Untwikkelders komme nei ús ta rinnen en sizze: "Jongens, wat dogge jim, it petear is ferbrutsen foar al ús kliïnten!" Wy sizze tsjin harren: "Wat dogge jo? Binne jo kliïnten net yn steat om opnij te ferbinen? Se sizze: "Nee, wy moatte de sesjes net ferskuord wurde." Koartsein, dit is eins ûnsin. Der moat rekken hâlden wurde mei de klantkant. Benammen, sa't ik sis, mei lange libbene sesjes lykas websockets, kin it brekke en, ûngemurken troch de brûker, moatte jo sokke sesjes opnij kinne ynstallearje. En dan is alles perfekt.
Resources
Eins, hjir sil ik jo gewoan in rjocht ferhaal fertelle. Wer út it echte libben. It siikste dat ik ea heard haw oer boarnen.
Boarnen yn dit gefal, ik bedoel, in soarte fan oanfragen, limiten dy't jo kinne pleatse op pods yn jo Kubernetes-klusters. It grappichste dat ik hearde fan in ûntwikkelder ... Ien fan myn kollega-ûntwikkelders op in earder wurkplak sei ienris: "Myn applikaasje sil net begjinne yn it kluster." Ik seach om te sjen dat it net begon, mar of it paste net yn 'e middels, of se hienen heul lytse grinzen ynsteld. Koartsein, de applikaasje kin net begjinne fanwege middels. Ik sis: "It sil net begjinne fanwege middels, jo beslute hoefolle jo nedich binne en set in adekwate wearde yn." Hy seit: "Wat foar boarnen?" Ik begûn út te lizzen oan him dat Kubernetes, grinzen op fersiken en blah, blah, blah moatte wurde ynsteld. De man harke fiif minuten, knikte en sei: "Ik bin hjir kommen om te wurkjen as ûntwikkelder, ik wol neat witte oer alle boarnen. Ik kaam hjir om koade te skriuwen en dat is it." It is tryst. Dit is in heul tryst konsept út it eachpunt fan in ûntwikkelder. Benammen yn 'e moderne wrâld, om sa te sizzen, fan progressive devops.
Wêrom binne middels hielendal nedich? D'r binne 2 soarten boarnen yn Kubernetes. Guon wurde neamd fersiken, oaren wurde neamd grinzen. Troch middels sille wy begripe dat d'r yn prinsipe altyd mar twa basisbeperkingen binne. Dat is, CPU tiid grinzen en RAM grinzen foar in kontener rint yn Kubernetes.
In limyt pleatst in boppegrins op hoe't in boarne brûkt wurde kin yn jo applikaasje. Dat is dus, as jo sizze 1GB RAM yn 'e grinzen, dan sil jo applikaasje net mear kinne brûke as 1GB RAM. En as hy dit ynienen wol en besiket te dwaan, dan sil in proses neamd oom killer, út it ûnthâld, dat is, komme en jo applikaasje deadzje - dat is, it sil gewoan opnij starte. Applikaasjes sille net opnij starte basearre op CPU. Yn termen fan CPU, as in applikaasje besiket in protte te brûken, mear dan spesifisearre yn 'e grinzen, sil de CPU gewoan strikt selektearre wurde. Dit liedt net ta opstarten. Dit is de limyt - dit is de boppegrins.
En der is in fersyk. In fersyk is hoe't Kubernetes begrypt hoe't de knopen yn jo Kubernetes-kluster befolke binne mei applikaasjes. Dat is, in fersyk is in soarte fan commit fan jo oanfraach. It seit wat ik brûke wol: "Ik soe graach wolle dat jo safolle CPU en safolle ûnthâld foar my reservearje." Sa'n ienfâldige analogy. Wat as wy hawwe in knooppunt dat hat, ik wit it net, 8 CPUs yn totaal. En dêr komt in pod oan, waans fersiken sizze 1 CPU, wat betsjut dat it knooppunt noch 7 CPU's hat. Dat is, dus, sa gau as 8 pods oankomme by dizze knooppunt, dy't elk 1 CPU yn har oanfragen hat, de knoop, as soe út it eachpunt fan Kubernetes, út CPU rinne en mear pods mei oanfragen kinne net wurde lansearre op dit knooppunt. As alle knooppunten út CPU rinne, dan sil Kubernetes begjinne te sizzen dat d'r gjin geskikte knooppunten binne yn it kluster om jo pods út te fieren, om't de CPU út is.
Wêrom binne oanfragen nedich en wêrom sûnder oanfragen, tink ik dat d'r gjin ferlet is om wat te starten yn Kubernetes? Litte wy ús in hypotetyske situaasje foarstelle. Jo starte jo applikaasje sûnder oanfragen, Kubernetes wit net hoefolle fan wat jo hawwe, nei hokker knopen jo it kinne triuwe. No, hy triuwt, skowt, skodt op 'e knopen. Op in stuit sille jo ferkear begjinne te krijen nei jo applikaasje. En ien fan 'e applikaasjes begjint ynienen boarnen te brûken oant de grinzen dy't it hat neffens de grinzen. It docht bliken dat d'r in oare applikaasje yn 'e buert is en dy hat ek boarnen nedich. It knooppunt eins begjint te fysyk rinne út middels, Bygelyks, OP. It knooppunt eins begjint te fysyk rinne út middels, Bygelyks, willekeurich tagong ûnthâld (RAM). As in knooppunt sûnder macht rint, sil de docker earst ophâlde te reagearjen, dan de kubelet, dan it OS. Se sille gewoan bewusteloos gean en ALLES sil perfoarst ophâlde te wurkjen foar jo. Dat is, dit sil liede ta jo knooppunt fêst te sitten en jo moatte it opnij starte. Koartsein, de situaasje is net hiel goed.
En as jo oanfragen hawwe, binne de grinzen net heul oars, teminsten net folle mear as de grinzen of oanfragen, dan kinne jo sa'n normale, rasjonele ynfolling fan applikaasjes hawwe oer knooppunten fan Kubernetes-klusters. Tagelyk is Kubernetes sawat bewust fan hoefolle fan wat it wêr pleatst, hoefolle fan wat wêr brûkt wurdt. Dat is, it is krekt sa'n momint. It is wichtich om it te begripen. En it is wichtich om te kontrolearjen dat dit wurdt oanjûn.
Data opslach
Us folgjende punt giet oer gegevensopslach. Wat te dwaan mei harren en yn it algemien, wat te dwaan mei persistinsje yn Kubernetes?
Ik tink, wer, binnen ús , der wie in ûnderwerp oer de databank yn Kubernetes. En it liket my ta dat ik sels rûchwei wit wat jo kollega's jo fertelden doe't se frege waarden: "Is it mooglik om in database yn Kubernetes út te fieren?" Om ien of oare reden liket it my dat jo kollega's jo moatte fertelle dat as jo de fraach stelle oft it mooglik is om in databank yn Kubernetes út te fieren, dan is it ûnmooglik.
De logika hjir is ienfâldich. Foar it gefal, ik sil nochris útlizze, as jo in heul coole keardel binne dy't in frij fouttolerant systeem kinne bouwe fan ferdielde netwurkopslach, begryp dan hoe't jo in databank yn dizze saak kinne passe, hoe't cloud native yn konteners moatte wurkje yn in databank yn it algemien. Meast wierskynlik hawwe jo gjin fraach oer hoe't jo it útfiere. As jo sa'n fraach, en jo wolle der wis fan dat it allegear unfolds en stiet rjocht ta dea yn produksje en nea falt, dan dit bart net. Jo wurde garandearre om josels yn 'e foet te sjitten mei dizze oanpak. Dus it is better net te dwaan.
Wat moatte wy dwaan mei de gegevens dy't ús applikaasje wol opslaan, guon foto's dy't brûkers uploade, guon dingen dy't ús applikaasje genereart tidens de operaasje, bygelyks by it opstarten? Wat te dwaan mei harren yn Kubernetes?
Yn 't algemien, by útstek, ja, fansels, Kubernetes is heul goed ûntworpen en waard oer it algemien yn earste ynstânsje betocht foar steatleaze applikaasjes. Dat is, foar dy applikaasjes dy't hielendal gjin ynformaasje opslaan. Dit is ideaal.
Mar, fansels, de ideale opsje bestiet net altyd. No en? De earste en simpelste punt is in nimme in soarte fan S3, krekt net in selsmakke, dat is ek ûndúdlik hoe't it wurket, mar fan guon provider. In goede, normale provider - en lear jo applikaasje S3 te brûken. Dat is, as jo brûker in bestân wol uploade, sis dan "hjir, asjebleaft, upload it nei S3." As hy it wol ûntfange, sis dan: "Hjir is in keppeling nei S3 werom en nim it hjirwei." Dit is ideaal.
As dizze ideale opsje om ien of oare reden ynienen net geskikt is, jo hawwe in applikaasje dy't jo net skreaun hawwe, jo net ûntwikkelje, of it is in soarte fan skriklike legacy, it kin it S3-protokol net brûke, mar moat wurkje mei lokale mappen yn lokale mappen. Nim wat mear of minder ienfâldich, ynsette Kubernetes. Dat is, Ceph fuortendaliks foar guon minimale taken, liket my, is in min idee. Want Ceph is fansels goed en modieus. Mar as jo net echt begripe wat jo dogge, dan as jo ienris wat op Ceph sette, kinne jo it der hiel maklik en gewoan noait wer út krije. Want, lykas jo witte, bewarret Ceph gegevens yn syn kluster yn binêre foarm, en net yn 'e foarm fan ienfâldige bestannen. Dêrom, as ynienen it Ceph-kluster brekt, dan is d'r in folsleine en hege kâns dat jo jo gegevens dêr noait wer krije.
Wy sille hawwe in kursus op Ceph, do kinst .
Dêrom is it better om wat ienfâldich te dwaan as in NFS-tsjinner. Kubernetes kin mei har wurkje, jo kinne in map montearje ûnder in NFS-tsjinner - jo applikaasje is krekt as in lokale map. Tagelyk moatte jo fansels begripe dat jo wer wat moatte dwaan mei jo NFS, jo moatte begripe dat it soms ûnberikber kin wurde en beskôgje de fraach fan wat jo sille dwaan yn dit gefal. Miskien moat it earne in reservekopy makke wurde op in aparte masine.
It folgjende punt dêr't ik oer praat is wat te dwaan as jo applikaasje guon bestannen genereart tidens operaasje. Bygelyks, as it begjint, genereart it wat statysk bestân, dat is basearre op guon ynformaasje dy't de applikaasje allinich ûntfangt op it momint fan lansearring. Wat in momint. As d'r net folle fan sokke gegevens is, dan hoege jo hielendal gjin lêst, gewoan dizze applikaasje foar josels ynstallearje en wurkje. De ienige fraach hjir is wat, sjoch. Hiel faak, allerhanne legacy systemen, lykas WordPress ensafuorthinne, benammen mei wizige wat soarte fan tûke plugins, tûke PHP-ûntwikkelders, se faak witte hoe te meitsje it sa dat se generearje in soarte fan triem foar harsels. Dêrtroch genereart men ien bestân, de twadde genereart in twadde bestân. Se binne oars. Balansearring bart yn 'e Kubernetes-kluster fan kliïnten gewoan troch tafal. Dêrtroch docht bliken dat se bygelyks net witte hoe't se gearwurkje moatte. De iene jout ien ynformaasje, de oare jout de brûker in oare ynformaasje. Dit is wat jo moatte foarkomme. Dat is, yn Kubernetes is alles wat jo lansearje garandearre om yn meardere eksimplaren te wurkjen. Om't Kubernetes in bewegend ding is. Dêrtroch kin er alles ferpleatse, wannear er wol, sûnder immen te freegjen. Dêrom moatte jo hjir op rekkenje. Alles dat yn ien eksimplaar is lansearre sil ier of let mislearje. Hoe mear reservearrings jo hawwe, hoe better. Mar wer, sis ik, as jo in pear fan sokke triemmen hawwe, dan kinne jo se krekt ûnder jo sette, se weagje in lyts bedrach. As d'r in bytsje mear fan binne, moatte jo se wierskynlik net yn 'e kontener triuwe.
Ik soe advisearje dat d'r sa'n prachtich ding is yn Kubernetes, jo kinne folume brûke. Benammen is der in folume fan type lege dir. Dat is, it is gewoan dat Kubernetes automatysk in map sil oanmeitsje yn har tsjinstmappen op 'e server wêr't jo begon binne. En hy sil it jo jaan, sadat jo it brûke kinne. Der is mar ien wichtich punt. Dat is, jo gegevens wurde net opslein yn 'e kontener, mar op' e host wêrop jo rinne. Boppedat kin Kubernetes sokke lege dirs kontrolearje ûnder normale konfiguraasje en is by steat om har maksimale grutte te kontrolearjen en net tastean dat it wurdt oerbrocht. It ienige punt is dat wat jo hawwe skreaun yn lege dir is net ferlern by pod opnij starte. Dat is, as jo pod by fersin falt en wer omheech komt, sil de ynformaasje yn 'e lege dir nergens hinne gean. Hy kin it wer brûke by in nij begjin - en dat is goed. As jo pod earne fuortgiet, dan sil hy fansels sûnder gegevens ferlitte. Dat is, sa gau as de pod fan 'e knooppunt wêr't it waard lansearre mei lege dir ferdwynt, wurdt lege dir wiske.
Wat oars is goed oer lege dir? It kin bygelyks brûkt wurde as cache. Litte wy ús foarstelle dat ús applikaasje wat op 'e flecht genereart, it oan brûkers jout en it foar in lange tiid docht. Dêrom, de applikaasje, bygelyks, genereart en jout it oan brûkers, en tagelyk bewarret it earne, sadat de folgjende kear de brûker komt foar itselde ding, it sil flugger te jaan it fuortendaliks generearre. Lege dir kin oan Kubernetes frege wurde om yn it ûnthâld te meitsjen. En sadwaande kinne jo caches oer it algemien mei bliksemsnelheid wurkje - yn termen fan skiiftagongssnelheid. Dat is, jo hawwe in lege dir yn it ûnthâld, yn it OS is it opslein yn it ûnthâld, mar foar jo, foar de brûker yn 'e pod, liket it gewoan in lokale map. Jo hawwe de app net nedich om spesifyk magy te learen. Jo nimme en pleats jo bestân gewoan direkt yn in map, mar, yn feite, yn it ûnthâld op it OS. Dit is ek in heul handige funksje yn termen fan Kubernetes.
Hokker problemen hat Minio? It wichtichste probleem mei Minio is dat om dit ding te wurkjen, it moat earne rinne, en d'r moat in soarte fan bestânsysteem wêze, dat is opslach. En hjir tsjinkomme wy deselde problemen dy't Ceph hat. Dat is, Minio moat har bestannen earne opslaan. It is gewoan in HTTP-ynterface foar jo bestannen. Boppedat is de funksjonaliteit dúdlik earmer as dy fan Amazon's S3. Earder koe it de brûker net goed autorisearje. No kin it, foar safier't ik wit, al bakken meitsje mei ferskillende autorisaasjes, mar wer liket it my ta dat it haadprobleem om sa te sizzen it ûnderlizzende opslachsysteem op syn minst is.
Hoe beynfloedet Empty dir yn it ûnthâld de grinzen? Hat gjin ynfloed op grinzen op ien of oare manier. It leit yn it ûnthâld fan de host, en net yn it ûnthâld fan jo kontener. Dat is, jo kontener sjocht de lege dir yn it ûnthâld net as in part fan syn besette ûnthâld. De gasthear sjocht dit. Dêrom, ja, út it eachpunt fan kubernetes, as jo begjinne te brûken dit, it soe wêze goed om te begripen dat jo besteegje in part fan jo ûnthâld oan lege dir. En dêrmei, begripe dat ûnthâld kin rinne út net allinnich fanwege applikaasjes, mar ek omdat immen skriuwt nei dizze lege dirs.
Wolkenberens
En it lêste subûnderwerp is wat Cloudnative is. Wêrom is it nedich? Wolkenberens ensafuorthinne.
Dat is, dy applikaasjes dy't by steat en skreaun binne om te wurkjen yn in moderne wolk ynfrastruktuer. Mar feitlik hat Cloudnative in oar sa'n aspekt. Dat dit is net allinnich in applikaasje dy't rekken hâldt mei alle easken fan in moderne wolk ynfrastruktuer, mar ek wit hoe te wurkjen mei dizze moderne wolk ynfrastruktuer, profitearje fan de foardielen en neidielen fan it feit dat it wurket yn dizze wolken. Gean net gewoan oerboard en wurkje yn 'e wolken, mar profitearje fan' e foardielen fan wurkjen yn 'e wolk.
Lit ús Kubernetes gewoan as foarbyld nimme. Jo applikaasje rint yn Kubernetes. Jo applikaasje kin altyd, of leaver de admins foar jo applikaasje, altyd in tsjinstaccount oanmeitsje. Dat is, in akkount foar autorisaasje yn Kubernetes sels yn har server. Foegje wat rjochten ta dy't wy dêr nedich hawwe. En jo kinne tagong krije ta Kubernetes fanút jo applikaasje. Wat kinne jo op dizze manier dwaan? Bygelyks, fan 'e applikaasje, ûntfange gegevens oer wêr't jo oare applikaasjes, oare ferlykbere eksimplaren lizze, en tegearre op ien of oare manier klusterje boppe op Kubernetes, as d'r sa'n need is.
Nochris, wy hienen letterlik in saak koartlyn. Wy hawwe ien controller dy't kontrolearret de wachtrige. En as guon nije taken yn dizze wachtrige ferskine, giet it nei Kubernetes - en binnen Kubernetes makket it in nije pod. Jout dizze pod wat nije taak en yn it ramt fan dizze pod fiert de pod de taak, stjoert in antwurd nei de controller sels, en de controller docht dan wat mei dizze ynformaasje. Bygelyks, it foeget in databank ta. Dat is, wer, dit is in plus fan it feit dat ús applikaasje rint yn Kubernetes. Wy kinne de ynboude Kubernetes-funksjonaliteit sels brûke om de funksjonaliteit fan ús applikaasje op ien of oare manier út te wreidzjen en te meitsjen handiger. Dat is, ferbergje gjin soarte fan magy oer hoe't jo in applikaasje kinne starte, hoe't jo in arbeider starte. Yn Kubernetes stjoere jo gewoan in fersyk yn 'e app as de applikaasje yn Python skreaun is.
Itselde jildt as wy fierder gean as Kubernetes. Wy hawwe ús Kubernetes earne rinnen - it is goed as it yn in soarte fan wolk is. Nochris kinne wy brûke, en sels moatte, leau ik, de mooglikheden fan 'e wolk sels brûke wêr't wy rinne. Fan 'e elemintêre dingen dy't de wolk ús leveret. Balansearjen, dat is, wy kinne wolkbalansers meitsje en se brûke. Dit is in direkte foardiel fan wat wy kinne brûke. Om't wolkbalansearring, yn it foarste plak, gewoan dom ferantwurding fan ús ferwiderje foar hoe't it wurket, hoe't it is konfigureare. Plus it is heul handich, om't gewoane Kubernetes kinne yntegrearje mei wolken.
Itselde jildt foar skaalfergrutting. Reguliere Kubernetes kinne yntegrearje mei wolkproviders. Wit hoe te begripen dat as it kluster út knopen rint, dat is, de noderomte is oprûn, dan moatte jo tafoegje - Kubernetes sels sil nije knopen tafoegje oan jo kluster en begjinne pods op har te lansearjen. Dat is, as jo lading komt, begjint it oantal hurden te ferheegjen. As de knooppunten yn it kluster op binne foar dizze pods, lanseart Kubernetes nije knopen en kin it oantal pods noch tanimme. En it is hiel handich. Dit is in direkte kâns om it kluster op 'e flecht te skaaljen. Net heul fluch, yn 't sin dat it gjin twadde is, it is mear as in minút om nije knopen ta te foegjen.
Mar út myn ûnderfining, wer, it is de coolste ding ik haw ea sjoen. Doe't de Cloudnative kluster skalearre basearre op tiid fan de dei. It wie in backend tsjinst dy't brûkt waard troch minsken yn 'e back office. Dat is, se komme om 9 oere oan it wurk, begjinne te loggen yn it systeem, en dêrtroch begjint it Cloudnative-kluster, wêr't it allegear rint, te swollen, nije pods lansearje sadat elkenien dy't oan it wurk komt kin mei de applikaasje wurkje. As se om 8 of 6 oere út it wurk gean, fernimme de Kubernetes-klusters dat nimmen de applikaasje mear brûkt en begjinne te krimp. Besparrings fan oant 30 prosint wurde garandearre. It wurke yn Amazon yn dy tiid wie der gjinien yn Ruslân dy't it sa goed koe.
Ik sil jo direkt sizze, de besparring is 30 prosint gewoan om't wy Kubernetes brûke en profitearje fan 'e mooglikheden fan' e wolk. No kin dit dien wurde yn Ruslân. Ik sil net advertearje oan gjinien, fansels, mar lit ús mar sizze dat der oanbieders dy't kinne dwaan dit, foarsjen it rjocht út 'e doaze mei in knop.
Der is noch ien lêste punt dêr't ik ek graach jo oandacht op freegje wolle. Om foar jo applikaasje, jo ynfrastruktuer te wêzen Cloudnative, is it logysk om einlings te begjinnen mei it oanpassen fan de oanpak neamd Ynfrastruktuer as in koade applikaasje, jo saaklike logika yn 'e foarm fan koade. En wurkje dermei as koade, dat is, test it, rôlje it út, bewarje it yn git, tapasse CICD derop.
En dit is krekt wêrmei jo, yn it foarste plak, altyd kontrôle hawwe oer jo ynfrastruktuer, om altyd te begripen yn hokker steat it is. Twads, foarkom hânmjittige operaasjes dy't flaters feroarsaakje. Tredde, foarkomme gewoan wat omset hjit, as jo konstant deselde hânmjittige taken moatte útfiere. Fjirde kinne jo folle flugger herstelle yn gefal fan in mislearring. Yn Ruslân, elke kear as ik hjir oer praat, binne d'r altyd in grut oantal minsken dy't sizze: "Ja, it is dúdlik, mar jo hawwe oanpak, koartsein, d'r is net nedich om neat te reparearjen." Mar it is wier. As der wat is brutsen yn jo ynfrastruktuer, dan út it eachpunt fan 'e Cloudnative-oanpak en út it eachpunt fan Infrastructure as in Code, yn stee fan it reparearjen, nei de server te gean, út te finen wat der brutsen is en it reparearje, is it makliker om de tsjinner te wiskjen en opnij oan te meitsjen. En ik sil dit alles weromsette.
Al dizze saken wurde besprutsen yn mear detail by . Troch de keppeling te folgjen kinne jo fertroud meitsje mei it programma en betingsten. It handige ding is dat jo Kubernetes kinne behearskje troch 1-2 oeren deis fan hûs te studearjen of te wurkjen.
Boarne: www.habr.com