Docker Compose ali Kubernetes: visoka razpoložljivost ima strošek upravljanja

Dockerjeva produkcijska navodila opisujejo namestitev Compose na enem strežniku kot najpreprostejšo možnost. Za manjšo ekipo je to razumna izbira, če lahko ob odpovedi gostitelja storitev začasno obstane in jo ekipa obnovi v sprejemljivem času. Kubernetes postane smiseln, ko mora storitev preživeti odpoved vozlišča, se prilagajati izrazito spremenljivi obremenitvi ali več ekip potrebuje ločene pravice za delo z aplikacijami.

Odločitev določajo zahteve storitve in zmožnost ekipe, da izbrano okolje vzdržuje. Dodatne kopije aplikacije pomagajo pri odpovedi vozlišča le, če tečejo na ločenih gostiteljih in lahko do njih še vedno pride promet. Razpoložljivost baze podatkov, shrambe in zunanjih odvisnosti je treba presoditi posebej; sama zamenjava orodja teh skupnih točk odpovedi ne odpravi.

Kaj pomeni produkcijska namestitev s Compose

Compose omogoča, da ekipa z isto definicijo storitev upravlja razvojno in produkcijsko okolje, vendar potrebuje produkcija svoje nastavitve. Sem sodijo primerna vrata, okoljske spremenljivke, politika ponovnega zagona in po potrebi zbiranje dnevnikov. Ločena produkcijska datoteka lahko te spremembe doda osnovni konfiguraciji, ne da bi ekipa vzdrževala povsem drugo definicijo aplikacije.

Politika ponovnega zagona pomaga, če se ustavi vsebnik. Ob odpovedi edinega gostitelja pa na njem ni več okolja, ki bi storitev zagnalo, zato mora ekipa poznati postopek obnove strežnika in podatkov. Podobno posodobitev aplikacije zahteva ponovno gradnjo slike oziroma pripravo nove slike ter ponovno ustvarjanje ustreznih vsebnikov. Pri majhnem številu storitev je tak postopek lahko pregleden, če so posegi načrtovani in je jasno, kdo jih izvede.

Posebno pozornost zahteva stanje aplikacije. Storitev, ki podatke zapisuje na lokalni disk istega strežnika kot spletni del, je od tega gostitelja odvisna tudi po zagonu dodatne kopije spletnega vsebnika. Varnostne kopije, njihova obnovitev, spremljanje delovanja in dostop do gostitelja so zato del produkcijske postavitve, ne dodatki, ki jih lahko nadomesti konfiguracija vsebnikov.

Kdaj se izplača upravljati gručo

Zahteva, da storitev deluje tudi po odpovedi gostitelja, spremeni obseg infrastrukture. Kubernetesova navodila za produkcijsko okolje pri visoki razpoložljivosti obravnavajo ločitev nadzorne ravnine od delovnih vozlišč, več primerkov njenih komponent, uravnotežen dostop do strežnika API in zadostno število delovnih vozlišč. Nadzorna ravnina potrebuje tudi certifikate ter varnostne kopije podatkovne zbirke etcd. Gruča na enem računalniku ohrani isto osnovno točko odpovedi kot enostrežniška namestitev.

To je strošek upravljanja, ki ga je treba primerjati s ceno izpada storitve. Ekipa mora določiti odgovorne za nadgradnje gruče, omrežje, dostop, opazovanje delovanja in obnovitev po napaki. Upravljana storitev lahko prevzame del skrbi za infrastrukturo, vendar morajo biti aplikacija, njene odvisnosti in razporeditev kopij še vedno zasnovane glede na zahtevano razpoložljivost. Če dodatna vozlišča nimajo dovolj prostih virov za prevzem dela ob okvari, samo število vozlišč ne reši težave.

Razlika med okolji je zato najbolj jasna pri vprašanju dopustnega izpada. Kadar je sprejemljiva ročna obnovitev po okvari strežnika, preprostost Compose prihrani stalno skrb za gručo. Kadar mora storitev ostati dosegljiva brez takega posega, mora ekipa načrtovati več gostiteljev, pot prometa do delujočih kopij in razpoložljivost podatkov.

Odločitveno drevo za manjšo ekipo

Najprej opredelite, kaj se sme zgoditi ob odpovedi strežnika. Nato preverite še obremenitev, število ekip in razpoložljivo znanje:

