Existuje několik způsobů, jak nakonfigurovat úložiště dat pro aplikace běžící na clusteru Kubernetes. Některé z nich jsou již zastaralé, jiné se objevily poměrně nedávno. V tomto článku se podíváme na koncept tří možností připojení úložných systémů, včetně té nejnovější – připojení přes Container Storage Interface.
Metoda 1: Zadejte PV v manifestu pod
Typický manifest popisující pod v clusteru Kubernetes:
Části manifestu, které popisují, který svazek je připojen a kde, jsou barevně zvýrazněny.
V sekci volumeMounts uveďte přípojné body (mountPath) - do kterého adresáře uvnitř kontejneru bude připojen trvalý svazek a také název svazku.
V sekci x uvádí všechny svazky, které jsou použity v podu. Zadejte název každého svazku a také typ (v našem případě: awsElasticBlockStore) a parametry připojení. Které parametry jsou uvedeny v manifestu, závisí na typu svazku.
Stejný objem lze namontovat současně do více zásobníků pod. Tímto způsobem mohou různé aplikační procesy přistupovat ke stejným datům.
Tato metoda připojení byla vynalezena na úplném začátku, kdy byl Kubernetes teprve v plenkách, a dnes je metoda zastaralá.
Při používání nastává několik problémů:
- všechny svazky musí být vytvořeny ručně, Kubernetes za nás nemůže nic vytvořit;
- přístupové parametry pro každý svazek jsou jedinečné a musí být uvedeny v manifestech všech modulů, které svazek používají;
- Chcete-li změnit systém úložiště (například přejít z AWS na Google Cloud), musíte změnit nastavení a typ připojených svazků ve všech manifestech.
To vše je velmi nepohodlné, takže ve skutečnosti se tato metoda používá k připojení pouze některých speciálních typů svazků: configMap, secret, emptyDir, hostPath:
-
configMap a secret jsou svazky služeb, které vám umožňují vytvořit svazek se soubory z manifestů Kubernetes v kontejneru.
-
emptyDir je dočasný svazek vytvořený pouze po dobu životnosti modulu. Pohodlné použití pro testování nebo ukládání dočasných dat. Když je modul smazán, je smazán také svazek emptyDir a všechna data jsou ztracena.
-
hostPath - umožňuje připojit libovolný adresář na lokální disk serveru, na kterém je aplikace spuštěna, uvnitř kontejneru s aplikací, včetně /etc/kubernetes. Toto je nebezpečná funkce, takže zásady zabezpečení obvykle zakazují použití svazků tohoto typu. V opačném případě bude aplikace útočníka schopna připojit adresář HTC Kubernetes do svého kontejneru a ukrást všechny certifikáty clusteru. Obvykle mohou být svazky hostPath používány pouze systémovými aplikacemi, které běží v jmenném prostoru systému kube.
jsou uvedeny v dokumentaci.
Metoda 2. Připojení k topeništi SC/PVC/PV
Alternativní metodou připojení je koncept třídy Storage, PersistentVolumeClaim, PersistentVolume.
Třída úložiště ukládá parametry připojení k systému ukládání dat.
PersistentVolumeClaim popisuje požadavky na to, co aplikace potřebuje.
Trvalý objem ukládá přístupové parametry a stav svazku.
Podstata myšlenky: v manifestu pod označují svazek typu PersistentVolumeClaim a uvádějí název této entity v parametru claimName.
Manifest PersistentVolumeClaim popisuje požadavky na objem dat, který aplikace vyžaduje. Počítaje v to:
- velikost disku;
- přístupová metoda: ReadWriteOnce nebo ReadWriteMany;
- odkaz na Storage class - ve kterém systému ukládání dat chceme svazek vytvořit.
Manifest třídy Storage ukládá typ a parametry připojení k systému úložiště. Cubelet je potřebuje k připojení svazku na svůj uzel.
Manifesty PersistentVolume označují třídu úložiště a parametry přístupu pro konkrétní svazek (ID svazku, cestu atd.).
Při vytváření PVC se Kubernetes podívá na to, jaká velikost svazku a jaká třída úložiště je vyžadována, a vybere bezplatný PersistentVolume.
Pokud takové PV nejsou k dispozici, může Kubernetes spustit speciální program - Provisioner (jeho název je uveden ve třídě Storage). Tento program se připojí k úložnému systému, vytvoří svazek požadované velikosti, obdrží identifikátor a vytvoří manifest PersistentVolume v clusteru Kubernetes, který je spojen s PersistentVolumeClaim.
Celá tato sada abstrakcí vám umožňuje odstranit informace o tom, se kterým úložným systémem aplikace pracuje, z úrovně manifestu aplikace na úroveň administrace.
Všechny parametry pro připojení k systému úložiště dat jsou umístěny ve třídě Storage, za kterou odpovídají správci clusteru. Vše, co musíte udělat při přechodu z AWS na Google Cloud, je změnit název třídy Storage na PVC v manifestech aplikace. Persistance Volume pro ukládání dat bude v clusteru vytvořen automaticky pomocí programu Provisioner.
Metoda 3: Rozhraní úložiště kontejneru
Veškerý kód, který interaguje s různými úložnými systémy, je součástí jádra Kubernetes. Vydání oprav chyb nebo nové funkce je svázáno s novými vydáními, kód je nutné změnit pro všechny podporované verze Kubernetes. To vše je náročné na údržbu a přidávání nových funkcí.
K vyřešení problému vytvořili vývojáři z Cloud Foundry, Kubernetes, Mesos a Docker rozhraní Container Storage Interface (CSI) – jednoduché jednotné rozhraní, které popisuje interakci systému správy kontejnerů a speciálního ovladače (CSI Driver), který pracuje s konkrétním skladovací systém. Veškerý kód pro interakci s úložnými systémy byl přesunut z jádra Kubernetes do samostatného systému.
.
CSI Driver se obvykle skládá ze dvou komponent: Node Plugin a Controller plugin.
Node Plugin běží na každém uzlu a je zodpovědný za připojení svazků a provádění operací na nich. Plugin Controller spolupracuje s úložným systémem: vytváří nebo odstraňuje svazky, přiděluje přístupová práva atd.
V jádře Kubernetes zatím zůstávají staré ovladače, které se však již nedoporučují používat a všem se doporučuje nainstalovat CSI Driver speciálně pro systém, se kterým budou pracovat.
Inovace může vyděsit ty, kteří jsou již zvyklí na nastavení úložiště dat prostřednictvím třídy Storage, ale ve skutečnosti se nic hrozného nestalo. Pro programátory se vlastně nic nemění – pracovali pouze s názvem Storage class a budou tak činit i nadále. Pro administrátory byla přidána instalace kormidla a změnila se struktura nastavení. Pokud byla dříve nastavení zadávána přímo do třídy Storage, nyní musí být nejprve nastavena v tabulce kormidla a poté ve třídě Storage. Když se na to podíváte, nic špatného se nestalo.
Podívejme se na příkladu, jaké výhody můžete získat přechodem na připojení úložných systémů Ceph pomocí ovladače CSI.
Při práci s Cephem poskytuje plugin CSI více možností pro práci s úložnými systémy než vestavěné ovladače.
- Dynamická tvorba disku. Disky RBD se obvykle používají pouze v režimu RWO, ale CSI pro Ceph umožňuje jejich použití v režimu RWX. Několik modulů na různých uzlech může připojit stejný disk RDB na své uzly a pracovat s nimi paralelně. Abychom byli spravedliví, ne všechno je tak jasné - tento disk lze připojit pouze jako blokové zařízení, což znamená, že budete muset přizpůsobit aplikaci, aby s ním pracovala v režimu vícenásobného přístupu.
- Vytváření snímků. V clusteru Kubernetes můžete vytvořit manifest s požadavkem na vytvoření snímku. CSI plugin to uvidí a udělá snímek z disku. Na základě toho můžete vytvořit buď zálohu nebo kopii PersistentVolume.
- Zvětšení velikosti disku na úložišti a PersistentVolume v clusteru Kubernetes.
- Kvóty. Ovladače CephFS zabudované do Kubernetes nepodporují kvóty, ale čerstvé pluginy CSI s nejnovějším Ceph Nautilus mohou kvóty na oddílech CephFS povolit.
- Metriky. Plugin CSI může společnosti Prometheus poskytnout různé metriky o tom, které svazky jsou připojeny, jaká komunikace probíhá atd.
- S vědomím topologie. Umožňuje v manifestech určit, jak je cluster geograficky distribuován, a vyhnout se připojení úložného systému umístěného v Amsterdamu k modulům běžícím v Londýně.
Jak připojit Ceph ke clusteru Kubernetes přes CSI, viz . Můžete se také přihlásit k odběru , která odstartuje 15. října.
Autor článku: Sergey Bondarev, praktikující architekt v Southbridge, Certified Kubernetes Administrator, jeden z vývojářů kubespray.
Trochu Post Scriptum ne pro reklamu, ale pro užitek...
PS Sergey Bondarev vede dva intenzivní kurzy: aktualizované 28.-30. září a pokročilé 14.–16. října.
Zdroj: www.habr.com