Kuberneteses reservatsioon: see eksisteerib

Minu nimi on Sergei, ma olen ettevõttest ITSumma ja tahan rääkida, kuidas me läheneme varundamisele Kuberneteses. Viimasel ajal olen palju nõustamistööd teinud erinevate devops-lahenduste rakendamise nimel, töötades erinevate meeskondadega, sealhulgas projektides, mis kasutavad K8s-i. Uptime day 4 konverentsil, kus arutati keerukate arhitektuuride varundamist, esitlesin ettekannet "kuubiku" varundamisest ning see on selle vabalt tõlgendatud kokkuvõte. Avalikult tahan eelnevalt märkida, et see ei ole otsene juhend, vaid pigem toimetuslik kokkuvõte antud teemal.

Põhimõtteliselt on jälgimine ja varundamine kaks peamist tööriista, mis suurendavad projekti tõrketaluvust. Aga kas Kubernetesis ei ole kõik ise tasakaalus, küsiksite te? Kõik skaleerub automaatselt ja kui midagi juhtub, siis tõuseb see ise... See tähendab, et esmapilgul teema uurimisel vastas internet mulle küsimusele, kuidas lähenetakse K8s-i varundamisele, 'miks üldse?'. Paljud arvavad, et Kubernetes on nagu maagiline tööriist, mis vabastab kõikidest infrastruktuuri probleemidest ja tagab, et projekt ei kuku kunagi kokku. Kuid... maailm ei ole see, milleks see näib.

Kuidas me varundamisprotsessi varem lähenesime? Meil olid identsed teenusepakkujad – kas see olid virtuaalmasinad või füüsilised serverid, serverid, millele rakendasime kolme põhipraktikat:

1. koodi ja staatika sünkroniseerimine
2. konfiguratsioonide sünkroniseerimine
3. andmebaasi replikatsioon

Ja voilà: igal ajal saame üle lülituda varuplatsile, kõik on õnnelikud, tõusame ja lahkume.

Mida meile pakutakse meie kubernetes-rakenduse pideva kättesaadavuse suurendamiseks? Esimene asi, millest ütleb mitteametlik dokumentatsioon, on paigaldada palju masinaid, luua palju meistreid - nende arv peaks rahuldama kvorumi saavutamise tingimusi klastris ja et iga meistri juures oleks töös etcd, api, MC, scheduler… Ja näib, et kõik on suurepärane: kui mõned töönoodid või meistrid rikki lähevad, siis meie klaster tasakaalustatakse ümber ja rakendus töötab edasi. Jälle näeb see välja nagu maagia! Kuid tihti on meie klaster ühe andmekeskuse raames ja see võib tekitada teatud küsimusi. Mis juhtub, kui kaevur tuleb ja kaevab kaabli üles, välk lööb, toimub universaalne uputus? Kõik on katki, meie klastrit enam pole. Kuidas läheneda varundamisele arvestades seda probleemipoolt?

Esiteks peaks teil olema veel üks klaster sooja varuna, st klaster, millele saate igal ajal üle minna. Samuti peaksid infrastruktuuri poolest olema klastrid täiesti identsed. See tähendab, et kui on mingeid mitte-standardseid pluginaid failisüsteemiga töötamiseks, kohandatud lahendusi ingressiks, peavad need olema teie kahel (või kolmel, või kümnel, siin on see juba raha ja administraatorite jõupingutuste küsimus) klastril täiesti identsed. Tuleb selgelt määratleda kaks rakenduste (deployment’ide, statefulset’ide, daemonset’ide, cronjob’ide jne) komplekti: millised neist võivad pidevalt töötada varunduses ja milliseid on parem mitte käivitada enne otsest üleminekut.

Kas meie varundusklaster peaks olema täiesti identne meie tootmisclusteriga? Ei. Kui varem monoliitsetes projektides, rauainfrastruktuuris hoidsime praktiliselt täielikult identset keskkonda, siis kubernekesis ma arvan, et seda ei tohiks olla. Vaatame, miks.