• En strežnik, sprejemljiva ročna obnova: Compose je primerna možnost, če ekipa lahko zazna izpad, obnovi gostitelja in podatke ter s tem izpolni dejanske zahteve storitve. Čas obnove naj vključuje tudi dostop do varnostnih kopij, ne samo ponovnega zagona vsebnika.
• Storitev mora preživeti odpoved vozlišča: potrebni so ločeni gostitelji in odprava drugih skupnih točk odpovedi. Kubernetes je smiseln kandidat, če ekipa potrebuje tudi razporejanje in upravljanje kopij aplikacije v takšni postavitvi. Podatkovna baza in vhodna omrežna pot potrebujeta lasten načrt.
• Obremenitev izrazito niha: presodite, ali ročno povečanje zmogljivosti še dohaja povpraševanje. Opis HorizontalPodAutoscaler pojasnjuje prilagajanje števila podov glede na meritve; za običajne meritve virov je praviloma potreben tudi ločeno nameščen Metrics Server. Več podov pomaga le, če imajo vozlišča zanje prostor oziroma se lahko poveča tudi zmogljivost vozlišč.
• Več ekip potrebuje različne pravice: ločen dostop lahko postane pomembnejši od samega števila storitev. Kubernetesova pravila RBAC omogočajo vezavo vlog na uporabnike, skupine in storitvene račune, tudi z omejitvijo na posamezen imenski prostor. Te pravice je treba določiti in vzdrževati, zato same po sebi niso razlog za gručo, če obstoječi način dostopa ustreza potrebam ekipe.
• Za gručo ni odgovornih skrbnikov: pred prehodom določite, kdo bo vzdrževal nadzorno ravnino, urejal dostop in vodil obnovitev. Zahteva po visoki razpoložljivosti je uporabna odločitev šele, ko ima tudi operativnega lastnika.

Merila ne tvorijo točkovnika. Majhna ekipa z eno kritično storitvijo lahko potrebuje več gostiteljev, medtem ko večja ekipa s predvidljivo obremenitvijo in sprejemljivim izpadom lahko še vedno uporablja Compose. Odločilna je najstrožja zahteva, ki jo mora postavitev dejansko izpolniti.

Kako preiti postopno, ko se zahteve spremenijo

Prehod je lažje omejiti, če ekipa najprej popiše slike, vrata, okoljske nastavitve, trajne podatke in zunanje storitve. Pri vsaki storitvi je koristno vedeti, ali jo je mogoče zagnati v več kopijah in ali je vezana na lokalni disk. Tako se že pred selitvijo pokaže, kateri del zahteva spremembo arhitekture in kateri potrebuje le drugačno namestitev.

1. Začnite s storitvijo brez lokalnega stanja. Pripravite jo v ločenem testnem okolju ter preverite zagon, preverjanje pripravljenosti, dnevnike in povezavo z obstoječimi odvisnostmi. Selitev baze podatkov obravnavajte posebej, skupaj z varnostnimi kopijami in možnostjo vrnitve.
2. Vzpostavite omrežno pot do aplikacije. Objekt Kubernetes Service zagotovi omrežno vstopno točko za skupino podov, čeprav se posamezni podi zamenjajo. Preverite, da odjemalci uporabljajo naslov storitve in da aplikacija ni odvisna od naslova posameznega poda.
3. Preusmerite promet nadzorovano. Novo postavitev primerjajte z obstoječo pri dejanskih zahtevah aplikacije, vnaprej določite razlog za ustavitev prehoda in ohranite pot nazaj. Pred izklopom stare kopije preverite predvsem zapisovanje podatkov: hkratno delovanje obeh namestitev je varno le, če ga uporabljena shramba in aplikacija podpirata.

Tak vrstni red omogoča, da se sprememba omrežne poti, delovanja aplikacije in ravnanja s podatki ne zgodi v enem samem posegu. Ekipa lahko posamezno storitev prenese takrat, ko zanjo obstaja jasna zahteva, preostale pa medtem še naprej upravlja v obstoječi namestitvi.

Preberite tudi:

• Jira ali Linear: nižja cena ne odtehta nujno stroška upravljanja
• Slack ali Mattermost: nadzor nad podatki prinese račun za strežnik
• pgvector ali Pinecone: več hitrosti lahko pomeni skoraj petkrat višji strošek