Det finns flera sätt att konfigurera datalagring för applikationer som körs på ett Kubernetes-kluster. Vissa av dem är redan föråldrade, andra dök upp ganska nyligen. I den här artikeln kommer vi att titta på konceptet med tre alternativ för att ansluta lagringssystem, inklusive det senaste - att ansluta via Container Storage Interface.
Metod 1: Ange PV i podmanifestet
Ett typiskt manifest som beskriver en pod i ett Kubernetes-kluster:
De delar av manifestet som beskriver vilken volym som är kopplad och var är markerade i färg.
I avsnitt volymfästen ange monteringspunkterna (mountPath) - i vilken katalog inuti behållaren den permanenta volymen kommer att monteras, samt namnet på volymen.
I avsnitt x listar alla volymer som används i podden. Ange namnet på varje volym, samt typ (i vårt fall: awsElasticBlockStore) och anslutningsparametrar. Vilka parametrar som anges i manifestet beror på volymtypen.
Samma volym kan monteras samtidigt i flera kapselbehållare. På så sätt kan olika ansökningsprocesser komma åt samma data.
Denna anslutningsmetod uppfanns redan i början, när Kubernetes bara var i sin linda, och idag är metoden förlegad.
Det finns flera problem när du använder det:
- alla volymer måste skapas manuellt, Kubernetes kan inte skapa något åt oss;
- åtkomstparametrar för varje volym är unika och de måste anges i manifesten för alla poddar som använder volymen;
- för att ändra lagringssystem (till exempel flytta från AWS till Google Cloud) måste du ändra inställningarna och typen av monterade volymer i alla manifest.
Allt detta är väldigt obekvämt, så i verkligheten används den här metoden för att bara ansluta några speciella typer av volymer: configMap, secret, emptyDir, hostPath:
-
configMap och secret är tjänstevolymer som låter dig skapa en volym med filer från Kubernetes-manifest i behållaren.
-
emptyDir är en tillfällig volym, skapad endast för poddens livstid. Bekväm att använda för att testa eller lagra temporär data. När en pod raderas raderas den tommaDir-volymen också och all data går förlorad.
-
hostPath - låter dig montera vilken katalog som helst på den lokala disken på servern där applikationen körs inuti behållaren med applikationen, inklusive /etc/kubernetes. Detta är en osäker funktion, så säkerhetspolicyer förbjuder vanligtvis användningen av volymer av denna typ. Annars kommer en angripares applikation att kunna montera HTC Kubernetes-katalogen inuti sin behållare och stjäla alla klustercertifikat. Vanligtvis tillåts hostPath-volymer endast användas av systemapplikationer som körs i kube-systems namnutrymme.
finns i dokumentationen.
Metod 2. Anslutning till SC/PVC/PV-härdar
En alternativ anslutningsmetod är konceptet Storage class, PersistentVolumeClaim, PersistentVolume.
Förvaringsklass lagrar anslutningsparametrar till datalagringssystemet.
PersistentVolumeClaim beskriver kraven på vad ansökan behöver.
Beständig volym lagrar åtkomstparametrar och volymstatus.
Kärnan i idén: i podmanifestet anger de en volym av typen PersistentVolumeClaim och anger namnet på denna enhet i parametern claimName.
PersistentVolumeClaim-manifestet beskriver kraven på mängden data som applikationen kräver. Inklusive:
- diskstorlek;
- åtkomstmetod: ReadWriteOnce eller ReadWriteMany;
- länk till Lagringsklass - i vilket datalagringssystem vi vill skapa volymen.
Klassmanifestet Storage lagrar typen och parametrarna för anslutningen till lagringssystemet. Kubelet behöver dem för att montera volymen på sin nod.
PersistentVolume-manifest anger lagringsklassen och åtkomstparametrar för en specifik volym (volym-ID, sökväg, etc.).
När man skapar en PVC tittar Kubernetes på vilken storleksvolym och vilken lagringsklass som krävs, och väljer en gratis PersistentVolume.
Om sådana PV inte är tillgängliga kan Kubernetes starta ett speciellt program - Provisioner (dess namn anges i klassen Storage). Det här programmet ansluter till lagringssystemet, skapar en volym av önskad storlek, tar emot en identifierare och skapar ett PersistentVolume-manifest i Kubernetes-klustret, som är associerat med PersistentVolumeClaim.
Alla denna mängd abstraktioner låter dig ta bort information om vilket lagringssystem applikationen arbetar med från applikationsmanifestnivån till administrationsnivån.
Alla parametrar för att ansluta till datalagringssystemet finns i klassen Storage, som klusteradministratörer ansvarar för. Allt du behöver göra när du flyttar från AWS till Google Cloud är att ändra namnet på lagringsklassen till PVC i applikationsmanifesterna. Persistance Volym för datalagring kommer att skapas i klustret automatiskt med hjälp av Provisioner-programmet.
Metod 3. Container Storage Interface
All kod som interagerar med olika lagringssystem är en del av Kubernetes kärna. Utgivningen av buggfixar eller ny funktionalitet är knuten till nya utgåvor; koden måste ändras för alla versioner av Kubernetes som stöds. Allt detta är svårt att underhålla och lägga till ny funktionalitet.
För att lösa problemet skapade utvecklare från Cloud Foundry, Kubernetes, Mesos och Docker Container Storage Interface (CSI) - ett enkelt enhetligt gränssnitt som beskriver interaktionen mellan containerhanteringssystemet och en speciell drivrutin (CSI Driver) som fungerar med en specifik lagringssystem. All kod för interaktion med lagringssystem flyttades från Kubernetes kärna till ett separat system.
.
Vanligtvis består CSI Driver av två komponenter: Node Plugin och Controller plugin.
Node Plugin körs på varje nod och ansvarar för att montera volymer och utföra operationer på dem. Controller-pluginen interagerar med lagringssystemet: skapar eller tar bort volymer, tilldelar åtkomsträttigheter, etc.
För närvarande finns de gamla drivrutinerna kvar i Kubernetes-kärnan, men de rekommenderas inte längre att användas och alla rekommenderas att installera CSI-drivrutinen specifikt för det system som de kommer att arbeta med.
Innovationen kan skrämma dem som redan är vana vid att sätta upp datalagring genom klassen Storage, men i själva verket har inget hemskt hänt. För programmerare förändras egentligen ingenting - de har bara arbetat med namnet Storage class, och kommer att fortsätta att göra det. För administratörer har styrdiagraminstallationen lagts till och strukturen på inställningarna har ändrats. Om inställningarna tidigare matades in direkt i klassen Storage, måste de nu först ställas in i styrdiagrammet och sedan i klassen Storage. Om du tittar på det hände inget dåligt.
Låt oss ta ett exempel för att titta på fördelarna du kan få genom att byta till att ansluta Ceph-lagringssystem med CSI-drivrutinen.
När du arbetar med Ceph ger CSI-pluginen fler alternativ för att arbeta med lagringssystem än inbyggda drivrutiner.
- Skapa dynamisk disk. Vanligtvis används RBD-skivor endast i RWO-läge, men CSI för Ceph tillåter dem att användas i RWX-läge. Flera pods på olika noder kan montera samma RDB-disk på sina noder och arbeta med dem parallellt. För att vara rättvis är inte allt så ljust - den här disken kan bara anslutas som en blockenhet, vilket innebär att du måste anpassa applikationen för att fungera med den i multipelåtkomstläge.
- Skapa ögonblicksbilder. I ett Kubernetes-kluster kan du skapa ett manifest med kravet att skapa en ögonblicksbild. CSI-pluginen kommer att se det och ta en ögonblicksbild från disken. Baserat på det kan du göra antingen en säkerhetskopia eller en kopia av PersistentVolume.
- Ökar diskstorlek på lagring och PersistentVolume i ett Kubernetes-kluster.
- Kvoter. CephFS-drivrutinerna som är inbyggda i Kubernetes stöder inte kvoter, men färska CSI-plugins med den senaste Ceph Nautilus kan aktivera kvoter på CephFS-partitioner.
- Metrik. CSI-pluginet kan ge Prometheus en mängd olika mätvärden om vilka volymer som är anslutna, vilken kommunikation som äger rum, etc.
- Topologi medveten. Låter dig specificera i manifest hur klustret är geografiskt fördelat och undvika att ansluta ett lagringssystem i Amsterdam till pods som körs i London.
Hur man ansluter Ceph till ett Kubernetes-kluster via CSI, se . Du kan också prenumerera på , som lanseras den 15 oktober.
Författare till artikeln: Sergey Bondarev, praktiserande arkitekt på Southbridge, Certified Kubernetes Administrator, en av utvecklarna av kubespray.
Lite Post Scriptum inte för reklam, utan för nytta...
PS Sergey Bondarev leder två intensiva kurser: uppdaterad 28-30 september och avancerad 14–16 oktober.
Källa: will.com