Rook - et selvbetjent datalager for Kubernetes

Den 29. januar, den tekniske komiteen til CNCF (Cloud Native Computing Foundation), organisasjonen bak Kubernetes, Prometheus og andre åpen kildekode-produkter fra verden av containere og skybaserte, kunngjort om aksept av prosjektet tårn inn i sine rekker. En utmerket mulighet til å bli kjent med denne "distribuerte lagringsorkestratoren i Kubernetes."

Hva slags røk?

tårn er programvare skrevet i Go (distribuert av under gratis Apache License 2.0), designet for å gi datavarehus automatiserte funksjoner som gjør dem selvadministrerende, selvskalerende og selvhelbredende. For å gjøre dette automatiserer Rook (for datalagre som brukes i et Kubernetes-miljø): distribusjon, oppstart, konfigurasjon, klargjøring, skalering, oppdateringer, migreringer, gjenoppretting etter katastrofe, overvåking og ressursadministrasjon.

Prosjektet er på alfastadiet og spesialiserer seg på å orkestrere det distribuerte lagringssystemet Ceph i Kubernetes-klynger. Forfatterne kunngjør også planer om å støtte andre lagringssystemer, men dette vil ikke skje i de neste utgivelsene.

Komponenter og teknisk utstyr

Rooks arbeid inne i Kubernetes er basert på en spesiell operatør (vi skrev mer om Kubernetes Operators i denne artikkelen), som automatiserer lagringskonfigurasjonen og implementerer dens overvåking.

således Rokoperatør ser ut til å være en beholder som inneholder alt nødvendig for distribusjon og påfølgende vedlikehold av depotet. Operatørens ansvar inkluderer:

• lage et DaemonSet for Ceph-lagringsdemoner (ceph-osd) med en enkel RADOS-klynge;
• lage pods for Ceph-overvåking (med ceph-mon, sjekke statusen til klyngen; for quorum, i de fleste tilfeller er tre eksemplarer utplassert, og hvis noen av dem faller, kommer en ny opp);
• håndtering av CRD-er (Egendefinerte ressursdefinisjoner) for seg selv klynge, lagringsbassenger, gjenstandslagre (sett med ressurser og tjenester for å betjene HTTP-forespørsler som utfører PUT/GET på objekter - de er kompatible med S3 og Swift API)Og filsystemer;
• initialisering av pods for å starte alle nødvendige tjenester;
• opprettelse av Rook-agenter.

Agenter fra Rook er representert av separate pods som er distribuert på hver Kubernetes-node. Formålet med agenten er plugin-konfigurasjon Flexvolum, som gir støtte for lagringsvolumer i Kubernetes. Agenten implementerer driften av lagringen: kobler til nettverkslagringsenheter, monterer volumer, formaterer filsystemet, etc.

Plassering og rolle for Rook-komponenter i det overordnede Kubernetes-klyngeskjemaet

Rook tilbyr tre typer oppbevaring:

1. blokkere (Blokker, StorageClass) — monterer lageret til en enkelt ildsted;
2. gjenstand (Objekt, ObjectStore) - tilgjengelig i og utenfor Kubernetes-klyngen (via S3 API);
3. delt filsystem (Delt filsystem, Filesystem) er et filsystem som kan monteres for lesing og skriving fra flere pods.

Innsiden av Rook inkluderer:

• Mons — pods for Ceph-overvåking (med den allerede nevnte ceph-mon);
• OSD-er - poder med ceph-osd-demoner (Object Storage Daemons);
• M.G.R. - belger med en demon ceph-mgr (Ceph Manager), som gir ekstra overvåkingsmuligheter og grensesnitt for eksterne systemer (overvåking/kontroll);
• RGW (valgfri) - pods med gjenstandslagring;
• MDS (valgfri) - poder med delt filsystem.

Alle Rook-demoner (Mons, OSD, MGR, RGW, MDS) er kompilert til en enkelt binær (rook) kjører i en container.

For en kort introduksjon til Rook-prosjektet kan denne korte (12 lysbildene) også være nyttig. presentasjon fra Bassam Tabbara (CTO hos Quantum Corp).

Betjening av røkten

Rook-operatøren støtter fullt ut Kubernetes versjon 1.6 og høyere (og delvis den eldre K8-utgivelsen - 1.5.2). hans installasjon в enkleste scenario ser slik ut:

cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml

I tillegg er Rook-operatøren forberedt Hjelmdiagram, takket være hvilken installasjonen kan utføres slik:

helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook

Liten mengde tilgjengelig oppsettsalternativer (du kan for eksempel deaktivere støtte RBAC, hvis denne funksjonen ikke brukes i klyngen din), som sendes til helm install via parameter --set key=value[,key=value] (eller lagre i en separat YAML-fil og send via -f values.yaml).

Etter å ha installert Rook-operatøren og lansert pods med agentene, gjenstår det bare å lage selve Rook-klyngen, hvis enkleste konfigurasjon ser slik ut (rook-cluster.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: rook
---
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook
spec:
  dataDirHostPath: /var/lib/rook
  storage:
    useAllNodes: true
    useAllDevices: false
    storeConfig:
      storeType: bluestore
      databaseSizeMB: 1024
      journalSizeMB: 1024

Note: spesiell oppmerksomhet bør rettes mot attributtet dataDirHostPath, den riktige verdien er nødvendig for å lagre klyngen etter omstart. For tilfeller der det brukes som permanent lagringssted for Rook-data på Kubernetes-verter, anbefaler forfatterne å ha minst 5 GB ledig diskplass i denne katalogen.

Alt som gjenstår er å faktisk opprette klyngen fra konfigurasjonen og sørge for at podene ble opprettet i klyngen (i navneområdet rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NAME                              READY     STATUS    RESTARTS   AGE
rook-api-1511082791-7qs0m         1/1       Running   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1       Running   0          5m
rook-ceph-mon0-jflt5              1/1       Running   0          6m
rook-ceph-mon1-wkc8p              1/1       Running   0          6m
rook-ceph-mon2-p31dj              1/1       Running   0          6m
rook-ceph-osd-0h6nb               1/1       Running   0          5m

Oppgradering Rook cluster (opp til en ny versjon) er en prosedyre som på dette stadiet krever sekvensiell oppdatering av alle komponentene i en bestemt sekvens, og du kan starte den først etter at du har forsikret deg om at den nåværende Rook-installasjonen er helt "sunn" stat. Detaljerte trinnvise instruksjoner ved hjelp av eksemplet med oppdatering av Rook versjon 0.5.0 til 0.5.1 finnes i prosjektdokumentasjon.

Sist november på Rook-bloggen ble publisert sammenligning produktivitet med EBS. Resultatene er verdt oppmerksomhet, og i korte trekk er de som følger:

Prospekter

Rooks nåværende status er alfa, og den siste store utgivelsen til dags dato er 0.6 versjon, utgitt i november 2017 (nåværende korreksjon - v0.6.2 - kom ut 14. desember). Allerede i første halvdel av 2018 forventes utgivelser av mer modne versjoner: beta og stabil (offisielt klar til bruk i produksjon).

Ifølge veikart prosjekt, har utviklerne en detaljert visjon for utviklingen av Rook i minst de to neste utgivelsene: 0.7 (beredskapen er i GitHub-sporingen Antatt som 60 %) og 0.8. Blant de forventede endringene er overføring av støtte for Ceph Block og Ceph Object til betaversjonsstatus, dynamisk levering av volumer for CephFS, et avansert loggingssystem, automatiserte klyngeoppdateringer, støtte for øyeblikksbilder for volumer.

Tar Rook inn i nummeret CNCF-prosjekter (så langt på et veldig tidlig stadium - "inception-level" - på nivå med linkerd и KjerneDNS) er en slags garanti for økende interesse for produktet. Hvordan den vil få fotfeste i verden av skyapplikasjoner vil bli tydeligere når stabile versjoner er utgitt, noe som helt sikkert vil bringe nye testere og brukere til Rook.

PS

Les også på bloggen vår:

• «Opprette vedvarende lagring med klargjøring i Kubernetes basert på Ceph";
• «Operatører for Kubernetes: hvordan kjøre stateful applikasjoner";
• «CoreDNS - DNS-server for cloud native verden og Service Discovery for Kubernetes";
• «Container Networking Interface (CNI) - nettverksgrensesnitt og standard for Linux-beholdere";
• «Infrastruktur med Kubernetes som en rimelig tjeneste'.

Kilde: www.habr.com