🥇Rook — "självbetjänad" datalagring för Kubernetes

Den 29 januari beslutade den tekniska kommittén inom CNCF (Cloud Native Computing Foundation), som står bakom Kubernetes, Prometheus och andra Open Source-produkter inom container- och cloud-native-världen, meddelade att anta projektet Rook i sina led. Ett utmärkt tillfälle att lära känna denna "orkestrator" för distribuerad datalagring i Kubernetes närmare.

Vad är Rook?

Rook – det är en programvara skriven i Go (sprids under den fria licensen Apache License 2.0), som syftar till att ge datalagringssystem automatiserade funktioner som gör dem självförvaltande, självskalerande och självåterställande.För detta automatiserar Rook (för datalagringssystem som används i Kubernetes-miljö): distribution, bootstrapping, konfiguration, provisionering, skalning, uppdateringar, migreringar, återställning efter fel, övervakning och resursförvaltning.

Projektet är för närvarande i alpha-stadiet och specialiserar sig på orkestrering av det distribuerade datalagringssystemet Ceph i Kubernetes-kluster. Utvecklarna har även planer på att stödja andra lagringssystem, men det kommer inte att ske i de kommande versionerna.

Komponenter och teknisk struktur

Rook fungerar inom Kubernetes genom en speciell operator (läs mer om Kubernetes Operators i vår tidigare artikel), som automatiserar konfigurationen av lagringssystemet och genomför dess övervakning. denna artikel)Rook-operatorn

Så, presenteras som en container som innehåller allt som behövs för distribution och efterföljande underhåll av lagringssystemet. Bland operatorns uppgifter ingår: skapande av DaemonSet för Ceph-lagringsdemoner

ceph-osd (med ett enkelt RADOS-kluster;) skapande av pods för övervakning av Ceph
(med ceph-mon , som kontrollerar klustrets tillstånd; för att uppnå majoritet distribueras vanligtvis tre instanser och vid nedgång av någon av dem startar en ny)hantering av CRD:er (;
Custom Resource Definitions) för självaklustret lagringspooler, objektdatabaser, (uppsättningar av resurser och tjänster för att hantera HTTP-förfrågningar som utför PUT/GET för objekt, som är kompatibla med S3 och Swift API) filsystem, samt initialisering av pods för att starta alla nödvändiga tjänster;;
skapande av Rook-agenter.
Rook-agenter

presenteras som separata pods som distribueras på varje Kubernetes-nod. Agentens uppgift är att konfigurera pluginet FlexVolume Flexvolym, som ger stöd för lagringsvolymer i Kubernetes. Agenten implementerar lagringshantering: ansluter nätverkslagringsenheter, monterar volymer, formaterar filsystem och så vidare.

Platsen och rollen för komponenter i Rook i den övergripande schemat för Kubernetes-klustret

Rook erbjuder tre typer av lagring:

blocklagring (Block, StorageClass) — monterar lagring till en enda pod;
objektlagring (Object, ObjectStore) — tillgänglig både inuti och utanför Kubernetes-klustret (via S3 API);
delad F (Shared File System, Filsystem) — ett filsystem som kan monteras med läs- och skrivåtkomst från flera pods.

Rooks interna enheter inkluderar:

Mons — pods för övervakning av Ceph (med redan nämnda ceph-mon);
OSDs — pods med demoner för ceph-osd (Object Storage Daemons);
MGR — pods med demonen ceph-mgr (Ceph Manager), vilket tillhandahåller ytterligare övervakningsfunktioner och gränssnitt för externa system (övervakning/hantering);
RGW (valfritt) — pods med objektlagring;
MDS (valfritt) — pods med delat filsystem.

Alla Rook-demoner (Mons, OSDs, MGR, RGW, MDS) är kompilera i en enda binärfil (rook), som körs i en container.

För en kort översikt av projektet kan även denna lilla (12 sidor) presentation avsedd av Bassam Tabbara (CTO på Quantum Corp).

Användning av Rook

Rook-operatören har fullt stöd för Kubernetes version 1.6 och högre (och delvis för äldre K8s-version 1.5.2). Dess installation på i det enklaste scenariot ser ut så här:

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

Dessutom har Rook-operatören förberett Helm-diagrammet, vilket möjliggör att installationen kan göras så här:

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

Det finns ett litet antal konfigurationsalternativ (till exempel, möjligheten att stänga av stödet RBAC, om den funktionen inte används i ditt kluster), som skickas till helm install genom parametern --set key=value[,key=value] (eller lagras i en separat YAML-fil och skickas med -f values.yaml).

Efter installationen av Rook-operatören och starten av pods med dess agenter är det dags att skapa själva Rook-klustret, vars enklaste konfiguration ser ut som följer (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

Anmärkning: särskild uppmärksamhet bör ägnas åt attributet dataDirHostPath, varsamt värde som behövs för att bevara klustret efter omstarter. För att använda det som en permanent lagringsplats rekommenderar författarna att ha minst 5 GB ledigt diskutrymme i denna katalog på Kubernetes-värdar.

Det återstår att skapa klustret från konfigurationen och säkerställa att poddarna har skapats i klustret (i namnutrymmet 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

Uppgradering av Rook-klustret (till en ny version) är en procedur som för närvarande kräver sekventiell uppdatering av alla dess komponenter i en viss ordning, och den kan påbörjas först när du har försäkrat dig om att den aktuella Rook-installationen är helt "frisk". En detaljerad steg-för-steg-instruktion för uppgradering från Rook version 0.5.0 till 0.5.1 kan hittas i projektets dokumentation.

I november förra året publicerades i Rook-bloggen resultaten jämförelsen prestanda med EBS. Resultaten är värda att uppmärksamma, och sammanfattningsvis ser de ut som följer:

Framtidsutsikter

Den aktuella statusen för Rook är alpha, och den senaste stora versionen som släppts är version 0.6, som släpptes i november 2017 (den aktuella uppdateringen — v0.6.2 — släpptes den 14 december). Redan under första halvan av 2018 förväntas släpp av mer mogna versioner: betor och den stabila (officiellt redo för produktion).

Enligt roadmap för projektet, utvecklarna har en detaljerad vision för utvecklingen av Rook i minst de två kommande versionerna: 0.7 (dess beredskap i GitHub-tracker bedöms som 60 %) och 0.8. Bland de förväntade ändringarna finns övergången av stödet för Ceph Block och Ceph Object till betastatus, dynamisk provisionering av volymer för CephFS, en avancerad loggningssystem, automatiserade klusteruppdateringar, stöd för snapshots av volymer.

Acceptans av Rook bland CNCF-projekt (åtminstone vid det allra tidigaste skedet — "inception-level", — på samma nivå som linkerd och CoreDNS) är en slags garanti för det växande intresset för produkten. Hur väl det kommer att etablera sig i världen av molnapplikationer kommer att bli tydligare efter lanseringen av stabila versioner, vilket utan tvekan kommer att ge Rook nya "testare" och användare.

P.S.

Läs även i vår blogg:

Källa: habr.com

Rook – datalagring för Kubernetes med "självbetjäning"

Vad är Rook?

Komponenter och teknisk struktur

Användning av Rook

Framtidsutsikter

P.S.