Lagre data i en Kubernetes-klynge

Det er flere måter å konfigurere datalagring for applikasjoner som kjører på en Kubernetes-klynge. Noen av dem er allerede utdaterte, andre dukket opp ganske nylig. I denne artikkelen vil vi se på konseptet med tre alternativer for tilkobling av lagringssystemer, inkludert det nyeste - tilkobling via Container Storage Interface.

Metode 1: Spesifiser PV i pod-manifestet

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

Delene av manifestet som beskriver hvilket volum som er koblet til og hvor er uthevet i farger.

I avsnitt volumMonter angi monteringspunktene (mountPath) - i hvilken katalog inne i beholderen det permanente volumet skal monteres, samt navnet på volumet.

I avsnitt x viser alle volumer som brukes i poden. Spesifiser navnet på hvert volum, samt type (i vårt tilfelle: awsElasticBlockStore) og tilkoblingsparametere. Hvilke parametere som er oppført i manifestet avhenger av volumtypen.

Det samme volumet kan monteres samtidig i flere pod-beholdere. På denne måten kan ulike søknadsprosesser få tilgang til de samme dataene.

Denne tilkoblingsmetoden ble oppfunnet helt i begynnelsen, da Kubernetes bare var i sin spede begynnelse, og i dag er metoden utdatert.

Det er flere problemer ved bruk:

1. alle volumer må opprettes manuelt, Kubernetes kan ikke lage noe for oss;
2. tilgangsparametere for hvert volum er unike, og de må spesifiseres i manifestene til alle pods som bruker volumet;
3. for å endre lagringssystemet (for eksempel flytte fra AWS til Google Cloud), må du endre innstillingene og typen monterte volumer i alle manifester.

Alt dette er veldig upraktisk, så i virkeligheten brukes denne metoden til å koble bare noen spesielle typer volumer: configMap, secret, emptyDir, hostPath:

• configMap og secret er tjenestevolumer som lar deg lage et volum med filer fra Kubernetes-manifester i beholderen.

• emptyDir er et midlertidig volum, opprettet kun for podens levetid. Praktisk å bruke for testing eller lagring av midlertidige data. Når en pod slettes, slettes også emptyDir-volumet og all data går tapt.

• hostPath - lar deg montere en hvilken som helst katalog på den lokale disken til serveren som applikasjonen kjører på inne i beholderen med applikasjonen, inkludert /etc/kubernetes. Dette er en usikker funksjon, så sikkerhetspolicyer forbyr vanligvis bruk av volumer av denne typen. Ellers vil en angripers applikasjon kunne montere HTC Kubernetes-katalogen inne i beholderen og stjele alle klyngesertifikatene. Vanligvis er hostPath-volumer bare tillatt å brukes av systemapplikasjoner som kjører i kube-systemets navneområde.

Lagringssystemer som Kubernetes jobber med ut av esken er gitt i dokumentasjonen.

Metode 2. Tilkobling til SC/PVC/PV-ildsteder

En alternativ tilkoblingsmetode er konseptet Storage class, PersistentVolumeClaim, PersistentVolume.

Oppbevaringsklasse lagrer tilkoblingsparametere til datalagringssystemet.

Vedvarende volum Krev beskriver kravene til hva søknaden trenger.
Vedvarende volum lagrer tilgangsparametere og volumstatus.

Essensen av ideen: i pod-manifestet angir de et volum av typen PersistentVolumeClaim og angir navnet på denne enheten i parameteren claimName.

PersistentVolumeClaim-manifestet beskriver kravene til mengden data som applikasjonen krever. Gjelder også:

• diskstørrelse;
• tilgangsmetode: ReadWriteOnce eller ReadWriteMany;
• lenke til Lagringsklasse - i hvilket datalagringssystem vi ønsker å lage volumet.

Storage-klassemanifestet lagrer typen og parameterne for tilkoblingen til lagringssystemet. Kubeletten trenger dem for å montere volumet på noden sin.

PersistentVolume-manifester indikerer lagringsklassen og tilgangsparametere for et spesifikt volum (volum-ID, bane osv.).

Når du lager en PVC, ser Kubernetes på hvilket størrelsesvolum og hvilken lagringsklasse som kreves, og velger et gratis PersistentVolume.

Hvis slike PV-er ikke er tilgjengelige, kan Kubernetes starte et spesielt program - Provisioner (navnet er angitt i Lagringsklassen). Dette programmet kobles til lagringssystemet, oppretter et volum med ønsket størrelse, mottar en identifikator og oppretter et PersistentVolume-manifest i Kubernetes-klyngen, som er knyttet til PersistentVolumeClaim.

Alt dette settet med abstraksjoner lar deg fjerne informasjon om hvilket lagringssystem applikasjonen jobber med fra applikasjonsmanifestnivå til administrasjonsnivå.

