Kubernetes-klastrite projekteerimine: kui palju neid peaks olema?

Märk. tõlge.: see this material from the educational project learnk8s — the answer to a popular question when designing infrastructure based on Kubernetes. We hope that the sufficiently detailed descriptions of the pros and cons of each option will help you make the best choice for your project.

TL;DR: the same set of workloads can be run on several large clusters (with a large number of workloads per cluster) or on many smaller ones (with a small number of workloads in each cluster).

Below is a table evaluating the pros and cons of each approach:

When using Kubernetes as a platform for application operations, several fundamental questions about cluster configuration often arise:

• How many clusters to use?
• How large should they be?
• What should each cluster include?

In this article, I will try to answer all these questions by analyzing the pros and cons of each approach.

The question posed

As a software creator, you are likely developing and operating multiple applications simultaneously.

Lisaks sellele töötab kindlasti palju nende rakenduste koopiaid erinevates keskkondades — näiteks võivad need olla dev, test ja prod.

Tulemusena saame terviku rakenduste ja keskkondade maatriksi:

Rakendused ja keskkonnad

Ülaltoodud näites on esitatud 3 rakendust ja 3 keskkonda, mis kokku annab 9 võimalikku varianti.

Iga rakenduse eksemplar on iseseisev deployment-üksus, millega saab töötada sõltumatult teistest.

Pange tähele, et rakenduse eksemplar võib koosneda paljusid komponente, nagu frontend, backend, andmebaas jne. Mikroteenuste rakenduse korral sisaldab eksemplar kõiki mikroteenuseid.

Seetõttu tõstatavad Kubernetes'e kasutajad mitmeid küsimusi:

• Kas tuleks kõik rakenduse eksemplarid paigutada ühte klastrisse?
• Kas tuleks iga rakenduse eksemplari jaoks luua eraldi klaster?
• Või võib-olla tuleks kasutada kombinatsiooni eespool mainitud lähenemistest?

Kõik need variandid on täiesti elujõulised, kuna Kubernetes on paindlik süsteem, mis ei piira kasutaja võimalusi.

Siin on mõned võimalused:

• üks suur ühine klastri;
• mitu väikest kitsalt spetsialiseerunud klastrit;
• üks klaster iga rakenduse jaoks;
• üks klaster iga keskkonna jaoks.

Nagu allpool näidatud, on kaks esimest lähenemist skaalal vastassuunal:

Mõnest suurest klastrist (vasakul) kuni paljude väikesteni (paremal)

Üldiselt loetakse, et üks klaster on "suurem" kui teine, kui tal on rohkem sõlmi ja pod'e. Näiteks kluster, kus on 10 sõlme ja 100 pod'i, on suurem kui kluster, kus on 1 sõlm ja 10 pod'i.

Nojah, alustame!

1. Üks suur ühine klaster

Esimene variant on paigutada kõik töökoormused ühte klastrisse:

Üks suur klaster

Selle lähenemise raames kasutatakse klastrit universaalse infrastruktuuri platvormina — kõik, mis vajalik, on lihtsalt olemasolevas Kubernetes klastris paigutatud.

Nimi ruumid Kubernetes võimaldab klastris osi üksteisest loogiliselt eraldada, mistõttu iga rakenduse eksemplarile saab kasutada oma nimeala.

Vaatame selle lähenemise plusse ja miinuseid.

+ Tõhus resursside kasutamine

Ainult ühe klastriga on vajalik ainult üks koopia kõikidest ressurssidest, mis on vajalikud Kubernetesi klastri käivitamiseks ja haldamiseks.

Näiteks kehtib see master-sõlmede kohta. Ühe Kubernetesi klastri kohta on tavaliselt 3 master-sõlme, seega jääb nende arv ühele klastrile samaks (võrdluseks, 10 klastrile on vaja 30 master-sõlme).

Ülaltoodud nüanss kehtib ka teiste teenuste kohta, mis toimivad klastris laiemalt, nagu koormuse tasakaalustajad, Ingressi kontrollerid, autentimise, logimise ja jälgimise süsteemid.

Ühes klastri kõik neid teenuseid saab kasutada kohe kõigi töökoormuste jaoks (pole vaja luua nende koopiaid, nagu mitme klastriga).

+ Odavus

Seetõttu maksab väiksem arv klastreid tavaliselt vähem, kuna puuduvad kulutused üleliigsetele ressurssidele.

See kehtib eriti master-sõlmede kohta, millel võivad olla märkimisväärsed kulud, sõltumata majutamisviisist (kas kohapeal või pilves).

Mõned hallatud Kubernetes teenused, nagu Google Kubernetes Engine (GKE) või Azure Kubernetes Service (AKS), pakuvad tasuta haldustaseme. Sellisel juhul on kuluküsimus vähem terav.

