Der er flere måder at konfigurere datalagring for applikationer, der kører i en Kubernetes-klynge. Nogle af dem er allerede forældede, andre er dukket op for ganske nylig. I denne artikel vil vi se på konceptet med tre muligheder for tilslutning af et lagringssystem, herunder den nyeste - tilslutning via Container Storage Interface.
Metode 1: Angivelse af PV i pod-manifestet
Et typisk manifest, der beskriver en pod i en Kubernetes-klynge:
De dele af manifestet, der beskriver hvilket volumen der er tilsluttet, og hvor, er fremhævet med farve.
I afsnit volumemounts Angiv monteringspunkterne (mountPath) - i hvilken mappe i containeren den persistente diskenhed skal monteres, samt navnet på diskenheden.
I afsnit x viser alle volumener, der bruges i poden. Angiv navnet på hvert volumen, samt typen (i vores tilfælde: awsElasticBlockStore) og forbindelsesparametre. De nøjagtige parametre, der er angivet i manifestet, afhænger af volumentypen.
Den samme volumen kan monteres på flere pod-containere på samme tid. På denne måde kan forskellige applikationsprocesser tilgå de samme data.
Denne forbindelsesmetode blev opfundet helt i begyndelsen, da Kubernetes lige var ved at opstå, og i dag er metoden forældet.
Der er flere problemer, der opstår, når man bruger det:
- alle volumener skal oprettes manuelt, Kubernetes kan ikke oprette noget for os;
- Adgangsparametre for hvert volumen er unikke og skal angives i manifesterne for alle pods, der bruger volumen;
- For at ændre lagringssystemet (f.eks. skifte fra AWS til Google Cloud), skal du ændre indstillingerne og typen af tilsluttede volumener i alle manifester.
Alt dette er meget ubelejligt, så i virkeligheden bruges denne metode kun til at forbinde nogle specielle typer volumener: configMap, secret, emptyDir, hostPath:
configMap og secret er servicevolumener, der giver dig mulighed for at oprette en volumen i en container med filer fra Kubernetes-manifester.
emptyDir - midlertidig volumen, oprettet kun i podens levetid. Praktisk at bruge til test eller lagring af midlertidige data. Når en pod slettes, slettes emptyDir-volumenet også, og alle data går tabt.
hostPath — giver dig mulighed for at montere en hvilken som helst mappe på den lokale disk på den server, hvor applikationen kører, inklusive /etc/kubernetes, inde i containeren med applikationen. Dette er en usikker funktion, så sikkerhedspolitikker forbyder typisk brugen af denne type enheder. Ellers vil en angribers applikation være i stand til at montere HTC Kubernetes-mappen i dens container og stjæle alle klyngecertifikater. Typisk må hostPath-volumener kun bruges af systemapplikationer, der kører i kube-system-navneområdet.
er givet i dokumentationen.
Metode 2. Tilslutning til SC/PV/PV-forsyninger
En alternativ måde at oprette forbindelse på er konceptet med Storage-klassen, PersistentVolumeClaim, PersistentVolume.
Opbevaringsklasse lagrer forbindelsesparametre i datalagringssystemet.
Vedvarende Volumen Krav beskriver kravene til, hvad applikationen har brug for.
Vedvarende volumen gemmer adgangsparametre og volumenstatus.
Ideen er at angive et volumen af typen PersistentVolumeClaim i pod-manifestet og angive navnet på denne enhed i parameteren claimName.
PersistentVolumeClaim-manifestet beskriver kravene til den datamængde, som applikationen kræver. Inklusive:
- diskstørrelse;
- adgangsmetode: ReadWriteOnce eller ReadWriteMany;
- Reference til lagerklasse - i hvilket lagersystem vi vil oprette volumen.
Storage-klassemanifestet lagrer typen og parametrene for forbindelsen til datalagringssystemet. De er nødvendige for at kubelet'en kan montere volumen på dens node.
PersistentVolume-manifester angiver lagringsklassen og adgangsparametrene for en specifik diskenhed (diskenheds-ID, sti osv.).
Når Kubernetes opretter en PVC, ser den på den nødvendige volumenstørrelse og Storage-klasse og vælger en ledig PersistentVolume.
Hvis sådanne PV'er ikke er tilgængelige, kan Kubernetes starte et særligt program - Provisioner (dets navn er angivet i Storage-klassen). Dette program opretter forbindelse til lagersystemet, opretter en diskenhed af den nødvendige størrelse, henter et id og opretter et PersistentVolume-manifest i Kubernetes-klyngen, som er knyttet til PersistentVolumeClaim.
Alt dette sæt af abstraktioner giver os mulighed for at fjerne information om hvilket lagringssystem applikationen arbejder med, fra applikationens manifestniveau til administrationsniveauet.
Alle parametre for forbindelse til datalagringssystemet er placeret i Storage-klassen, som er klyngeadministratorernes ansvar. Alt du skal gøre, når du skifter fra AWS til Google Cloud, er at ændre navnet på Storage-klassen til PVC i dine applikationsmanifester. Persistensvolumener til lagring af data oprettes automatisk i klyngen ved hjælp af Provisioner-programmet.
Metode 3. Grænseflade til containeropbevaring
Al kode, der interagerer med forskellige lagringssystemer, er en del af Kubernetes-kernen. Udgivelsen af fejlrettelser eller ny funktionalitet er knyttet til nye udgivelser, og koden skal ændres for alle understøttede versioner af Kubernetes. Alt dette er vanskeligt at vedligeholde og tilføje ny funktionalitet.
For at løse problemet skabte udviklere fra Cloud Foundry, Kubernetes, Mesos og Docker Container Storage Interface (CSI) - en simpel, samlet grænseflade, der beskriver interaktionen mellem containerstyringssystemet og en speciel driver (CSI Driver), der fungerer med et specifikt storagesystem. Al kode til interaktion med lagringssystemet blev flyttet fra Kubernetes-kernen til et separat system.
.
Typisk består en CSI-driver af to komponenter: et Node-plugin og et Controller-plugin.
Node-pluginet kører på hver node og er ansvarlig for at montere volumener og udføre handlinger på dem. Controller-plugin'et interagerer med lagringssystemet: opretter eller sletter volumener, tildeler adgangsrettigheder osv.
Selvom de gamle drivere forbliver i Kubernetes-kernen, anbefales de ikke længere til brug, og alle rådes til at installere CSI-driveren specifikt til det system, de skal arbejde med.
Innovationen kan måske skræmme dem, der allerede er vant til at opsætte datalagring via Storage-klassen, men faktisk er der ikke sket noget forfærdeligt. For programmører ændrer der sig helt sikkert ingenting - de vil fortsat kun arbejde med Storage-klassenavnet. For administratorer er installationen af Helm Chart blevet tilføjet, og indstillingsstrukturen er ændret. Hvis indstillingerne tidligere blev indtastet direkte i Storage-klassen, skal de nu først indstilles i rordiagrammet og derefter i Storage-klassen. Hvis man ser nærmere på det, er der ikke sket noget forfærdeligt.
Lad os bruge et eksempel til at overveje, hvilke fordele der kan opnås ved at skifte til at forbinde Ceph-lagringssystemer ved hjælp af CSI-driveren.
Når man arbejder med Ceph, giver CSI-plugin'et flere muligheder for at arbejde med lagringssystemer end de indbyggede drivere.
- Dynamisk oprettelse af diske. Typisk bruges RBD-diske kun i RWO-tilstand, men CSI til Ceph tillader dem at blive brugt i RWX-tilstand. Flere pods på forskellige noder kan montere den samme RDB-disk på deres noder og arbejde parallelt med dem. For at være fair, er ikke alt så rosenrødt - denne disk kan kun tilsluttes som en blokenhed, hvilket betyder, at du bliver nødt til at tilpasse applikationen til at fungere med den i multiadgangstilstand.
- Oprettelse af snapshots. I en Kubernetes-klynge kan du oprette et manifest, der anmoder om, at der oprettes et snapshot. CSI-pluginnet vil se det og lave et snapshot fra disken. Baseret på det kan du enten lave en sikkerhedskopi eller en kopi af PersistentVolume.
- Øg diskstørrelsen på lager og PersistentVolume i Kubernetes-klyngen.
- Kvoter. CephFS-driverne, der er indbygget i Kubernetes, understøtter ikke kvoter, men de nyeste CSI-plugins med den nyeste Ceph Nautilus kan aktivere kvoter på CephFS-partitioner.
- Målinger. CSI-pluginnet kan give Prometheus en række målinger om, hvilke volumener der er forbundet, hvilke interaktioner der foregår osv.
- Topologibevidst. Giver dig mulighed for at angive i manifester, hvordan klyngen er geografisk fordelt, og undgå at oprette forbindelse til pods, der kører i London, fra et lagersystem placeret i Amsterdam.
For at forbinde Ceph til en Kubernetes-klynge via CSI, se . Du kan også abonnere på , som lanceres den 15. oktober.
Artiklens forfatter: Sergey Bondarev, praktiserende arkitekt hos Southbridge, certificeret Kubernetes-administrator, en af udviklerne af kubespray.
Lidt Post Scriptum, ikke for reklamens skyld, men for gavnens skyld...
P.S. Sergey Bondarev afholder to intensive kurser: opdateret 28.-30. september og frem 14.–16. oktober.
Kilde: www.habr.com
