🥇Ukládání dat v clusteru Kubernetes

Konfiguraci úložiště dat aplikací spuštěných v clusterech Kubernetes lze provést několika způsoby. Některé z nich jsou už zastaralé, jiné se objevily teprve nedávno. V tomto článku se podíváme na koncept tří variant připojení úložiště, včetně té nejnovější — připojení prostřednictvím Container Storage Interface.

Způsob 1. Určení PV v manifestu podu

Typický manifest popisující pod v clusterech Kubernetes:

Barvou jsou zvýrazněny části manifestu, kde je popsáno, který svazek se připojuje a kam.

V sekci volumeMounts určuje body připojení (mountPath) — do jakého adresáře uvnitř kontejneru bude připojen trvalý svazek, a také jméno svazku.

V sekci x vyjmenovává všechny svazky, které se používají v podu. Uvádí jméno každého svazku a také typ (v našem případě: awsElasticBlockStore) a parametry připojení. Jaké přesně parametry se uvádějí v manifestu, závisí na typu svazku.

Tentýž svazek může být připojen zároveň v několika kontejnerech podu. Takto mohou různé procesy aplikace mít přístup ke stejným datům.

Tento způsob připojení byl vymyšlen na samém začátku, když Kubernetes teprve vznikal, a dnes je zastaralý.

Při jeho použití vzniká několik problémů:

všechny svazky je třeba vytvářet ručně, Kubernetes nebude schopno vytvořit nic za nás;
parametry přístupu k jednotlivým svazkům jsou unikátní a je třeba je uvádět v manifestech všech podů, které svazek používají;
pro změnu úložiště (například přechod z AWS na Google Cloud) je nutné měnit nastavení a typ připojených svazků ve všech manifestech.

To vše je velmi nepohodlné, proto se ve skutečnosti tímto způsobem používají pouze některé speciální typy svazků: configMap, secret, emptyDir, hostPath:

configMap a secret — služební svazky, umožňují vytvořit v kontejneru svazek s soubory z manifestů Kubernetes.
emptyDir — dočasný svazek, vytváří se pouze na dobu života podu. Je vhodné ho používat pro testování nebo uchovávání dočasných dat. Když je pod odstraněn, svazek typu emptyDir je také odstraněn a všechna data zmizí.
hostPath — umožňuje připojit do kontejneru s aplikací jakýkoliv adresář z místního disku serveru, na kterém aplikace běží, včetně /etc/kubernetes. To je riskantní funkce, a proto bezpečnostní politiky obvykle zakazují použití objemů tohoto typu. Jinak může útočníkova aplikace připojit do svého kontejneru adresář HTC Kubernetes a ukrást všechny certifikáty clusteru. Obvykle se objemy hostPath umožňují používat pouze systémovým aplikacím, které běží v namespace kube-system.

Systémy ukládání dat, se kterými Kubernetes pracuje bez dalších úprav jsou uvedeny v dokumentaci.

Způsob 2. Připojení k podům SC/PVC/PV

Alternativní způsob připojení — koncept Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class uchovává parametry připojení k systému ukládání dat.

PersistentVolumeClaim popisuje požadavky na objem potřebný aplikaci.
PersistentVolume uchovává parametry přístupu a stav objemu.

Jádro myšlenky: v manifestu podu se uvádí objem typu PersistentVolumeClaim a uvádí se název této entity v parametru claimName.

V manifestu PersistentVolumeClaim se popisují požadavky na objem dat, který je potřebný aplikaci. Mezi nimi:

velikost disku;
způsob přístupu: ReadWriteOnce nebo ReadWriteMany;
odkaz na Storage class — ve kterém systému ukládání dat chceme objem vytvořit.

V manifestu Storage class jsou uloženy typ a parametry připojení k systému ukládání dat. Ty jsou potřebné kubeletu, aby připojil objem k sobě na uzel.

V manifestech PersistentVolume se uvádí Storage class a parametry přístupu k konkrétnímu objemu (ID objemu, cesta atd.).

Při vytváření PVC Kubernetes zkoumá, jakou velikost objemu a z jaké Storage class bude potřeba, a vybírá dostupný PersistentVolume.

Pokud takové PV nejsou k dispozici, může Kubernetes spustit speciální program — Provisioner (její název se uvádí ve Storage class). Tento program se připojuje k SCSI, vytváří objem požadované velikosti, získává identifikátor a vytváří v clusterech Kubernetes manifest PersistentVolume, který se váže na PersistentVolumeClaim.