Samuti on olemas hallatud teenused, mis küsivad fikseeritud tasu iga Kubernetes'i klastrite töö eest (näiteks, Amazon Elastic Kubernetes Service, EKS).

+ Tõhus haldus

Üht klastrit on lihtsam hallata kui mitut.

Haldus võib hõlmata järgmisi ülesandeid:

• Kubernetes'e versiooni värskendamine;
• CI/CD torujuhtme seadistamine;
• CNI pistiku installimine;
• Kasutaja autentimissüsteemi seadistamine;
• Luba kontrolleri installimine;

ja palju muud…

Ühe klastriga on vaja seda kõike teha ainult üks kord.

Mitme klastri puhul tuleb operatsioone korduvalt korrata, mis tõenäoliselt vajab protsesside ja tööriistade automatiseerimist, et tagada järjepidevus ja ühtsus.

Ja nüüd paar sõna puudustest.

− Üksik rikkepunkt

Üksiku klastri rikke korral lakka vahetult töötama kõik koormused!

On tohutult võimalusi, kus midagi võiks valesti minna:

• Kubernetes'e värskendamine toob ootamatud kõrvaltoimed;
• üldklastrikomponent (näiteks CNI pistikprogramm) käivitub ootamatult;
• üks grupi komponentidest on valesti seadistatud;
• aluseks oleva infrastruktuuri rike.

Üks selline juhtum võib tõsiselt kahjustada kõiki töökoormusi, mis on paigutatud üldklastrisse.

− Rangete isoleerimise puudumine

Töötamine üldklastris tähendab, et rakendused jagavad riistvara, võrguvõimalusi ja operatsioonisüsteemi klastrisõlmede vahel.

Mõnes mõttes on kaks konteinerit, kus töötab kaks erinevat rakendust samas sõlmes, sarnased kahele protsessile, mis töötavad ühel ja samal masinal sama operatsioonisüsteemi tuuma all.

Linuxi konteinerid pakuvad mingit vormi isoleerimisest, kuid see ei ole sugugi nii tugev, kui näiteks virtuaalmasinate korral. Põhimõtteliselt on konteineris olev protsess sama protsess, mis käivitatakse hostoperatsioonisüsteemis.

See võib olla turvalisuse seisukohalt probleem: selline korraldus võimaldab teoreetiliselt omavahel seotud rakendustel üksteisega suhelda (kas teadlikult või kogemata).

Lisaks kasutavad kõik Kubernetes klastri töökoormused ühiselt mõningaid klastriteenuseid, nagu DNS — see võimaldab rakendustel leida teiste rakenduste teenuseid klastris.

Kõigil ülaltoodud punktidel võib olla erinev tähendus sõltuvalt rakenduste turvanõuetest.

Kubernetes pakub erinevaid tööriistu turvaprobleemide vältimiseks, nagu PodSecurityPolicies ja NetworkPolicies. Kuid nende õige seadistamine nõuab teatud kogemust, pealegi ei ole nad võimelised sulgema absoluutselt kõiki turvaauke.

Oluline on alati meeles pidada, et Kubernetes on algselt loodud koostööks, mitte isolatsiooni ja turvalisuse.

− Jõhkralt puudub multi-tenancy.

Arvestades Kubernetes klastri hulka ühiseid ressursse, on palju viise, kuidas erinevad rakendused võivad üksteisele “peale astuda”.

Näiteks võib rakendus monopoliseerida mõne ühise ressursi (nagu protsessor või mälu) ja jätta teised rakendused, mis töötavad samas sõlmes, sellest ilma.

Kubernetes tagab erinevad mehhanismid sellise käitumise kontrollimiseks, nagu ressursside päringud ja piirangud vt ka artiklit « CPU piirangud ja agressiivne trottling Kuberneteses » — tõlk. märkus), ResourceQuotas ja LimitRanges. Siiski, nagu ka turvalisuse puhul, on nende seadistamine piisavalt keeruline ja need ei suuda vältida kõiki ettenägematuid kõrvalmõjusid.

− Suur hulk kasutajaid

Ühe klastriga peab juurdepääsu avama paljudele inimestele. Ja mida rohkem neid on, seda suurem on risk, et nad midagi "katkestavad".

Klastri sees saab hallata, kes ja mida teha saab, kasutades rollipõhist juurdepääsu haldust (RBAC) vt artiklit « Kasutajad ja autoriseerimine RBAC Kuberneteses » — tõlk. märkus). Siiski ei takista see kasutajaid "katkestamast" midagi oma vastutusala piires.

− Klastrid ei saa kasvama kuni lõpmatuseni

