Kuberneteses reserveerimine: see eksisteerib

Minu nimi on Sergei, olen ITSumma ettevõttest ja tahan rääkida, kuidas me läheneme Kuberneteses varukoopiate tegemisele. Viimasel ajal olen palju tegelenud konsultatsioonitegevusega erinevate DevOps lahenduste juurutamisel erinevatele meeskondadele ning eriti olen töötanud K8s projektidega. Uptime päeva 4. konverentsil, mis oli pühendatud keeruliste arhitektuuride varukoopiatele, esitasin ettekande varukohtade kohta "kuubikus", ja siin on selle vabalt koostatud kokkuvõte. Kuid enne mainin, et see ei ole otsene tegevusjuhend, vaid pigem ülevaade mõtetest antud teema kohta.

Põhimõtteliselt on monitorimine ja reserveerimine kaks peamist tööriista, et suurendada iga projekti talitlushäirekindlust. Aga te ütlete, et Kubernetesis toimub kõik tasakaalustamine automaatselt, kõik skaleerub iseseisvalt ja kui midagi juhtub, tõuseb see iseenesest... Esimese, pinnapealse teema uurimise käigus vastas internet küsimusele, kuidas keegi läheneb K8s-i reserveerimisele, et "miks?" Paljud arvavad, et Kubernetes on maagiline lahendus, mis vabastab kõikidest infrastruktuursetest probleemidest ja tagab, et projekt ei kuku kunagi kokku. Aga... maailm ei ole see, mida see näib.

Kuidas me lähenesime reserveerimise protsessile varem? Meil olid identsed platvormid, kas virtuaalmasinad või füüsilised serverid, serverid, millele me rakendasime kolme põhipraktikat:

1. koodi ja staatika sünkroonimine
2. konfiguratsioonide sünkroonimine
3. andmebaasi replikeerimine

Ja voilà: igal hetkel saame vahetada varuplaatvormile, kõik on õnnelikud, tõusime ja lahkume.

Mida pakutakse meie Kubernetes rakenduse pideva kättesaadavuse suurendamiseks? Esimene asi, millest ütleb mitteformaalse dokumentatsiooni järgi — on paigutada palju masinaid, luua palju mastereid — nende arv peab vastama kvoorumi nõuetele klastris, ja igal masteril peab olema üles tõstetud etcd, api, MC, scheduler… Ja nagu kõik oleks suurepärane: kui mitu töönode või masterit ebaõnnestub, siis meie klaster tasakaalustub ümber ja rakendus jätkab tööd. See kõik tundub nagu võlu! Kuid sageli asub meie klaster ühes andmekeskuses, mis võib tekitada teatud küsimusi. Mis juhtub, kui ekshaator tuleb ja kaevab kaabli üles, kui lööb välk, või toimub universaalne tulv? Kõik on lõppenud, meie klastrit enam pole. Kuidas läheneda varundamisele, arvestades selle probleemi külge?

Esmalt, teil peab olema veel üks klaster kuumaks varuks, st klaster, millele saate igal hetkel üle minna. Sel juhul peavad infrastruktuurid Kubernetes'i seisukohalt olema täielikult identsed. See tähendab, et kui teie failisüsteemil on mingeid ebatavalisi pluginaid, kohandatud lahendusi ingressi jaoks, siis peavad need olema täielikult identsed teie kahel (või kolmel, või kümnel, sõltuvalt sellest, kui palju raha ja adminnide jõudu on) klastril. Tuleb selgelt määratleda kaks rakenduste (deploymentide, statefulsetide, daemonsetide, cronjobide jne) komplekti: millised neist võivad pidevalt töötada varuklastris, ja milliseid ei tasuks üldse käivitada enne üleminekut.

Kas meie varuklaster peab olema täielikult identne meie tootmisklastriga? Ei. Kui varem monoliitsete projektide ning rauainfrastruktuuri töö käigus hoidsime praktiliselt täielikult identses keskkonnas, siis Kubernetes'i kontekstis ei peaks seda olema. Vaatame, miks.

Näiteks alustame Kubernetes'i põhielementidest — deployments — need peavad olema identsed. Peavad olema käivitatud rakendused, mis võivad igal hetkel üle võtta liikluse töötlemise ja võimaldada meie projektil jätkata elu. Kui me räägime konfiguratsioonifailidest, siis peame vaatama, kas need peavad olema identsed või mitte. See tähendab, et kui me, targad inimesed, ei tarbi mingeid keelatud aineid ja ei hoia andmebaasi K8s, siis peavad meie configmap'id sisaldama juurdepääsu seadeid tootmisandmebaasi (mille varundusprotsess on üles ehitatud eraldi). Seetõttu juurdepääsu tagamiseks varundatud andmebaasi peame meil olema eraldi konfiguratsioonifail (configmap). Täpselt nii töötame ka secret'itega: andmebaasi juurdepääsuks paroolidega, API võtmetega; igal hetkel võib meil olla töötav kas tootmissecret või varundussecret. Seega on meil juba kaks Kubernetes'e elementi, mille varukoopiad ei tohi olla identsed tootmisversioonidega. Järgmiseks elemendiks, millele tasub keskenduda, on cronjob. Cronjob'id varukoopias ei tohi mingil juhul olla identsed tootmiscluster'i cronjob'ide kogumiga! Kui tõstame üles varuaklastri ja aktiveerime selle koos kõikide cronjob'idega — näiteks saavad inimesed teilt ühe asemel kaks e-kirja samal ajal. Või mõni andmete sünkroonimine väliste allikatega toimub kaks korda, seega hakkame haiget saama, nutma, karjuma ja sõimama.

