Dat lagring i en Kubernetes-kluster

Datastore för applikationer som körs i en Kubernetes-kluster kan konfigureras på flera sätt. Vissa av dem är redan föråldrade, medan andra har dykt upp nyligen. I denna artikel kommer vi att gå igenom konceptet med tre sätt att ansluta lagringssystem, inklusive den senaste — anslutning via Container Storage Interface.

Sätt 1. Angivande av PV i podens manifest

Ett typiskt manifest som beskriver en pod i Kubernetes-klustret:

Delarna av manifestet som beskriver vilken volym som ansluts och var, markeras med färg.

I avsnittet volumeMounts anger monteringspunkterna (mountPath) — i vilken mapp inom containern den persistenta volymen kommer att monteras, samt volymens namn.

I avsnittet x anger alla volymer som används i podden. Anger namnet på varje volym samt typ (i vårt fall: awsElasticBlockStore) och anslutningsparametrar. Vilka specifika parametrar som anges i manifestet beror på volymtypen.

Samma volym kan monteras samtidigt i flera containrar i podden. På så sätt kan olika processer av applikationen få tillgång till samma data.

Denna anslutningsmetod uppfanns i början, när Kubernetes just började utvecklas, och idag anses metoden vara föråldrad.

Det finns flera problem med att använda det:

1. alla volymer måste skapas manuellt, Kubernetes kan inte skapa något åt oss;
2. åtkomlighetsparametrarna för varje volym är unika och måste anges i manifesten för alla pods som använder volymen;
3. för att byta lagringssystem (till exempel flytta från AWS till Google Cloud) måste inställningarna och typen av anslutna volymer ändras i alla manifest.

Allt detta är mycket opraktiskt, så i verkligheten används denna metod endast för att ansluta vissa speciella typer av volymer: configMap, secret, emptyDir, hostPath:

• configMap och secret — tjänstefunktioner som gör det möjligt att skapa en volym i containern med filer från Kubernetes-manifesten.

• emptyDir — en temporär volym som endast skapas under podens livstid. Den är praktisk att använda för testning eller för att lagra temporära data. När podden tas bort, tas även emptyDir-volymen bort och all data går förlorad.

• hostPath - gör det möjligt att montera valfri katalog från den lokala serverdisk där applikationen körs inuti containern, inklusive /etc/kubernetes. Detta är en osäker funktion, vilket gör att säkerhetspolicyer vanligtvis förbjuder användning av den här typen av volymer. Annars kan en angripares applikation montera katalogen HTC Kubernetes inuti sin container och stjäla alla klustercertifikat. Som regel tillåts hostPath-volymer endast för systemapplikationer som körs i kube-system-namnområdet.

Lagringssystem som Kubernetes arbetar med direkt ur boxen anges i dokumentationen.

Metod 2. Anslutning till poddar SC/PVC/PV

Ett alternativt sätt att ansluta är konceptet Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class lagrar anslutningsparametrar till lagringssystemet.

PersistentVolumeClaim beskriver kraven för den volym som applikationen behöver.
PersistentVolume lagrar åtkomstparametrar och status för volymen.

Huvudidén är att i podens manifest ange en volym av typen PersistentVolumeClaim och ange namnet på denna entitet i parametern claimName.

I manifestet för PersistentVolumeClaim beskriver man kraven på de data som applikationen behöver. Bland annat:

• diskstorlek;
• åtkomstmetod: ReadWriteOnce eller ReadWriteMany;
• länk till Storage class - i vilket lagringssystem vi vill skapa volymen.

I manifestet för Storage class lagras typen och anslutningsparametrarna till lagringssystemet. Dessa är nödvändiga för kubelet att montera volymen på sin nod.

I manifesten för PersistentVolume anges Storage class och åtkomstparametrar för en specifik volym (volymens ID, sökväg, etc.).

När en PVC skapas, kontrollerar Kubernetes vilken storlek och vilken Storage class som behövs och väljer en ledig PersistentVolume.

Om det inte finns några sådana PV tillgängliga kan Kubernetes starta ett specialprogram - Provisioner (dess namn anges i Storage class). Detta program ansluter till lagringssystemet, skapar en volym av rätt storlek, får ett ID och skapar en PersistentVolumes manifest i Kubernetes-klustret som kopplas till PersistentVolumeClaim.