Toto množství abstrakcí umožňuje oddělit informace o tom, s jakou SCSI aplikace pracuje, z úrovně manifestů aplikací na úroveň správy.

Všechny parametry připojení k systému pro ukládání dat jsou součástí Storage class, za které odpovídají administrátoři clustera. Vše, co je potřeba udělat při přechodu z AWS na Google Cloud, je změnit název Storage class v PVC v manifestech aplikace. Persistent Volumes pro ukládání dat budou automaticky vytvořeny v clusterech pomocí programu Provisioner.

Způsob 3. Container Storage Interface

Veškerý kód, který interaguje s různými systémy pro ukládání dat, je součástí jádra Kubernetes. Vydávání oprav chyb nebo nové funkčnosti je vázáno na nové release, kód se musí měnit pro všechny podporované verze Kubernetes. To vše je těžké udržovat a přidávat novou funkčnost.

Aby se vyřešil problém, vytvořili vývojáři z Cloud Foundry, Kubernetes, Mesos a Docker Container Storage Interface (CSI) — jednoduché unifikované rozhraní, které popisuje interakci mezi systémem správy kontejnerů a speciálním ovladačem (CSI Driver), který pracuje s konkrétními SCSI. Veškerý kód pro interakci se SCSI byl vyňat z jádra Kubernetes do samostatného systému.

Dokumentace k Container Storage Interface.

Obvykle se CSI Driver skládá ze dvou komponent: Node Plugin a Controller Plugin.

Node Plugin je spouštěn na každém uzlu a odpovídá za montování objemů a operace na nich. Controller Plugin interaguje se SCSI: vytváří nebo odstraňuje objemy, přiřazuje přístupová práva atd.

Zatím v jádře Kubernetes zůstávají staré ovladače, ale jejich používání již není doporučeno a všem se radí instalovat CSI Driver konkrétně pro ten systém, se kterým budou pracovat.

Novinka může vystrašit ty, kteří si už zvykli nastavovat úložiště přes Storage class, ale ve skutečnosti se nic hrozného nestalo. Pro programátory se určitě nic nemění — stále pracují pouze s názvem Storage class. Pro administrátory se přidala instalace helm chart a změnila se struktura nastavení. Pokud dříve byla nastavení zadávána přímo do Storage class, nyní je nejprve nutné je určit v helm chart a poté v Storage class. Pokud se na to podíváte, nic hrozného se nestalo.

Pojďme si na příkladu ukázat, jaké výhody lze získat přechodem na připojení SCSI Ceph pomocí CSI ovladače.

Při práci s Ceph poskytuje CSI plugin více možností pro práci se SCSI než integrované ovladače.

Dynamické vytváření disků. Obvykle se disky RBD používají pouze v režimu RWO a CSI pro Ceph umožňuje jejich použití v režimu RWX. Více podů na různých uzlech může připojit stejný RDB disk a pracovat s ním současně. Je třeba poznamenat, že tento disk lze připojit pouze jako blokové zařízení, takže je nutné přizpůsobit aplikaci pro práci s ním v režimu vícestupňového přístupu.
Vytváření snapshotů. V clusteru Kubernetes lze vytvořit manifest se žádostí o vytvoření snapshotu. CSI plugin ho uvidí a vytvoří snapshot z disku. Na jeho základě bude možné provést buď zálohu, nebo kopii PersistentVolume.
Zvětšení velikosti disku na storage a PersistentVolume v clusteru Kubernetes.
Kvóty. Vestavěné ovladače CephFS v Kubernetes nepodporují kvóty, zatímco nové CSI pluginy se čerstvým Ceph Nautilus umí povolit kvóty na CephFS oddílech.
Metriky. CSI plugin může poskytovat v Prometheu mnoho metrik o tom, jaké svazky jsou připojeny, jaké probíhají interakce atd.
Topologická informovanost. Umožňuje uvést v manifestech, jak je geograficky rozložen cluster, a vyhnout se připojení k podům, které běží v Londýně, k systému ukládání dat umístěnému v Amsterdamu.

Jak připojit Ceph k clusteru Kubernetes přes CSI, viz v praktické části přednášky večerní školy Sljorm. Také se můžete přihlásit na videokurz Ceph, který začne 15. října.

Autor článku: Sergej Bondarěv, praktický architekt ve Southbridge, Certified Kubernetes Administrator, jeden z vývojářů kubespray.

Trochu post scriptum ne reklamy, ale pro užitečnost...

P.S. Sergej Bondarěv vede dva intenzivy: aktualizovaný Základy Kubernetes 28-30. září a pokročilý Mega Kubernetes 14–16. října.