Alle parametere for å koble til datalagringssystemet er plassert i klassen Storage, som klyngeadministratorer er ansvarlige for. Alt du trenger å gjøre når du flytter fra AWS til Google Cloud er å endre navnet på lagringsklassen til PVC i applikasjonsmanifestene. Persistensvolum for datalagring opprettes automatisk i klyngen ved hjelp av Provisioner-programmet.

Metode 3: Container Storage Interface

All kode som samhandler med ulike lagringssystemer er en del av Kubernetes-kjernen. Utgivelsen av feilrettinger eller ny funksjonalitet er knyttet til nye utgivelser; koden må endres for alle støttede versjoner av Kubernetes. Alt dette er vanskelig å vedlikeholde og legge til ny funksjonalitet.

For å løse problemet har utviklere fra Cloud Foundry, Kubernetes, Mesos og Docker laget Container Storage Interface (CSI) – et enkelt enhetlig grensesnitt som beskriver interaksjonen mellom containeradministrasjonssystemet og en spesiell driver (CSI Driver) som fungerer med en spesifikk lagringssystem. All kode for interaksjon med lagringssystemer ble flyttet fra Kubernetes-kjernen til et eget system.

Dokumentasjon for containerlagringsgrensesnitt.

Vanligvis består CSI Driver av to komponenter: Node Plugin og Controller plugin.

Node Plugin kjører på hver node og er ansvarlig for å montere volumer og utføre operasjoner på dem. Kontroller-plugin-modulen samhandler med lagringssystemet: oppretter eller sletter volumer, tildeler tilgangsrettigheter osv.

Foreløpig forblir de gamle driverne i Kubernetes-kjernen, men de anbefales ikke lenger å brukes, og alle anbefales å installere CSI-driveren spesifikt for systemet de skal jobbe med.

Innovasjonen kan skremme de som allerede er vant til å sette opp datalagring gjennom Storage-klassen, men det har faktisk ikke skjedd noe forferdelig. For programmerere endrer ingenting egentlig - de har bare jobbet med navnet Storage-klassen, og vil fortsette å gjøre det. For administratorer er rorkartinstallasjonen lagt til og strukturen på innstillingene er endret. Hvis innstillingene tidligere ble lagt inn direkte i Lagringsklassen, må de nå først settes i rordiagrammet, og deretter i Lagringsklassen. Hvis du ser nærmere på det, har det ikke skjedd noe vondt.

La oss ta et eksempel for å se på fordelene du kan få ved å bytte til å koble til Ceph-lagringssystemer ved å bruke CSI-driveren.

Når du arbeider med Ceph, gir CSI-pluginen flere muligheter for å jobbe med lagringssystemer enn innebygde drivere.

1. Dynamisk diskoppretting. Vanligvis brukes RBD-disker bare i RWO-modus, men CSI for Ceph lar dem brukes i RWX-modus. Flere pods på forskjellige noder kan montere den samme RDB-disken på nodene sine og jobbe med dem parallelt. For å være rettferdig er ikke alt så lyst - denne disken kan bare kobles til som en blokkenhet, noe som betyr at du må tilpasse applikasjonen til å fungere med den i flertilgangsmodus.
2. Lage øyeblikksbilder. I en Kubernetes-klynge kan du opprette et manifest med kravet om å lage et øyeblikksbilde. CSI-pluginen vil se den og ta et øyeblikksbilde fra disken. Basert på det kan du lage enten en sikkerhetskopi eller en kopi av PersistentVolume.
3. Økende diskstørrelse på lagring og PersistentVolume i Kubernetes-klyngen.
4. Kvoter. CephFS-driverne innebygd i Kubernetes støtter ikke kvoter, men ferske CSI-plugins med den nyeste Ceph Nautilus kan aktivere kvoter på CephFS-partisjoner.
5. Beregninger. CSI-plugin-modulen kan gi Prometheus en rekke beregninger om hvilke volumer som er tilkoblet, hvilken kommunikasjon som finner sted, etc.
6. Topologi bevisst. Lar deg spesifisere i manifester hvordan klyngen er geografisk fordelt, og unngå å koble et lagringssystem i Amsterdam til pods som kjører i London.

Hvordan koble Ceph til en Kubernetes-klynge via CSI, se i den praktiske delen av Slurm kveldsskoleforelesning. Du kan også abonnere på Ceph videokurs, som lanseres 15. oktober.

Forfatter av artikkelen: Sergey Bondarev, praktiserende arkitekt ved Southbridge, Certified Kubernetes Administrator, en av utviklerne av kubespray.

Et lite Post Scriptum, ikke for reklame, men til fordel...

PS Sergey Bondarev leder to intensive kurs: oppdatert Kubernetes Base 28-30 september og videregående Kubernetes Mega 14.–16. oktober.

Kilde: www.habr.com