Huomautus. käännös: tämä materiaali on koulutusprojektista on vastaus suosittuun kysymykseen suunniteltaessa Kubernetes-pohjaista infrastruktuuria. Toivomme, että melko yksityiskohtaiset kuvaukset kunkin vaihtoehdon eduista ja haitoista auttavat sinua tekemään parhaan valinnan projektiisi.
TL; DR: samaa kuormitusjoukkoa voidaan ajaa useissa suurissa klusteissa (jokaisessa klusterissa on suuri määrä työkuormia) tai useissa pienissä (pieni määrä kuormia kussakin klusterissa).
Alla on taulukko, jossa arvioidaan kunkin lähestymistavan edut ja haitat:
Käytettäessä Kubernetesia sovellusten suoritusalustana, herää usein useita peruskysymyksiä klusterien perustamisen monimutkaisuudesta:
- Kuinka monta klusteria minun pitäisi käyttää?
- Kuinka isot niistä pitäisi tehdä?
- Mitä jokaisen klusterin tulisi sisältää?
Tässä artikkelissa yritän vastata kaikkiin näihin kysymyksiin analysoimalla kunkin lähestymistavan etuja ja haittoja.
Lausunto kysymyksestä
Ohjelmistokehittäjänä todennäköisesti kehität ja käytät monia sovelluksia samanaikaisesti.
Lisäksi monet näistä sovelluksista toimivat todennäköisesti eri ympäristöissä - esimerkiksi nämä voivat olla dev, testi и tuot.
Tuloksena on kokonainen matriisi sovelluksia ja ympäristöjä:
Sovellukset ja ympäristöt
Yllä oleva esimerkki edustaa 3 sovellusta ja 3 ympäristöä, jolloin yhteensä 9 mahdollista vaihtoehtoa.
Jokainen sovellusesiintymä on itsenäinen käyttöönottoyksikkö, jonka kanssa voidaan työskennellä muista riippumatta.
Huomaa, että sovellusesiintymä voi koostua useista komponentit, kuten käyttöliittymä, taustajärjestelmä, tietokanta jne. Mikropalvelusovelluksen tapauksessa ilmentymä sisältää kaikki mikropalvelut.
Tämän seurauksena Kubernetes-käyttäjillä on useita kysymyksiä:
- Pitäisikö kaikki sovellusesiintymät sijoittaa yhteen klusteriin?
- Kannattaako jokaiselle sovellusesiintymälle erillinen klusteri?
- Tai ehkä pitäisi käyttää yllä olevien lähestymistapojen yhdistelmää?
Kaikki nämä vaihtoehdot ovat varsin käyttökelpoisia, koska Kubernetes on joustava järjestelmä, joka ei rajoita käyttäjän ominaisuuksia.
Tässä on joitain mahdollisista tavoista:
- yksi suuri yhteinen klusteri;
- monet pienet pitkälle erikoistuneet klusterit;
- yksi klusteri sovellusta kohden;
- yksi klusteri ympäristöä kohden.
Kuten alla näkyy, kaksi ensimmäistä lähestymistapaa ovat vaihtoehtojen asteikon vastakkaisissa päissä:
Muutamasta suuresta klusterista (vasemmalla) moniin pieniin (oikealla)
Yleensä yhtä klusteria pidetään "suurempana" kuin toista, jos siinä on suurempi määrä solmuja ja podeja. Esimerkiksi klusteri, jossa on 10 solmua ja 100 podia, on suurempi kuin klusteri, jossa on 1 solmu ja 10 podia.
No, aloitetaan!
1. Yksi suuri yhteinen klusteri
Ensimmäinen vaihtoehto on sijoittaa kaikki työkuormat yhteen klusteriin:
Yksi iso klusteri
Tässä lähestymistavassa klusteria käytetään universaalina infrastruktuurialusta — otat vain kaiken tarvitsemasi käyttöön olemassa olevassa Kubernetes-klusterissa.
Kubernetes sallii klusterin osien erottamisen loogisesti toisistaan, jolloin jokaisella sovellusesiintymällä voi olla oma nimiavaruutensa.
Katsotaanpa tämän lähestymistavan hyviä ja huonoja puolia.
+ Tehokas resurssien käyttö
Yhdellä klusterilla tarvitset vain yhden kopion kaikista Kubernetes-klusterin suorittamiseen ja hallintaan tarvittavista resursseista.
Tämä pätee esimerkiksi pääsolmuihin. Tyypillisesti jokaisessa Kubernetes-klusterissa on 3 pääsolmua, joten yhden yksittäisen klusterin lukumäärä pysyy sellaisena (vertailun vuoksi 10 klusteria tarvitsee 30 pääsolmua).
Yllä oleva hienovaraisuus pätee myös muihin koko klusterissa toimiviin palveluihin, kuten kuormituksen tasapainottajiin, sisääntuloohjaimiin, todennus-, loki- ja valvontajärjestelmiin.
Yhdessä klusterissa kaikkia näitä palveluita voidaan käyttää kerralla kaikille työkuormille (niistä ei tarvitse luoda kopioita, kuten useiden klustereiden tapauksessa).
+ Halpa
Edellä olevan seurauksena harvemmat klusterit ovat yleensä halvempia, koska niistä ei aiheudu yleiskustannuksia.
Tämä pätee erityisesti pääsolmuihin, jotka voivat maksaa huomattavan määrän rahaa riippumatta siitä, miten niitä isännöidään (paikan päällä tai pilvessä).
Jotkut hallinnoidut Kubernetes-palvelut, kuten tai , tarjoa ohjauskerroksen ilmaiseksi. Tässä tapauksessa kustannuskysymys on vähemmän akuutti.
On myös hallittuja palveluita, jotka veloittavat kiinteän maksun kunkin Kubernetes-klusterin toiminnasta (esim. ).
+ Tehokas hallinto
Yhden klusterin hallinta on helpompaa kuin useiden.
Hallinto voi sisältää seuraavat tehtävät:
- Kubernetes-version päivitys;
- CI/CD-putkilinjan perustaminen;
- CNI-laajennuksen asentaminen;
- käyttäjän todennusjärjestelmän perustaminen;
- kulunohjaimen asennus;
ja monet muut…
Yhden klusterin tapauksessa sinun on tehtävä kaikki tämä vain kerran.
Monissa klusteissa toiminnot on toistettava useita kertoja, mikä todennäköisesti vaatii jonkin verran prosessien ja työkalujen automatisointia prosessin johdonmukaisuuden ja johdonmukaisuuden varmistamiseksi.
Ja nyt muutama sana haitoista.
− Yksi vikakohta
Kieltäytymisen tapauksessa ainoa klusteri lakkaa toimimasta välittömästi kaikki työmäärät!
Asiat voivat mennä pieleen monella tapaa:
- Kubernetesin päivittäminen johtaa odottamattomiin sivuvaikutuksiin;
- Klusterinlaajuinen komponentti (esimerkiksi CNI-laajennus) ei toimi odotetulla tavalla;
- yksi klusterin komponenteista ei ole määritetty oikein;
- taustalla olevan infrastruktuurin vika.
Yksi tällainen tapaus voi aiheuttaa vakavaa vahinkoa kaikille jaetussa klusterissa isännöidyille työkuormille.
− Ei jäykkää eristystä
Jaetussa klusterissa ajaminen tarkoittaa, että sovellukset jakavat laitteiston, verkkoominaisuudet ja käyttöjärjestelmän klusterin solmuissa.
Tietyssä mielessä kaksi säilöä, joissa on kaksi eri sovellusta samassa solmussa, ovat kuin kaksi prosessia, jotka toimivat samassa koneessa ja käyttävät samaa käyttöjärjestelmän ydintä.
Linux-säiliöt tarjoavat jonkinlaisen eristyksen, mutta se ei ole läheskään yhtä vahva kuin esimerkiksi virtuaalikoneiden tarjoama. Pohjimmiltaan säilössä oleva prosessi on sama prosessi, joka suoritetaan isäntäkäyttöjärjestelmässä.
Tämä voi olla turvallisuusongelma: tämä järjestely mahdollistaa teoriassa toisiinsa liittymättömien sovellusten kommunikoinnin toistensa kanssa (joko tarkoituksellisesti tai vahingossa).
Lisäksi kaikki Kubernetes-klusterin työkuormat jakavat joitakin klusterinlaajuisia palveluita, kuten - Tämä sallii sovellusten löytää klusterin muiden sovellusten palvelut.
Kaikilla yllä olevilla kohdilla voi olla eri merkitys sovelluksen suojausvaatimuksista riippuen.
Kubernetes tarjoaa erilaisia työkaluja suojausongelmien estämiseen, kuten и . Niiden oikea asentaminen vaatii kuitenkin jonkin verran kokemusta, ja ne eivät myöskään pysty sulkemaan kaikkia turva-aukkoja.
On tärkeää aina muistaa, että Kubernetes on alun perin suunniteltu jakaminen, ei varten eristystä ja turvallisuutta.
− Tiukan monivuokrasuhteen puute
Kun otetaan huomioon Kubernetes-klusterin jaettujen resurssien runsaus, on monia tapoja, joilla eri sovellukset voivat astua toistensa varpaille.
Sovellus voi esimerkiksi monopolisoida jaetun resurssin (kuten suorittimen tai muistin) ja estää muiden samassa solmussa toimivien sovellusten pääsyn siihen.
Kubernetes tarjoaa erilaisia mekanismeja tämän käyttäytymisen hallitsemiseksi, kuten (katso myös artikkeli ""- n. käännös.), и . Kuitenkin, kuten turvallisuuden tapauksessa, niiden kokoonpano on melko ei-triviaali, eivätkä ne pysty estämään täysin kaikkia odottamattomia sivuvaikutuksia.
− Suuri määrä käyttäjiä
Yhden klusterin tapauksessa sinun on avattava pääsy siihen useille ihmisille. Ja mitä enemmän niitä on, sitä suurempi on riski, että he "rikkoavat" jotain.
Klusterin sisällä voit hallita, kuka voi tehdä mitä käyttää (katso artikkeli ""- n. käännös.). Se ei kuitenkaan estä käyttäjiä "rikkomasta" jotain vastuualueensa rajoissa.
− Klusterit eivät voi kasvaa loputtomiin
Kaikille työkuormille käytettävä klusteri on todennäköisesti melko suuri (solmujen ja tyynyjen lukumäärän suhteen).
Mutta tässä syntyy toinen ongelma: Kubernetesin klusterit eivät voi kasvaa loputtomiin.
Klusterin koolla on teoreettinen raja. Kubernetesissa se on noin .
Tosielämässä ongelmat voivat kuitenkin alkaa paljon aikaisemmin - esimerkiksi vain .
Tosiasia on, että suuret klusterit kuormittavat suuresti Kubernetes-ohjauskerrosta. Toisin sanoen klusterin ylläpitäminen tehokkaassa toiminnassa vaatii huolellista viritystä.
Tätä ongelmaa käsitellään alkuperäisen blogin aiheeseen liittyvässä artikkelissa "'.
Mutta harkitaan päinvastaista lähestymistapaa: monia pieniä klustereita.
2. Monet pienet, erikoistuneet klusterit
Tällä lähestymistavalla käytät erillistä klusteria kullekin käyttöön ottamasi elementille:
Useita pieniä klustereita
Tämän artikkelin tarkoituksia varten alla levitettävä elementti viittaa sovelluksen esiintymään - esimerkiksi erillisen sovelluksen kehittäjäversioon.
Tämä strategia käyttää Kubernetesia erikoistuneena suoritusaika yksittäisiä sovellustapauksia varten.
Katsotaanpa tämän lähestymistavan hyviä ja huonoja puolia.
+ Rajoitettu ”räjähdyssäde”
Kun klusteri epäonnistuu, negatiiviset seuraukset rajoittuvat vain niihin työkuormiin, jotka on otettu käyttöön kyseisessä klusterissa. Kaikki muut työmäärät säilyvät ennallaan.
+ Eristys
Yksittäisissä klustereissa isännöidyt työkuormat eivät jaa resursseja, kuten prosessoria, muistia, käyttöjärjestelmää, verkkoa tai muita palveluita.
Tuloksena on tiukka eristys toisiinsa liittyvien sovellusten välillä, mikä voi olla hyödyllistä niiden turvallisuuden kannalta.
+ Pieni määrä käyttäjiä
Koska jokainen klusteri sisältää vain rajoitetun joukon työkuormia, käyttäjien määrä, joilla on pääsy siihen, vähenee.
Mitä harvemmalla ihmisellä on pääsy klusteriin, sitä pienempi on riski, että jokin "rikkoutuu".
Katsotaanpa haittoja.
− Resurssien tehoton käyttö
Kuten aiemmin mainittiin, jokainen Kubernetes-klusteri vaatii tietyt hallintaresurssit: pääsolmut, ohjauskerroksen komponentit, valvonta- ja lokiratkaisut.
Jos pieniä klustereita on paljon, johtamiseen on kohdistettava suurempi osa resursseista.
− Kallista
Resurssien tehoton käyttö aiheuttaa automaattisesti suuria kustannuksia.
Esimerkiksi 30 isäntäsolmun ylläpitäminen samalla laskentateholla kolmen sijasta vaikuttaa välttämättä kustannuksiin.
− Hallinnolliset vaikeudet
Useiden Kubernetes-klusterien hallinta on paljon vaikeampaa kuin yhden.
Sinun on esimerkiksi määritettävä todennus ja valtuutus jokaiselle klusterille. Kubernetes-versio on myös päivitettävä useita kertoja.
Sinun on todennäköisesti käytettävä automaatiota kaikkien näiden tehtävien tehostamiseksi.
Katsotaan nyt vähemmän äärimmäisiä skenaarioita.
3. Yksi klusteri sovellusta kohden
Tässä lähestymistavassa luot erillisen klusterin tietyn sovelluksen kaikille esiintymille:
Klusteri sovelluskohtaisesti
Tätä polkua voidaan pitää periaatteen yleistyksenä "erillinen klusteri per joukkue”, koska yleensä insinööritiimi kehittää yhtä tai useampaa sovellusta.
Katsotaanpa tämän lähestymistavan hyviä ja huonoja puolia.
+ Klusteri voidaan säätää sovelluksen mukaan
Jos sovelluksella on erityistarpeita, ne voidaan toteuttaa klusterissa vaikuttamatta muihin klustereihin.
Tällaisia tarpeita voivat olla GPU-työntekijät, tietyt CNI-laajennukset, palveluverkko tai jokin muu palvelu.
Jokainen klusteri voidaan räätälöidä siinä olevan sovelluksen mukaan siten, että se sisältää vain sen, mitä tarvitaan.
− Eri ympäristöt yhdessä klusterissa
Tämän lähestymistavan haittana on, että eri ympäristöistä tulevat sovellusesiintymät esiintyvät rinnakkain samassa klusterissa.
Esimerkiksi sovelluksen prod-versio toimii samassa klusterissa kuin kehittäjäversio. Tämä tarkoittaa myös sitä, että kehittäjät toimivat samassa klusterissa, jossa sovelluksen tuotantoversiota käytetään.
Jos kehittäjien toimien tai kehittäjäversion häiriötekijöiden vuoksi klusterissa tapahtuu vika, myös prod-versio saattaa kärsiä - tämän lähestymistavan valtava haittapuoli.
Ja lopuksi viimeinen skenaario luettelossamme.
4. Yksi klusteri ympäristöä kohden
Tämä skenaario sisältää erillisen klusterin varaamisen kullekin ympäristölle:
Yksi klusteri ympäristöä kohden
Sinulla voi olla esimerkiksi klustereita dev, testi и tuot, jossa suoritat kaikki tietylle ympäristölle omistetut sovelluksen esiintymät.
Tässä on tämän lähestymistavan edut ja haitat.
+ Tuotantoympäristön eristäminen
Tässä lähestymistavassa kaikki ympäristöt on eristetty toisistaan. Käytännössä tämä on kuitenkin erityisen tärkeää tuotantoympäristössä.
Sovelluksen tuotantoversiot ovat nyt riippumattomia siitä, mitä muissa klustereissa ja ympäristöissä tapahtuu.
Tällä tavalla, jos kehittäjäklusterissa ilmenee yhtäkkiä ongelma, sovellusten prod-versiot jatkavat toimintaansa kuin mitään ei olisi tapahtunut.
+ Klusteri on säädettävissä ympäristöön sopivaksi
Jokainen klusteri voidaan mukauttaa ympäristöönsä. Voit esimerkiksi:
- asentaa työkaluja kehitystä ja virheenkorjausta varten kehittäjäklusteriin;
- asentaa testikehykset ja työkalut klusteriin testi;
- käyttää tehokkaampia laitteita ja verkkokanavia klusterissa tuot.
Näin voit lisätä sekä sovelluskehityksen että toiminnan tehokkuutta.
+ Tuotantoklusteriin pääsyn rajoittaminen
Tarve työskennellä suoraan tuoteklusterin kanssa tulee harvoin esiin, joten voit rajoittaa merkittävästi niiden ihmisten joukkoa, joilla on pääsy siihen.
Voit mennä vielä pidemmälle ja estää ihmisiä pääsemästä tähän klusteriin kokonaan ja suorittaa kaikki käyttöönotot automaattisen CI/CD-työkalun avulla. Tällainen lähestymistapa minimoi inhimillisten virheiden riskin juuri siellä, missä se on olennaisinta.
Ja nyt muutama sana haitoista.
− Ei eristystä sovellusten välillä
Lähestymistavan suurin haittapuoli on laitteiston ja resurssien eristyksen puute sovellusten välillä.
Liittyvät sovellukset jakavat klusterin resursseja: järjestelmän ytimen, prosessorin, muistin ja jotkin muut palvelut.
Kuten mainittiin, tämä voi olla vaarallista.
− Sovellusriippuvuuksien lokalisointi ei onnistu
Jos sovelluksella on erityisvaatimuksia, ne on täytettävä kaikissa klustereissa.
Jos sovellus esimerkiksi vaatii grafiikkasuorittimen, jokaisessa klusterissa on oltava vähintään yksi työntekijä, jolla on grafiikkasuoritin (vaikka vain kyseinen sovellus käyttäisi sitä).
Seurauksena on korkeammat kustannukset ja resurssien tehoton käyttö.
Johtopäätös
Jos sinulla on tietty joukko sovelluksia, ne voidaan sijoittaa useisiin suuriin ryhmiin tai useisiin pieniin.
Artikkelissa käsitellään erilaisten lähestymistapojen etuja ja haittoja, jotka vaihtelevat yhdestä globaalista klusterista useisiin pieniin ja pitkälle erikoistuneisiin:
- yksi suuri yleinen klusteri;
- monet pienet pitkälle erikoistuneet klusterit;
- yksi klusteri sovellusta kohden;
- yksi klusteri ympäristöä kohden.
Joten mikä lähestymistapa sinun pitäisi valita?
Kuten aina, vastaus riippuu käyttötapauksesta: sinun on punnittava eri lähestymistapojen edut ja haitat ja valittava optimaalinen vaihtoehto.
Valinta ei kuitenkaan rajoitu yllä oleviin esimerkkeihin - voit käyttää mitä tahansa niiden yhdistelmää!
Voit esimerkiksi järjestää jokaiselle tiimille pari klusteria: kehitysklusterin (jossa on ympäristöjä dev и testi) ja klusteri for tuotanto (missä tuotantoympäristö sijoitetaan).
Tämän artikkelin tietojen perusteella voit optimoida edut ja haitat tietyn skenaarion mukaan. Onnea!
PS.
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com