🥇Uloženie dát v klastre Kubernetes

Nastaviť ukladanie údajov aplikácií, ktoré sú spustené v klastri Kubernetes, je možné viacerými spôsobmi. Niektoré z nich sú už zastarané, iné sa objavili len nedávno. V tomto článku sa pozrieme na koncept troch možností pripojenia úložiska, vrátane najnovšej — pripojenia cez Container Storage Interface.

Spôsob 1. Určenie PV v manifeste podu

Typický manifest, ktorý popisuje pod v klastri Kubernetes:

Farba zvýrazňuje časti manifestu, kde je opísané, ktorý zväzok sa pripojuje a kam.

V sekcii volumeMounts uvádza body pripojenia (mountPath) – do ktorého adresára vnútri kontajnera sa pripojí trvalý zväzok, ako aj meno zväzku.

V sekcii x vypisujú všetky zväzky, ktoré sa používajú v pode. Uvádzajú názov každého zväzku, ako aj typ (v našom prípade: awsElasticBlockStore) a parametre pripojenia. Aké presne parametre sú uvedené v manifeste, závisí od typu zväzku.

Ten istý zväzok môže byť pripojený súčasne v niekoľkých kontajneroch podu. Takto môžu mať rôzne procesy aplikácie prístup k rovnakým údajom.

Tento spôsob pripojenia bol navrhnutý na začiatku, keď sa Kubernetes práve rozvíjal, a dnes je už zastaraný.

Pri jeho použití vzniká niekoľko problémov:

všetky zväzky je potrebné vytvoriť ručne, Kubernetes za nás nič nevytvorí;
parametre prístupu k každému zo zväzkov sú jedinečné a treba ich uviesť v manifestoch všetkých podov, ktoré zväzok používajú;
pre zmenu systému ukladania (napríklad presun z AWS do Google Cloud) je potrebné upraviť nastavenia a typ pripojených zväzkov vo všetkých manifestoch.

To všetko je veľmi nepríjemné, preto sa v praxi tento spôsob používa iba na pripojenie niektorých špeciálnych typov zväzkov: configMap, secret, emptyDir, hostPath:

configMap a secret – služobné zväzky, umožňujú vytvoriť v kontajneri zväzok s súbormi z manifestov Kubernetes.
emptyDir — dočasný zväzok, vytvára sa iba na čas životnosti podu. Je vhodné ho používať na testovanie alebo ukladanie dočasných údajov. Keď je pod odstránený, zväzok typu emptyDir tiež zmizne a všetky údaje sa stratí.
hostPath — umožňuje pripojiť akýkoľvek adresár lokálneho disku servera, na ktorom aplikácia beží, dovnútra kontajnera s aplikáciou, vrátane /etc/kubernetes. Toto je nebezpečná funkcia, a preto politiky zabezpečenia zvyčajne zakazujú používanie objemov tohto typu. Inak môže útočníkova aplikácia pripojiť do svojho kontajnera adresár HTC Kubernetes a ukradnúť všetky certifikáty klastre. Zvyčajne sa objemy hostPath umožňujú používať len systémovým aplikáciám, ktoré sa spúšťajú v namespace kube-system.

Systémy ukladania údajov, s ktorými Kubernetes pracuje priamo z krabice sú uvedené v dokumentácii.

Spôsob 2. Pripojenie k podom SC/PVC/PV

Alternatívny spôsob pripojenia — koncept Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class uchováva parametre pripojenia k systému ukladania údajov.

PersistentVolumeClaim popisuje požiadavky na objem, ktorý aplikácia potrebuje.
PersistentVolume uchováva parametre prístupu a stav objemu.

Podstatou myšlienky je: v manifeste podu sa uvádza objem typu PersistentVolumeClaim a uvádza sa názov tejto entity v parametri claimName.

V manifeste PersistentVolumeClaim sa popisujú požiadavky na objem údajov, ktorý je potrebný aplikácii. A to vrátane:

veľkosť disku;
spôsob prístupu: ReadWriteOnce alebo ReadWriteMany;
odkaz na Storage class — v ktorom systéme ukladania údajov chceme vytvoriť objem.

V manifeste Storage class sa uchovávajú typ a parametre pripojenia k systému ukladania údajov. Sú potrebné kubeletu na pripojenie objemu k sebe na uzol.

V manifestoch PersistentVolume sa uvádza Storage class a parametre prístupu k konkrétnemu objemu (ID objemu, cesta atď.).

Pri vytváraní PVC Kubernetes kontroluje, aký objem a z akého Storage class bude potrebný a vyberá voľný PersistentVolume.

Ak takéto PV nie sú k dispozícii, Kubernetes môže spustiť špeciálny program — Provisioner (jeho názov sa uvádza v Storage class). Tento program sa pripojí k SHTD, vytvorí objem požadovanej veľkosti, získa identifikátor a vytvorí v klastri Kubernetes manifest PersistentVolume, ktorý sa viaže s PersistentVolumeClaim.

Toto množstvo abstrakcií umožňuje odstrániť informácie o tom, s ktorým SHTD aplikácia pracuje, z úrovne manifestov aplikácií na úroveň administrácie.

