Nainstalovat Kubernetes je na jeden víkend. Provozovat ho je těch dalších čtyři sta nocí. Většina toho rozdílu se do nabídky nikdy nedostane, protože se skládá z věcí, které jsou vidět jedině ve chvíli, kdy selžou: záloha, která nakonec chybí, certifikát, který nikdo neobnovil, svazek, který se ve tři ráno zaplnil.
Prodáváme provoz, ne instalaci. Tenhle článek popisuje, co ta věta v našich clusterech konkrétně znamená - dost konkrétně na to, abyste si mohli ověřit, jestli to váš současný dodavatel dělá stejně.
Tři vrstvy záloh, protože jedna je jediný bod selhání
Snapshoty bloků, objekty clusteru a logické výpisy databází řeší různé problémy a ani jedno z toho nezastupuje to ostatní.
První vrstva: zálohy svazků. Opakovaná úloha Longhornu běží v 01:00 UTC a zálohuje každý označený svazek do objektového úložiště Hetzneru v Helsinkách, inkrementálně, s historií sedmi dnů. Je to úplný obraz blokového zařízení - rychle se z něj obnovuje, ale u běžící databáze je konzistentní jen na úrovni pádu.
Druhá vrstva: objekty clusteru. Velero zálohuje manifesty Kubernetes - deployments, stateful sets, secrets, config maps - s historií jednoho týdne. Data svazků úmyslně ne: to je práce první vrstvy a míchání obojího vyrábí zálohy, které selžou napůl způsobem, jakého si nikdo nevšimne.
Třetí vrstva: logické výpisy. U databází, kde chceme transakčně konzistentní obnovu a přesnost na úrovni „vrať to do včerejška“, vypisuje úloha spouštěná cronem databázi do vlastního úložiště, oddělenou od záloh svazků.
Výchozí stav je nezálohovat. Každý chráněný svazek je vědomá řádka v seznamu v Gitu a každé rozhodnutí něco nechránit v tom seznamu zůstává jako zakomentovaná řádka s důvodem. Jinak za půl roku nikdo nepozná, jestli chybějící záznam bylo rozhodnutí, nebo opomenutí.
Co monitoring hlídá
Alerty existují pro způsoby selhání, které služby opravdu položí, ne pro přehledovou obrazovku plnou zelené:
- Úložiště - svazky nad 80 % a nad 90 % zaplnění, k tomu alert na rychlý růst pro cokoli, co za hodinu přibere 10 %. Růst zachycený z trendu je lepší než růst zachycený z výpadku.
- Zdraví úložiště - degradované a vadné svazky, uzly, jejichž úložiště není připravené, disky blížící se zaplnění.
- Zdraví clusteru - paměť řídicí vrstvy i pracovních uzlů, velikost databáze etcd, uzly přecházející do stavu not-ready, čekání na I/O, opakované přenosy TCP a odebraný procesorový čas.
- Mimo cluster - sondy dostupnosti, blížící se expirace certifikátů TLS, růst poštovní frony a zaplnění disku na samostatných serverech, které reportují do téhož Prometheu.
- Logy - centralizované, takže incident se vyšetřuje z jednoho místa místo hádání, který pod si pustit.
Úložiště nadimenzované tak, aby ještě mohlo růst
Jedno pravidlo určuje, jak dimenzujeme, a vyplatí se ho převzít: svazek se dá zvětšit, nikdy zmenšit.
Kubernetes odmítne snížení požadované velikosti úložiště. Takže „přidáme si rezervu, pro jistotu“ není opatrnost - je to nevratné rozhodnutí, a k tomu hlučné, protože pozdější pokus to číslo snížit shodí upgrade a zablokuje každé další nasazení té aplikace. Vrátit to zpět znamená odstávku, zálohu, smazání svazku a obnovu dat.
Dimenzujeme proto úsporně a rosteme reaktivně. Kapacitní alerty nám dají varování, zvětšení běží za provozu a nepotřebuje odstávku, a zvětšovat je levné, kdežto zmenšovat drahé. Když si nejste jistí, bezpečnější je menší číslo - přesný opak toho, co většina lidí instinktivně udělá.
Produkční data leží na úložišti se třemi replikami. Úložiště s jednou replikou je vyhrazené pro věci, které jsou skutečně zahoditelné, jako jsou cache a testovací prostředí. Šetříme na velikosti svazků, nikdy na redundanci živých dat.
Git je zdroj pravdy, i ve tři ráno
V produkci se ručně nemění nic. Nasazuje se přes Git a pipeline: commit, postavení obrazu označeného neměnným SHA commitu, povýšení release z chartů a hodnot, které žijí v infrastrukturním repozitáři.
Pokušení opravit produkční systém přímo je nejsilnější během incidentu, což je přesně ta chvíle, kdy udělá nejvíc škody - změna není vidět v auditní stopě a při dalším nasazení zmizí, obvykle za několik týdnů, kdy si už nikdo ty dvě události nespojí. Havarijní přístup existuje, ale je to výslovné a zaznamenané rozhodnutí, ne zvyk.
Jak byste odešli
Když popisujeme, co děláme po nocích, je fér popsat i cestu pryč. Data si můžete odnést kdykoli: výpisy databází, obsah svazků, hodnoty a manifesty Helmu, které definují vaše nasazení, a zdrojový kód všeho, co jsme pro vás napsali na míru. Všechno běží na standardních open source součástech - Kubernetes, Longhorn, Postgres, Keycloak - takže tu není žádný proprietární runtime k vypnutí a nic, co by fungovalo jen po dobu placení faktur.
Není to velkorysost. Klient, který zůstává proto, že odejít by bolelo, je klient, který přestal posuzovat, jestli jsme k něčemu.
Pro koho to je
- Firmy s produkčním provozem, ale bez vlastního provozního týmu, kde otázka „kdo dostane telefonát?“ má dnes nepříjemnou odpověď.
- Regulované organizace, které potřebují zálohy, jejich uchovávání a obnovu doložit, ne o nich tvrdit, že jsou.
- Týmy, které už Kubernetes provozují a chtějí předat provozní vrstvu bez toho, aby se vzdaly platformy.
Jak začít
Napište nám, co provozujete, jaké máte požadavky na dobu a bod obnovy a co musí během migrace zůstat funkční. Vrátíme se s plánem a s nabídkou.
Napište na info@cybermindnet.eu nebo použijte kontaktní formulář.