Lagring av data i Kubernetes-klyngen

Det finnes flere måter å konfigurere datalagring for applikasjoner som kjører i Kubernetes-klyngen. Noen av dem er utdaterte, mens andre har oppstått nylig. I artikkelen vil vi se på konseptet med tre alternativer for tilkobling av lagringssystemer, inkludert den nyeste — tilkoblingen via Container Storage Interface.

Metode 1. Angi PV i pod-manifestet

Et typisk manifest som beskriver en pod i Kubernetes-klyngen:

Deler av manifestet er uthevet med farge for å vise hvilken volum som kobles til og hvor.

I delen volumeMounts angir man monteringspunkter (mountPath) — i hvilken katalog inne i containeren det vedvarende volumet skal monteres, samt navnet på volumet.

I delen x anger alle volumene som brukes i pod-en. Man angir navnet til hvert volum, samt typen (i vårt tilfelle: awsElasticBlockStore) og tilkoblingsparametrene. Hvilke parametere som spesifiseres i manifestet, avhenger av typen volum.

Det samme volumet kan monteres samtidig i flere containere i pod-en. Dermed kan forskjellige prosesser av applikasjonen få tilgang til de samme dataene.

Denne metoden for tilkobling ble utviklet i begynnelsen, da Kubernetes nettopp ble til, og er i dag utdatert.

Ved bruk av denne metoden oppstår det flere problemer:

1. alle volumene må opprettes manuelt; Kubernetes kan ikke opprette noe for oss;
2. tilgangsparametrene for hvert volum er unike, og de må spesifiseres i manifestene til alle pod-er som bruker volumet;
3. for å endre lagringssystemet (for eksempel å flytte fra AWS til Google Cloud), må man endre innstillingene og typen av tilkoblede volum i alle manifestene.

Alt dette er veldig upraktisk, så i virkeligheten brukes denne metoden kun for tilkobling av noen spesielle typer volumer: configMap, secret, emptyDir, hostPath:

• configMap og secret — systemvolumer, lar deg opprette et volum i containeren med filer fra Kubernetes-manifester.

• emptyDir — midlertidig volum, opprettes kun så lenge pod-en lever. Praktisk å bruke for testing eller lagring av midlertidige data. Når pod-en slettes, slettes også emptyDir-volumet, og alle data går tapt.

• hostPath — lar larer å montere inn i containeren med applikasjonen enhver katalog fra den lokale disken til serveren der applikasjonen kjører, inkludert /etc/kubernetes. Dette er en usikker funksjon, så sikkerhetspolicyer forbyr vanligvis bruken av volumer av denne typen. Ellers kan en angripers applikasjon montere katalogen HTC Kubernetes inn i sin egen container og stjele alle sertifikatene i klyngen. Som regel tillates hostPath-volumer kun for systemapplikasjoner som kjører i kube-system-namespacet.

Lagringssystemer som Kubernetes jobber med rett ut av boksen er beskrevet i dokumentasjonen.

Metode 2. Tilkobling til podene SC/PVC/PV

Et alternativ for tilkobling er konseptet Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class lagrer tilkoblingsparametere til lagringssystemet.

PersistentVolumeClaim beskriver kravene til volumet som applikasjonen trenger.
PersistentVolume lagrer tilgangsparametere og status for volumet.

Kjernen i ideen: i manifestet til poden angir man volumet av typen PersistentVolumeClaim og spesifiserer navnet på denne entiteten i parameteren claimName.

I manifestet PersistentVolumeClaim beskriver man krav til datavolumet som er nødvendig for applikasjonen. Blant annet:

• størrelsen på disken;
• tilgangstype: ReadWriteOnce eller ReadWriteMany;
• lenke til Storage class — i hvilket lagringssystem vi ønsker å opprette volumet.

I manifestet Storage class lagres type og tilkoblingsparametere til lagringssystemet. Dette er nødvendig for kubelet for å montere volumet til sin node.

I manifestene til PersistentVolume angis Storage class og tilgangsparametere til det spesifikke volumet (volum-ID, bane, osv.).

Når en PVC opprettes, vurderer Kubernetes hvilket volum som er nødvendig størrelse og fra hvilken Storage class, og finner en tilgjengelig PersistentVolume.

Hvis det ikke finnes slike PV-er tilgjengelig, kan Kubernetes starte et spesialprogram — Provisioner (navnet på dette angis i Storage class). Dette programmet kobler til SAN, oppretter volumet i ønsket størrelse, får en identifikator og oppretter et manifest for PersistentVolume i Kubernetes-klyngen, som knyttes til PersistentVolumeClaim.

Alle disse abstraksjonene gjør det mulig å skjule informasjon om hvilket SAN applikasjonen jobber med, fra applikasjonsmanifestnivået til administrasjonsnivået.

