Vandag beplan ek om te praat oor hoe om aansoeke te skryf en wat die vereistes is vir jou aansoek om goed in Kubernetes te werk. Sodat daar geen kopsere met die toepassing is nie, sodat jy nie enige "krake" daarom hoef uit te vind en te bou nie - en alles werk soos Kubernetes self bedoel het.
Hierdie lesing is deel van "" Jy kan die oop teoretiese lesings van die Aandskool sien . Vir diegene wat teks eerder as video verkies, het ons hierdie artikel voorberei.
My naam is Pavel Selivanov, tans is ek die voorste DevOps-ingenieur by Mail.ru Cloud Solutions, ons maak wolke, ons maak bestuurskubernetes en so aan. My take sluit nou in bystand met ontwikkeling, die uitrol van hierdie wolke, die uitrol van die toepassings wat ons skryf en die regstreekse ontwikkeling van die gereedskap wat ons aan ons gebruikers verskaf.
Ek het DevOps gedoen, dink ek vir die laaste, waarskynlik, drie jaar. Maar in beginsel doen ek nou al seker sowat vyf jaar wat DevOps doen. Voor dit was ek meestal betrokke by admin goed. Ek het lank gelede met Kubernetes begin werk – seker so vier jaar het verloop sedert ek daarmee begin werk het.
Oor die algemeen het ek begin toe Kubernetes weergawe 1.3 was, waarskynlik, en miskien 1.2 - toe dit nog in sy kinderskoene was. Nou is dit nie meer in sy kinderskoene nie - en dit is duidelik dat daar 'n groot aanvraag in die mark is na ingenieurs wat graag Kubernetes wil kan doen. En maatskappye het 'n baie groot aanvraag na sulke mense. Daarom het hierdie lesing in werklikheid verskyn.
As ons praat volgens die plan waaroor ek gaan praat, lyk dit so, tussen hakies staan daar (TL;DR) geskryf - “te lank; lees nie". My aanbieding vandag sal uit eindelose lyste bestaan.
Trouens, ek self hou nie van sulke aanbiedings wanneer dit gemaak word nie, maar dit is so 'n onderwerp dat ek toe ek hierdie aanbieding voorberei het, eenvoudig nie regtig uitgevind het hoe om hierdie inligting anders te organiseer nie.
Omdat hierdie inligting oor die algemeen “ctrl+c, ctrl+v” is, van onder meer ons Wiki in die DevOps-afdeling, waar ons geskrewe vereistes vir ontwikkelaars het: “ouens, sodat ons jou toepassing in Kubernetes, dit moet so wees."
Dit is hoekom die aanbieding so 'n groot lys was. Jammer. Ek sal probeer om soveel as moontlik te vertel sodat dit nie vervelig is as dit moontlik is nie.
Waarna ons nou gaan kyk:
- dit is eerstens logs (toepassingslogboeke?), wat om daarmee te doen in Kubernetes, wat om daarmee te doen, wat dit moet wees;
- wat om te doen met konfigurasies in Kubernetes, wat is die beste en slegste maniere om 'n toepassing vir Kubernetes op te stel;
- Kom ons praat oor wat toeganklikheidkontroles in die algemeen is, hoe dit moet lyk;
- kom ons praat oor wat 'n grasieuse afsluiting is;
- kom ons praat weer oor hulpbronne;
- Kom ons raak weer die onderwerp van databerging aan;
- en aan die einde sal ek jou vertel wat die term hierdie geheimsinnige wolk-inheemse toepassing is. Cloudnativeness, as 'n byvoeglike naamwoord van hierdie term.
Logs
Ek stel voor om met die stompe te begin - met waar hierdie stompe in Kubernetes gedruk moet word. Nou het jy 'n toepassing in Kubernetes geloods. Volgens die klassieke het voorheen toepassings altyd logs iewers in 'n lêer geskryf. Slegte toepassings het logs geskryf na 'n lêer in die tuisgids van die ontwikkelaar wat die toepassing geloods het. Goeie toepassings het logs na 'n lêer iewers in geskryf /var/log.
Gevolglik het goeie administrateurs verder sekere dinge in hul infrastruktuur opgestel wat hierdie logs kan draai - dieselfde rsyslog, wat na hierdie logs kyk en wanneer iets met hulle gebeur, is daar baie van hulle, dit skep rugsteunkopieë, plaas logs daar , vee ou lêers uit, meer as 'n week, ses maande en 'n ander tyd. In teorie behoort ons bepalings te hê sodat bloot omdat die toepassing logs skryf, die spasie op die produksiebedieners (gevegbedieners?) nie opraak nie. En dienooreenkomstig het die hele produksie nie gestop as gevolg van die stompe nie.
Wanneer ons na die wêreld van Kubernetes beweeg en dieselfde ding daar laat loop, is die eerste ding waaraan jy kan aandag gee die feit dat mense, terwyl hulle logs in 'n lêer geskryf het, aanhou om dit te skryf.
Dit blyk dat as ons oor Kubernetes praat, die regte plek om logs iewers vanaf 'n docker-houer te skryf, eenvoudig is om dit van die toepassing na die sogenaamde Stdout/Stderr te skryf, dit wil sê die standaard uitsetstrome van die bedryfstelsel, die standaard foutuitset. Dit is die mees korrekte, eenvoudigste en mees logiese manier om logs in beginsel in Docker en spesifiek in Kubernetis te plaas. Want as jou toepassing logs na Stdout/Stderr skryf, is dit aan Docker en die Kubernetes-byvoeging om te besluit wat om met hierdie logs te doen. Docker sal by verstek sy spesiale lêers in JSON-formaat bou.
Hier ontstaan die vraag, wat gaan jy volgende met hierdie logs doen? Die maklikste manier is duidelik, ons het die vermoë om te doen kubectl logs en kyk na hierdie logs van hierdie "peule". Maar dit is waarskynlik nie 'n baie goeie opsie nie - iets anders moet met die logs gedoen word.
Kom ons praat vir eers terselfdertyd, aangesien ons die onderwerp van logs aangeraak het, oor iets soos logs moet lyk. Dit wil sê, dit is nie direk op Kubernetes van toepassing nie, maar wanneer ons begin dink oor wat om met logs te doen, sal dit goed wees om ook hieroor te dink.
Ons het 'n soort hulpmiddel nodig, op 'n vriendskaplike manier, wat hierdie logs wat ons koppelaar in sy lêers plaas, sal neem en iewers heen stuur. Oor die algemeen loods ons gewoonlik 'n soort agent binne Kubernetes in die vorm van 'n DaemonSet - 'n log-insamelaar, wat eenvoudig vertel word waar die logs wat Docker versamel, geleë is. En hierdie versameling agent neem hulle eenvoudig, miskien selfs op een of ander manier ontleed hulle langs die pad, miskien verryk hulle met 'n paar bykomende meta-inligting en, uiteindelik, stuur hulle vir berging iewers. Variasies is reeds daar moontlik. Die mees algemene is waarskynlik Elasticsearch, waar jy logs kan stoor en jy dit gerieflik van daar af kan haal. Gebruik dan 'n versoek, gebruik byvoorbeeld Kibana, bou grafieke op grond daarvan, bou waarskuwings op grond daarvan, ensovoorts.
Die belangrikste idee, ek wil dit weer herhaal, is dat binne Docker, veral binne Kubernetes, die stoor van jou logs in 'n lêer 'n baie slegte idee is.
Want eerstens is dit moeilik om die stompe in die houer in 'n lêer te kry. Jy moet eers in die houer gaan, daar uitvoer en dan na die logs kyk. Die volgende punt is dat as jy logs in 'n lêer het, dan het die houers gewoonlik 'n minimalistiese omgewing en daar is geen nutsprogramme wat gewoonlik nodig is vir normale werk met logs nie. Begrawe hulle, kyk na hulle, maak hulle oop in 'n teksredigeerder. Die volgende oomblik is wanneer ons logs in 'n lêer binne 'n houer het, as hierdie houer uitgevee word, verstaan jy, sal die logs daarmee saam sterf. Gevolglik beteken enige herbegin van die houer dat daar nie meer logs is nie. Weereens, slegte opsie.
En die laaste punt is dat binne houers jy gewoonlik jou aansoek het en dit is dit - dit is gewoonlik die enigste proses wat loop. Daar word glad nie gepraat oor enige proses wat lêers met jou logs sal roteer nie. Sodra die logs na 'n lêer geskryf word, beteken dit dat, verskoon my, ons die produksiebediener sal begin verloor. Omdat hulle eerstens moeilik is om te vind, niemand volg hulle nie, plus niemand beheer hulle nie - dienooreenkomstig groei die lêer eindeloos totdat die spasie op die bediener eenvoudig opraak. Daarom sê ek weer dat om aan te meld by Docker, veral in Kubernetes, by 'n lêer 'n slegte idee is.
Die volgende punt, hier wil ek weer hieroor praat - aangesien ons die onderwerp van logs aanraak, sal dit goed wees om te praat oor hoe logs moet lyk om dit gerieflik te maak om daarmee te werk. Soos ek gesê het, is die onderwerp nie direk verwant aan Kubernetes nie, maar dit hou baie goed verband met die onderwerp van DevOps. Oor die onderwerp van ontwikkelingskultuur en vriendskap tussen hierdie twee verskillende departemente - Dev en Ops, sodat almal gemaklik is.
Dit beteken dat logs vandag ideaal in JSON-formaat geskryf moet word. As jy een of ander onverstaanbare toepassing van jou eie het, wat logs in onverstaanbare formate skryf omdat jy een of ander druk of so iets invoeg, dan is dit tyd om een of ander soort raamwerk te google, een of ander soort omhulsel wat jou toelaat om normale logging te implementeer; aktiveer logparameters in JSON daar, omdat JSON 'n eenvoudige formaat is, is dit eenvoudig om dit te ontleed.
As jou JSON nie volgens sekere kriteria werk nie, niemand weet wat nie, skryf dan ten minste logs in 'n formaat wat ontleed kan word. Hier is dit eerder die moeite werd om na te dink oor die feit dat, byvoorbeeld, as jy 'n klomp houers of net prosesse met nginx bedryf, en elkeen het sy eie aantekeninstellings, dan blyk dit waarskynlik dat dit vir jou baie ongerieflik sal wees om ontleed hulle. Want vir elke nuwe nginx-instansie moet jy jou eie ontleder skryf, want hulle skryf logs anders. Weereens, dit was waarskynlik die moeite werd om te dink om seker te maak dat al hierdie nginx-gevalle dieselfde aantekenkonfigurasie het en al hul logs absoluut eenvormig geskryf het. Dieselfde geld vir absoluut alle toepassings.
Op die ou end wil ek ook olie op die vuur gooi dat, ideaal gesproke, multi-lyn formaat logs vermy moet word. Hier is die ding, as jy al ooit met log versamelaars gewerk het, dan het jy heel waarskynlik gesien wat hulle jou belowe, dat hulle met multi-lyn logs kan werk, weet hoe om dit te versamel, ensovoorts. Trouens, na my mening kan nie 'n enkele versamelaar vandag multi-lyn logs normaalweg, volledig en sonder foute versamel nie. Op 'n menslike manier, sodat dit gerieflik en foutloos is.
Maar stapelspoor is altyd multi-lyn logs en hoe om dit te vermy. Die vraag hier is dat 'n log 'n rekord van 'n gebeurtenis is, en stactrace is nie eintlik 'n log nie. As ons logs versamel en dit iewers in Elasticsearch plaas en dan grafieke daaruit trek, 'n paar verslae van gebruikersaktiwiteit op jou werf bou, dan wanneer jy 'n stapelspoor kry, beteken dit dat iets onverwags aan die gebeur is, 'n onbehandelde situasie in jou toepassing. En dit maak sin om outomaties 'n stapelspoor iewers in 'n stelsel op te laai wat hulle kan opspoor.
Dit is sagteware (dieselfde Sentry) wat spesifiek gemaak is om met stapelspoor te werk. Dit kan onmiddellik outomatiese take skep, dit aan iemand toewys, waarsku wanneer stacttraces voorkom, hierdie stacttraces volgens een tipe groepeer, ensovoorts. In beginsel maak dit nie veel sin om oor stapraces te praat wanneer ons oor logs praat nie, want dit is immers verskillende dinge met verskillende doeleindes.
opset
Vervolgens praat ons oor konfigurasie in Kubernetes: wat om daarmee te doen en hoe toepassings binne Kubernetes opgestel moet word. Oor die algemeen sê ek gewoonlik dat Docker nie oor houers gaan nie. Almal weet dat Docker oor houers gaan, selfs diegene wat nie veel met Docker gewerk het nie. Ek herhaal, Docker gaan nie oor houers nie.
Docker gaan na my mening oor standaarde. En daar is standaarde vir feitlik alles: standaarde vir die bou van jou toepassing, standaarde vir die installering van jou toepassing.
En hierdie ding - ons het dit voorheen gebruik, dit het net veral gewild geword met die koms van houers - hierdie ding word ENV (omgewing) veranderlikes genoem, dit wil sê omgewingsveranderlikes wat in jou bedryfstelsel is. Dit is oor die algemeen 'n ideale manier om jou toepassing op te stel, want as jy toepassings in JAVA, Python, Go, Perl het, en hulle kan almal die databasisgasheer, databasisgebruiker, databasiswagwoordveranderlikes lees, dan is dit ideaal. U het toepassings in vier verskillende tale wat op dieselfde manier in die databasisplan gekonfigureer is. Daar is nie meer verskillende konfigurasies nie.
Alles kan gekonfigureer word met behulp van ENV veranderlikes. As ons oor Kubernetes praat, is daar 'n goeie manier om ENV-veranderlikes direk binne Ontplooiing te verklaar. Gevolglik, as ons van geheime data praat, dan kan ons onmiddellik geheime data van ENV-veranderlikes (wagwoorde na databasisse, ens.) in 'n geheim stoot, 'n geheime groepering skep en in die ENV-beskrywing in Ontplooiing aandui dat ons nie direk verklaar nie die waarde van hierdie veranderlike, en die waarde van hierdie databasis wagwoord veranderlike sal uit die geheim gelees word. Dit is standaard Kubernetes-gedrag. En dit is die mees ideale opsie om jou toepassings op te stel. Net op die kodevlak is dit weer van toepassing op ontwikkelaars. As jy DevOps is, kan jy vra: “Ouens, leer asseblief jou toepassing om omgewingsveranderlikes te lees. En ons sal almal gelukkig wees.”
As almal in die maatskappy dieselfde genoemde omgewingsveranderlikes lees, dan is dit wonderlik. Sodat dit nie gebeur dat sommige wag vir die postgres-databasis nie, ander wag vir die databasisnaam, ander wag vir iets anders, ander wag vir 'n dbn van een of ander aard, sodat daar dienooreenkomstig eenvormigheid is.
Die probleem kom wanneer jy soveel omgewingsveranderlikes het dat jy net Ontplooiing oopmaak - en daar is vyfhonderd reëls omgewingsveranderlikes. In hierdie geval het jy bloot omgewingsveranderlikes ontgroei – en jy hoef nie meer jouself te martel nie. In hierdie geval sal dit sin maak om configs te begin gebruik. Dit wil sê, lei u toepassing op om konfigurasies te gebruik.
Die enigste vraag is dat konfigurasies nie is wat jy dink nie. Config.pi is nie 'n konfigurasie wat gerieflik is om te gebruik nie. Of een of ander config in jou eie formaat, alternatiewelik begaafd - dit is ook nie die config wat ek bedoel nie.
Waaroor ek praat, is konfigurasie in aanvaarbare formate, dit wil sê, verreweg die gewildste standaard is die .yaml-standaard. Dit is duidelik hoe om dit te lees, dit is menslik leesbaar, dit is duidelik hoe om dit uit die toepassing te lees.
Gevolglik, benewens YAML, kan jy ook, byvoorbeeld, JSON gebruik, ontleding is omtrent so gerieflik soos YAML in terme van die lees van die toepassingkonfigurasie van daar af. Dit is merkbaar meer ongerieflik vir mense om te lees. Jy kan die formaat probeer, a la ini. Dit is redelik gerieflik om te lees, vanuit 'n menslike oogpunt, maar dit kan ongerieflik wees om dit outomaties te verwerk, in die sin dat as jy ooit jou eie konfigurasies wil genereer, die ini-formaat dalk reeds ongerieflik is om te genereer.
Maar in elk geval, watter formaat jy ook al kies, die punt is dat dit vanuit 'n Kubernetes-oogpunt baie gerieflik is. Jy kan jou hele konfigurasie binne Kubernetes plaas, in die ConfigMap. En neem dan hierdie configmap en vra dit om in jou pod in een of ander spesifieke gids gemonteer te word, waar jou toepassing die konfigurasie vanaf hierdie configmap sal lees asof dit net 'n lêer is. Dit is in werklikheid wat goed is om te doen as u baie konfigurasie-opsies in u toepassing het. Of dit is net een of ander komplekse struktuur, daar is nes.
As jy 'n configmap het, dan kan jy jou toepassing baie goed leer, byvoorbeeld om outomaties veranderinge in die lêer waar die configmap gemonteer is op te spoor, en ook outomaties jou toepassing te herlaai wanneer die konfigurasies verander. Dit sal oor die algemeen 'n ideale opsie wees.
Weereens, ek het reeds hieroor gepraat - geheime inligting is nie in die configmap nie, geheime inligting is nie in veranderlikes nie, geheime inligting is nie in geheime nie. Van daar af, koppel hierdie geheime inligting aan diplomasie. Gewoonlik stoor ons alle beskrywings van Kubernetes-voorwerpe, ontplooiings, configmaps, dienste in git. Gevolglik is dit 'n slegte idee om die wagwoord vir die databasis in git te plaas, selfs al is dit jou git, wat jy intern in die maatskappy het. Omdat git ten minste alles onthou en om eenvoudig wagwoorde daarvandaan te verwyder is nie so maklik nie.
Gesondheids ondersoek
Die volgende punt is hierdie ding genaamd Health check. Oor die algemeen is 'n Gesondheidsondersoek bloot om te kyk of jou toepassing werk. Terselfdertyd praat ons meestal van sekere webtoepassings, waarvoor dit dienooreenkomstig, vanuit die oogpunt van gesondheidsondersoek (dit is beter om nie hier en verder te vertaal nie), 'n spesiale URL sal wees, wat hulle verwerk as 'n standaard, doen hulle gewoonlik /health.
Wanneer ons toegang tot hierdie URL kry, sê ons aansoek dienooreenkomstig óf "ja, goed, alles is reg met my, 200" of "nee, alles is nie reg met my nie, sowat 500." Gevolglik, as ons toepassing nie http is nie, nie 'n webtoepassing nie, praat ons nou van 'n soort daemoon, ons kan uitvind hoe om gesondheidsondersoeke te doen. Dit wil sê, dit is nie nodig nie, as die toepassing nie http is nie, dan werk alles sonder 'n gesondheidsondersoek en dit kan op geen manier gedoen word nie. Jy kan van tyd tot tyd sekere inligting in die lêer opdateer, jy kan met 'n spesiale opdrag vir jou daemon vorendag kom, soos, daemon status, wat sal sê "ja, alles is reg, die daemoon werk, hy leef."
Waarvoor is dit? Die eerste en mees ooglopende ding is waarskynlik hoekom 'n gesondheidsondersoek nodig is - om te verstaan dat die toepassing werk. Ek bedoel, dit is net dom, as dit nou op is, lyk dit of dit werk, so jy kan seker wees dat dit werk. En dit blyk dat die toepassing loop, die houer loop, die instansie werk, alles is reg - en dan het die gebruikers al die telefoonnommers van tegniese ondersteuning afgesny en gesê "wat is jy..., jy aan die slaap geraak, niks werk nie.”
'n Gesondheidsondersoek is net so 'n manier om vanuit die gebruiker se oogpunt te sien dat dit werk. Een van die metodes. Kom ons stel dit so. Uit die oogpunt van Kubernetes is dit ook 'n manier om te verstaan wanneer die toepassing begin, want ons verstaan dat daar 'n verskil is tussen wanneer die houer geloods, geskep en begin is, en wanneer die toepassing direk in hierdie houer geloods is. Want as ons een of ander gemiddelde Java-toepassing neem en dit in die beskuldigdebank probeer begin, dan kan dit vir veertig sekondes, of selfs 'n minuut, of selfs tien, net goed begin. In hierdie geval kan u ten minste op sy poorte klop, dit sal nie daar antwoord nie, dit wil sê, dit is nog nie gereed om verkeer te ontvang nie.
Weereens, met die hulp van 'n gesondheidsondersoek en met behulp van die feit dat ons hierheen draai, kan ons in Kubernetes verstaan dat nie net 'n houer in die toepassing opgestyg het nie, maar die toepassing self het begin, dit reageer reeds op die gesondheidsondersoek, wat beteken dat ons verkeer daarheen kan stuur.
Waaroor ek nou praat, word gereedheids-/lewenskragtoetse binne Kubernetes genoem; dienooreenkomstig is ons gereedheidstoetse verantwoordelik vir die beskikbaarheid van die toepassing in balansering. Dit wil sê, as gereedheidstoetse in die toepassing uitgevoer word, dan is alles in orde, kliëntverkeer gaan na die toepassing. As gereedheidstoetse nie uitgevoer word nie, neem die toepassing eenvoudig nie deel nie, hierdie spesifieke geval neem nie deel aan balansering nie, dit word uit balansering verwyder, kliëntverkeer vloei nie. Gevolglik is Liveness-toetse binne Kubernetes nodig sodat as die toepassing vashaak, dit herbegin kan word. As die lewendheidstoets nie werk vir 'n toepassing wat in Kubernetes verklaar is nie, word die toepassing nie net van balansering verwyder nie, dit word weer begin.
En hier is 'n belangrike punt wat ek graag wil noem: vanuit 'n praktiese oogpunt word die gereedheidstoets gewoonlik meer gereeld gebruik en is dit meer dikwels nodig as die lewendigheidstoets. Dit wil sê, om eenvoudig beide gereedheids- en lewenskragtoetse onnadenkend te verklaar, want Kubernetes kan dit doen, en kom ons gebruik alles wat dit kan doen, is nie 'n baie goeie idee nie. Ek sal verduidelik hoekom. Want punt nommer twee in toetsing is dat dit 'n goeie idee sal wees om die onderliggende diens in jou gesondheidsondersoeke na te gaan. Dit beteken dat as jy 'n webtoepassing het wat inligting gee, wat dit op sy beurt natuurlik van iewers af moet neem. In 'n databasis, byvoorbeeld. Wel, dit stoor die inligting wat in hierdie REST API kom in dieselfde databasis. Dan, dienooreenkomstig, as jou gesondheidskontrole eenvoudig reageer soos gekontak slashhealth, die toepassing sê "200, oukei, alles is reg," en terselfdertyd is jou toepassing se databasis ontoeganklik, en die gesondheidskontrole-toepassing sê "200, oukei, alles is in orde ” - Dit is 'n slegte gesondheidsondersoek. Dit is nie hoe dit moet werk nie.
Dit is, jou aansoek, wanneer 'n versoek om dit kom /health, dit reageer nie net, “200, ok” nie, dit gaan byvoorbeeld eers na die databasis, probeer om daaraan te koppel, doen iets baie basies daar, soos kies een, kyk net dat daar 'n verbinding in die databasis en jy kan die databasis navraag doen. As dit alles suksesvol was, dan is die antwoord "200, ok." As dit nie suksesvol is nie, sê dit dat daar 'n fout is, die databasis is nie beskikbaar nie.
Daarom keer ek in hierdie verband weer terug na die Readiness/Liveness-toetse - hoekom jy heel waarskynlik 'n gereedheidstoets nodig het, maar 'n lewendigheidstoets is ter sprake. Want as jy gesondheidsondersoeke presies beskryf soos ek sopas gesê het, dan sal dit blyk dat dit nie in die instansie-deel beskikbaar is nieв или со всех instancein 'n databasis, byvoorbeeld. Toe jy 'n gereedheidstoets verklaar het, het ons gesondheidsondersoeke begin misluk, en dienooreenkomstig word al die toepassings waaruit die databasis nie toeganklik is nie, hulle eenvoudig afgeskakel van balansering en eintlik "hang" net in 'n verwaarloosde toestand en wag vir hul databasisse om werk.
As ons 'n lewendheidstoets verklaar het, stel jou voor, ons databasis het gebreek, en in jou Kubernetes begin die helfte van alles herbegin omdat die lewendheidstoets misluk. Dit beteken jy moet weer begin. Dit is glad nie wat jy wil hê nie, ek het selfs persoonlike ondervinding in die praktyk gehad. Ons het 'n kletstoepassing gehad wat in JS geskryf is en in 'n Mongo-databasis ingevoer is. En die probleem was dat dit aan die begin van my werk met Kubernetes was, ons het die gereedheid, lewendheid van toetse beskryf volgens die beginsel dat Kubernetes dit kan doen, so ons sal dit gebruik. Gevolglik het Mongo op 'n sekere stadium 'n bietjie "saai" geword en die monster het begin misluk. Gevolglik, volgens die reëntoets, het die peule begin “dood”.
Soos u verstaan, wanneer hulle "doodgemaak" word, is dit 'n geselsie, dit wil sê, daar is baie verbindings van kliënte wat daaraan hang. Hulle word ook “gedood” - nee, nie kliënte nie, net verbindings - nie almal op dieselfde tyd nie, en as gevolg van die feit dat hulle nie gelyktydig doodgemaak word nie, sommige vroeër, ander later, begin hulle nie op dieselfde tyd nie. tyd. Plus standaard ewekansig, ons kan nie elke keer met millisekonde akkuraatheid die begintyd van die toepassing voorspel nie, so hulle doen dit een geval op 'n slag. Een infokol styg, word by die balansering gevoeg, alle kliënte kom daarheen, dit kan nie so 'n las weerstaan nie, want dit is alleen, en rofweg gesproke is daar 'n dosyn van hulle wat daar werk, en dit val. Die volgende een staan op, die hele vrag is op hom, hy val ook. Wel, hierdie valle gaan net voort om te waterval. Op die ou end, hoe dit opgelos is - ons moes net gebruikersverkeer na hierdie toepassing streng stop, alle gevalle laat styg en dan alle gebruikersverkeer op een slag begin sodat dit reeds onder al tien gevalle versprei is.
As dit nie was dat hierdie lewendheidstoets aangekondig is nie, wat dit alles sou dwing om weer te begin, sou die toepassing dit goed hanteer het. Maar alles van balansering is vir ons gedeaktiveer, want die databasisse is ontoeganklik en alle gebruikers het “afgeval”. Dan, wanneer hierdie databasis beskikbaar word, is alles by balansering ingesluit, maar toepassings hoef nie weer te begin nie, en dit is nie nodig om tyd en hulpbronne hierop te mors nie. Hulle is almal reeds hier, hulle is gereed vir verkeer, so verkeer maak net oop, alles is reg - die toepassing is in plek, alles werk voort.
Daarom is gereedheids- en lewendheidstoetse verskillend, selfs bowendien kan jy teoreties verskillende gesondheidsondersoeke doen, byvoorbeeld een tipe radii, een tipe liv, en verskillende dinge nagaan. Gaan jou agterkant na tydens gereedheidstoetse. En op 'n lewendheidstoets, byvoorbeeld, kyk jy nie uit die oogpunt dat die lewendheidstoets oor die algemeen net 'n toepassing is wat reageer, as dit enigsins in staat is om te reageer nie.
Omdat die lewendigheidstoets, oor die algemeen, is wanneer ons "vas" is. 'n Eindelose lus het begin of iets anders - en geen versoeke word meer verwerk nie. Daarom maak dit sin om hulle selfs te skei - en verskillende logika daarin te implementeer.
Met betrekking tot wat jy moet antwoord wanneer jy 'n toets het, wanneer jy gesondheidsondersoeke doen. Dit is net regtig 'n pyn. Diegene wat hiermee vertroud is, sal waarskynlik lag - maar ernstig, ek het dienste in my lewe gesien wat in 200% van die gevalle "XNUMX" antwoord. Dit wil sê wie is suksesvol. Maar terselfdertyd in die liggaam van die antwoord skryf hulle "so en so 'n fout."
Dit wil sê, die reaksiestatus kom na jou toe - alles is suksesvol. Maar terselfdertyd moet jy die liggaam ontleed, want die liggaam sê "jammer, die versoek het met 'n fout geëindig" en dit is net realiteit. Ek het dit in die regte lewe gesien.
En sodat sommige mense dit nie snaaks vind nie, en ander vind dit baie pynlik, is dit steeds die moeite werd om by 'n eenvoudige reël te hou. In gesondheidsondersoeke, en in beginsel wanneer met webtoepassings gewerk word.
As alles goed gegaan het, reageer dan met die tweehonderdste antwoord. In beginsel sal enige tweehonderdste antwoord jou pas. As jy baie goed lees en weet dat sommige reaksiestatusse verskil van ander, antwoord met die toepaslike: 204, 5, 10, 15, wat ook al. As dit nie baie goed is nie, dan net "twee nul nul." As alles sleg gaan en die gesondheidsondersoek reageer nie, antwoord dan met enige vyf honderdste. Weereens, as jy verstaan hoe om te reageer, hoe verskillende reaksiestatusse van mekaar verskil. As jy nie verstaan nie, dan is 502 jou opsie om op gesondheidsondersoeke te reageer as iets verkeerd loop.
Dit is nog 'n punt, ek wil 'n bietjie terugkom oor die nagaan van die onderliggende dienste. As jy byvoorbeeld begin om al die onderliggende dienste wat agter jou aansoek staan, na te gaan – alles in die algemeen. Wat ons uit die oogpunt van mikrodiensargitektuur kry, het ons so 'n konsep soos "lae koppeling" - dit wil sê wanneer jou dienste minimaal van mekaar afhanklik is. As een van hulle misluk, sal al die ander sonder hierdie funksionaliteit eenvoudig aanhou werk. Sommige van die funksies werk net nie. Gevolglik, as jy al die gesondheidskontroles aan mekaar koppel, dan sal jy eindig met een ding wat in die infrastruktuur val, en omdat dit geval het, begin al die gesondheidsondersoeke van alle dienste ook misluk - en daar is meer infrastruktuur in die algemeen vir die hele mikrodiensargitektuur No. Alles het donker geword daar.
Daarom wil ek dit weer herhaal dat jy die onderliggende dienste moet nagaan, dié waarsonder jou aansoek in honderd persent van gevalle nie sy werk kan doen nie. Dit wil sê, dit is logies dat as jy 'n REST API het waardeur die gebruiker na die databasis stoor of uit die databasis haal, dan kan jy in die afwesigheid van 'n databasis nie werk met jou gebruikers waarborg nie.
Maar as jou gebruikers, wanneer jy hulle uit die databasis haal, addisioneel verryk word met 'n paar ander metadata, vanaf 'n ander backend, wat jy invoer voordat jy 'n antwoord na die frontend stuur - en hierdie backend is nie beskikbaar nie, beteken dit dat jy jou antwoord sonder enige deel van die metadata.
Vervolgens het ons ook een van die pynlike probleme wanneer toepassings begin word.
Trouens, dit geld nie net in die algemeen vir Kubernetes nie; dit het net so gebeur dat die kultuur van een of ander soort massa-ontwikkeling en veral DevOps ongeveer dieselfde tyd as Kubernetes begin versprei het. Daarom blyk dit oor die algemeen dat u u toepassing grasieus moet afsluit sonder Kubernetes. Selfs voor Kubernetes het mense dit gedoen, maar met die koms van Kubernetes het ons massaal daaroor begin praat.
Grasieuse afsluiting
In die algemeen, wat is Graceful Shutdown en hoekom is dit nodig? Dit gaan oor wanneer jou toepassing om een of ander rede ineenstort, wat jy moet doen app stop - of jy ontvang byvoorbeeld 'n sein van die bedryfstelsel, jou toepassing moet dit verstaan en iets daaraan doen. Die ergste scenario is natuurlik wanneer jou aansoek 'n SIGTERM ontvang en is soos "SIGTERM, kom ons hou aan, werk, doen niks." Dit is 'n heeltemal slegte opsie.
'n Byna ewe slegte opsie is wanneer jou aansoek 'n SIGTERM ontvang en is soos "hulle het gesê segterm, dit beteken ons eindig, ek het nie gesien nie, ek ken geen gebruikerversoeke nie, ek weet nie watter soort versoeke waaraan ek nou werk, het hulle gesê SIGTERM, dit beteken ons eindig " Dit is ook 'n slegte opsie.
Watter opsie is goed? Die eerste punt is om die voltooiing van bedrywighede in ag te neem. 'n Goeie opsie is dat jou bediener steeds in ag neem wat dit doen as dit 'n SIGTERM ontvang.
SIGTERM is 'n sagte afsluiting, dit is spesiaal ontwerp, dit kan op die kodevlak onderskep word, dit kan verwerk word, sê nou, wag, ons sal eers die werk voltooi wat ons het, dan sal ons uitgaan.
Vanuit 'n Kubernetes-perspektief is dit hoe dit lyk. Wanneer ons vir 'n peul sê wat in 'n Kubernetes-groepering loop, "stop asseblief, gaan weg," of 'n herbegin vind plaas, of 'n opdatering vind plaas wanneer Kubernetes die peule herskep, stuur Kubernetes net dieselfde SIGTERM-boodskap na die peul, wag vir 'n geruime tyd, en , dit is die tyd wat hy wag, dit is ook gekonfigureer, daar is so 'n spesiale parameter in diplomas en dit word genoem Graceful ShutdownTimeout. Soos u verstaan, word dit nie verniet so genoem nie, en dit is nie verniet dat ons nou daaroor praat nie.
Daar kan ons spesifiek sê hoe lank ons moet wag tussen die tyd wat ons SIGTERM na die aansoek stuur en wanneer ons verstaan dat dit lyk of die aansoek mal geword het vir iets of "vas" is en nie gaan eindig nie - en ons moet stuur dit SIGKILL, dit wil sê, hard voltooi sy werk. Dit is, dienooreenkomstig, ons het 'n soort daemon wat loop, dit verwerk bedrywighede. Ons verstaan dat ons bedrywighede waarop die daemon werk, gemiddeld nie meer as 30 sekondes op 'n slag duur nie. Gevolglik, wanneer SIGTERM aankom, verstaan ons dat ons daemon hoogstens 30 sekondes na SIGTERM kan klaarmaak. Ons skryf dit, byvoorbeeld, 45 sekondes net vir ingeval en sê dat SIGTERM. Daarna wag ons 45 sekondes. In teorie moes die demoon gedurende hierdie tyd sy werk voltooi het en homself geëindig het. Maar as dit skielik nie kon nie, beteken dit dat dit heel waarskynlik vas is - dit verwerk nie meer ons versoeke normaalweg nie. En binne 45 sekondes kan jy hom trouens veilig vasspyker.
En hier kan eintlik selfs 2 aspekte in ag geneem word. Eerstens, verstaan dat as jy 'n versoek ontvang het, jy op een of ander manier daarmee begin werk het en nie 'n antwoord aan die gebruiker gegee het nie, maar jy het byvoorbeeld SIGTERM ontvang. Dit maak sin om dit te verfyn en 'n antwoord aan die gebruiker te gee. Dit is punt nommer een in hierdie verband. Punt nommer twee hier is dat as jy jou eie toepassing skryf, gewoonlik die argitektuur so bou dat jy 'n versoek vir jou toepassing ontvang, dan begin jy bietjie werk, begin lêers van iewers af aflaai, 'n databasis aflaai, en wat nog. - Daardie. In die algemeen, jou gebruiker, jou versoek hang vir 'n halfuur en wag vir jou om hom te antwoord - dan, waarskynlik, moet jy werk aan die argitektuur. Dit wil sê, neem net selfs gesonde verstand in ag dat as jou bedrywighede kort is, dit sin maak om SIGTERM te ignoreer en dit te verander. As u operasies lank is, maak dit geen sin om SIGTERM in hierdie geval te ignoreer nie. Dit maak sin om die argitektuur te herontwerp om sulke lang operasies te vermy. Sodat gebruikers nie net rondhang en wag nie. Ek weet nie, maak een of ander websocket daar, maak reverse hooks wat jou bediener alreeds na die kliënt sal stuur, enigiets anders, maar moenie die gebruiker dwing om vir 'n halfuur te hang en net vir 'n sessie te wag totdat jy antwoord hom. Want dit is onvoorspelbaar waar dit kan breek.
Wanneer jou aansoek beëindig word, moet jy 'n toepaslike uitgangkode verskaf. Dit wil sê, as u aansoek gevra is om toe te maak, te stop, en dit kon homself normaalweg stop, dan hoef u nie 'n soort uitgangkode 1,5,255 ensovoorts terug te gee nie. Enigiets wat nie nulkode is nie, ten minste in Linux-stelsels, ek is seker hiervan, word as onsuksesvol beskou. Dit wil sê, dit word beskou as dat u aansoek in hierdie geval met 'n fout geëindig het. Gevolglik, op 'n vriendskaplike manier, as jou aansoek sonder 'n fout voltooi is, sê jy 0 op die afvoer. As jou toepassing om een of ander rede misluk, sê jy nie-0 in die uitvoer. En jy kan met hierdie inligting werk.
En die laaste opsie. Dit is sleg as jou gebruiker 'n versoek stuur en vir 'n halfuur hang terwyl jy dit verwerk. Maar oor die algemeen wil ek ook sê oor wat oor die algemeen die moeite werd is van die kliënt se kant af. Dit maak nie saak of jy 'n mobiele toepassing, front-end, ens. Dit is nodig om in ag te neem dat die gebruiker se sessie oor die algemeen beëindig kan word, enigiets kan gebeur. 'n Versoek kan gestuur word, byvoorbeeld, onderverwerk en geen antwoord word teruggestuur nie. Jou frontend of jou mobiele toepassing - enige frontend in die algemeen, kom ons stel dit so - moet dit in ag neem. As jy met websockets werk, is dit oor die algemeen die ergste pyn wat ek nog ooit gehad het.
Wanneer die ontwikkelaars van sommige gereelde kletse dit nie weet nie, blyk dit dat die websok kan breek. Vir hulle, wanneer iets by die instaanbediener gebeur, verander ons net die konfigurasie, en dit herlaai. Natuurlik word alle langlewende sessies in hierdie geval geskeur. Ontwikkelaars kom na ons aangehardloop en sê: “Manne, wat doen julle, die klets het vir al ons kliënte gebreek!” Ons sê vir hulle: “Wat doen julle? Kan u kliënte nie weer koppel nie? Hulle sê: "Nee, ons het nodig dat die sessies nie verskeur word nie." Kortom, dit is eintlik nonsens. Die kliëntkant moet in ag geneem word. Veral, soos ek sê, met langlewende sessies soos websockets, kan dit breek en, ongemerk deur die gebruiker, moet jy sulke sessies kan herinstalleer. En dan is alles perfek.
Ресурсы
Eintlik, hier sal ek jou net 'n reguit storie vertel. Weereens uit die regte lewe. Die siekste ding wat ek nog van hulpbronne gehoor het.
Hulpbronne in hierdie geval, ek bedoel, 'n soort versoeke, limiete wat jy op peule in jou Kubernetes-klusters kan plaas. Die snaakste ding wat ek van 'n ontwikkelaar gehoor het ... Een van my mede-ontwikkelaars by 'n vorige werkplek het eenkeer gesê: "My toepassing sal nie in die groep begin nie." Ek het gekyk om te sien dat dit nie begin nie, maar óf dit pas nie by die hulpbronne in nie, óf hulle het baie klein perke gestel. Kortom, die toepassing kan weens hulpbronne nie begin nie. Ek sê: "Dit sal nie begin as gevolg van hulpbronne nie, jy besluit hoeveel jy nodig het en stel 'n voldoende waarde." Hy sê: “Watter soort hulpbronne?” Ek het vir hom begin verduidelik dat Kubernetes, limiete op versoeke en bla, bla, bla gestel moet word. Die man het vyf minute lank geluister, geknik en gesê: “Ek het hierheen gekom om as ’n ontwikkelaar te werk, ek wil niks van enige hulpbronne weet nie. Ek het hierheen gekom om kode te skryf en dit is dit.” Dit is hartseer. Dit is 'n baie hartseer konsep uit 'n ontwikkelaar se oogpunt. Veral in die moderne wêreld, so te sê, van progressiewe devops.
Hoekom is hulpbronne enigsins nodig? Daar is 2 soorte hulpbronne in Kubernetes. Sommige word versoeke genoem, ander word limiete genoem. Deur hulpbronne sal ons verstaan dat daar basies altyd net twee basiese beperkings is. Dit wil sê SVE-tydperke en RAM-limiete vir 'n houer wat in Kubernetes loop.
'n Limiet plaas 'n boonste limiet op hoe 'n hulpbron in jou toepassing gebruik kan word. Dit is dus, as jy sê 1GB RAM in die limiete, dan sal jou toepassing nie meer as 1GB RAM kan gebruik nie. En as hy dit skielik wil en probeer doen, dan sal 'n proses genaamd oom killer, uit geheue, dit wil sê, jou aansoek kom doodmaak - dit wil sê, dit sal eenvoudig weer begin. Toepassings sal nie herbegin op grond van SVE nie. In terme van SVE, as 'n toepassing baie probeer gebruik, meer as wat in die limiete gespesifiseer word, sal die SVE eenvoudig streng gekies word. Dit lei nie tot herstart nie. Dit is die limiet - dit is die boonste limiet.
En daar is 'n versoek. 'n Versoek is hoe Kubernetes verstaan hoe die nodusse in jou Kubernetes-kluster met toepassings gevul is. Dit wil sê, 'n versoek is 'n soort commit van jou aansoek. Dit sê wat ek wil gebruik: "Ek wil graag hê jy moet soveel SVE en soveel geheue vir my reserveer." So 'n eenvoudige analogie. Wat as ons 'n nodus het wat, ek weet nie, altesaam 8 SVE's het. En 'n peul kom daar aan, wie se versoeke 1 SVE sê, wat beteken dat die nodus 7 SVE's oor het. Dit is dienooreenkomstig, sodra 8 peule by hierdie nodus aankom, wat elkeen 1 SVE in hul versoeke het, die nodus, asof uit die oogpunt van Kubernetes, se SVE opgeraak het en meer peule met versoeke kan nie op hierdie nodus geloods. As al die nodusse se SVE opraak, sal Kubernetes begin sê dat daar geen geskikte nodusse in die groep is om jou peule te laat loop nie, want die SVE het opgeraak.
Hoekom is versoeke nodig en hoekom sonder versoeke, dink ek is dit nie nodig om iets in Kubernetes te begin nie? Kom ons stel ons 'n hipotetiese situasie voor. Jy begin jou toepassing sonder versoeke, Kubernetes weet nie hoeveel van wat jy het, na watter nodusse jy dit kan stoot nie. Wel, hy stoot, stoot, stoot op die nodes. Op 'n stadium sal jy verkeer na jou toepassing begin kry. En een van die toepassings begin skielik hulpbronne gebruik tot die limiete wat dit volgens die perke het. Dit blyk dat daar 'n ander toepassing naby is en dit benodig ook hulpbronne. Die knoop begin eintlik fisies uit hulpbronne raak, byvoorbeeld OP. Die nodus begin eintlik fisies uit hulpbronne raak, byvoorbeeld, ewekansige toegang geheue (RAM). Wanneer 'n nodus nie meer krag het nie, sal die koppelaar eerstens ophou reageer, dan die cubelet, dan die OS. Hulle sal bloot bewusteloos raak en ALLES sal beslis ophou werk vir jou. Dit wil sê, dit sal daartoe lei dat jou nodus vassit en jy sal dit moet herbegin. Kortom, die situasie is nie baie goed nie.
En wanneer u versoeke het, is die limiete nie baie anders nie, ten minste nie baie keer meer as die limiete of versoeke nie, dan kan u so 'n normale, rasionele vulling van toepassings oor die nodusse van Kubernetes-klusters hê. Terselfdertyd is Kubernetes ongeveer bewus van hoeveel van wat dit waar plaas, hoeveel van wat waar gebruik word. Dit wil sê, dit is net so 'n oomblik. Dit is belangrik om dit te verstaan. En dit is belangrik om te beheer dat dit aangedui word.
Datastoor
Ons volgende punt gaan oor databerging. Wat om te doen met hulle en in die algemeen, wat om te doen met volharding in Kubernetes?
Ek dink weer binne ons , was daar 'n onderwerp oor die databasis in Kubernetes. En dit lyk vir my of ek selfs min of meer weet wat jou kollegas vir jou gesê het toe hulle gevra is: "Is dit moontlik om 'n databasis in Kubernetes te laat loop?" Om een of ander rede lyk dit vir my of jou kollegas jou moes vertel het dat as jy die vraag vra of dit moontlik is om 'n databasis in Kubernetes te laat loop, dan is dit onmoontlik.
Die logika hier is eenvoudig. Net vir ingeval, ek sal weereens verduidelik, as jy 'n baie gawe ou is wat 'n redelik foutverdraagsame stelsel van verspreide netwerkberging kan bou, verstaan hoe om 'n databasis in hierdie geval in te pas, hoe cloud native in houers moet werk in 'n databasis in die algemeen. Waarskynlik, jy het geen twyfel oor hoe om dit te bestuur nie. As jy so 'n vraag het, en jy wil seker maak dat dit alles ontvou en reg tot die dood in produksie staan en nooit val nie, dan gebeur dit nie. Jy is gewaarborg om jouself in die voet te skiet met hierdie benadering. Dit is dus beter om nie.
Wat moet ons doen met die data wat ons toepassing wil stoor, 'n paar foto's wat gebruikers oplaai, 'n paar dinge wat ons toepassing genereer tydens die werking daarvan, byvoorbeeld by opstart? Wat om met hulle te doen in Kubernetes?
Oor die algemeen, ideaal, ja, natuurlik, Kubernetes is baie goed ontwerp en is oor die algemeen aanvanklik vir staatlose toepassings ontwerp. Dit wil sê vir daardie toepassings wat glad nie inligting stoor nie. Dit is ideaal.
Maar die ideale opsie bestaan natuurlik nie altyd nie. So wat? Die eerste en eenvoudigste punt is om 'n soort S3 te neem, net nie 'n tuisgemaakte een nie, wat ook onduidelik is hoe dit werk, maar van een of ander verskaffer. 'n Goeie, normale verskaffer - en leer jou toepassing om S3 te gebruik. Dit wil sê, wanneer jou gebruiker 'n lêer wil oplaai, sê "hier, asseblief, laai dit op na S3." Wanneer hy dit wil ontvang, sê: "Hier is 'n skakel na S3 terug en neem dit van hier af." Dit is ideaal.
As hierdie ideale opsie om een of ander rede skielik nie geskik is nie, jy het 'n toepassing wat jy nie geskryf het nie, jy ontwikkel nie, of dit is 'n soort verskriklike nalatenskap, dit kan nie die S3-protokol gebruik nie, maar moet met plaaslike dopgehou werk in plaaslike dopgehou. Neem iets min of meer eenvoudig, ontplooi Kubernetes. Dit wil sê, om Ceph dadelik vir 'n paar minimale take te omhein, lyk dit vir my, is 'n slegte idee. Want Ceph is natuurlik goed en modieus. Maar as jy nie regtig verstaan wat jy doen nie, as jy eers iets op Ceph gesit het, kan jy dit baie maklik en eenvoudig nooit weer daar uitkry nie. Want, soos jy weet, berg Ceph data in sy groepering in binêre vorm, en nie in die vorm van eenvoudige lêers nie. Daarom, as die Ceph-kluster skielik breek, dan is daar 'n volledige en hoë waarskynlikheid dat jy nooit weer jou data daarvandaan sal kry nie.
Ons sal 'n kursus oor Ceph hê, jy kan .
Daarom is dit beter om iets eenvoudig te doen soos 'n NFS-bediener. Kubernetes kan met hulle werk, jy kan 'n gids onder 'n NFS-bediener monteer - jou toepassing is net soos 'n plaaslike gids. Terselfdertyd moet jy natuurlik verstaan dat jy weer iets met jou NFS moet doen, jy moet verstaan dat dit soms ontoeganklik kan word en die vraag oorweeg wat jy in hierdie geval sal doen. Miskien moet dit iewers op 'n aparte masjien gerugsteun word.
Die volgende punt waaroor ek gepraat het, is wat om te doen as jou toepassing 'n paar lêers genereer tydens werking. Byvoorbeeld, wanneer dit begin, genereer dit een of ander statiese lêer, wat gebaseer is op sekere inligting wat die toepassing slegs ontvang ten tyde van die bekendstelling. Wat 'n oomblik. As daar nie baie sulke data is nie, hoef jy glad nie die moeite te doen nie, installeer net hierdie toepassing vir jouself en werk. Die enigste vraag hier is wat, kyk. Baie dikwels, allerhande erfenisstelsels, soos WordPress ensovoorts, veral met gewysigde een of ander soort slim plugins, slim PHP-ontwikkelaars, weet hulle dikwels hoe om dit so te maak dat hulle 'n soort lêer vir hulself genereer. Gevolglik genereer een een lêer, die tweede genereer 'n tweede lêer. Hulle is anders. Balansering gebeur in die kliënte se Kubernetes-kluster bloot toevallig. Gevolglik blyk dit dat hulle byvoorbeeld nie weet hoe om saam te werk nie. Die een gee een inligting, die ander gee die gebruiker 'n ander inligting. Dit is iets wat jy moet vermy. Dit wil sê, in Kubernetes is alles wat u begin gewaarborg om in verskeie gevalle te kan werk. Want Kubernetes is 'n roerende ding. Gevolglik kan hy enigiets beweeg, wanneer hy wil, sonder om enigiemand te vra. Daarom moet jy hierop reken. Alles wat in een geval geloods word, sal vroeër of later misluk. Hoe meer besprekings jy het, hoe beter. Maar ek sê weer, as jy 'n paar sulke lêers het, dan kan jy dit reg onder jou sit, hulle weeg 'n klein hoeveelheid. As daar 'n bietjie meer van hulle is, moet jy hulle waarskynlik nie in die houer druk nie.
Ek sal aanraai dat daar so 'n wonderlike ding in Kubernetes is, jy kan volume gebruik. In die besonder, is daar 'n volume van tipe leë dir. Dit wil sê, dit is net dat Kubernetes outomaties 'n gids sal skep in sy diensgidse op die bediener waar u begin het. En hy sal dit vir jou gee sodat jy dit kan gebruik. Daar is net een belangrike punt. Dit wil sê, jou data sal nie binne die houer gestoor word nie, maar eerder op die gasheer waarop jy hardloop. Boonop kan Kubernetes sulke leë dirs onder normale konfigurasie beheer en is in staat om hul maksimum grootte te beheer en nie toe te laat dat dit oorskry word nie. Die enigste punt is dat dit wat jy in leë dir geskryf het, nie verlore gaan tydens pod herstarts nie. Dit wil sê, as jou peul per ongeluk val en weer styg, sal die inligting in die leë dir nêrens heen gaan nie. Hy kan dit weer met 'n nuwe begin gebruik - en dit is goed. As jou peul iewers weggaan, sal hy natuurlik sonder data vertrek. Dit wil sê, sodra die pod van die nodus waar dit met leë dir gelanseer is, verdwyn, word leë dir uitgevee.
Wat anders is goed aan leë dir? Dit kan byvoorbeeld as 'n kas gebruik word. Kom ons stel ons voor dat ons toepassing iets op die vlieg genereer, dit aan gebruikers gee en dit vir 'n lang tyd doen. Daarom genereer en gee die toepassing dit byvoorbeeld aan gebruikers, en stoor dit terselfdertyd iewers, sodat die volgende keer as die gebruiker vir dieselfde ding kom, dit vinniger sal wees om dit dadelik gegenereer te gee. Leë dir kan aan Kubernetes gevra word om in die geheue te skep. En dus kan jou kas oor die algemeen blitsvinnig werk - in terme van skyftoegangspoed. Dit wil sê, jy het 'n leë dir in die geheue, in die OS word dit in die geheue gestoor, maar vir jou, vir die gebruiker binne die pod, lyk dit soos net 'n plaaslike gids. Jy het nie die toepassing nodig om spesifiek enige magie te leer nie. Jy neem net en plaas jou lêer direk in 'n gids, maar in werklikheid in die geheue op die OS. Dit is ook 'n baie gerieflike kenmerk in terme van Kubernetes.
Watter probleme het Minio? Die grootste probleem met Minio is dat om hierdie ding te laat werk, dit iewers moet loop, en daar moet 'n soort lêerstelsel wees, dit wil sê berging. En hier kry ons dieselfde probleme as wat Ceph het. Dit wil sê, Minio moet sy lêers iewers stoor. Dit is bloot 'n HTTP-koppelvlak vir jou lêers. Boonop is die funksionaliteit duidelik swakker as dié van Amazon se S3. Voorheen kon dit nie die gebruiker behoorlik magtig nie. Nou, sover ek weet, kan dit reeds emmers met verskillende magtigings skep, maar weereens lyk dit vir my of die hoofprobleem so te sê die onderliggende stoorstelsel op 'n minimum is.
Hoe beïnvloed Leë dir in geheue die limiete? Beïnvloed op geen manier perke nie. Dit lê in die geheue van die gasheer, en nie in die geheue van jou houer nie. Dit wil sê, jou houer sien nie die leë dir in die geheue as deel van sy besette geheue nie. Die gasheer sien dit. Gevolglik, ja, uit die oogpunt van kubernetes, wanneer jy dit begin gebruik, sal dit goed wees om te verstaan dat jy 'n deel van jou geheue aan leë dir wy. En dienooreenkomstig, verstaan dat geheue kan opraak nie net as gevolg van toepassings nie, maar ook omdat iemand aan hierdie leë dirs skryf.
Bewolkheid
En die laaste subonderwerp is wat Cloudnative is. Hoekom is dit nodig? Bewolkheid en so aan.
Dit wil sê, daardie toepassings wat in staat en geskryf is om in 'n moderne wolkinfrastruktuur te werk. Maar in werklikheid het Cloudnative nog so 'n aspek. Dat dit nie net 'n toepassing is wat al die vereistes van 'n moderne wolkinfrastruktuur in ag neem nie, maar ook weet hoe om met hierdie moderne wolkinfrastruktuur te werk, trek voordeel uit die voor- en nadele van die feit dat dit in hierdie wolke werk. Moenie net oorboord gaan en in die wolke werk nie, maar trek voordeel uit die voordele van werk in die wolk.
Kom ons neem net Kubernetes as 'n voorbeeld. Jou toepassing loop in Kubernetes. Jou aansoek kan altyd, of eerder die admins vir jou aansoek, altyd 'n diensrekening skep. Dit wil sê, 'n rekening vir magtiging in Kubernetes self in sy bediener. Voeg 'n paar regte by wat ons daar nodig het. En jy het toegang tot Kubernetes vanuit jou toepassing. Wat kan jy op hierdie manier doen? Byvoorbeeld, vanaf die toepassing, ontvang data oor waar u ander toepassings, ander soortgelyke gevalle geleë is, en groepeer saam op een of ander manier bo-op Kubernetes, as daar so 'n behoefte is.
Weereens, ons het onlangs letterlik 'n saak gehad. Ons het een kontroleerder wat die tou monitor. En wanneer 'n paar nuwe take in hierdie tou verskyn, gaan dit na Kubernetes - en binne Kubernetes skep dit 'n nuwe peul. Gee hierdie peul 'n nuwe taak en binne die raamwerk van hierdie peul voer die peul die taak uit, stuur 'n antwoord na die beheerder self, en die beheerder doen dan iets met hierdie inligting. Byvoorbeeld, dit voeg 'n databasis by. Dit is weereens, dit is 'n pluspunt van die feit dat ons toepassing in Kubernetes loop. Ons kan die ingeboude Kubernetes-funksionaliteit self gebruik om op een of ander manier uit te brei en die funksionaliteit van ons toepassing geriefliker te maak. Dit wil sê, moenie 'n soort towerkrag wegsteek oor hoe om 'n toepassing te begin, hoe om 'n werker te begin nie. In Kubernetes stuur jy eenvoudig 'n versoek in die toepassing as die toepassing in Python geskryf is.
Dieselfde geld as ons verder gaan as Kubernetes. Ons het ons Kubernetes iewers aan die gang - dit is goed as dit in 'n soort wolk is. Weereens, ons kan die vermoëns van die wolk self gebruik, en moet selfs, glo ek, gebruik waar ons hardloop. Van die elementêre dinge wat die wolk aan ons verskaf. Balansering, dit wil sê, ons kan wolkbalanseerders skep en dit gebruik. Dit is 'n direkte voordeel van wat ons kan gebruik. Omdat wolkbalansering eerstens eenvoudig die verantwoordelikheid van ons verwyder vir hoe dit werk, hoe dit opgestel is. Boonop is dit baie gerieflik, want gewone Kubernetes kan met wolke integreer.
Dieselfde geld vir skaal. Gereelde Kubernetes kan met wolkverskaffers integreer. Weet hoe om te verstaan dat as die kluster uit nodusse opraak, dit wil sê, die knoopspasie op is, dan moet jy byvoeg - Kubernetes sal self nuwe nodusse by jou cluster voeg en peule daarop begin lanseer. Dit wil sê, wanneer jou vrag kom, begin die aantal vuurherde toeneem. Wanneer die nodusse in die groep opraak vir hierdie peule, loods Kubernetes nuwe nodusse en dienooreenkomstig kan die aantal peule steeds toeneem. En dit is baie gerieflik. Dit is 'n direkte geleentheid om die tros op die vlieg te skaal. Nie baie vinnig nie, in die sin dat dit nie 'n sekonde is nie, dit is meer soos 'n minuut om nuwe nodusse by te voeg.
Maar uit my ervaring is dit weer die coolste ding wat ek nog ooit gesien het. Wanneer die Cloudnative-kluster geskaal het op grond van tyd van die dag. Dit was 'n backend-diens wat deur mense in die back-office gebruik is. Dit wil sê, hulle kom om 9:8 by die werk, begin by die stelsel aanmeld, en dienooreenkomstig begin die Cloudnative-kluster, waar dit alles aan die gang is, swel, en begin nuwe peule sodat almal wat kom werk met die toepassing kan werk. Wanneer hulle om 6:30 of XNUMX:XNUMX die werk verlaat, merk die Kubernetes-klusters op dat niemand meer die toepassing gebruik nie en begin krimp. Spaar van tot XNUMX persent is gewaarborg. Dit het destyds in Amazon gewerk; op daardie stadium was daar niemand in Rusland wat dit so goed kon doen nie.
Ek sal jou reguit sê, die besparing is 30 persent bloot omdat ons Kubernetes gebruik en voordeel trek uit die vermoëns van die wolk. Nou kan dit in Rusland gedoen word. Ek sal natuurlik aan niemand adverteer nie, maar kom ons sê net dat daar verskaffers is wat dit kan doen, verskaf dit reg uit die boks met 'n knoppie.
Daar is 'n laaste punt waarop ek ook graag u aandag wil vestig. Om jou toepassing, jou infrastruktuur Cloudnative te laat wees, maak dit sin om uiteindelik die benadering genaamd Infrastructure as a Code te begin aanpas. Dit wil sê, dit beteken dat jou toepassing, of eerder jou infrastruktuur, presies dieselfde benodig as die kode Beskryf jou toepassing, jou besigheidslogika in die vorm van kode. En werk daarmee as kode, dit wil sê, toets dit, rol dit uit, stoor dit in git, pas CICD daarop toe.
En dit is presies wat jou eerstens toelaat om altyd beheer oor jou infrastruktuur te hê, om altyd te verstaan in watter toestand dit is. Tweedens, vermy handbewerkings wat foute veroorsaak. Derdens, vermy bloot wat omset genoem word, wanneer jy voortdurend dieselfde handtake moet uitvoer. Vierdens laat dit jou toe om baie vinniger te herstel in die geval van 'n mislukking. In Rusland, elke keer as ek hieroor praat, is daar altyd 'n groot aantal mense wat sê: "Ja, dit is duidelik, maar jy het benaderings, kortom, dit is nie nodig om iets reg te stel nie." Maar dis waar. As iets in jou infrastruktuur gebreek is, dan vanuit die oogpunt van die Cloudnative-benadering en vanuit die oogpunt van Infrastruktuur as 'n kode, eerder as om dit reg te maak, na die bediener te gaan, uit te vind wat stukkend is en dit reg te maak, is dit makliker om die bediener uit te vee en dit weer te skep. En ek sal dit alles laat herstel.
Al hierdie kwessies word in meer besonderhede bespreek by . Deur die skakel te volg kan jy jouself vergewis van die program en voorwaardes. Die gerieflike ding is dat jy Kubernetes kan bemeester deur 1-2 uur per dag van die huis of werk te studeer.
Bron: will.com