Aga kuidas soovitavad inimesed internetis varundusklastri korraldada? Teine populaarne vastus peale „miks?” on Kubernetes Federation'i kasutamine.

Mis see on? See on, ütleme nii, suur meta-klaster. Kui me kujutame ette Kuberneetside arhitektuuri — kus meil on juht ja mitmed sõlmed — siis föderatsiooni vaates on meil samuti juht ja mitmed sõlmed, ainult et iga sõlm on eraldi klaster. See tähendab, et me töötame nende samade elementide ja primitiividega nagu üksiku Kuberneetsi puhul, ainult et pöörame ja keerame mitte meie füüsilisi masinaid, vaid terveid klastreid. Föderatsiooni raames toimub meil täielik föderatiivsete ressursside sünkroniseerimine vanematelt järglastele. Näiteks, kui me käivitame mõne juurutamise läbi föderatsiooni — see juurutatakse meie iga tütarklastrisse. Kui me võtame mingi configmap’i, salajase info, ja levitame selle föderatsiooni kaudu — see laieneb kõigisse meie tütarklastreisse; samas võimaldab föderatsioon meie ressursside kohandamist lastes. See tähendab, et me võtsime mingi configmap'i, juurutame selle läbi föderatsiooni ja seejärel, kui me peame midagi spetsiifilist tükkide järgi kohandama, läheme ja muudame seda üksikusse klastrisse, ja see muudatus ei sünkroniseeru enam kuskile.

Kubernetesi föderatsioon — suhteliselt uus tööriist, ja see ei toeta kaugelki kogu ressursikomplekti, mida pakub K8s: dokumentatsiooni esimese versiooni avaldamise ajal räägiti toimetusartikkelide, replikasete juurutamisest ja ingressist. Saladused ei olnud toetatud, samuti ei olnud võimalik töötada vaba ruumiga. Liialt piiratud komplekt. Eriti kui me armastame eksperimentida, — näiteks, kasutada custom resource definition, et edastada oma ressursse Kubernetesesse, — föderatsiooniga me neid enam ei suru. Nii et nagu… väga tõelise lahenduse sarnane, kuid sunnib meid perioodiliselt endale jalga tulistama. Teiselt poolt võimaldab föderatsioon paindlikult hallata meie replicaset'i. Näiteks, me tahame, et meie rakendus töötaks 10 koopiat, siis jagab föderatsioon selle numbri automaatselt proportsionaalselt klastrite arvu vahel. Ja seda kõike saab veel ka konfigureerida! See tähendab, et saame määrata, et tootmisklastris peab olema 6 koopiat meie rakendusest, ja varukoopiat klasstri jaoks, ressursikasutuse kokkuhoiu või omaenda lõbustamiseks — ainult 4 koopiat meie rakendusest. Mis on samuti piisavalt mugav. Kuid föderatsiooniga peame kasutama uusi lahendusi, midagi kulutama jooksvalt, sundima end rohkem mõtlema…

Kas saaksime küberprotsessi lihtsamalt läheneda? Millised tööriistad meil üldse olemas on?

Esiteks on meil alati mingi CI/CD süsteem, seega me ei lähe käsitsi, ei kirjuta serverites create/apply. Süsteem genereerib YAML-failid meie konteinerite jaoks.

Teiseks on meil mitu klastrit, meil on kas üks või mitu (kui oleme nutikad) registrit, mille me samuti broneerisime. Ja on suurepärane utiliit kubectl, mis suudab samaaegselt töötada mitme klassiga.

Nii et: minu arvates on kõige lihtsam ja tõhusam lahendus varukoopia klastrite loomine primitiivne paralleelne juurutamine. On olemas mingi CI/CD süsteem, mille kaudu ehitame meie konteinerid, testime neid ja juurutame rakendusi läbi kubectl mitmesse sõltumatusse klastrisse. Me saame samal ajal luua väljaandeid mitmesse klastrisse. Vastavalt sellele lahendame ka konfigureerimise kohaletoimetamise sellel etapil. Saab ette määrata konfigureerimise kogumi meie tootmistgehüsteemile, konfigureerimise komplekti varuklastrile ja CI/CD süsteemi tasandil juurutada tootmisümbruse tootmisklastri, varuooperi varuklastrisse. Erinevalt föderatsioonist ei pea pärast föderatiivse ressursi määramist minema iga tütarklastri juurde ja midagi ümber määrama. Oleme selle eelnevalt valmis teinud. Kuidas me oleme kenad.