Alle tilkoblingsparametere til lagringssystemet finnes i Storage class, som administratører av klyngen har ansvar for. Alt som må gjøres når man flytter fra AWS til Google Cloud, er å endre navnet på Storage class i PVC i applikasjonsmanifestene. Persistance Volume for lagring av data vil bli opprettet automatisk i klyngen ved hjelp av Provisioner-programmet.

Metode 3. Container Storage Interface

All kode som interagerer med ulike lagringssystemer er en del av kjernen i Kubernetes. Utgivelse av feilrettinger eller ny funksjonalitet er knyttet til nye utgivelser, og koden må endres for alle støttede versjoner av Kubernetes. Dette er vanskelig å vedlikeholde og legge til nye funksjoner.

For å løse problemet, utviklet utviklerne fra Cloud Foundry, Kubernetes, Mesos og Docker Container Storage Interface (CSI) — et enkelt, ensartet grensesnitt som beskriver interaksjonen mellom containeradministrasjonssystemet og en spesialisert driver (CSI Driver) som arbeider med spesifikke lagringssystemer. All koden for interaksjon med lagringssystemet ble flyttet ut av kjernen i Kubernetes til et eget system.

Dokumentasjon for Container Storage Interface.

Som regel består CSI Driver av to komponenter: Node Plugin og Controller Plugin.

Node Plugin kjøres på hver node og er ansvarlig for montering av volumer og operasjoner på dem. Controller Plugin interagerer med lagringssystemet: oppretter eller sletter volumer, tildeler tilgangsrettigheter osv.

Så lenge gamle drivere er igjen i kjernen av Kubernetes, er det ikke lenger anbefalt å bruke dem, og alle anbefales å installere CSI Driver spesielt for det systemet man skal jobbe med.

Innovasjonen kan skremme de som allerede er vant til å konfigurere datalagring via Storage class, men egentlig har ingenting dramatisk skjedd. For programmererne endres ingenting — de vil fortsatt jobbe med navnet Storage class. For administratorer har installasjon av helm chart blitt lagt til, og strukturen av innstillingene har endret seg. Hvis tidligere innstillingene ble skrevet direkte i Storage class, må de nå defineres i helm chart først, og deretter i Storage class. Hvis man finner ut av det, har ingenting dramatisk skjedd.

La oss se på et eksempel for å vurdere hvilke fordeler man kan oppnå ved å gå over til tilkobling av lagringssystemet Ceph ved hjelp av CSI-driveren.

Når man arbeider med Ceph, gir CSI-pluginen flere muligheter for å jobbe med lagringssystemet enn de innebygde driverne.

1. Dynamisk opprettelse av disker. Vanligvis brukes RBD-disker bare i RWO-modus, men CSI for Ceph lar deg bruke dem i RWX-modus. Flere pod-er på forskjellige noder kan montere den samme RDB-disken og jobbe med dem parallelt. For rettferdighetens skyld, alt er ikke så strålende — denne disken kan bare kobles til som et blokkapparat, så du må tilpasse applikasjonen for å fungere med den i flere tilkoblingsmoduser.
2. Opprettelse av snapshots. I Kubernetes-klyngen kan du lage et manifest som ber om å opprette et snapshot. CSI-plugin vil se det og ta et snapshot av disken. Basert på det kan du lage enten en backup eller en kopi av PersistentVolume.
3. Øke størrelsen på disken på SAN og PersistentVolume i Kubernetes-klyngen.
4. Kvoter. Innebygde Kubernetes-drivere for CephFS støtter ikke kvoter, men nye CSI-plugins med den nyeste Ceph Nautilus versjonen kan aktivere kvoter på CephFS-partisjoner.
5. Metrikker. CSI-plugin kan returnere mange metrikker til Prometheus om hvilke volum som er tilkoblet, hvilke interaksjoner som foregår, osv.
6. Topology aware. Lar deg angi i manifestene hvordan den geografiske distribusjonen av klyngen er, og unngå tilkoblinger til pod-er som kjører i London fra lagringssystemet plassert i Amsterdam.

Hvordan koble Ceph til Kubernetes-klyngen via CSI, se i den praktiske delen av kvelden Skole Slyrm. Du kan også melde deg på videokurs i Ceph, som starter 15. oktober.

Artikkelforfatter: Sergey Bondarev, praktiserende arkitekt i Southbridge, Certified Kubernetes Administrator, en av utviklerne av kubespray.

Litt Post Scriptum ikke reklame for, men for nytte...

P.S. Sergey Bondarev holder to intensive kurs: den oppdaterte Kubernetes Grunnkurs 28-30 september og avansert Kubernetes Mega 14–16 oktober.

Kilde: habr.com