Klastrid, mida kasutatakse kõigi töökoormuste jaoks, on tõenäoliselt üsna suured (node'ide ja pod'ide arvult).

Kuid siin tekib teine probleem: Kuberneteses ei saa klastrid kasvada lõpmatuseni.

Klastri suuruse teoreetiline piir on olemas. Kuberneteses on see ligikaudu 5000 node'it, 150 000 pod'i ja 300 000 konteinerit..

Kuid tegelikus elus võivad probleemid alata palju varem – näiteks juba 500 node'iga. Asi on selles, et suured klastrid koormavad Kubernetes'i juhtimistaset tugevalt. Teisisõnu, et hoida klastrit töökorras ja kasutada ressursse efektiivselt, on vajalik hoolikas konfigureerimine..

Seda probleemi uuritakse vastavas artiklis algses päevas, pealkirjaga «

Architecting Kubernetes clusters — choosing a worker node sizeAga vaatame vastupidist lähenemist: palju väikseid klastreid.».

2. Palju väikeseid, spetsialiseeritud klastreid.

Selle lähenemise korral kasutate iga paigaldatava elemendi jaoks eraldi klastrit:

Palju väikeseid klustreid.

Käesoleva artikli eesmärkidel peame

paigaldatavaks elemendiks juurutatud element rakendusinstance mõistetakse - näiteks, arenduse versioon eraldiseisvast rakendusest.

Selles strateegias kasutatakse Kubernetes't kui spetsialiseeritud käituskeskkonda erakordsete rakenduste jaoks.

Vaatame selle lähenemise plusse ja miinuseid.

+ Piiratud "plahvatuse ring"

Klaster "purunemise" korral piirdub negatiivne mõju vaid nende töökoormustega, mis olid selles klastris juurutatud. Kõik teised töökoormused jäävad puutumatuks.

+ Isolatsioon

Eraldatud klastrites paigutatud töökoormustel ei ole ühiseid ressursse, nagu protsessor, mälu, opsüsteem, võrk või muud teenused.

Tulemuseks on range isolatsioon omavahel seotud rakenduste vahel, mis võib soodsalt mõjutada nende turvalisust.

+ Väike kasutajate arv

Kuna igas klastris on vaid piiratud arv töökoormusi, väheneb sellele juurdepääsu saavate kasutajate arv.

Mida vähem inimesi pääseb klastrile ligi, seda madalam on risk, et midagi "katki läheb".

Vaatame miinuseid.

− Ressursside ebaefektiivne kasutamine

Nagu varem mainitud, vajab iga Kubernetes'i klaster teatud haldusressursse: master-sõlmed, kontrollitasandi komponendid, jälgimis- ja logimislahendused.

Kui on palju väikse väikseid klastreid, tuleb rohkem ressursse eraldada halduseks.

− Kulukus

Ebatõhus ressursikasutus toob automaatselt kaasa kõrged kulud.

Näiteks 30 master-sõlme hoidmine kolme asemel sama arvutusvõimsuse juures mõjutab kindlasti kulusid.

− Halduse keerukus

Paljude Kubernetes'i klastrite haldamine on palju keerulisem kui ühega töötamine.

Näiteks tuleb iga klastrite jaoks seadistada autentimine ja autoriseerimine. Kubernetes'i versiooniuuendust tuleb samuti teha mitu korda.

Tõenäoliselt tuleb rakendada automatiseerimist, et suurendada nende ülesannete tõhusust.

Nüüd vaatame vähem äärmuslikke stsenaariume.

3. Üks klaster iga rakenduse jaoks

Selle lähenemise raames loote eraldi klastri kõigi konkreetse rakenduse eksemplaride jaoks:

Rakenduse klaster

Seda teed võib pidada põhimõtte «erinev klaster meeskonna jaoks» üldistamiseks, kuna tavaliselt tegeleb inseneride meeskond ühe või mitme rakenduse arendamisega.

Vaatame selle lähenemise plusse ja miinuseid.

+ Klastrit saab rakendusele kohandada

Kui rakendusel on erilised vajadused, saab neid klastri sees ellu viia, mõjutamata teisi klastreid.

Sellised vajadused võivad hõlmata GPU-dega worker’ite, teatud CNI pluginate, teenuse võrgu või mõne muu teenuse kasutamist.

Iga klaster saab kohandada töötavale rakendusele, et see sisaldaks ainult vajalikke elemente.

− Erinevad keskkonnad ühes klastris

Selle lähenemise miinuseks on see, et erinevate keskkondade rakenduse eksemplarid eksisteerivad ühes klastris.

Näiteks töötab rakenduse prod-version samas klastris nagu dev-version. See tähendab ka, et arendajad tegutsevad samas klastris, kus toodang on rakenduse versioon.