Näiteks alustame Kubernetes'i põhielementidest — deployments - need peavad olema identsed. Peavad olema käivitatud rakendused, mis suudavad igal ajal liiklust töödelda ja võimaldavad meie projektil edasi elada. Kui räägime konfigureerimisfailidest, siis tuleb vaadata, kas need peavad olema identsed või mitte. St kui me, targad inimesed, ei tarbi mingit keelatud ainet ja ei hoia andmebaasi K8s, siis peaks meie configmaps'ides olema juurdepääsude seadistused peamise andmebaasi jaoks (mille reserveerimisprotsess on korraldatud eraldi). Vastavalt sellele, et tagada juurdepääs varukoopia andmebaasile, peame omama eraldi konfigureerimisfaili (configmap). Just nii töötame ka secret'itega: paroolidega andmebaasi juurdepääsuks, API-võtmetega; igal ajal võib meil olla töötav kas peamine secret või varu. Kokkuvõttes on meil juba kaks Kubernetes'e elementi, mille varukoopiad ei tohiks olla identsed peamistega. Järgmine element, millele tasub peatuda, on cronjob. Varukoopia cronjob'id ei tohi mingil juhul olla identsed tootmisklastri cronjob'idega! Kui me tõstame varuklastri üles ja käivitame selle täielikult koos kõigi aktiveeritud cronjob'idega — siis näiteks saavad inimesed teilt korraga kaks kirja ühe asemel. Või mõne andmete sünkroniseerimine välistest allikatest toimub kaks korda, vastavalt sellele hakkame me haiget saama, nutma, karjuma ja sõimama.

Kuidas meedia teab, kuidas korraldada varuklastrit? Teine populaarne vastus peale „miks?” — Kubernetes Federationi kasutamine.

Mis see on? See on, ütleme nii, suur meta-klaster. Kui me kujutame ette kube arhitektuuri — kus meil on meester, mitu sõlme — siis föderatsiooni vaatenurgast on meil samuti meister ja mitu sõlme, ainult et iga sõlm on eraldi klaster. See tähendab, et me töötame nende samade entsüklopediate ja primitiividega, nagu tavalise kube puhul, ainult et toimetame mitte meie füüsiliste masinatega, vaid tervete klastritega. Föderatsiooni raames toimub täielik föderatiivsete ressursside sünkroonimine vanematest järeltulijatele. Näiteks kui me käivitame mingi deployment'i läbi föderatsiooni — see paigaldatakse igasse meie tütarklastrisse. Kui me võtame mõne konfiguratsioonikaardi, salajase, ja rakendame seda föderatsioonis — see levib kõigisse meie tütarklastritesse; samal ajal võimaldab föderatsioon meil kohandada meie ressursse lastes. See tähendab, et me võtsime mõne konfiguratsioonikaardi, paigaldasime selle läbi föderatsiooni ja siis, kui meil on vaja midagi konkreetset, me muudame seda eraldi klastris ning see muudatus ei sünkroonita enam kuhugi.

Kubernetes Federation on hiljuti loodud tööriist ja see toetab kaugel mitte kogu ressursikomplekti, mille K8s ise pakub: dokumendi ühe varasema versiooni avaldamise ajal räägiti, et toetas ainult konfiguraatsioonikaarte, rakendusi replikasete all, ingressi. Salajased andmed ei olnud toetatud, töö mahtudega samuti ei olnud toetatud. Liialt piiratud komplekt. Eriti kui me armastame lõbutseda - näiteks edastada oma ressursse Kubernetesile läbi custom resource definition - ei saa me neid liidame federatsiooni. See on nagu... väga tõsi lahendus, kuid sunnib meid perioodiliselt endale jalga tulistama. Teisest küljest võimaldab federatsioon paindlikult hallata meie replicaset'i. Näiteks kui me tahame, et meie rakendusest töötaks 10 koopiat, jagab federatsioon selle arvu automaatselt klastrite vahel. Ja kõike seda saab ka konfigureerida! Võite näidata, et tootmisklastris peavad olema 6 koopiat meie rakendusest, ning reserveeritud klastris, ressursside kokkuhoiu nimel, või oma lõbustamiseks - vaid 4 koopiat meie rakendusest. Mis on samuti üsna mugav. Kuid federatsiooniga peame kasutama uusi lahendusi, midagi tuleb jooksvalt juurde seadistada, sundima end natuke rohkem mõtlema...

Kas saaksime läheneda Kubernetes'i varundamisprotsessile kuidagi lihtsamalt? Millised tööriistad meil üldse on?

Esiteks on meil alati mingisugune CI/CD süsteem, mis tähendab, et me ei käi käsitsi, ega kirjuta serverites create/apply. Süsteem genereerib YAML-failid meie konteinerite jaoks.

Teiseks on mitu klastrit, meil on kas üks või mitu (kui me oleme targad) registrit, mille oleme samuti reserveerinud. Ja meil on suurepärane utiliit kubectl, mis oskab töötada mitme klastri jaoks samaaegselt.

Nii et: minu arvates on kõige lihtsam ja õigem lahendus varukoopia klastrite ülesehitamiseks primitiivne paralleelne deploy. Seal on mingi CI/CD süsteemis töötav pipeline; esmalt anname ehituse meie konteineritele, testime ja seadistame rakendusi kubectl kaudu mitmesse sõltumatutesse klastrisse. Saame teha samal ajal väljalaskeid mitmesse klastrisse. Seega lahendame konfiguratsioonide edastamise ka sel hetkel. Saame eelnevalt määrata konfiguratsioonide kogumi meie tootmisklastri jaoks, varuklastri konfiguratsioonide kogumi ning CI/CD süsteemi tasemel levitada tootmisvälja tootmisklastrisse, varuvälja varuklastrisse. Võrreldes föderatsiooniga pole pärast föderatiivse ressursi kindlaksmääramist vaja iga mahakantud klastrisse minna ja midagi ületada. Oleme selle eelnevalt teinud. Kui toredad me oleme.

