Számos módja van a Kubernetes-fürtön futó alkalmazások adattárolásának konfigurálására. Ezek egy része már elavult, mások egészen nemrég jelentek meg. Ebben a cikkben megvizsgáljuk a tárolórendszerek csatlakoztatásának három lehetőségét, köztük a legújabbat – a konténertároló interfészen keresztül történő csatlakozást.
1. módszer: Adja meg a PV-t a pod-jegyzékben
Egy tipikus jegyzék, amely egy Kubernetes-fürtben lévő podot ír le:
A jegyzék azon részei, amelyek leírják, hogy melyik kötet és hol van csatlakoztatva, színnel vannak kiemelve.
Szakaszban volumeMounts jelölje meg a beillesztési pontokat (mountPath) - a konténeren belül melyik könyvtárba lesz csatolva az állandó kötet, valamint a kötet nevét.
Szakaszban x felsorolja a podban használt összes kötetet. Adja meg az egyes kötetek nevét, valamint típusát (esetünkben: awsElasticBlockStore) és kapcsolati paramétereit. A jegyzékben felsorolt paraméterek a kötet típusától függenek.
Ugyanaz a térfogat egyszerre több hüvelyes tartályba is felszerelhető. Így a különböző alkalmazási folyamatok ugyanazokhoz az adatokhoz férhetnek hozzá.
Ezt a kapcsolódási módot a legelején találták fel, amikor a Kubernetes még csak gyerekcipőben járt, és mára a módszer elavult.
Használata során több probléma is felmerül:
- minden kötetet manuálisan kell létrehozni, a Kubernetes nem tud semmit létrehozni számunkra;
- az egyes kötetek hozzáférési paraméterei egyediek, és ezeket meg kell adni a kötetet használó összes pod manifestjében;
- a tárolórendszer megváltoztatásához (például az AWS-ről a Google Cloudra való átálláshoz) minden manifestben módosítania kell a csatlakoztatott kötetek beállításait és típusát.
Mindez nagyon kényelmetlen, ezért a valóságban ezt a módszert csak néhány speciális típusú kötet csatlakoztatására használják: configMap, secret, emptyDir, hostPath:
-
A configMap és a titkos olyan szolgáltatáskötetek, amelyek lehetővé teszik egy kötet létrehozását a tárolóban lévő Kubernetes-jegyzékfájlból.
-
Az emptyDir egy ideiglenes kötet, amely csak a pod élettartamára készült. Kényelmesen használható ideiglenes adatok tesztelésére vagy tárolására. Egy pod törlésekor a emptyDir kötet is törlődik, és minden adat elveszik.
-
hostPath – lehetővé teszi bármely könyvtár csatlakoztatását annak a kiszolgálónak a helyi lemezére, amelyen az alkalmazás fut, az alkalmazást tartalmazó tárolóban, beleértve az /etc/kubernetes könyvtárat is. Ez egy nem biztonságos szolgáltatás, ezért a biztonsági szabályzatok általában tiltják az ilyen típusú kötetek használatát. Ellenkező esetben a támadó alkalmazása képes lesz beilleszteni a HTC Kubernetes könyvtárat a tárolójába, és ellopni az összes fürttanúsítványt. A hostPath köteteket általában csak a kube-system névtérben futó rendszeralkalmazások használhatják.
a dokumentációban vannak megadva.
2. módszer Csatlakoztatás SC/PVC/PV kandallókhoz
Alternatív kapcsolódási mód a Storage class, PersistentVolumeClaim, PersistentVolume koncepció.
Tárolási osztály kapcsolati paramétereket tárol az adattároló rendszerhez.
PersistentVolumeClamment leírja azokat a követelményeket, amelyekre az alkalmazásnak szüksége van.
PersistentVolume tárolja a hozzáférési paramétereket és a kötet állapotát.
Az ötlet lényege: a pod manifestben egy PersistentVolumeClaim típusú kötetet jeleznek, és ennek az entitásnak a nevét jelzik a requestName paraméterben.
A PersistentVolumeClaim jegyzék leírja az alkalmazás által igényelt adatmennyiség követelményeit. Beleértve:
- lemez mérete;
- hozzáférési mód: ReadWriteOnce vagy ReadWriteMany;
- hivatkozás a Storage osztályhoz - melyik adattároló rendszerben szeretnénk a kötetet létrehozni.
A Tárolási osztály jegyzéke tárolja a tárolórendszerrel való kapcsolat típusát és paramétereit. A kockának szüksége van rájuk, hogy a kötetet a csomópontjára illessze.
A PersistentVolume jegyzékek egy adott kötet Storage osztályát és hozzáférési paramétereit jelzik (kötetazonosító, elérési út stb.).
A PVC létrehozásakor a Kubernetes megvizsgálja, hogy mekkora kötetre és milyen tárolási osztályra van szükség, és kiválaszt egy ingyenes PersistentVolume-ot.
Ha ilyen PV-k nem állnak rendelkezésre, a Kubernetes elindíthat egy speciális programot - Provisioner (a neve a Storage osztályban van feltüntetve). Ez a program csatlakozik a tárolórendszerhez, létrehoz egy szükséges méretű kötetet, azonosítót kap, és létrehoz egy PersistentVolume jegyzéket a Kubernetes-fürtben, amely a PersistentVolumeClaim-hez van társítva.
Az absztrakciók sokasága lehetővé teszi, hogy az alkalmazás jegyzékének szintjéről az adminisztrációs szintre távolítsa el az arról szóló információkat, hogy az alkalmazás melyik tárolórendszerrel dolgozik.
Az adattároló rendszerhez való csatlakozáshoz szükséges összes paraméter a Storage osztályban található, amelyért a fürt adminisztrátorok felelősek. Az AWS-ről a Google Cloudra való áttéréskor mindössze annyit kell tennie, hogy az alkalmazás jegyzékében módosítsa a Storage class nevét PVC-re. Az adattárolás állandó kötete automatikusan létrejön a fürtben a Provisioner program segítségével.
3. módszer. Tartálytárolási felület
Minden kód, amely kölcsönhatásba lép a különböző tárolórendszerekkel, a Kubernetes mag része. A hibajavítások vagy az új funkciók kiadása új kiadásokhoz van kötve; a kódot a Kubernetes összes támogatott verziójában módosítani kell. Mindezt nehéz fenntartani és új funkciókkal bővíteni.
A probléma megoldása érdekében a Cloud Foundry, a Kubernetes, a Mesos és a Docker fejlesztői létrehozták a Container Storage Interface-t (CSI) - egy egyszerű, egységes felületet, amely leírja a konténerkezelő rendszer és egy speciális illesztőprogram (CSI Driver) interakcióját, amely egy adott speciális eszközzel működik. tároló rendszer. A tárolórendszerekkel való interakció minden kódja átkerült a Kubernetes magból egy külön rendszerbe.
.
A CSI-illesztőprogram általában két összetevőből áll: Node Plugin és Controller plugin.
A Node Plugin minden csomóponton fut, és felelős a kötetek csatlakoztatásáért és a rajtuk végzett műveletek végrehajtásáért. A Controller beépülő modul együttműködik a tárolórendszerrel: köteteket hoz létre vagy töröl, hozzáférési jogokat rendel stb.
Egyelőre a Kubernetes kernelben maradnak a régi illesztőprogramok, de már nem javasolt a használatuk, és mindenkinek azt tanácsolják, hogy kifejezetten arra a rendszerre telepítse a CSI Drivert, amellyel dolgozni fog.
Az újítás megijesztheti azokat, akik már hozzászoktak az adattárolás beállításához a Storage osztályon keresztül, de valójában semmi szörnyűség nem történt. A programozók számára valójában semmi sem változik – eddig csak a Storage class névvel dolgoztak, és továbbra is így fognak dolgozni. Az adminisztrátorok számára a kormánydiagram telepítése hozzáadásra került, és a beállítások szerkezete megváltozott. Ha korábban a beállításokat közvetlenül a Tárolás osztályba adták meg, most először a Helm diagramban, majd a Tárolás osztályban kell beállítani őket. Ha belegondolunk, semmi rossz nem történt.
Vegyünk egy példát, és nézzük meg, milyen előnyökhöz juthat, ha a Ceph tárolórendszerek CSI-illesztőprogram segítségével történő csatlakoztatására vált.
A Ceph használatakor a CSI beépülő modul több lehetőséget kínál a tárolórendszerekkel való munkavégzéshez, mint a beépített illesztőprogramok.
- Dinamikus lemezkészítés. Az RBD lemezeket általában csak RWO módban használják, de a CSI for Ceph lehetővé teszi, hogy RWX módban is használják őket. A különböző csomópontokon lévő több pod ugyanazt az RDB lemezt csatlakoztathatja a csomópontjaihoz, és párhuzamosan dolgozhat velük. Az igazság kedvéért, nem minden olyan fényes - ez a lemez csak blokkeszközként csatlakoztatható, ami azt jelenti, hogy hozzá kell igazítania az alkalmazást, hogy többszörös hozzáférési módban működjön.
- Pillanatképek készítése. A Kubernetes-fürtben létrehozhat egy jegyzéket a pillanatkép létrehozásának követelményével. A CSI beépülő modul látni fogja, és pillanatképet készít a lemezről. Ez alapján készíthet biztonsági másolatot vagy másolatot a PersistentVolume-ról.
- A lemez méretének növelése a tárolásról és a PersistentVolume-ról a Kubernetes-fürtben.
- Kvóták. A Kubernetesbe épített CephFS-illesztőprogramok nem támogatják a kvótákat, de a legújabb Ceph Nautilus-szal rendelkező friss CSI-bővítmények engedélyezhetik a kvótákat a CephFS-partíciókon.
- Metrikák. A CSI beépülő modul számos mérőszámot biztosít a Prometheus számára arról, hogy mely kötetek vannak csatlakoztatva, milyen kommunikáció zajlik stb.
- Topológia ismerete. Lehetővé teszi a jegyzékekben a fürt földrajzi eloszlásának meghatározását, és elkerülhető, hogy egy Amszterdamban található tárolórendszert csatlakoztasson Londonban futó podokhoz.
A Ceph csatlakoztatása Kubernetes-fürthöz CSI-n keresztül, lásd . Előfizethetsz is , amely október 15-én indul.
A cikk szerzője: Sergey Bondarev, gyakorló építész a Southbridge-nél, okleveles Kubernetes-adminisztrátor, a kubespray egyik fejlesztője.
Egy kis Post Scriptum nem reklámból, hanem haszonból...
PS Szergej Bondarev két intenzív tanfolyamot vezet: frissítve Szeptember 28-30 és haladó október 14-16.
Forrás: will.com