Všetky pripojovacie parametre k systému ukladania údajov sa nachádzajú v Storage class, za ktorý zodpovedajú správcovia klastra. Všetko, čo treba urobiť pri presune z AWS do Google Cloud, je zmeniť názov Storage class v PVC v manifestoch aplikácie. Persistenčný objem na ukladanie údajov sa v klastri automaticky vytvorí pomocou programu Provisioner.

Spôsob 3. Rozhranie úložiska kontajnerov

Celý kód, ktorý interaguje s rôznymi systémami ukladania údajov, je súčasťou jadra Kubernetes. Vydávanie opráv chýb alebo novej funkčnosti je viazané na nové verzie, čo znamená, že kód je potrebné meniť pre všetky podporované verzie Kubernetes. Všetko toto je ťažké udržiavať a pridávať novú funkčnosť.

Aby sa problém vyriešil, vývojári z Cloud Foundry, Kubernetes, Mesos a Docker vytvorili Rozhranie úložiska kontajnerov (CSI) — jednoduché jednotné rozhranie, ktoré popisuje interakciu systému správy kontajnerov a špeciálneho ovládača (CSI Driver), ktorý pracuje so špecifickým úložným systémom. Celý kód interakcie so SÚD presunuli z jadra Kubernetes do samostatného systému.

Dokumentácia k Rozhraniu úložiska kontajnerov.

Zvyčajne pozostáva CSI Driver z dvoch komponentov: Node Plugin a Controller plugin.

Node Plugin sa spúšťa na každom uzle a zodpovedá za pripojenie objemov a operácie na nich. Controller plugin interaguje so SÚD: vytvára alebo odstraňuje objemy, priraďuje prístupové práva atď.

Kým v jadre Kubernetes zostávajú staré ovládače, ich používanie už nie je odporúčané a všetkým sa doporučuje nainštalovať CSI Driver konkrétne pre systém, s ktorým sa má pracovať.

Toto novinky môžu vystrašiť tých, ktorí si už zvykli na nastavenie ukladania údajov prostredníctvom Storage class, ale v skutočnosti sa nič zlé nestalo. Pre programátorov sa presne nič nemení — budú sa aj naďalej zaoberať iba menom Storage class. Pre správcov pribudla inštalácia helm chart a zmenila sa štruktúra nastavení. Zatiaľ čo predtým sa nastavenia zadávali priamo v Storage class, teraz ich najprv treba zadať v helm chart a až potom v Storage class. Ak sa do toho človek ponoří, nič zlé sa nestalo.

Poďme si na príklade ukázať, aké výhody môžeme získať prechodom na pripojenie úložiska Ceph pomocou ovládača CSI.

Pri práci s Ceph poskytuje plugin CSI viac možností pre prácu so SÚD než zabudované ovládače.

Dynamické vytváranie diskov. Zvyčajne sa disky RBD používajú len v režime RWO, a CSI pre Ceph umožňuje ich používanie v režime RWX. Niekoľko pod’ov na rôznych uzloch môže namontovať ten istý RDB-disk na svoje uzly a pracovať s nimi paralelne. Na spravodlivosť, nie je všetko tak ružové — tento disk je možné pripojiť iba ako blokové zariadenie, teda bude potrebné prispôsobiť aplikáciu na prácu s ním v režime viacerého prístupu.
Vytvorenie snapshotov. V klastre Kubernetes je možné vytvoriť manifest s požiadavkou na vytvorenie snapshotu. Plugin CSI si to všimne a vytvorí snapshot z disku. Na jeho základe bude možné urobiť buď zálohu alebo kópiu PersistentVolume.
Zväčšenie veľkosti disku na SÚZD a PersistentVolume v klastre Kubernetes.
Kvóty. Vstavané ovládače CephFS v Kubernetes nepodporujú kvóty, zatiaľ čo nové CSI pluginy s novým Ceph Nautilus dokážu povoliť kvóty na CephFS oddieloch.
Metriky. CSI plugin môže poskytovať v Prometheus množstvo metrik o tom, aké zväzky sú pripojené, aké interakcie prebiehajú atď.
Geograficky vedomé. Umožňuje špecifikovať v manifestoch, ako je geograficky rozložený klaster a vyhnúť sa pripojeniu k podom, ktoré sú spustené v Londýne, k systému ukladania dát umiestnenému v Amsterdame.

Ako pripojiť Ceph k klastru Kubernetes cez CSI, pozrite si v praktickej časti prednášky večernej školy Slyrm. Taktiež sa môžete prihlásiť na video kurz Ceph, ktorý začne 15. októbra.

Autor článku: Sergey Bondarev, praktizujúci architekt Southbridge, Certified Kubernetes Administrator, jeden z vývojárov kubespray.

Trochu Post Scriptum nie reklamy, ale pre užitočnosť...

P.S. Sergey Bondarev vedie dva intenzívy: aktualizovaný Základy Kubernetes 28-30. septembra a pokročilý Mega Kubernetes 14.-16. októbra.