Tänään aion puhua hakemusten kirjoittamisesta ja siitä, mitkä ovat hakemuksesi vaatimukset, jotta se toimisi hyvin Kubernetesissa. Jotta sovelluksen kanssa ei aiheudu päänsärkyä, jotta sinun ei tarvitse keksiä ja rakentaa sen ympärille mitään "naarmuja" - ja kaikki toimii niin kuin Kubernetes itse on tarkoittanut.
Tämä luento on osa "" Voit katsoa Iltakoulun avoimet teoreettiset luennot . Niille, jotka pitävät tekstistä videon sijaan, olemme laatineet tämän artikkelin.
Nimeni on Pavel Selivanov, tällä hetkellä olen johtava DevOps-insinööri Mail.ru Cloud Solutionsissa, teemme pilviä, teemme hallintakubernetteja ja niin edelleen. Tehtäviini kuuluu nyt kehitysapu, näiden pilvien käyttöönotto, kirjoittamiemme sovellusten käyttöönotto ja käyttäjille tarjoamiemme työkalujen suora kehittäminen.
Olen tehnyt DevOpsia viimeiset, luultavasti kolme vuotta. Mutta periaatteessa olen tehnyt sitä mitä DevOps tekee varmaan noin viisi vuotta. Ennen sitä olin lähinnä järjestelmänvalvojan asioissa. Aloitin työskentelyn Kuberneteksen kanssa kauan sitten - siitä on varmaan noin neljä vuotta aikaa.
Yleensä aloitin, kun Kubernetes oli luultavasti versio 1.3 ja ehkä 1.2 - kun se oli vielä lapsenkengissään. Nyt se ei ole enää lapsenkengissään - ja on selvää, että markkinoilla on valtava kysyntä insinööreille, jotka haluaisivat pystyä tekemään Kubernetesia. Ja yrityksillä on erittäin suuri kysyntä tällaisille ihmisille. Siksi itse asiassa tämä luento ilmestyi.
Jos puhumme suunnitelman mukaan, mistä puhun, se näyttää tältä, suluissa on kirjoitettu (TL;DR) - "liian pitkä; älä lue". Tämänpäiväinen esitykseni koostuu loputtomista listoista.
Itse asiassa en itse pidä sellaisista esityksistä, kun niitä tehdään, mutta tämä on sellainen aihe, että tätä esitystä valmistellessa en yksinkertaisesti keksinyt, miten tämä tieto järjestettäisi toisin.
Koska nämä tiedot ovat pääsääntöisesti "ctrl+c, ctrl+v", muun muassa Wikistämme DevOps-osiossa, jossa olemme kirjoittaneet kehittäjille vaatimukset: "Kaverit, jotta voimme käynnistää sovelluksesi Kubernetes, sen pitäisi olla näin."
Siksi esittelystä tuli niin laaja lista. Anteeksi. Yritän kertoa niin paljon kuin mahdollista, jotta se ei ole tylsää, jos mahdollista.
Mitä nyt katsomme:
- nämä ovat ensinnäkin lokit (sovelluslokit?), mitä niille tehdään Kubernetesissa, mitä niille tehdään, mitä niiden pitäisi olla;
- mitä tehdä Kubernetesin määrityksille, mitkä ovat parhaat ja huonoimmat tavat määrittää sovellus Kubernetesille;
- Puhutaanpa siitä, mitä esteettömyystarkistukset ovat yleensä, miltä niiden pitäisi näyttää;
- Puhutaanpa siitä, mitä siro sammutus on;
- Puhutaanpa taas resursseista;
- Kosketaanpa vielä kerran tiedon tallennuksen aihetta;
- ja lopuksi kerron sinulle, mikä termi tämä salaperäinen pilvisovellus on. Pilvisyys, tämän termin adjektiivina.
Lokit
Suosittelen aloittamaan tukista - siitä, mihin nämä tukit on työnnettävä Kubernetesissa. Nyt olet käynnistänyt sovelluksen Kubernetesissa. Klassikoiden mukaan aiemmin sovellukset kirjoittivat aina lokit jonnekin tiedostoon. Huonot sovellukset kirjoittivat lokeja sovelluksen käynnistäneen kehittäjän kotihakemistossa olevaan tiedostoon. Hyvät sovellukset kirjoittivat lokeja johonkin tiedostoon /var/log.
Tämän mukaisesti hyvät järjestelmänvalvojat olivat lisäksi määrittäneet infrastruktuuriinsa asioita, joita nämä lokit voisivat pyörittää - sama rsyslog, joka katsoo näitä lokeja ja kun niille tapahtuu jotain, niitä on paljon, se luo varmuuskopioita, laittaa lokit sinne , poistaa vanhoja tiedostoja yli viikon, kuuden kuukauden ja joskus muulloinkin. Teoriassa meillä pitäisi olla säännökset, jotta pelkkä sovellus kirjoittaa lokeja, tuotantopalvelimien (taistelupalvelimien?) tila ei lopu kesken. Ja vastaavasti koko tuotanto ei pysähtynyt tukkien takia.
Kun siirrymme Kubernetesin maailmaan ja pyöritämme samaa asiaa siellä, ensimmäinen asia, johon voit kiinnittää huomiota, on se, että ihmiset jatkavat niiden kirjoittamista, kun he kirjoittivat lokeja tiedostoon.
Osoittautuu, että jos puhumme Kubernetesista, oikea paikka kirjoittaa lokeja jonnekin telakointisäiliöstä on yksinkertaisesti kirjoittaa ne sovelluksesta ns. Stdout/Stderriin, eli käyttöjärjestelmän standardilähtövirtoihin, vakiovirhetulostus. Tämä on oikea, yksinkertaisin ja loogisin tapa laittaa lokit periaatteessa Dockeriin ja erityisesti Kubernetisiin. Koska jos sovelluksesi kirjoittaa lokeja Stdout/Stderriin, Dockerin ja Kubernetes-lisäosan päättävät, mitä näille lokeille tehdään. Docker rakentaa oletuksena erityistiedostonsa JSON-muodossa.
Tässä herää kysymys, mitä aiot tehdä seuraavaksi näillä tukilla? Helpoin tapa on selkeä, meillä on kyky tehdä kubectl logs ja katso näitä lokeja näistä "paloista". Mutta luultavasti tämä ei ole kovin hyvä vaihtoehto - lokeille on tehtävä jotain muuta.
Puhutaan nyt toistaiseksi samaan aikaan, koska kosketimme hirsien aihetta, sellaisesta asiasta, miltä hirsien pitäisi näyttää. Eli tämä ei päde suoraan Kubernetesiin, mutta kun alamme miettimään, mitä puun kanssa tehdään, olisi hyvä miettiä myös tätä.
Tarvitsemme jonkinlaisen työkalun ystävällisellä tavalla, joka ottaa nämä lokit, jotka telakointiasemamme laittaa tiedostoihinsa, ja lähettää ne jonnekin. Pääsääntöisesti käynnistämme Kubernetesin sisällä jonkinlaisen agentin DaemonSetin muodossa - lokikerääjän, jolle yksinkertaisesti kerrotaan missä Dockerin keräämät lokit sijaitsevat. Ja tämä keräysagentti yksinkertaisesti ottaa ne, ehkä jopa jotenkin jäsentää ne matkan varrella, ehkä rikastaa niitä jollain lisämetatiedolla ja lopulta lähettää ne tallennettavaksi jonnekin. Variaatiot ovat jo mahdollisia siellä. Yleisin on luultavasti Elasticsearch, johon voi tallentaa lokit ja sieltä saa ne kätevästi talteen. Rakenna sitten pyynnön avulla esimerkiksi Kibanan avulla kaavioita niiden perusteella, rakenna hälytyksiä niiden perusteella ja niin edelleen.
Tärkein ajatus, haluan toistaa sen uudelleen, on, että Dockerin sisällä, erityisesti Kubernetesissa, lokien tallentaminen tiedostoon on erittäin huono idea.
Koska ensinnäkin lokit on vaikea saada tiedostoon säilön sisällä. Sinun on ensin mentävä säiliöön, suoritettava siellä ja katsottava sitten lokeja. Seuraava kohta on se, että jos tiedostossa on lokit, niin konteissa on yleensä minimalistinen ympäristö eikä siellä ole apuohjelmia, joita tavallisesti tarvitaan normaaliin lokityöskentelyyn. Hauta ne, katso niitä, avaa ne tekstieditorissa. Seuraava hetki on, kun meillä on lokit tiedostossa kontin sisällä, jos tämä kontti poistetaan, ymmärräthän, lokit kuolevat sen mukana. Näin ollen mikä tahansa säiliön uudelleenkäynnistys tarkoittaa, että lokeja ei ole enää. Taas huono vaihtoehto.
Ja viimeinen kohta on, että konttien sisällä sinulla on yleensä sovelluksesi ja siinä se - se on yleensä ainoa käynnissä oleva prosessi. Ei puhuta lainkaan prosessista, joka kiertäisi tiedostoja lokiesi kanssa. Heti kun lokit alkavat kirjoittaa tiedostoon, tämä tarkoittaa, että, anteeksi, alamme menettää tuotantopalvelimen. Koska ensinnäkin niitä on vaikea löytää, kukaan ei seuraa niitä eikä kukaan hallitse niitä - vastaavasti tiedosto kasvaa loputtomasti, kunnes palvelimen tila yksinkertaisesti loppuu. Siksi sanon jälleen, että Dockerissa, erityisesti Kubernetesissa, kirjautuminen tiedostoon on huono idea.
Seuraava kohta, tässä haluan puhua tästä taas - koska koskemme hirsien aihetta, olisi hyvä puhua siitä, miltä tukkien pitäisi näyttää, jotta niiden kanssa työskentely olisi kätevää. Kuten sanoin, aihe ei liity suoraan Kubernetesiin, mutta se liittyy erittäin hyvin DevOps-aiheeseen. Aiheesta kehityskulttuuri ja ystävyys näiden kahden eri osaston - Dev ja Ops - välillä, jotta kaikilla olisi mukavaa.
Tämä tarkoittaa, että ihannetapauksessa lokit pitäisi nykyään kirjoittaa JSON-muodossa. Jos sinulla on jokin käsittämätön oma sovellus, joka kirjoittaa lokeja käsittämättömissä muodoissa, koska laitat sisään jonkinlaisen printin tai jotain sellaista, niin on aika googlettaa jonkinlainen kehys, jonkinlainen kääre, jolla voit toteuttaa normaalin kirjauksen; Ota lokiparametrit käyttöön JSONissa siellä, koska JSON on yksinkertainen muoto, sen jäsentäminen on yksinkertaista.
Jos JSON ei toimi joidenkin kriteerien mukaan, kukaan ei tiedä mitä, kirjoita ainakin lokit jäsennettävässä muodossa. Tässä kannattaa pikemminkin miettiä sitä tosiasiaa, että jos esimerkiksi käytät konttia tai vain prosesseja nginxillä, ja jokaisella on omat lokiasetukset, niin näyttää siltä, että sinun on erittäin hankalaa jäsentää niitä. Koska jokaista uutta nginx-esiintymää varten sinun on kirjoitettava oma jäsentimesi, koska ne kirjoittavat lokit eri tavalla. Jälleen, oli luultavasti syytä harkita varmistaa, että kaikilla näillä nginx-esiintymillä oli sama lokimääritys ja että ne kirjoittivat kaikki lokit täysin yhtenäisesti. Sama pätee ehdottomasti kaikkiin sovelluksiin.
Lopuksi haluan myös lisätä öljyä tuleen, että ihannetapauksessa monirivisiä lokeja tulisi välttää. Tässä on asia, jos olet koskaan työskennellyt hirsikeräilijöiden kanssa, olet todennäköisesti nähnyt, mitä he lupaavat sinulle, että he voivat työskennellä monilinjaisten tukkien kanssa, osaavat kerätä ne ja niin edelleen. Itse asiassa mielestäni yksikään kerääjä ei voi kerätä monirivisiä lokeja normaalisti, täysin ja ilman virheitä. Inhimillisesti niin, että se on kätevää ja virheetöntä.
Mutta pinojäljitys on aina monirivisiä lokeja ja miten niitä vältetään. Tässä on kysymys siitä, että loki on tapahtuman tietue, ja stactrace ei itse asiassa ole loki. Jos keräämme lokit ja laitamme ne jonnekin Elasticsearchiin ja sitten piirrämme niistä kaavioita, rakennamme joitain raportteja käyttäjien toiminnasta sivustollasi, niin kun saat pinon jäljen, se tarkoittaa, että jotain odottamatonta tapahtuu. Käsittelemätön tilanne sovelluksessasi. Ja on järkevää ladata pinojälki automaattisesti jonnekin järjestelmään, joka voi seurata niitä.
Tämä on ohjelmisto (sama Sentry), joka on tehty erityisesti toimimaan pinon jäljityksen kanssa. Se voi välittömästi luoda automaattisia tehtäviä, määrittää ne jollekin, hälyttää, kun stacttraces esiintyy, ryhmitellä nämä stacttraces yhden tyypin mukaan ja niin edelleen. Periaatteessa ei ole paljon järkeä puhua stactracesista, kun puhumme lokeista, koska nämä ovat loppujen lopuksi eri asioita, joilla on eri tarkoitus.
kokoonpano
Seuraavaksi puhumme Kubernetesin konfiguroinnista: mitä sille tehdään ja kuinka Kubernetesin sisällä olevat sovellukset tulisi määrittää. Yleensä sanon, että Docker ei ole konteista. Kaikki tietävät, että Dockerissa on kyse konteista, jopa ne, jotka eivät ole työskennelleet paljon Dockerin kanssa. Toistan, Docker ei koske kontteja.
Dockerissa on mielestäni kyse standardeista. Ja standardeja on käytännössä kaikelle: standardit sovelluksesi rakentamiselle, standardit sovelluksesi asentamiselle.
Ja tämä asia - käytimme sitä ennen, siitä tuli vain erityisen suosittu konttien myötä - tätä asiaa kutsutaan ENV (ympäristö) -muuttujiksi, eli käyttöjärjestelmässäsi oleviksi ympäristömuuttujiksi. Tämä on yleensä ihanteellinen tapa määrittää sovelluksesi, koska jos sinulla on sovelluksia JAVA-, Python-, Go-, Perl-kielillä, ja ne kaikki voivat lukea tietokannan isännän, tietokannan käyttäjän ja tietokannan salasanamuuttujia, se on ihanteellinen. Sinulla on sovelluksia neljällä eri kielellä määritettynä tietokantasuunnitelmassa samalla tavalla. Erilaisia konfiguraatioita ei enää ole.
Kaikki voidaan konfiguroida käyttämällä ENV-muuttujia. Kun puhumme Kubernetesista, on loistava tapa ilmoittaa ENV-muuttujat suoraan käyttöönoton sisällä. Vastaavasti, jos puhumme salaisista tiedoista, voimme välittömästi työntää salaiset tiedot ENV-muuttujista (salasanat tietokantoihin jne.) salaisuudeksi, luoda salaisen klusterin ja ilmoittaa käyttöönoton ENV-kuvauksessa, että emme suoraan ilmoita. tämän muuttujan arvo ja tämän tietokannan salasanamuuttujan arvo luetaan salaisuudesta. Tämä on normaalia Kubernetes-käyttäytymistä. Ja tämä on ihanteellinen vaihtoehto sovellusten määrittämiseen. Vain kooditasolla tämä koskee jälleen kehittäjiä. Jos olet DevOps, voit kysyä: "Kaverit, opeta sovelluksesi lukemaan ympäristömuuttujia. Ja me kaikki olemme onnellisia."
Jos kaikki yrityksessä lukevat samoja nimettyjä ympäristömuuttujia, se on hienoa. Jotta ei tapahdu niin, että jotkut odottavat postgres-tietokantaa, toiset odottavat tietokannan nimeä, toiset odottavat jotain muuta, toiset odottavat jonkinlaista dbn: tä, jotta vastaavasti olisi yhdenmukaisuutta.
Ongelma syntyy, kun sinulla on niin monta ympäristömuuttujaa, että avaat vain Deploymentin - ja ympäristömuuttujia on viisisataa riviä. Tässä tapauksessa olet yksinkertaisesti ylittänyt ympäristömuuttujat – etkä enää tarvitse kiduttaa itseäsi. Tässä tapauksessa olisi järkevää aloittaa asetusten käyttö. Eli kouluta sovelluksesi käyttämään asetuksia.
Ainoa kysymys on, että konfiguraatiot eivät ole sitä, mitä luulet. Config.pi ei ole kätevä käyttää. Tai jokin konfiguraatio omassa muodossa, vaihtoehtoisesti lahjakas - tämä ei myöskään ole se konfiguraatio, jota tarkoitan.
Puhun konfiguroinnista hyväksytyissä muodoissa, eli ylivoimaisesti suosituin standardi on .yaml-standardi. On selvää, kuinka se luetaan, se on ihmisten luettavissa, on selvää, kuinka se luetaan sovelluksesta.
Vastaavasti voit YAML:n lisäksi käyttää myös esimerkiksi JSON:ia, jäsentäminen on suunnilleen yhtä kätevää kuin YAML sovelluksen asetusten lukemisen kannalta. Lukeminen on ihmisten kannalta huomattavasti hankalampaa. Voit kokeilla muotoa, a la ini. Se on varsin kätevää lukea, ihmisen näkökulmasta, mutta voi olla hankalaa käsitellä sitä automaattisesti siinä mielessä, että jos haluat joskus luoda omia konfiguraatioita, ini-muoto voi jo olla hankalaa luoda.
Mutta joka tapauksessa valitsetpa minkä tahansa muodon, asia on, että Kubernetesin näkökulmasta se on erittäin kätevä. Voit laittaa koko kokoonpanosi Kubernetesiin ConfigMapiin. Ja sitten ota tämä konfiguraatiokartta ja pyydä se liitettäväksi podin sisälle johonkin tiettyyn hakemistoon, jossa sovelluksesi lukee konfiguraatiot tästä konfiguraatiokartasta ikään kuin se olisi vain tiedosto. Tämä on itse asiassa hyvä tehdä, kun sovelluksessasi on paljon konfigurointivaihtoehtoja. Tai se on vain jonkinlainen monimutkainen rakenne, siellä on pesiä.
Jos sinulla on konfiguraatiokartta, voit hyvin opettaa sovelluksesi esimerkiksi seuraamaan automaattisesti muutoksia tiedostossa, johon konfiguraatiokartta on asennettu, ja myös lataamaan sovelluksesi automaattisesti uudelleen asetusten muuttuessa. Tämä olisi yleensä ihanteellinen vaihtoehto.
Jälleen, olen jo puhunut tästä - salainen tieto ei ole konfiguraatiokartassa, salainen tieto ei ole muuttujissa, salainen tieto ei ole salaisuuksissa. Sieltä yhdistä nämä salaiset tiedot diplomatiaan. Yleensä tallennamme kaikki kuvaukset Kubernetes-objekteista, käyttöönotoista, konfiguraatiokartoista ja palveluista gitiin. Näin ollen salasanan asettaminen tietokantaan gitissä, vaikka se olisikin oma git, joka sinulla on yrityksen sisällä, on huono idea. Koska git ainakin muistaa kaiken, ja salasanojen poistaminen sieltä ei ole niin helppoa.
Terveystarkastus
Seuraava kohta on tämä terveystarkastus. Yleisesti ottaen terveystarkastus vain tarkistaa, että sovelluksesi toimii. Samaan aikaan puhumme useimmiten tietyistä verkkosovelluksista, joille vastaavasti terveystarkastuksen kannalta (on parempi olla kääntämättä täällä ja edelleen) tämä on jokin erityinen URL-osoite, jonka he käsittelevät standardi, he yleensä tekevät /health.
Kun käytät tätä URL-osoitetta, sovelluksemme sanoo joko "kyllä, okei, kaikki on kunnossa, 200" tai "ei, kaikki ei ole kunnossa minulle, noin 500". Näin ollen, jos sovelluksemme ei ole http, ei verkkosovellus, puhumme nyt jonkinlaisesta demonista, voimme selvittää, kuinka terveystarkastuksia tehdään. Eli ei ole välttämätöntä, jos sovellus ei ole http, niin kaikki toimii ilman terveystarkastusta, eikä tätä voi tehdä millään tavalla. Voit ajoittain päivittää joitain tiedoston tietoja, voit keksiä jonkin erityisen komennon demonillesi, kuten daemon status, joka sanoo "kyllä, kaikki on hyvin, demoni toimii, se on elossa."
Mitä varten se on? Ensimmäinen ja ilmeisin asia on luultavasti se, miksi terveystarkastus tarvitaan - ymmärtääksesi, että sovellus toimii. Tarkoitan, se on vain typerää, kun se on nyt päällä, se näyttää toimivan, joten voit olla varma, että se toimii. Ja käy ilmi, että sovellus on käynnissä, kontti on käynnissä, ilmentymä toimii, kaikki on hyvin - ja sitten käyttäjät ovat jo katkaisseet kaikki puhelinnumerot teknisestä tuesta ja sanoneet "mitä sinä olet..., sinä nukahdin, mikään ei toimi."
Terveystarkastus on juuri sellainen tapa nähdä käyttäjän näkökulmasta, että se toimii. Yksi menetelmistä. Laitetaan se näin. Kubernetesin näkökulmasta tämä on myös tapa ymmärtää, milloin sovellus käynnistyy, koska ymmärrämme, että on ero sen välillä, milloin kontti käynnistettiin, luotiin ja käynnistettiin, ja milloin sovellus käynnistettiin suoraan tässä säilössä. Koska jos otamme jonkin keskimääräisen java-sovelluksen ja yritämme käynnistää sen telakassa, niin se voi käynnistyä neljänkymmenen sekunnin tai jopa minuutin tai jopa kymmenen ajan. Tässä tapauksessa voit ainakin koputtaa sen portteihin, se ei vastaa siellä, eli se ei ole vielä valmis vastaanottamaan liikennettä.
Jälleen terveystarkastuksen avulla ja sen avulla, että olemme täällä käännettynä, voimme Kubernetesissa ymmärtää, että kontti ei ole noussut sovelluksessa, vaan sovellus itse on käynnistynyt, se vastaa jo terveystarkastus, mikä tarkoittaa, että voimme lähettää liikennettä sinne.
Se, mistä nyt puhun, on nimeltään Readiness/Liveness -testit Kubernetesissa, joten valmiustestimme vastaavat sovelluksen saatavuudesta tasapainotuksessa. Eli jos sovelluksessa tehdään valmiustestejä, niin kaikki on ok, asiakasliikenne menee sovellukseen. Jos valmiustestejä ei suoriteta, sovellus ei yksinkertaisesti osallistu, tämä tietty esiintymä ei osallistu tasapainottamiseen, se poistetaan tasapainotuksesta, asiakasliikenne ei kulje. Vastaavasti Kubernetesin Liveness-testejä tarvitaan, jotta jos sovellus juuttuu, se voidaan käynnistää uudelleen. Jos elävyystesti ei toimi Kubernetesissa ilmoitetulle sovellukselle, sovellusta ei vain poisteta tasapainotuksesta, vaan se käynnistetään uudelleen.
Ja tässä on tärkeä seikka, jonka haluan mainita: käytännön näkökulmasta valmiuskoetta käytetään yleensä useammin ja sitä tarvitaan useammin kuin elävyyskoetta. Eli yksinkertaisesti ajattelemattomasti sekä valmius- että elävyystestien julistaminen, koska Kubernetes pystyy siihen, ja käytettäkäämme kaikkea mitä se voi tehdä, ei ole kovin hyvä idea. Selitän miksi. Koska testauksen kohta kaksi on, että taustalla oleva palvelu olisi hyvä tarkistaa terveystarkastuksissa. Tämä tarkoittaa, että jos sinulla on verkkosovellus, joka antaa jotain tietoa, joka puolestaan on luonnollisesti otettava jostain. Esimerkiksi tietokannassa. No, se tallentaa tähän REST-sovellusliittymään tulevat tiedot samaan tietokantaan. Sitten vastaavasti, jos terveystarkistus vastaa yksinkertaisesti kuten ota yhteyttä slashhealthiin, sovellus sanoo "200, okei, kaikki on hyvin" ja samaan aikaan sovelluksesi tietokanta ei ole käytettävissä, ja terveystarkastussovellus sanoo "200, okei, kaikki on hyvin" ”- Tämä on huono terveystarkastus. Näin sen ei pitäisi toimia.
Eli hakemuksesi, kun siihen tulee pyyntö /health, se ei vain vastaa, "200, ok", se menee ensin esimerkiksi tietokantaan, yrittää muodostaa yhteyden siihen, tekee siellä jotain hyvin yksinkertaista, kuten valitse yksi, vain tarkistaa, että tietokantaan on yhteys. tietokanta ja voit tehdä kyselyjä tietokannasta. Jos kaikki tämä onnistui, vastaus on "200, ok". Jos se ei onnistu, se sanoo, että on virhe, tietokanta ei ole käytettävissä.
Siksi palaan tässä suhteessa taas valmius/elävyystesteihin - miksi todennäköisimmin tarvitset valmiuskokeen, mutta elävyyskoe on kyseenalainen. Koska jos kuvailet terveystarkastuksia täsmälleen niin kuin juuri sanoin, niin käy ilmi, että se ei ole saatavilla instanssiosassaв или со всех instanceesimerkiksi tietokannassa. Kun julistit valmiustestin, terveystarkastuksemme alkoivat epäonnistua, ja vastaavasti kaikki sovellukset, joista tietokanta ei ole käytettävissä, yksinkertaisesti sammutetaan tasapainottamisesta ja itse asiassa "roikkuvat" vain laiminlyötyssä tilassa ja odottavat tietokantaansa tehdä työtä.
Jos olemme julistaneet elävyystestin, kuvittele, että tietokanta on rikki ja Kubernetessi puolet kaikesta alkaa käynnistyä uudelleen, koska elävyystesti epäonnistuu. Tämä tarkoittaa, että sinun on käynnistettävä uudelleen. Tämä ei ole ollenkaan sitä, mitä haluat, minulla oli jopa omakohtaista kokemusta käytännössä. Meillä oli chat-sovellus, joka oli kirjoitettu JS:llä ja syötetty Mongo-tietokantaan. Ja ongelma oli siinä, että Kubernetesin kanssa työskentelyni alussa kuvailimme testien valmiutta, elävyyttä sillä periaatteella, että Kubernetes pystyy tekemään sen, joten käytämme sitä. Näin ollen Mongosta tuli jossain vaiheessa hieman "tylsää" ja näyte alkoi epäonnistua. Näin ollen sadetestin mukaan palot alkoivat "tappaa".
Kuten ymmärrät, kun heidät "tappataan", tämä on chat, eli siinä on paljon yhteyksiä asiakkailta. Heidät myös "tappataan" - ei, ei asiakkaita, vain yhteyksiä - ei kaikkia samaan aikaan, ja koska heitä ei tapeta samaan aikaan, jotkut aikaisemmin, jotkut myöhemmin, ne eivät ala samaan aikaan. aika. Lisäksi tavallinen satunnainen, emme voi ennustaa millisekunnin tarkkuudella sovelluksen alkamisaikaa joka kerta, joten he tekevät sen yksi instanssi kerrallaan. Yksi infopiste nousee, lisätään tasapainotukseen, kaikki asiakkaat tulevat sinne, se ei kestä sellaista kuormaa, koska se on yksin, ja karkeasti sanottuna niitä on siellä töissä kymmenkunta, ja se putoaa. Seuraava nousee, koko kuorma on hänen päällä, hän myös putoaa. No, nämä putoukset vain jatkavat kaskadeja. Lopulta kuinka tämä ratkesi - meidän piti vain pysäyttää käyttäjäliikenne tähän sovellukseen tiukasti, antaa kaikkien esiintymien nousta ja sitten aloittaa kaikki käyttäjäliikenne kerralla niin, että se oli jo jaettu kaikkien kymmenen esiintymän kesken.
Jos tätä elävyystestiä ei olisi julkistettu, mikä pakottaisi kaiken käynnistymään uudelleen, sovellus olisi hoitanut sen hienosti. Mutta kaikki tasapainotuksesta on meiltä poissa käytöstä, koska tietokannat ovat saavuttamattomissa ja kaikki käyttäjät ovat "pudonneet". Sitten kun tämä tietokanta tulee saataville, kaikki sisältyy tasapainotukseen, mutta sovellusten ei tarvitse käynnistyä uudelleen, eikä siihen tarvitse tuhlata aikaa ja resursseja. Ne ovat kaikki jo täällä, ne ovat valmiita liikenteeseen, joten liikenne vain avautuu, kaikki on hyvin - sovellus on paikallaan, kaikki toimii edelleen.
Siksi valmius- ja elävyyskokeet ovat erilaisia, vieläkin teoriassa voi tehdä erilaisia terveystarkastuksia, esimerkiksi yhden tyypin säteitä, yhden tyypin eläviä ja tarkastaa erilaisia asioita. Tarkista taustajärjestelmäsi valmiustestien aikana. Ja esimerkiksi elävyystestissä ei tarkisteta siltä kannalta, että elävyystesti on yleensä vain sovellus, joka vastaa, jos se pystyy vastaamaan ollenkaan.
Koska elävyystesti on suurelta osin silloin, kun olemme "jumissa". Loputon silmukka on alkanut tai jotain muuta - eikä enempää pyyntöjä käsitellä. Siksi on järkevää jopa erottaa ne - ja toteuttaa niissä erilainen logiikka.
Mitä sinun on vastattava, kun sinulla on testi, kun teet terveystarkastuksia. Se on vain todella tuskaa. Asian tuntevat varmaan nauravat - mutta vakavasti, olen nähnyt elämässäni palveluita, jotka vastaavat "200" XNUMX% tapauksista. Eli kuka menestyy. Mutta samaan aikaan vastauksen runkoon he kirjoittavat "sellaisen ja sellaisen virheen".
Eli vastaustila tulee sinulle - kaikki onnistuu. Mutta samalla sinun on jäsennettävä keho, koska keho sanoo "anteeksi, pyyntö päättyi virheeseen" ja tämä on vain todellisuutta. Näin tämän tosielämässä.
Ja jotta jotkut ihmiset eivät pidä sitä hauskana, ja toisten mielestä se on erittäin tuskallista, kannattaa silti noudattaa yksinkertaista sääntöä. Terveystarkastuksissa ja periaatteessa verkkosovellusten kanssa työskennellessä.
Jos kaikki meni hyvin, vastaa kahdessasadassa vastauksella. Periaatteessa mikä tahansa kahden sadasosan vastaus sopii sinulle. Jos luet räsyä erittäin hyvin ja tiedät, että jotkut vastaustilat poikkeavat muista, vastaa oikealla: 204, 5, 10, 15, mikä tahansa. Jos se ei ole kovin hyvä, niin vain "kaksi nolla nolla". Jos kaikki menee huonosti ja terveystarkastus ei vastaa, vastaa millä tahansa viidellä sadasosalla. Jälleen, jos ymmärrät kuinka vastata, kuinka eri vastaustilat eroavat toisistaan. Jos et ymmärrä, 502 on vaihtoehtosi vastata terveystarkastuksiin, jos jokin menee pieleen.
Tämä on toinen kohta, haluan palata hieman taustapalvelujen tarkistamiseen. Jos aloitat esimerkiksi kaikkien sovelluksesi taustalla olevien palveluiden tarkistamisen - kaiken yleensä. Mitä saamme mikropalveluarkkitehtuurin näkökulmasta, meillä on sellainen käsite kuin "low coupling" - eli kun palvelusi ovat minimaalisesti riippuvaisia toisistaan. Jos yksi niistä epäonnistuu, kaikki muut ilman tätä toimintoa jatkavat toimintaansa. Osa toiminnoista ei vain toimi. Vastaavasti, jos sitoat kaikki terveystarkastukset toisiinsa, päädyt siihen, että yksi asia putoaa infrastruktuurissa, ja koska se kaatui, myös kaikkien palveluiden terveystarkastukset alkavat epäonnistua - ja infrastruktuuria on yleensä enemmän koko mikropalveluarkkitehtuuri nro. Siellä kaikki pimeni.
Siksi haluan toistaa tämän uudelleen, että sinun on tarkistettava taustalla olevat palvelut, joita ilman hakemuksesi ei sataprosenttisesti tapauksista voi hoitaa tehtäväänsä. Eli on loogista, että jos sinulla on REST API, jonka kautta käyttäjä tallentaa tietokantaan tai hakee tietokannasta, niin tietokannan puuttuessa et voi taata käyttäjien kanssa toimimista.
Mutta jos käyttäjäsi, kun poistat heidät tietokannasta, rikastuvat lisäksi jollain muulla metatiedolla toisesta taustajärjestelmästä, jotka syötät ennen vastauksen lähettämistä käyttöliittymälle - ja tämä taustajärjestelmä ei ole käytettävissä, tämä tarkoittaa, että annat vastaa ilman mitään osaa metatiedoista.
Seuraavaksi meillä on myös yksi tuskallisista ongelmista sovellusten käynnistämisessä.
Itse asiassa tämä ei päde vain Kubernetesiin yleisesti, vaan sattui niin, että jonkinlaisen massakehityksen kulttuuri ja erityisesti DevOps alkoivat levitä suunnilleen samaan aikaan kuin Kubernetes. Siksi yleisesti ottaen käy ilmi, että sinun on suljettava sovelluksesi sulavasti ilman Kubernetesia. Jo ennen Kubernetesia ihmiset tekivät näin, mutta Kubernetesin myötä aloimme puhua siitä massiivisesti.
Graceful sammutus
Yleisesti, mikä on Graceful Shutdown ja miksi sitä tarvitaan? Tässä on kyse siitä, kun sovelluksesi kaatuu jostain syystä, sinun on tehtävä app stop - tai saat esimerkiksi signaalin käyttöjärjestelmästä, sovelluksesi täytyy ymmärtää se ja tehdä asialle jotain. Pahin tapaus on tietysti, kun hakemuksesi saa SIGTERM-ilmoituksen ja on kuin "SIGTERM, odotellaan, tee työtä, älä tee mitään". Tämä on todella huono vaihtoehto.
Melkein yhtä huono vaihtoehto on, kun hakemuksesi vastaanottaa SIGTERM ja on kuin "he sanoivat segterm, se tarkoittaa, että olemme lopettamassa, en ole nähnyt, en tiedä käyttäjien pyyntöjä, en tiedä millaisia pyyntöjä, joita olen parhaillaan työstämässä, he sanoivat SIGTERM, mikä tarkoittaa, että olemme lopettamassa " Tämä on myös huono vaihtoehto.
Kumpi vaihtoehto on hyvä? Ensimmäinen kohta on ottaa huomioon toimintojen valmistuminen. Hyvä vaihtoehto on, että palvelimesi ottaa silti huomioon, mitä se tekee, jos se vastaanottaa SIGTERM-ilmoituksen.
SIGTERM on pehmeä sammutus, se on erityisesti suunniteltu, se voidaan siepata kooditasolla, se voidaan käsitellä, sano, että nyt, odota, teemme ensin valmiit työt, sitten poistumme.
Kubernetesin näkökulmasta se näyttää tältä. Kun sanomme Podille, joka on käynnissä Kubernetes-klusterissa, "pysähdy, mene pois" tai meidät käynnistetään uudelleen tai päivitys tapahtuu, kun Kubernetes luo podit uudelleen, Kubernetes lähettää podille saman SIGTERM-viestin ja odottaa jonkin aikaa, ja , tämä on aika, jolloin hän odottaa, se on myös määritetty, tutkintotodistuksessa on sellainen erityinen parametri ja sitä kutsutaan Graceful ShutdownTimeoutiksi. Kuten ymmärrät, sitä ei turhaan kutsuta, emmekä turhaan puhu siitä nyt.
Siellä voimme nimenomaan sanoa, kuinka kauan meidän on odotettava SIGTERM-sovellukselle lähettämisen ja sen hetken välillä, jolloin ymmärrämme, että sovellus näyttää olevan sekaisin johonkin tai on "jumiutunut" eikä se lopu - ja meidän on lähetä se SIGKILL, eli saa kovasti valmiiksi työnsä. Eli meillä on siis jonkinlainen demoni käynnissä, se käsittelee toimintoja. Ymmärrämme, että toimintamme, jossa demoni työskentelee, eivät kestä keskimäärin yli 30 sekuntia kerrallaan. Vastaavasti, kun SIGTERM saapuu, ymmärrämme, että demonimme voi lopettaa korkeintaan 30 sekuntia SIGTERM:n jälkeen. Kirjoitamme siihen esimerkiksi 45 sekuntia varmuuden vuoksi ja sanomme, että SIGTERM. Sen jälkeen odotamme 45 sekuntia. Teoriassa tänä aikana demonin olisi pitänyt suorittaa työnsä ja lopettaa itsensä. Mutta jos se ei yhtäkkiä pystynyt, se tarkoittaa, että se on todennäköisesti jumissa – se ei enää käsittele pyyntöjämme normaalisti. Ja 45 sekunnissa voit itse asiassa turvallisesti naulata hänet.
Ja tässä voidaan itse asiassa ottaa huomioon jopa 2 näkökohtaa. Ensinnäkin, ymmärrä, että jos sait pyynnön, aloit työskennellä sen kanssa jotenkin etkä vastannut käyttäjälle, mutta sait esimerkiksi SIGTERM. On järkevää tarkentaa sitä ja antaa vastaus käyttäjälle. Tämä on kohta ykkönen tässä suhteessa. Kohta kaksi tässä on, että jos kirjoitat oman sovelluksesi, rakennat yleensä arkkitehtuurin siten, että saat hakemuksesi pyynnön, sitten aloitat työt, alat ladata tiedostoja jostain, lataat tietokantaa ja mitä muuta. Että. Yleensä käyttäjäsi, pyyntösi roikkuu puoli tuntia ja odottaa, että vastaat hänelle - sitten todennäköisesti sinun on työstettävä arkkitehtuuria. Eli ota huomioon jopa maalaisjärki, että jos toimintasi ovat lyhyitä, on järkevää jättää SIGTERM huomioimatta ja muokata sitä. Jos operaatiosi ovat pitkiä, ei ole mitään järkeä jättää SIGTERM huomioimatta tässä tapauksessa. On järkevää suunnitella arkkitehtuuri uudelleen näin pitkien toimintojen välttämiseksi. Jotta käyttäjät eivät vain jäädä odottamaan. En tiedä, tee sinne joku websocket, tee käänteiset koukut, jotka palvelimesi lähettää jo asiakkaalle, mitä tahansa muuta, mutta älä pakota käyttäjää roikkumaan puoli tuntia ja odota vain istuntoa, kunnes vastaa hänelle. Koska on arvaamatonta, missä se voi rikkoutua.
Kun sovelluksesi päättyy, sinun tulee antaa sopiva poistumiskoodi. Eli jos sovellustasi pyydettiin sulkeutumaan, pysähtymään ja se pystyi pysähtymään normaalisti, sinun ei tarvitse palauttaa jonkinlaista poistumiskoodia 1,5,255 ja niin edelleen. Kaikki mikä ei ole nollakoodia, ainakin Linux-järjestelmissä, olen varma tästä, katsotaan epäonnistuneeksi. Toisin sanoen katsotaan, että hakemuksesi tässä tapauksessa päättyi virheeseen. Vastaavasti, jos hakemuksesi valmistui ilman virhettä, sanot sovinnolla 0 tulosteen. Jos sovelluksesi epäonnistuu jostain syystä, sanot ei-0 tulosteessa. Ja voit työskennellä näiden tietojen kanssa.
Ja viimeinen vaihtoehto. On huonoa, kun käyttäjä lähettää pyynnön ja jumittuu puoli tuntia, kun käsittelet sitä. Mutta yleisesti ottaen haluaisin sanoa myös siitä, mikä yleensä on asiakkaan puolelta sen arvoista. Sillä ei ole väliä, onko sinulla mobiilisovellus, käyttöliittymä tms. On otettava huomioon, että yleensä käyttäjän istunto voidaan lopettaa, mitä tahansa voi tapahtua. Pyyntö voidaan lähettää esimerkiksi alikäsiteltynä, eikä vastausta palauteta. Käyttöliittymäsi tai mobiilisovelluksesi - mikä tahansa käyttöliittymä yleensä, sanotaanpa se näin - pitäisi ottaa tämä huomioon. Jos työskentelet websockettien kanssa, tämä on yleensä pahin kipu, mitä minulla on koskaan ollut.
Kun joidenkin tavallisten keskustelujen kehittäjät eivät tiedä sitä, käy ilmi, että verkkopistoke voi rikkoutua. Heille, kun välityspalvelimella tapahtuu jotain, muutamme vain konfiguraatiota, ja se lataa uudelleen. Luonnollisesti kaikki pitkäikäiset istunnot ovat tässä tapauksessa repeytyneet. Kehittäjät juoksevat luoksemme ja sanovat: "Kaverit, mitä te teette, kaikkien asiakkaidemme chat on katkennut!" Kerromme heille: "Mitä sinä teet? Eivätkö asiakkaasi pysty muodostamaan yhteyttä uudelleen? He sanovat: "Ei, meidän ei tarvitse repiä istuntoja." Lyhyesti sanottuna tämä on todella hölynpölyä. Asiakaspuoli on otettava huomioon. Erityisesti, kuten sanon, pitkäikäisten istuntojen, kuten websockettien, yhteydessä se voi rikkoutua, ja käyttäjän huomaamatta tällaiset istunnot on voitava asentaa uudelleen. Ja sitten kaikki on täydellistä.
voimavarat
Itse asiassa, tässä kerron sinulle vain suoran tarinan. Jälleen tosielämästä. Sairain asia, jonka olen koskaan kuullut resursseista.
Resurssit tässä tapauksessa tarkoitan jonkinlaisia pyyntöjä, rajoituksia, joita voit asettaa Kubernetes-klusterien podille. Hauskin asia, jonka olen kuullut kehittäjältä... Eräs kehittäjätovereistani edellisessä työpaikassa sanoi kerran: "Sovellukseni ei käynnisty klusterissa." Katsoin, ettei se käynnisty, mutta joko se ei mahtunut resursseihin tai he olivat asettaneet hyvin pienet rajat. Lyhyesti sanottuna sovellus ei voi käynnistyä resurssien vuoksi. Sanon: "Se ei lähde käyntiin resurssien takia, sinä päätät kuinka paljon tarvitset ja asetat riittävän arvon." Hän sanoo: "Millaisia resursseja?" Aloin selittää hänelle, että Kubernetes, rajoitukset pyyntöille ja blaa, bla, bla on asetettava. Mies kuunteli viisi minuuttia, nyökkäsi ja sanoi: ”Tulin tänne kehittäjäksi, en halua tietää mitään resursseista. Tulin tänne kirjoittamaan koodia ja siinä se." Se on surullista. Tämä on erittäin surullinen käsite kehittäjän näkökulmasta. Varsinkin nykymaailmassa, niin sanotusti progressiivisten devoppien maailmassa.
Miksi resursseja ylipäätään tarvitaan? Kubernetesissa on kahdenlaisia resursseja. Joitakin kutsutaan pyynnöiksi, toisia rajoituksiksi. Resursseilla ymmärrämme, että periaatteessa on aina vain kaksi perusrajoitusta. Toisin sanoen suorittimen aikarajat ja RAM-rajoitukset Kubernetesissa toimivalle säilölle.
Raja asettaa ylärajan sille, kuinka resurssia voidaan käyttää sovelluksessasi. Eli jos sanot 1 Gt RAM-muistia rajoissa, sovelluksesi ei voi käyttää enempää kuin 1 Gt RAM-muistia. Ja jos hän yhtäkkiä haluaa ja yrittää tehdä tämän, prosessi nimeltä oom killer, muisti loppuu, eli tulee ja tappaa sovelluksesi - eli se yksinkertaisesti käynnistyy uudelleen. Sovellukset eivät käynnisty uudelleen suorittimen perusteella. Mitä tulee suorittimeen, jos sovellus yrittää käyttää paljon, enemmän kuin rajoituksissa on määritelty, CPU valitaan tiukasti. Tämä ei johda uudelleenkäynnistyksiin. Tämä on raja - tämä on yläraja.
Ja pyyntöä on. Pyyntö kertoo, kuinka Kubernetes ymmärtää, kuinka Kubernetes-klusterisi solmut täytetään sovelluksilla. Toisin sanoen pyyntö on eräänlainen hakemuksesi sitoumus. Siinä lukee, mitä haluan käyttää: "Haluaisin, että varaat minulle näin paljon prosessoria ja näin paljon muistia." Niin yksinkertainen analogia. Entä jos meillä on solmu, jossa on, en tiedä, yhteensä 8 CPU:ta. Ja sinne saapuu pod, jonka pyynnöt sanovat 1 CPU, mikä tarkoittaa, että solmulla on 7 CPU:ta jäljellä. Eli heti kun 8 podia saapuu tähän solmuun, joista jokaisella on 1 CPU pyynnöissään, solmun CPU on loppunut, ikään kuin Kubernetesin näkökulmasta katsottuna, eikä enempää podeja, joissa on pyyntöjä käynnistetty tässä solmussa. Jos kaikista solmuista loppuu CPU, Kubernetes alkaa sanoa, että klusterissa ei ole sopivia solmuja podien suorittamiseen, koska suoritin on loppunut.
Miksi pyyntöjä tarvitaan ja miksi ilman pyyntöjä ei mielestäni tarvitse käynnistää mitään Kubernetesissa? Kuvitellaanpa hypoteettinen tilanne. Käynnistät sovelluksesi ilman pyyntöjä, Kubernetes ei tiedä kuinka paljon mitä sinulla on, mihin solmuihin voit työntää sen. No, hän työntää, työntää, työntää solmujen päälle. Jossain vaiheessa alat saada liikennettä sovellukseesi. Ja yksi sovelluksista alkaa yhtäkkiä käyttää resursseja rajojen mukaan. Osoittautuu, että lähellä on toinen sovellus ja sekin tarvitsee resursseja. Solmun resurssit alkavat fyysisesti loppua, esimerkiksi OP. Solmun resurssit, esimerkiksi hajasaantimuisti (RAM) alkavat itse asiassa loppua. Kun solmun teho loppuu, ensin telakka lakkaa vastaamasta, sitten kuutio ja sitten käyttöjärjestelmä. Ne yksinkertaisesti menevät tajuttomaksi ja KAIKKI lakkaa varmasti toimimasta puolestasi. Eli tämä johtaa siihen, että solmu juuttuu ja sinun on käynnistettävä se uudelleen. Lyhyesti sanottuna tilanne ei ole kovin hyvä.
Ja kun sinulla on pyyntöjä, rajat eivät ole kovin erilaisia, ainakaan ei monta kertaa enempää kuin rajat tai pyynnöt, niin sinulla voi olla niin normaali, järkevä hakemusten täyttäminen Kubernetes-klusterien solmujen yli. Samalla Kubernetes on suunnilleen tietoinen siitä, kuinka paljon mitä se laittaa minne, kuinka paljon mitä missä käytetään. Eli se on vain sellainen hetki. On tärkeää ymmärtää se. Ja on tärkeää valvoa, että tämä ilmoitetaan.
Tietovarasto
Seuraava kohta koskee tietojen tallennusta. Mitä tehdä niille ja ylipäätään, mitä tehdä sinnikkyydellä Kubernetesissa?
Luulen jälleen, meidän sisällämme , Kubernetesissa oli aihe tietokannasta. Ja minusta tuntuu, että tiedän jopa karkeasti, mitä kollegasi sanoivat, kun heiltä kysyttiin: "Onko mahdollista käyttää tietokantaa Kubernetesissa?" Jostain syystä minusta tuntuu, että kollegojesi olisi pitänyt kertoa sinulle, että jos kysyt, onko mahdollista käyttää tietokantaa Kubernetesissa, se on mahdotonta.
Logiikka tässä on yksinkertainen. Selitän varmuuden vuoksi vielä kerran, jos olet todella siisti kaveri, joka osaa rakentaa melko vikasietoisen hajautetun verkkotallennusjärjestelmän, ymmärrä, kuinka tietokanta sovitetaan tähän tapaukseen, kuinka konteissa olevan pilven pitäisi toimia. tietokannassa yleensä. Todennäköisesti sinulla ei ole kysyttävää siitä, kuinka se suoritetaan. Jos sinulla on tällainen kysymys ja haluat varmistaa, että se kaikki avautuu ja seisoo kuoliaaksi tuotannossa eikä koskaan putoa, niin näin ei tapahdu. Tällä lähestymistavalla ammut taatusti itseäsi jalkaan. Joten on parempi olla tekemättä.
Mitä tehdä tiedoille, jotka sovelluksemme haluaisi tallentaa, joillekin käyttäjien lataamille kuville, joillekin asioille, joita sovelluksemme luo toimintansa aikana, esimerkiksi käynnistyksen yhteydessä? Mitä tehdä niille Kubernetesissa?
Yleisesti ottaen ihannetapauksessa, kyllä, tietysti Kubernetes on erittäin hyvin suunniteltu ja yleensä alun perin suunniteltu valtiottomille sovelluksille. Eli niille sovelluksille, jotka eivät tallenna tietoja ollenkaan. Tämä on ihanteellinen.
Mutta tietenkään ihanteellinen vaihtoehto ei aina ole olemassa. Mitä sitten? Ensimmäinen ja yksinkertaisin kohta on ottaa jonkinlainen S3, ei vain kotitekoinen, mikä on myös epäselvää, miten se toimii, vaan joltain palveluntarjoajalta. Hyvä, normaali palveluntarjoaja - ja opeta sovelluksesi käyttämään S3:a. Eli kun käyttäjä haluaa ladata tiedoston, sano "tähän, ole hyvä ja lataa se S3:een." Kun hän haluaa vastaanottaa sen, sano: "Tässä on linkki S3:een takaisin ja ota se täältä." Tämä on ihanteellinen.
Jos tämä ihanteellinen vaihtoehto ei jostain syystä äkillisesti sovi, sinulla on sovellus, jota et ole kirjoittanut, jota et kehitä tai se on jonkinlainen kauhea perintö, se ei voi käyttää S3-protokollaa, mutta sen on toimittava paikallisten hakemistojen kanssa. paikalliset kansiot. Ota jotain enemmän tai vähemmän yksinkertaista, ota Kubernetes käyttöön. Toisin sanoen Ceph-miekkailu heti pieniin tehtäviin on minusta huono idea. Koska Ceph on tietysti hyvä ja muodikas. Mutta jos et todellakaan ymmärrä mitä olet tekemässä, niin kun laitat jotain Cephiin, voit helposti ja yksinkertaisesti koskaan saada sitä sieltä pois. Koska, kuten tiedät, Ceph tallentaa tiedot klusteriinsa binäärimuodossa, ei yksinkertaisten tiedostojen muodossa. Siksi, jos Ceph-klusteri yhtäkkiä hajoaa, on täydellinen ja suuri todennäköisyys, että et koskaan saa tietojasi sieltä enää.
Meillä on Ceph-kurssi, voit .
Siksi on parempi tehdä jotain yksinkertaista, kuten NFS-palvelin. Kubernetes voi toimia niiden kanssa, voit asentaa hakemiston NFS-palvelimen alle - sovelluksesi on aivan kuin paikallinen hakemisto. Samanaikaisesti sinun on luonnollisesti ymmärrettävä, että sinun on jälleen tehtävä jotain NFS:si kanssa, sinun on ymmärrettävä, että joskus se voi muuttua saavuttamattomaksi, ja harkita kysymystä siitä, mitä aiot tehdä tässä tapauksessa. Ehkä se pitäisi varmuuskopioida jonnekin erilliselle koneelle.
Seuraava kohta, josta puhuin, on mitä tehdä, jos sovelluksesi luo tiedostoja käytön aikana. Esimerkiksi käynnistyessään se luo staattisen tiedoston, joka perustuu joihinkin tietoihin, jotka sovellus vastaanottaa vasta käynnistyksen yhteydessä. Mikä hetki. Jos tällaisia tietoja ei ole paljon, sinun ei tarvitse vaivautua ollenkaan, vain asenna tämä sovellus itsellesi ja työskentele. Ainoa kysymys tässä on mitä, katso. Hyvin usein kaikenlaiset vanhat järjestelmät, kuten WordPress ja niin edelleen, varsinkin muokatuilla fiksuilla liitännöillä, älykkäillä PHP-kehittäjillä, he usein osaavat tehdä sen niin, että he luovat jonkinlaisen tiedoston itselleen. Vastaavasti toinen luo yhden tiedoston, toinen toisen tiedoston. He ovat erilaisia. Tasapainottaminen tapahtuu asiakkaiden Kubernetes-klusterissa yksinkertaisesti sattumalta. Näin ollen käy ilmi, että he eivät esimerkiksi osaa työskennellä yhdessä. Toinen antaa yhtä tietoa, toinen antaa käyttäjälle toisen tiedon. Tätä sinun tulee välttää. Eli Kubernetesissa kaikki käynnistämäsi voi taatusti toimia useissa tapauksissa. Koska Kubernetes on liikuttava asia. Näin ollen hän voi siirtää mitä tahansa, milloin tahansa, kysymättä keneltäkään. Siksi sinun täytyy luottaa tähän. Kaikki yhdessä tapauksessa käynnistetty epäonnistuu ennemmin tai myöhemmin. Mitä enemmän varauksia sinulla on, sen parempi. Mutta taas sanon, että jos sinulla on muutamia tällaisia tiedostoja, voit laittaa ne suoraan alle, ne painavat pienen määrän. Jos niitä on vähän enemmän, sinun ei luultavasti kannata työntää niitä säiliöön.
Suosittelen, että Kubernetesissa on niin ihana asia, voit käyttää äänenvoimakkuutta. Erityisesti on olemassa volyymi tyyppiä tyhjä dir. Eli Kubernetes luo automaattisesti hakemiston palveluhakemistoihinsa palvelimelle, josta aloitit. Ja hän antaa sen sinulle, jotta voit käyttää sitä. On vain yksi tärkeä kohta. Toisin sanoen tietojasi ei tallenneta säilöön, vaan isäntään, jossa käytät. Lisäksi Kubernetes voi hallita tällaisia tyhjiä kansioita normaalissa kokoonpanossa ja pystyy hallitsemaan niiden enimmäiskokoa eikä sallia sen ylittämistä. Ainoa asia on, että tyhjään diriin kirjoittamasi ei katoa pod-uudelleenkäynnistyksen aikana. Eli jos pod putoaa vahingossa ja nousee uudelleen, tyhjän kansion tiedot eivät katoa mihinkään. Hän voi käyttää sitä uudelleen uudessa alussa - ja se on hyvä. Jos pod lähtee jonnekin, hän lähtee luonnollisesti ilman tietoja. Toisin sanoen heti, kun sen solmun pod, josta se käynnistettiin tyhjällä dir:llä, katoaa, tyhjä dir poistetaan.
Mitä muuta hyvää tyhjässä dirissä on? Sitä voidaan käyttää esimerkiksi välimuistina. Kuvitellaan, että sovelluksemme luo jotain lennossa, antaa sen käyttäjille ja tekee sitä pitkään. Siksi sovellus esimerkiksi generoi ja antaa sen käyttäjille ja samalla tallentaa sen jonnekin, jotta seuraavan kerran kun käyttäjä tulee hakemaan samaa, on nopeampi antaa se heti generoituna. Tyhjä dir voidaan pyytää Kubernetesin luomaan muistiin. Ja näin ollen välimuistisi voivat yleensä toimia salamannopeasti - mitä tulee levyn käyttönopeuteen. Eli sinulla on tyhjä dir muistissa, käyttöjärjestelmässä se on tallennettu muistiin, mutta sinulle, podin sisällä olevalle käyttäjälle, se näyttää vain paikalliselta hakemistolta. Et tarvitse sovellusta taikuuden opettamiseen. Otat vain suoraan ja laitat tiedostosi hakemistoon, mutta itse asiassa käyttöjärjestelmän muistiin. Tämä on myös erittäin kätevä ominaisuus Kubernetesin kannalta.
Mitä ongelmia Miniolla on? Minion suurin ongelma on, että jotta tämä toimisi, sen on oltava käynnissä jossain ja jonkinlainen tiedostojärjestelmä, eli tallennustila, täytyy olla. Ja täällä kohtaamme samat ongelmat kuin Cephillä. Eli Minion on tallennettava tiedostonsa jonnekin. Se on yksinkertaisesti HTTP-liitäntä tiedostoillesi. Lisäksi toiminnallisuus on selvästi huonompi kuin Amazonin S3:ssa. Aiemmin se ei pystynyt valtuuttamaan käyttäjää kunnolla. Nyt tietääkseni se voi jo luoda kauhoja erilaisilla valtuuksilla, mutta taas minusta näyttää siltä, että suurin ongelma on niin sanotusti taustalla oleva tallennusjärjestelmä.
Miten Tyhjä dir muistissa vaikuttaa rajoihin? Ei vaikuta rajoituksiin millään tavalla. Se sijaitsee isännän muistissa, ei säilösi muistissa. Toisin sanoen säiliösi ei näe tyhjää hakemistoa muistissa osana varattua muistia. Isäntä näkee tämän. Vastaavasti kyllä, kuberneteksen näkökulmasta, kun aloitat tämän käytön, olisi hyvä ymmärtää, että omistat osan muististasi tyhjälle dirille. Ja vastaavasti, ymmärrä, että muisti voi loppua paitsi sovellusten takia, myös siksi, että joku kirjoittaa näihin tyhjiin kansioihin.
Pilvisyys
Ja viimeinen ala-aihe on se, mitä Cloudnative on. Miksi sitä tarvitaan? Pilvisyys ja niin edelleen.
Eli ne sovellukset, jotka ovat valmiita ja kirjoitettuja toimimaan nykyaikaisessa pilviinfrastruktuurissa. Mutta itse asiassa Cloudnativella on toinen tällainen näkökohta. Että tämä ei ole vain sovellus, joka ottaa huomioon kaikki nykyaikaisen pilviinfrastruktuurin vaatimukset, vaan osaa myös työskennellä tämän modernin pilviinfrastruktuurin kanssa, hyödyntää sen edut ja haitat, että se toimii näissä pilvissä. Älä mene yli laidan ja työskentele pilvissä, vaan hyödynnä pilvityöskentelyn edut.
Otetaan vaikka Kubernetes esimerkkinä. Sovelluksesi on käynnissä Kubernetesissa. Sovelluksesi, tai pikemminkin sovelluksesi ylläpitäjät, voivat aina luoda palvelutilin. Eli tili valtuutusta varten itse Kubernetesissa sen palvelimella. Lisää siihen joitain oikeuksia, joita tarvitsemme. Ja voit käyttää Kubernetesia sovelluksestasi. Mitä voit tehdä tällä tavalla? Saat esimerkiksi sovelluksesta tietoja siitä, missä muut sovelluksesi, muut vastaavat ilmentymät sijaitsevat, ja klusteroitua yhdessä jotenkin Kubernetesin päälle, jos sellainen tarve on.
Jälleen kerran, meillä oli kirjaimellisesti tapaus äskettäin. Meillä on yksi ohjain, joka valvoo jonoa. Ja kun tähän jonoon tulee uusia tehtäviä, se siirtyy Kubernetesiin - ja Kubernetesiin se luo uuden pod. Antaa tälle podille uuden tehtävän ja tämän podin puitteissa pod suorittaa tehtävän, lähettää vastauksen itse ohjaimelle ja sitten ohjain tekee jotain näillä tiedoilla. Se esimerkiksi lisää tietokannan. Tämä on jälleen plussa siitä, että sovelluksemme toimii Kubernetesissa. Voimme käyttää itse sisäänrakennettua Kubernetes-toimintoa laajentaaksemme ja tehdäksemme sovelluksemme toimivuudesta jotenkin mukavampaa. Eli älä piilota jonkinlaista taikuutta sovelluksen käynnistämisestä tai työntekijän käynnistämisestä. Kubernetesissa lähetät vain pyynnön sovelluksessa, jos sovellus on kirjoitettu Pythonilla.
Sama pätee, jos menemme Kubernetesin ulkopuolelle. Meillä on Kubernetes jossain käynnissä - on hyvä, jos se on jossain pilvessä. Jälleen voimme käyttää, ja uskon, että meidän pitäisi jopa käyttää itse pilven ominaisuuksia siellä, missä toimimme. Niistä alkeisasioista, joita pilvi meille tarjoaa. Balancing, eli voimme luoda pilven tasapainottajia ja käyttää niitä. Tämä on suora etu siitä, mitä voimme käyttää. Koska pilvitasapainotus ensinnäkin yksinkertaisesti tyhmästi poistaa meiltä vastuun siitä, miten se toimii, miten se on konfiguroitu. Lisäksi se on erittäin kätevä, koska tavalliset Kubernetes voivat integroitua pilviin.
Sama pätee skaalaukseen. Tavallinen Kubernetes voidaan integroida pilvipalveluntarjoajien kanssa. Tietää kuinka ymmärtää, että jos klusterin solmut loppuvat, eli solmutila on loppunut, sinun on lisättävä - Kubernetes itse lisää uusia solmuja klusteriisi ja alkaa käynnistää podeja niihin. Eli kun kuormasi tulee, tulisijojen määrä alkaa kasvaa. Kun klusterin solmut loppuvat näille podille, Kubernetes käynnistää uusia solmuja ja vastaavasti podien määrä voi vielä kasvaa. Ja se on erittäin kätevä. Tämä on suora mahdollisuus skaalata klusteria lennossa. Ei kovin nopea, siinä mielessä, että se ei ole sekunti, se on enemmän kuin minuutti uusien solmujen lisäämiseen.
Mutta kokemukseni mukaan se on siistein asia, jonka olen koskaan nähnyt. Kun Cloudnative-klusteri skaalattiin kellonajan perusteella. Se oli taustapalvelu, jota taustatoimiston ihmiset käyttivät. Eli he tulevat töihin klo 9, alkavat kirjautua järjestelmään, ja vastaavasti Cloudnative-klusteri, jossa se kaikki on käynnissä, alkaa turvota ja käynnistää uusia podeja, jotta kaikki töihin tulevat voivat työskennellä sovelluksen kanssa. Kun he lähtevät töistä klo 8 tai 6, Kubernetes-klusterit huomaavat, että kukaan ei enää käytä sovellusta ja alkaa kutistua. Jopa 30 prosentin säästö on taattu. Se toimi Amazonissa tuolloin, Venäjällä ei tuolloin ollut ketään, joka tekisi sen niin hyvin.
Sanon suoraan, että säästöt ovat 30 prosenttia yksinkertaisesti siksi, että käytämme Kubernetesia ja hyödynnämme pilven ominaisuuksia. Nyt tämä voidaan tehdä Venäjällä. En tietenkään mainosta kenellekään, mutta sanotaanpa vain, että on palveluntarjoajia, jotka voivat tehdä tämän ja tarjota sen heti laatikosta painikkeella.
Haluaisin myös kiinnittää huomionne viimeiseen kohtaan. Jotta sovelluksesi, infrastruktuurisi olisi Cloudnative, on järkevää vihdoin alkaa mukauttaa lähestymistapaa nimeltä Infrastructure as a Code, eli tämä tarkoittaa, että sovellustasi tai pikemminkin infrastruktuuriasi tarvitaan täsmälleen samalla tavalla kuin koodi Kuvaile sovelluksesi, liiketoimintalogiikkasi koodin muodossa. Ja käytä sitä koodina, eli testaa, rullaa se ulos, tallenna se gitiin, käytä CICD:tä siihen.
Ja juuri tämän ansiosta voit ensinnäkin hallita infrastruktuuriasi ja ymmärtää aina, missä tilassa se on. Toiseksi, vältä virheitä aiheuttavia manuaalisia toimintoja. Kolmanneksi, vältä yksinkertaisesti sitä, mitä kutsutaan liikevaihdoksi, kun sinun on jatkuvasti suoritettava samoja manuaalisia tehtäviä. Neljänneksi, sen avulla voit toipua paljon nopeammin epäonnistumisen sattuessa. Venäjällä aina kun puhun tästä, on aina valtava määrä ihmisiä, jotka sanovat: "Joo, se on selvää, mutta sinulla on lähestymistapoja, lyhyesti sanottuna, ei tarvitse korjata mitään." Mutta se on totta. Jos infrastruktuurissasi on jotain rikki, niin Cloudnative-lähestymistavan näkökulmasta ja Infrastruktuuri koodina -näkökulmasta on helpompaa kuin korjata sitä, mennä palvelimelle, selvittää mikä on rikki ja korjata se. poistaaksesi palvelimen ja luodaksesi sen uudelleen. Ja aion palauttaa tämän kaiken.
Kaikista näistä asioista keskustellaan tarkemmin osoitteessa . Linkin takaa pääset tutustumaan ohjelmaan ja ehtoihin. Kätevä asia on, että voit hallita Kubernetesia opiskelemalla kotoa tai töissä 1-2 tuntia päivässä.
Lähde: will.com