Kuid... on... ma olin kirjutanud, et on „kõikide probleemide juur”, kuid neid on tegelikult kaks. Esiteks, failisüsteem. On mingi PV, või kasutame me välist salvestust. Kui me salvestame faile klastrisse, peame käituma vanade praktikate kohaselt, mis on jäänud terasest infrastruktuuride ajast: näiteks sünkroniseerima lsync'iga. Või mõne muu teie poolt isiklikult eelistatud ning abiainena. Seame kõik uutele masinatele ja elame edasi.

Teiseks, ja tegelikult isegi olulisem takistuspunkt — andmebaas. Kui me oleme targad inimesed ja ei hoia andmebaasi kuberenetes, siis andmete varundamise protsess on sama vana skeemi järgi — master-slave replikatsioon, siis lülitus ja replikatsioon, hoidke andmebaas käimas ja elame hästi. Kuid kui me hoiame oma andmebaasi klastris, siis on olemas palju valmis lahendusi master-slave replikatsiooni korraldamiseks, palju lahendusi andmebaasi käivitamiseks kuberenetes.
Andmebaaside varundamisest on juba miljard ettekannet peetud, kirjutatud miljard artiklit, midagi uut siin tegelikult ei ole. Üldiselt järgige oma unistusi, elage nagu soovite, leiutage endale ka mõned keerulised abivahendid, kuid mõelge kindlasti, kuidas te kõike seda varundate.

Ja nüüd räägime sellest, kuidas põhimõtteliselt toimub meie protsess varusüsteemile üleminek tulekahju korral. Esiteks paigaldame paralleelselt stateless-rakendusi. Need ei mõjuta meie rakenduste, meie projekti äriloogikat. Saame pidevalt hoida kahte käivitatud rakenduste komplekti, mis võivad hakata liiklust vastu võtma. Ülemineku protsessi käigus on väga oluline jälgida, kas konfiguratsioone on vaja ümber seadistada. Näiteks, meil on tootmiscluster Kuberneteses, meil on varucluster Kuberneteses, meil on väline andmebaas master ja meil on varu andmebaas master. Meil on neli võimalust, kuidas need rakendused tootmises saavad omavahel suhelda. Andmebaas võib minna vahetusse ja selgub, et tootmisclusteris tuleb liiklus suunata uuele andmebaasile, või meie cluster võib minna katki — ja me oleme üle läinud varu peal, aga jätkame töötamist tootmisandmebaasiga, ning kolmas variant on see, kui see on katki ja too on katki, ja me suuname mõlemad rakendused ümber, seadistame meie konfiguratsiooni nii, et uued rakendused töötavad juba uue andmebaasiga.

Ja mis järeldused me kõik sellest teha saame?

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 teise teenusepakkuja juures. Sageli on olnud nii — ja minu praktikas on see tõesti juhtunud. Kahjuks ei saa ma projekte nimetada, kui just ajal, kui toimus tulekahju andmekeskuses… Ma ütlesin: lülitame varule üle! Ja varu serverid olid sama rack'i sees...

Või kujutage ette, et Amazon on Venemaal blokeeritud (ja see on juhtunud). Ja kõik: mis kasu on sellest, et teises amazonis on meie varu? See ei ole ka ju kätte saadav. Seega kordasin: hoidke varu vähemalt teises andmekeskuses ja soovitavalt — teise teenusepakkuja juures.

Teine väljund: kui teil on Kubernetesis rakendus, mis suhtleb väliste allikatega (see võib olla nii andmebaas kui ka mõni väline API), määrake see kindlasti teenusena, millel on väline lõpp-punkt, et lülitamisel ei peaks iga kord 15 rakendust, mis pöörduvad sama andmebaasi poole, uuesti üles seadma. Määrake andmebaas eraldi teenusena, pöörduge selle poole justkui see oleks teie klastris: kui teie andmebaas mingil põhjusel hävib, muudate ip-d ühes kohas ja elate edasi õnnelikult.

Ja lõpetuseks: ma armastan "kuubikut", nagu ka eksperimente selle alusel. Mulle meeldib jagada nende katsete tulemusi ja üldiselt oma isiklikku kogemust. Seetõttu olen salvestanud K8si kohta veebiseminaride seeria, olete oodatud meie YouTube'i kanalile lisainfot saama.

Allikas: habr.com