Alla dessa abstraktioner gör det möjligt att eliminera information om vilket lagringssystem applikationen arbetar med från nivån av applikationsmanifestet till nivå av administration.

Alla anslutningsparametrar till lagringssystemet finns i Storage class, som administratörer av klustret ansvarar för. För att flytta från AWS till Google Cloud behöver man bara ändra namnet på Storage class i PVC-filerna. Persistance Volume för datalagring kommer automatiskt att skapas i klustret med hjälp av programmet Provisioner.

Metod 3. Container Storage Interface

All kod som interagerar med olika lagringssystem är en del av Kubernetes-kärnan. Utfärdande av buggfixar eller ny funktionalitet är kopplat till nya versioner, och koden måste ändras för alla stödja versioner av Kubernetes. 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 arbetar med ett specifikt lagringssystem. All kod för interaktion med lagringssystemet flyttades från Kubernetes-kärnan till ett separat system.

Dokumentation för Container Storage Interface.

Som regel 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 för operationer på dem. Controller plugin interagerar med lagringssystemet: skapar eller tar bort volymer, tilldelar åtkomsträttigheter, etc.

Även om gamla drivrutiner fortfarande finns i Kubernetes-kärnan rekommenderar man inte att använda dem längre, och alla uppmanas att installera CSI Driver specifikt för det system man ska arbeta med.

Nyheten kan skrämma dem som redan är vana vid att konfigurera datalagring via Storage class, men egentligen har inget hemskt hänt. För programmerarna förändras inget; de fortsätter att arbeta med namnet Storage class. För administratörerna har installationen av helm chart tillkommit och strukturen för inställningarna har förändrats. Tidigare angavs inställningarna direkt i Storage class, men nu måste de först definieras i helm chart och sedan i Storage class. Om man undersöker saken har inget hemskt inträffat.

Låt oss med ett exempel titta på vilka fördelar man kan få genom att ansluta lagringssystemet Ceph med hjälp av CSI-drivrutinen.

Vid arbete med Ceph ger CSI-plugin fler möjligheter för att arbeta med lagringssystemet än inbyggda drivrutiner.

1. Dynamisk skapelse av diskar. Normalt används RBD-diskar endast i RWO-läge, medan CSI för Ceph gör det möjligt att använda dem i RWX-läge. Flera poddar på olika noder kan montera samma RBD-disk till sina noder och arbeta med den parallellt. För att vara rättvis, är inte allt så rosenskimrande — den här disken kan endast anslutas som en blockenhet, vilket innebär att applikationen måste anpassas för att fungera med den i läge för multipel åtkomst.
2. Skapa ögonblicksbilder. I Kubernetes-klustret kan man skapa ett manifest som begär att en ögonblicksbild ska skapas. CSI-pluginet ser det och skapar en ögonblicksbild från disken. Utifrån det kan man göra antingen en säkerhetskopia eller en kopia av PersistentVolume.
3. Öka storleken på disken på lagringssystemet och PersistentVolume i Kubernetes-klustret.
4. Kvoter. Inbyggda Kubernetes-drivrutiner för CephFS stöder inte kvoter, medan nya CSI-plugins med den senaste Ceph Nautilus kan aktivera kvoter på CephFS-partitioner.
5. Metrik. CSI-pluginet kan tillhandahålla en mängd metrik i Prometheus om vilka volymer som är anslutna, vilka interaktioner som sker osv.
6. Topologiskt medveten. Möjliggör att ange i manifest att klustret är geografiskt distribuerat och undvika anslutning till pods som körs i London med lagringssystem som är placerade i Amsterdam.

För att ansluta Ceph till Kubernetes-klustret via CSI, se den praktiska delen av föreläsningen i kvällsskolan Slyrme. Man kan också prenumerera på videokursen Ceph, som startar den 15 oktober.

Författare till artikeln: Sergey Bondarev, verksam arkitekt på Southbridge, Certified Kubernetes Administrator, en av utvecklarna av kubespray.

Lite Post Scriptum inte för reklam, utan för nytta...

P.S. Sergey Bondarev håller två intensiver: uppdaterad Kubernetes Grund 28-30 september och avancerad Kubernetes Mega 14–16 oktober.

Källa: habr.com