Existuje niekoľko spôsobov, ako nakonfigurovať ukladanie údajov pre aplikácie spustené v klastri Kubernetes. Niektoré z nich sú už zastarané, iné sa objavili pomerne nedávno. V tomto článku sa pozrieme na koncept troch možností pripojenia úložných systémov vrátane tej najnovšej – pripojenia cez rozhranie Container Storage Interface.
Metóda 1: Zadajte PV v manifeste pod
Typický manifest popisujúci modul v klastri Kubernetes:
Časti manifestu, ktoré popisujú, ktorý zväzok je pripojený a kde, sú farebne zvýraznené.
V sekcii VolumeMounts uveďte body pripojenia (mountPath) - do ktorého adresára vnútri kontajnera bude pripojený trvalý zväzok, ako aj názov zväzku.
V sekcii x zoznam všetkých zväzkov, ktoré sa používajú v pod. Zadajte názov každého zväzku, ako aj typ (v našom prípade: awsElasticBlockStore) a parametre pripojenia. Ktoré parametre sú uvedené v manifeste, závisí od typu zväzku.
Rovnaký objem je možné namontovať súčasne do viacerých zásobníkov. Týmto spôsobom môžu rôzne aplikačné procesy pristupovať k rovnakým údajom.
Táto metóda pripojenia bola vynájdená na úplnom začiatku, keď bol Kubernetes len v plienkach, a dnes je táto metóda zastaraná.
Pri používaní sa vyskytuje niekoľko problémov:
- všetky zväzky musia byť vytvorené ručne; Kubernetes za nás nemôže nič vytvoriť;
- prístupové parametre pre každý zväzok sú jedinečné a musia byť špecifikované v manifestoch všetkých modulov, ktoré zväzok používajú;
- ak chcete zmeniť úložný systém (napríklad prejsť z AWS na Google Cloud), musíte zmeniť nastavenia a typ pripojených zväzkov vo všetkých manifestoch.
To všetko je veľmi nepohodlné, takže v skutočnosti sa táto metóda používa na pripojenie iba niektorých špeciálnych typov zväzkov: configMap, secret, emptyDir, hostPath:
-
configMap a secret sú zväzky služieb, ktoré vám umožňujú vytvoriť zväzok so súbormi z manifestov Kubernetes v kontajneri.
-
emptyDir je dočasný zväzok vytvorený iba na dobu životnosti modulu. Pohodlné použitie na testovanie alebo ukladanie dočasných údajov. Po odstránení modulu sa vymaže aj zväzok emptyDir a všetky údaje sa stratia.
-
hostPath - umožňuje pripojiť ľubovoľný adresár na lokálny disk servera, na ktorom je aplikácia spustená, do kontajnera s aplikáciou, vrátane /etc/kubernetes. Toto nie je bezpečná funkcia, takže bezpečnostné zásady zvyčajne zakazujú používanie zväzkov tohto typu. V opačnom prípade bude môcť aplikácia útočníka pripojiť adresár HTC Kubernetes do svojho kontajnera a ukradnúť všetky certifikáty klastra. Zväzky hostPath môžu zvyčajne používať iba systémové aplikácie, ktoré bežia v mennom priestore systému kube.
sú uvedené v dokumentácii.
Spôsob 2. Pripojenie k SC/PVC/PV ohniskám
Alternatívnou metódou pripojenia je koncept triedy Storage, PersistentVolumeClaim, PersistentVolume.
Skladovacia trieda ukladá parametre pripojenia k systému ukladania údajov.
PersistentVolumeClaim popisuje požiadavky na to, čo aplikácia potrebuje.
Trvalý objem ukladá prístupové parametre a stav zväzku.
Podstata myšlienky: v manifeste pod označujú zväzok typu PersistentVolumeClaim a uvádzajú názov tejto entity v parametri claimName.
Manifest PersistentVolumeClaim popisuje požiadavky na objem údajov, ktoré aplikácia vyžaduje. Počítajúc do toho:
- veľkosť disku;
- prístupová metóda: ReadWriteOnce alebo ReadWriteMany;
- link na Storage class - v akom systéme ukladania dát chceme zväzok vytvoriť.
Manifest triedy Storage ukladá typ a parametre pripojenia k úložnému systému. Cubelet ich potrebuje na pripojenie zväzku na svoj uzol.
Manifesty PersistentVolume označujú triedu úložiska a parametre prístupu pre konkrétny zväzok (ID zväzku, cestu atď.).
Pri vytváraní PVC sa Kubernetes pozrie na to, aký veľký zväzok a aká trieda úložiska sa vyžaduje, a vyberie bezplatný PersistentVolume.
Ak takéto PV nie sú k dispozícii, Kubernetes môže spustiť špeciálny program - Provisioner (jeho názov je uvedený v triede Storage). Tento program sa pripojí k úložnému systému, vytvorí zväzok požadovanej veľkosti, prijme identifikátor a vytvorí manifest PersistentVolume v klastri Kubernetes, ktorý je spojený s PersistentVolumeClaim.
Všetko toto množstvo abstrakcií vám umožňuje odstrániť informácie o systéme úložiska, s ktorým aplikácia pracuje, z úrovne manifestu aplikácie na úroveň správy.
Všetky parametre pre pripojenie k systému ukladania dát sa nachádzajú v triede Storage, za ktorú zodpovedajú správcovia klastra. Všetko, čo musíte urobiť pri prechode z AWS na Google Cloud, je zmeniť názov triedy Storage na PVC v manifestoch aplikácie. Perzistentný zväzok pre ukladanie údajov sa v klastri vytvorí automaticky pomocou programu Provisioner.
Metóda 3: Rozhranie zásobníka
Všetok kód, ktorý interaguje s rôznymi úložnými systémami, je súčasťou jadra Kubernetes. Vydanie opráv chýb alebo nových funkcií je viazané na nové vydania, kód je potrebné zmeniť pre všetky podporované verzie Kubernetes. To všetko je náročné na údržbu a pridávanie nových funkcií.
Na vyriešenie problému vývojári z Cloud Foundry, Kubernetes, Mesos a Docker vytvorili rozhranie Container Storage Interface (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ý systém. Všetok kód pre interakciu s úložnými systémami bol presunutý z jadra Kubernetes do samostatného systému.
.
Ovládač CSI sa zvyčajne skladá z dvoch komponentov: doplnku uzla a doplnku radiča.
Node Plugin beží na každom uzle a je zodpovedný za pripojenie zväzkov a vykonávanie operácií na nich. Doplnok Controller interaguje s úložným systémom: vytvára alebo odstraňuje zväzky, prideľuje prístupové práva atď.
Zatiaľ staré ovládače zostávajú v jadre Kubernetes, ale už sa neodporúčajú používať a každému sa odporúča nainštalovať ovládač CSI špeciálne pre systém, s ktorým bude pracovať.
Inovácia môže vystrašiť tých, ktorí sú už zvyknutí na nastavovanie ukladania dát cez triedu Storage, no v skutočnosti sa nič hrozné nestalo. Pre programátorov sa vlastne nič nemení – pracovali len s názvom Storage class a budú tak robiť aj naďalej. Pre administrátorov pribudla inštalácia kormidla a zmenila sa štruktúra nastavení. Ak sa predtým nastavenia zadávali priamo do triedy Storage, teraz sa musia najskôr nastaviť v tabuľke kormidla a potom v triede Storage. Ak sa na to pozriete, nič zlé sa nestalo.
Uveďme si príklad, aby sme sa pozreli na výhody, ktoré môžete získať prechodom na pripojenie úložných systémov Ceph pomocou ovládača CSI.
Pri práci s Ceph poskytuje doplnok CSI viac možností pre prácu s úložnými systémami ako vstavané ovládače.
- Dynamická tvorba disku. Disky RBD sa zvyčajne používajú iba v režime RWO, ale CSI pre Ceph umožňuje ich použitie v režime RWX. Niekoľko modulov na rôznych uzloch môže pripojiť rovnaký RDB disk na svoje uzly a pracovať s nimi paralelne. Aby sme boli spravodliví, nie všetko je také jasné - tento disk je možné pripojiť iba ako blokové zariadenie, čo znamená, že budete musieť prispôsobiť aplikáciu, aby s ním pracovala v režime viacnásobného prístupu.
- Vytváranie snímok. V klastri Kubernetes môžete vytvoriť manifest s požiadavkou na vytvorenie snímky. CSI plugin to uvidí a urobí snímku z disku. Na základe toho si môžete vytvoriť zálohu alebo kópiu PersistentVolume.
- Zväčšenie veľkosti disku na úložisku a PersistentVolume v klastri Kubernetes.
- Kvóty. Ovládače CephFS zabudované do Kubernetes nepodporujú kvóty, ale nové doplnky CSI s najnovším Ceph Nautilus môžu povoliť kvóty na oddieloch CephFS.
- Metriky. Doplnok CSI môže spoločnosti Prometheus poskytnúť rôzne metriky o tom, ktoré zväzky sú prepojené, aká komunikácia prebieha atď.
- Vedomá topológia. Umožňuje vám určiť v manifestoch, ako je klaster geograficky distribuovaný, a vyhnúť sa pripojeniu úložného systému umiestneného v Amsterdame k modulom spusteným v Londýne.
Ako pripojiť Ceph do klastra Kubernetes cez CSI, pozri . Môžete sa tiež prihlásiť na odber , ktorá odštartuje 15. októbra.
Autor článku: Sergey Bondarev, praktický architekt v Southbridge, Certified Kubernetes Administrator, jeden z vývojárov kubespray.
Trochu Post Scriptum nie na reklamu, ale na úžitok...
PS Sergey Bondarev vedie dva intenzívne kurzy: aktualizované 28. – 30. septembra a pokročilých 14. – 16. októbra.
Zdroj: hab.com