Kui arendajate tegevuse või dev-versiooni vead põhjustavad klastris rikke, võib potentsiaalselt kannatada ka prod-version — selle lähenemise suur puudus.

Ja lõpuks, viimane stsenaarium meie nimekirjas.

4. Üks klaster igas keskkonnas

See stsenaarium näeb ette igas keskkonnas eraldi klastri eraldamist:

Üks klaster iga keskkonna jaoks

Näiteks võivad teil olla klastrid, dev, test ja prod, kus käitate kõiki rakenduse eksemplare, mis on mõeldud kindlale keskkonnale.

Siin on selle lähenemise plussid ja miinused.

+ Produktiivsete keskkondade isoleerimine

Selle lähenemise raames on kõik keskkonnad teineteisest isoleeritud. Kuid praktikas on see eriti oluline tootmiskeskkonna jaoks.

Rakenduse tootmisversioonid ei sõltu enam muudest klastritest ja keskkondadest.

Nii et kui dev-klastris tekib äkki probleem, jätkavad tootmisversioonid töötamist nagu midagi ei juhtunud.

+ Klastrit saab kohandada keskkonna järgi

Iga klastrit saab kohandada oma keskkonna jaoks. Näiteks võib:

• paigaldada dev-klastrisse arendamise ja tõrkeotsingu tööriistad;
• paigaldada testimisraamistikke ja tööriistu klastrisse test;
• kasutada klastris võimsamat riistvara ja võrguühendusi. prod.

See aitab suurendada nii arenduse kui ka rakenduste haldamise tõhusust.

+ Juhtimise piiramine production-klastrisse

Otsene töötamine prod-klastriga on haruldane, seega on võimalik oluliselt piirata neid, kellel on sellele juurdepääs.

Saame minna veelgi kaugemale ja täiesti keelata inimeste juurdepääsu sellele klastrile, tehes kõik juurutamised automatiseeritud CI/CD tööriista abil. Selline lähenemine vähendab inimlike vigade riski just seal, kus see on kõige olulisem.

Ja nüüd paar sõna puudustest.

− Aparaadi ja ressursside isolatsiooni puudumine rakenduste vahel

Peamine puudus on see, et rakenduste vahel puudub riistvara ja ressursside isolatsioon.

Üksikud rakendused kasutavad koos klastrite ressursside süsteemi, protsessorit, mälu ja mõningaid teisi teenuseid.

Nagu juba mainitud, võib see osutuda potentsiaalselt ohtlikuks.

− Rakenduste sõltuvuste lokaliseerimise võimatus

Kui rakendusel on erilised nõudmised, tuleb neid täita kõigis klastrites.

Näiteks, kui rakendus vajab GPU-d, peab iga klaster sisaldama vähemalt ühte GPU-ga töötlusüksust (isegi kui seda kasutatakse ainult selle rakenduse poolt).

Tulemuseks on suuremad kulud ja ebaefektiivne ressursside kasutamine.

Kokkuvõte

Kuna on olemas teatud rakenduste komplekt, saab need paigutada paarisse suurtesse klastritesse või paljudesse väikestesse.

Artiklis käsitletakse erinevate lähenemisviiside plusse ja miinuseid, alates ühest globaalsest klastrist kuni paljude väikeste ja kitsaste:

• üks suur ühisklaster;
• mitu väikest kitsalt spetsialiseerunud klastrit;
• üks klaster iga rakenduse jaoks;
• üks klaster iga keskkonna jaoks.

Niisiis, millist lähenemist valida?

Nagu tavaliselt, sõltub vastus kasutusstsenaariumist: tuleb kaaluda erinevate lähenemisviiside plusse ja miinuseid ning valida kõige optimaalsem variant.

Kuid valik ei piirdu ainult eespool toodud näidetega – võib rakendada igasugust kombinatsiooni!

Näiteks võib korraldada igale meeskonnale paar klastrit: arenduse klaster (kus on keskkonnad dev ja test) ja klaster tootmisse (kus asub tootmiskeskkond).

Tuginedes sellele artiklile, saate vastavalt optimeerida iga variandi plussid ja miinused konkreetse stsenaariumi jaoks. Edu!

P.S.

Lugege ka meie blogist:

• «Visuaalne juhend Kubernetes'e tõrgete diagnoosimiseks»;
• «Logid Kuberneteses (ja mitte ainult) täna: ootused ja reaalsus»;
• «Teenusete võrk: mida iga tarkvarainsener peab teadma kõige populaarsemast tehnoloogiast»;
• «Kubernetes'e turvaabitus: autentimine, autoriseerimine, audit».

Allikas: habr.com