Rook – et "selvbetjenings" datalager til Kubernetes

Den 29. januar vedtog det tekniske udvalg i CNCF (Cloud Native Computing Foundation), som står bag Kubernetes, Prometheus og andre Open Source-produkter fra container- og cloud native-verdenen, har annonceret et projekt Rook i sine rækker. En fremragende mulighed for at lære denne "orkestrator for distribuerede datalagringssystemer i Kubernetes" bedre at kende.

Hvad er Rook?

Rook — det er et softwareprogram skrevet i Go (distribueres under den åbne licens Apache License 2.0), der har til formål at give datalagre automatiserede funktioner, som gør dem selvstyrende, selvskalerende og selvgenoprettende. For at opnå dette automatiserer Rook (for datalagre anvendt i Kubernetes-miljøer): deployment, bootstrapping, konfiguration, provisioning, skalering, opdateringer, migration, fejlgendannelse, overvågning og ressourceadministration.

Projektet er i alfa-fasen og specialiserer sig i orkestrering af det distribuerede datalagringssystem Ceph i Kubernetes-klynger. Forfatterne angiver også planer om at understøtte andre lagringssystemer, men det vil ikke ske i de kommende udgivelser.

Komponenter og teknisk opbygning

I Rooks funktion inde i Kubernetes er der en særlig operator der automatiserer konfigurationen af lagring og realiserer den nødvendige overvågning. denne artikel)Rook-operatoren

Så, fremstår som en container, der indeholder alt nødvendigt for at implementere og efterfølgende vedligeholde lagringen. Blandt operatorens opgaver er: oprettelse af DaemonSet til Ceph-lagermedarbejdere

• ceph-osd (med et simpelt RADOS-kluster;) oprettelse af pods til overvågning af Ceph
• (med ceph-mon , der kontrollerer clusterets tilstand; for quorum bliver der i de fleste tilfælde implementeret tre instanser, og når en af dem falder, genstartes en ny)administration af CRD'er (;
• ) for selveCustom Resource Definitionsklusteret lagringspuljer, object stores, (sæt af ressourcer og tjenester til håndtering af HTTP-anmodninger, der udfører PUT/GET for objekter, — de er kompatible med S3 og Swift API) filsystemer, samt initialisering af pods til at køre alle nødvendige tjenester;;
• oprettelse af Rook-agenter.
• Rook-agenter

fremstår som separate pods, der implementeres på hver Kubernetes-node. Agentens formål er at konfigurere FlexVolume-pluginet. Præsenteres som separate pods, der implementeres på hver Kubernetes-node. Agentens formål er at konfigurere pluginet FlexVolume, der sikrer understøttelse af lagertomme i Kubernetes. Agenten implementerer lagringsdriften: tilslutter netværkslagringsenheder, monterer tomme, formaterer filsystemet osv.

Placering og rolle for Rook-komponenter i den samlede arkitektur af Kubernetes-klyngen

Rook tilbyder tre typer lagring:

1. blok (Block, StorageClass) — monterer lagren til en enkelt pod;
2. objekt (Object, ObjectStore) — tilgængelig både indenfor og udenfor Kubernetes-klyngen (via S3 API);
3. delt filsystem (Shared File System, Filsystem) — et filsystem, der kan monteres til læsning og skrivning fra flere pods.

Rooks interne enheder inkluderer:

• Mons — pods til overvågning af Ceph (med de nævnte ceph-mon);
• OSDs — pods med dæmoner fra ceph-osd (Object Storage Daemons);
• MGR — pods med dæmonen ceph-mgr (Ceph Manager), der tilbyder yderligere overvågningsmuligheder og interfaces til eksterne systemer (overvågning/styring);
• RGW (valgfrit) — pods med objektlagring;
• MDS (valgfrit) — pods med delt filsystem.

Alle Rook-dæmoner (Mons, OSDs, MGR, RGW, MDS) er kompilering i en enkelt binær fil (rook), der køres i en container.

For kort at præsentere Rook-projektet kan denne lille (12 slides) præsentation præsentation af Bassam Tabbara (CTO i Quantum Corp) være nyttig.

Drift af Rook

Rook-operatoren understøtter fuldt ud Kubernetes version 1.6 og højere (og delvist den ældre K8s-udgave — 1.5.2). Its installation i i det simpleste scenario ser sådan ud:

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

Derudover er der for Rook-operatoren forberedt Helm-diagram, hvilket muliggør, at installationen kan udføres på den måde:

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

Der er et lille antal konfigurationsmuligheder (for eksempel kan understøttelsen deaktiveres RBAC, hvis denne mulighed ikke anvendes i din klynge), som sendes i helm install gennem parameteren --set key=value[,key=value] (eller opbevares i en separat YAML-fil og sendes via -f values.yaml).

Efter installationen af Rook-operatoren og lanceringen af pods med dens agenter skal selve Rook-klyngen oprettes, hvis enkleste konfiguration ser således ud (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

Bemærk: særlig opmærksomhed bør rettes mod attributten dataDirHostPath, hvis værdi er nødvendig for at bevare klusteret efter genstarter. I tilfælde, hvor det anvendes som et permanent datalager, anbefaler Rook-forfatterne at have mindst 5 GB ledig diskplads i denne mappe på Kubernetes-værter.

Det er nu blot at oprette et kluster ud fra konfigurationen og sikre, at pods er blevet oprettet i klusteret (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

Upgrade opdatering af Rook-klusteret (indtil den nye version) er en procedure, der på dette stadium kræver sekventiel opdatering af alle dets komponenter i en bestemt rækkefølge, og man kan kun begynde den, efter man har bekræftet, at den nuværende Rook-installation er helt "sund". En detaljeret trin-for-trin vejledning til opdatering fra Rook version 0.5.0 til 0.5.1 kan findes i projektets dokumentation.

I november sidste år blev der i Rook-bloggen offentliggjort sammenligning ydelse med EBS. Dens resultater er bemærkelsesværdige, og kort sagt, de er som følger:

Udsigter

Den nuværende status for Rook er alpha, og den seneste større udgivelse til dato er version 0.6, der blev frigivet i november 2017 (den aktuelle opdatering er v0.6.2 — udgivet den 14. december). Allerede i første halvdel af 2018 forventes der frigivelser af mere modne versioner: beta og stabil (officielt klar til brug i produktion).

Ifølge roadmap for projektet, har udviklerne en detaljeret vision for udviklingen af Rook i mindst de to kommende versioner: 0.7 (som er 60 % klar i GitHub-tracker vurderet og 0.8. Blandt de forventede ændringer er opgradering af support for Ceph Block og Ceph Object til beta-status, dynamisk provisioning af volumes til CephFS, et forbedret logningssystem, automatiserede klusteropdateringer og understøttelse af snapshots til volumes.

Optagelsen af Rook blandt CNCF-projekter (for nu på det tidligste stadium — "inception-level", — på linje med linkerd og CoreDNS) er en slags garanti for den voksende interesse for produktet. Hvor godt det vil slå rod i verden af cloud-applikationer, vil blive klarere efter frigivelsen af stabile versioner, som uden tvivl vil tiltrække nye "testere" og brugere til Rook.

P.S.

Læs også på vores blog:

• «Opretter vedvarende lager med provisioning i Kubernetes baseret på Ceph»;
• «Operatorer til Kubernetes: hvordan man kører stateful-applikationer.»;
• «Der er tilføjet understøttelse af mørk tilstand i Play Store-applikationen»;
• «Container Networking Interface (CNI) — netværksinterface og standard for Linux-containere»;
• «Infrastruktur med Kubernetes som en tilgængelig tjeneste».

Kilde: habr.com