Aga... on... ma kirjutasin, et on "kõigi kurjade juur", kuid neid on tegelikult kaks. Esiteks, failisüsteem. On mingi PV, või kasutame me välist salvestust. Kui me salvestame faile klastrisse, siis tuleb järgida vanu praktikaid, mis on pärit rauainfrastruktuuri ajast: näiteks sünkroniseerida lsync’iga. Või mõne muu isiklikult eelistaud leidlikkusega. Rullime kõik üle teistele masinatele ja elame edasi.

Teiseks, ja tegelikult isegi olulisem takistuspunkt — andmebaas. Kui me oleme intelligentsed inimesed ja ei hoia andmebaasi kuber-networkis, siis andmete varundamine sama vana skeemi järgi — master-slave replikatsioon, siis vahetame ja rebime repliika järele ning elame hästi. Kuid kui me hoiame oma DB-d klastris, siis on tegelikult palju valmis lahendusi sama master-slave repliika korraldamiseks, palju lahendusi DB käivitamiseks kuber-networkis.
Andmebaaside varundamise teemal on juba miljard ettekannet peetud, miljard artiklit kirjutatud — siin pole midagi uut. Ühesõnaga, järgige oma unistusi, elage nagu soovite, leiutage endale ka keerulisi lahendusi, kuid mõelge kindlasti, kuidas kõike seda varundada.

Nüüd räägime sellest, kuidas meie hankeprotsess töökeskkonda edaspidi seekord toimub, juhul kui peaks tulekahju. Esiteks turgutame me paralleelselt staatuseid rakendusi. Need ei mõjuta meie rakenduste äriloogikat ega projekti, saame pidevalt hoida kahte komplekti töötavaid rakendusi, kusjuures mõlemad saavad hakata liiklust vastu võtma. Üks oluline aspekt, millest tuleb tähelepanu pöörata, on see, et vahetusprotsessis peaksite kindlasti vaatama, kas on vaja konfigureerimist uuesti määrata. Näiteks meil on tootmiscluster Kubernetes, varuregister Kubernetes, välised andmebaasid master ja varuregister master. Meil on neli erinevat võimalust, kuidas need rakendused tootes omavahel koostööd saavad alustada. Võib-olla vahetame andmebaasi ning selgub, et tuleb tootmisclusteris liiklus suunata uuele andmebaasile; või võib olla cluster katki — ja me oleme läinud varurakendusse, kuid jätkame töötamist tootmisandmebaasiga; ning kolmas variant on, et meil on katki see ja katki too, ning me vahetame mõlemad rakendused, määrame meie seadistuse ümber, et uued rakendused töötaksid juba uue andmebaasi põhjal.

Nii, millised järeldused saab kõigest sellest teha?

Esimene järeldus: varuga on hea elada. Aga see on kallis. Ideaalis ei tohiks elada ainult ühe varuga. Ideaalis peaks olema mitu varu. Esiteks peab varu olema vähemalt mitte ühes andmekeskuses ja teiseks, vähemalt teiselt teenusepakkujalt. Olen korduvalt selliseid olukordi kogenud. Kahjuks ei saa ma projekte nimetada, kui just siis, kui andmekeskuses tulekahju juhtus... Oli mul selline olukord: lülitame üle varule! Ja varu serverid olid just selles samas rack'is.

Või kujutage ette, et Amazon on Venemaal keelatud (ja nii on juhtunud). Ja kõik: mis kasu on sellest, et meie varu on teises amazon'is? See on samuti kättesaamatu. Nii et kordangi: hoidke varu vähemalt teises andmekeskuses ja eelistatavalt — teisel teenusepakkujal.

Teise tähelepanek: kui teie Kubernetesis rakendus suhtleb väliste allikatega (see võib olla kas andmebaas või mõni väline API), määrake see kindlasti teenusena koos välise Endpoint'iga, et üleminekul ei peaks te uuesti üles seadma 15 teie rakendust, mis pääsevad samasse andmebaasi. Määrake andmebaas eraldi teenusena ja pääseda sellele, nagu oleks see teie klusteris: kui andmebaas tõrkub, muudate IP-d ühes kohas ja jätkate muretult elu.

Ja lõpetuseks: mulle meeldib 'kuubik', samuti katsetused sellega. Samuti meeldib mulle jagada nende katsete tulemusi ja üldiselt oma isiklikke kogemusi. Seepärast olen salvestanud seriaali veebinaridest K8s kohta, tere tulemast meie YouTube kanalile lisainfot saama.

Allikas: habr.com