Die meisten Anwendungen benötigen auf die eine oder andere Weise persistenten Speicher. Egal ob Profilbilder, Textdokumente oder Produktinformationen in einer ausgelagerten Datenbank, irgendwo müssen immer Daten gespeichert werden. In der Cloud greift man hierbei normalerweise auf Block Storage oder Object Storage zurück. Doch was, wenn die Cloudumgebungen den Anforderungen nicht genügt, oder man seinen Speicher selbst verwalten möchte? Hier kommt Ceph ins Spiel.
Ceph ist ein Open Source Projekt für skalierbaren, verteilten Speicher über mehrere Hosts und Festplatten hinweg. Es bietet Block Storage, Object Storage und Dateisysteme als konsumierbaren Speicher. In der NETWAYS Cloud stellt ebenfalls ein Ceph-Cluster den Speicher für deine VMs, persistenten Volumes in NETWAYS Managed Kubernetes® und S3-kompatiblen Object Storage bereit.
In diesem Tutorial zeigen wir dir, wie du mithilfe von Rook in überschaubarer Zeit dein eigenes Ceph-Cluster provisionieren und nach deinen Vorstellungen konfigurieren kannst.
Was ist Rook?
Rook ist ein Kubernetes-Operator, der sich um die Installation, Konfiguration, den Betrieb und Updates eines oder mehrerer Ceph-Cluster kümmert. Dies geschieht durch verschiedene CustomResources, die von Rook definiert, interpretiert und umgesetzt werden.
Rook unterscheidet grundsätzlich zwischen vier verschiedenen Cluster-Typen:
- Host Storage Cluster: Der von Ceph verwaltete Speicher befindet sich direkt auf den Hosts des Kubernetes-Clusters, in dem Rook läuft.
- External Storage Cluster: Ceph läuft in einem externen Provider Cluster. Rook konfiguriert im Consumer Cluster nur die Storageklassen und den Zugriff.
- PVC Storage Cluster: Der von Ceph verwaltete Speicher befindet sich auf PersistentVolumeClaims, die im Kubernetes-Clusters provisioniert werden.
- Stretch Storage Cluster: Der von Ceph verwaltete Speicher wird durch Rook auf zwei Fehlerdomänen verteilt, um im Ausfall einer der Domänen weiterhin verfügbar zu bleiben.
In diesem Tutorial befassen wir uns mit einem PVC Storage Cluster, da dieses das häufigste Szenario in der Cloud ist: In einem Managed Kubernetes Cluster kann man den Speicher auf den Nodes des Clusters zum Beispiel häufig nicht erweitern, hat aber PersistentVolumeClaims zur Verfügung. Als Bonus lässt sich so ReadWriteMany (RWX) Speicher umsetzen, ein Feature, das viele Clouds nicht von Haus aus anbieten.
Voraussetzungen
Zur Einrichtung von Rook benötigen wir ein paar Dinge:
- Ein Kubernetes-Cluster (gemanaged oder nicht), mit einer Storageklasse, die die Modi File und Block unterstützt
- Genug Ressourcen im Cluster (Ceph ist leider relativ ressourcenhungrig – mindestens 16GB RAM pro Node wären von Vorteil)
- Helm, um Rook mittels Helmcharts zu installieren
- kubectl, um den Installationsvorgang zu überwachen
Sind alle Voraussetzungen erfüllt, können wir mit der Installation von Rook beginnen.
Installation von Rook
Die Installation von Rook besteht im Großen und Ganzen aus sechs Schritten:
- Einrichtung des Rook-Chart-Repositorys
- Konfiguration des Rook-Operators
- Installation des Rook-Operators
- Konfiguration des Ceph-Clusters
- Installation des Ceph-Clusters
- Testen des durch Ceph verwalteten Speichers
Schritt 1: Einrichtung des Rook-Chart-Repositorys
Auch wenn viele Beispielkonfigurationen für Rook-Szenarien in Form von Kubernetes-Manifesten existieren, hat sich in der Praxis eine Installation via Helm bewährt. Hierzu konfigurieren wir zuerst das Chart-Repository des Rook-Projekts und laden die neuesten Informationen über die enthaltenen Charts herunter :
helm repo add rook-release https://charts.rook.io/release
helm repo update
helm search repo rook-cephDer letzte Befehl sollte folgende Informationen auflisten:
NAME CHART VERSION APP VERSION DESCRIPTION
rook-release/rook-ceph v1.19.1 v1.19.1 File, Block, and Object Storage Services for...
rook-release/rook-ceph-cluster v1.19.1 v1.19.1 Manages a single Ceph cluster namespace for RookIm Chart-Repository von Rook befinden sich zwei Helmcharts: rook-ceph und rook-ceph-cluster. Die Chart rook-ceph-cluster ist für die Installation eines Ceph-Clusters zuständig. Hierfür benötigen wir allerdings zuerst den Rook-Operator, den wir mit der Chart rook-ceph installieren können. In Schritt 2 kümmern wir uns um die Konfiguration dieser Chart.
Schritt 2: Konfiguration des Rook-Operators
Helmcharts lassen sich normalerweise über eine Datei values.yaml konfigurieren, in der vorgegebene Werte für das Templating der Chart vorgegeben werden können. Die vollständige values.yaml mit allen möglichen Konfigurationen der rook-ceph Helmchart findest du auf GitHub.
Mit knapp 700 Zeilen ist sie nicht gerade klein, glücklicherweise müssen wir für ein erstes Deployment keine Werte anpassen.
Möchtest du später Änderungen am Rook-Operator vornehmen, ginge das mithilfe von helm upgrade und einer entsprechenden values.yaml immernoch. Die Folgende values.yaml würde beispielsweise den containerSecurityContext des Rook-Operators für PodSecurityAdmissions anpassen und das Deployment des CephFS-Drivers deaktivieren:
containerSecurityContext:
seccompProfile:
type: RuntimeDefault
allowPrivilegeEscalation: false
ceph-csi-operator:
controllerManager:
manager:
containerSecurityContext:
seccompProfile:
type: RuntimeDefault
csi:
enableCephfsDriver: falseSchritt 3: Installation des Rook-Operators
Die Installation von Helmcharts geschieht mithilfe des Befehls helm install. Erwartete Argumente sind ein Name für den sogenannten Helm-Release (die zu installierende Anwendung), welche Helmchart installiert werden soll, und optional ein existierender oder zu erstellender Namespace.
Zusätzlich kannst du Werte der values.yaml explizit mit --set setzen oder eine eigene values.yaml übergeben.
Die Installation der Helmchart rook-ceph sieht in unserem Szenario also so aus:
helm install rook-ceph rook-release/rook-ceph \
--namespace rook-ceph \
--create-namespaceDer Rook-Operator sollte von Helm im Namespace rook-ceph installiert werden – den Fortschritt kannst du mit kubectl überprüfen:
kubectl get pods --namespace rook-ceph
NAME READY STATUS RESTARTS AGE
ceph-csi-controller-manager-7f5867ddb-rrr45 1/1 Running 0 43s
rook-ceph-operator-c67cd758c-8b4dw 1/1 Running 0 43sSind beide Pods Ready und Running, war die Installation des Rook-Operators erfolgreich, und wir können mit der Konfiguration eines tatsächlichen Ceph-Clusters weitermachen.
Schritt 4: Konfiguration des Ceph-Clusters
Die Konfiguration und Installation eines Ceph-Clusters funktioniert mit Rook ebenfalls über eine Helmchart: rook-ceph-cluster. Die Helmchart installiert hier fast ausschließlich RBAC-Ressourcen und CustomResources. Um die tatsächliche Einrichtung des Clusters kümmert sich dann der Rook-Operator, der diese CustomResources interpretiert und umsetzt:
helm template rook-ceph-cluster rook-release/rook-ceph-cluster | grep kind
kind: ServiceAccount
kind: ServiceAccount
kind: ServiceAccount
kind: ServiceAccount
kind: ServiceAccount
kind: ServiceAccount
kind: ServiceAccount
kind: StorageClass
kind: StorageClass
kind: StorageClass
kind: ClusterRoleBinding
kind: ClusterRole
- kind: ServiceAccount
kind: ClusterRoleBinding
kind: ClusterRole
- kind: ServiceAccount
kind: Role
kind: Role
kind: Role
kind: Role
kind: RoleBinding
kind: ClusterRole
- kind: ServiceAccount
kind: RoleBinding
kind: Role
- kind: ServiceAccount
kind: RoleBinding
kind: Role
- kind: ServiceAccount
kind: RoleBinding
kind: ClusterRole
- kind: ServiceAccount
kind: RoleBinding
kind: Role
- kind: ServiceAccount
kind: RoleBinding
kind: Role
- kind: ServiceAccount
kind: CephBlockPool
kind: CephCluster
kind: CephFilesystem
kind: CephFilesystemSubVolumeGroup
kind: CephObjectStoreNeben RBAC-Manifesten (ServiceAccounts, Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) und CustomResources für das Ceph-Cluster selbst (CephCluster) installiert die Helmchart Ressourcen für Storagepools (CephBlockPool), geteilte Dateisysteme (CephFilesystem, CephFilesystemSubVolumeGroup) und Objectstores (CephObjectStore), sowie zu diesen Ressourcen gehörige StorageClasses.
Das einzige durch die Helmchart installierte Deployment sind die Ceph-Tools, mit deren Hilfe du dein Ceph-Cluster inspizieren und debuggen kannst.
Bevor wir ein Ceph-Cluster installieren können, müssen wir jedoch zuerst die nötige Konfiguration für unser PVC Storage Cluster vornehmen. Dazu erstellen wir folgende values.yaml:
cephClusterSpec:
mon:
count: 3
volumeClaimTemplate:
spec:
resources:
requests:
storage: 10Gi
storageClassName: standard # this storage class must exist in your cluster
storage:
storageClassDeviceSets:
- name: set1
count: 3
portable: true
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: standard # this storage class must exist in your cluster
volumeMode: BlockDie hier eingetragenen Werte definieren vor Allem die Nutzung von PersistentVolumeClaims (PVC) für die Ceph Monitore (Abschnitt mon) und Object Storage Devices (OSD, Abschnitt storage).
In beiden Abschnitten definieren wir die Anzahl gewünschter Replikas (3), die für die PVCs zu verwendende Storageclass, und die gewünschte Größe des verfügbaren Speichers. Für das Tutorial wählen wir eine relativ kleine Speichergröße von 10GB.
Schritt 5: Installation des Ceph-Clusters
Die erstellte Ceph-Konfiguration können wir nun als rook-ceph-cluster Helmchart in unser Cluster installieren. Der Namespace ist hierbei der gleiche wie bei der Installation des Rook-Operators:
helm install -n rook-ceph rook-ceph-cluster rook-release/rook-ceph-cluster -f values.yamlDie Installation und Einrichtung des Clusters kann einige Minuten in Anspruch nehmen. Der Rook-Operator fährt die vom Ceph-Cluster benötigten Ressourcen nacheinander hoch, konfiguriert die bereitgestellten PVCs für den Cluster-Speicher, und kümmert sich um die Erstellung von Storageklassen und CustomResources.
Den Fortschritt kannst du anhand der Pods im Namespace rook-ceph beobachten, oder am Status der CephCluster CustomResource ablesen:
kubectl get pods -n rook-ceph -l=rook_cluster=rook-ceph
NAME READY STATUS RESTARTS AGE
rook-ceph-crashcollector-48c6fcc6eef1956bf1e1247c60581206-s2x74 1/1 Running 0 24m
rook-ceph-crashcollector-5bc661df96ac242309cd28dfcdc1efd0-mh25x 1/1 Running 0 24m
rook-ceph-crashcollector-d449ca875daa794f49a1147650b323ae-8mvkg 1/1 Running 0 5m56s
rook-ceph-crashcollector-f16a0024aad7d77ed6e79b538eb2906d-gfs8s 1/1 Running 0 22m
rook-ceph-exporter-48c6fcc6eef1956bf1e1247c60581206-74f97fwfmr4 1/1 Running 0 24m
rook-ceph-exporter-5bc661df96ac242309cd28dfcdc1efd0-5576f6wpmnd 1/1 Running 0 24m
rook-ceph-exporter-d449ca875daa794f49a1147650b323ae-84fb7bt4lfb 1/1 Running 0 5m54s
rook-ceph-exporter-f16a0024aad7d77ed6e79b538eb2906d-9c456bzgw72 1/1 Running 0 22m
rook-ceph-mds-ceph-filesystem-a-58b645f497-jnck2 2/2 Running 0 23m
rook-ceph-mds-ceph-filesystem-b-7b686f5cd5-g85bd 2/2 Running 0 23m
rook-ceph-mgr-a-55fd7c8f44-kqbnr 3/3 Running 0 24m
rook-ceph-mgr-b-5b4bfcbb69-tfz52 3/3 Running 0 24m
rook-ceph-mon-a-5f878c749b-rldvv 2/2 Running 0 26m
rook-ceph-mon-b-6b8578dd8d-f2nkq 2/2 Running 0 25m
rook-ceph-mon-c-58fcf64c98-7t255 2/2 Running 0 25m
rook-ceph-osd-0-c797bfb97-rzt4j 2/2 Running 0 106s
rook-ceph-osd-1-768787c556-qxdkj 2/2 Running 0 3m32s
rook-ceph-osd-2-fd6f986fb-sx46r 2/2 Running 0 2m52s
rook-ceph-osd-prepare-48c6fcc6eef1956bf1e1247c60581206-2tmb2 0/1 Completed 0 43s
rook-ceph-osd-prepare-5bc661df96ac242309cd28dfcdc1efd0-84wx5 0/1 Completed 0 46s
rook-ceph-osd-prepare-d449ca875daa794f49a1147650b323ae-mwwk9 0/1 Completed 0 52s
rook-ceph-osd-prepare-f16a0024aad7d77ed6e79b538eb2906d-kcncr 0/1 Completed 0 49s
rook-ceph-osd-prepare-set1-data-1blxfw-pwhf9 0/1 Completed 0 4m26s
rook-ceph-rgw-ceph-objectstore-a-5c4bcdfff9-jj5c4 2/2 Running 0 22mDas CephCluster sollte sich jetzt im Zustand Health_OK befinden:
kubectl get cephcluster -n rook-ceph rook-ceph
NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH
rook-ceph /var/lib/rook 3 27m Ready Cluster created successfully HEALTH_OKAuf den ersten Blick sieht alles gut aus. Jetzt gilt es, die verschiedenen durch Rook Ceph bereitgestellten Storageklassen auf ihre Funktionalität zu testen!
Schritt 6: Testen des durch Ceph verwalteten Speichers
Ist das Ceph-Cluster erfolgreich installiert, können wir in unserem Cluster drei neue Storageklassen entdecken:
kubectl get storageclasses
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ceph-block (default) rook-ceph.rbd.csi.ceph.com Delete Immediate true 17h
ceph-bucket rook-ceph.ceph.rook.io/bucket Delete Immediate false 17h
ceph-filesystem rook-ceph.cephfs.csi.ceph.com Delete Immediate true 17h
[...]- ceph-block stellt RWO-kompatiblen Block Storage bereit
- ceph-bucket stellt S3-/SWIFT-kompatible Buckets für Object Storage bereit
- ceph-filesystem stellt RWX-kompatible Ceph Filesysteme bereit
Im letzten Teil dieses Tutorials wollen wir die verschiedenen Storageklassen nun testen.
Schritt 6.1: Testen von ceph-block
Die Storageklasse ceph-block stellt RWO-kompatiblen Block Storage bereit. Das bedeutet, dass wir mit ihr PersistentVolume(Claim)s provisionieren können, die von genau einem Node gleichzeitig gemounted werden können. Wir erstellen also folgendes Manifest pod-rwo.yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rwo-pvc
labels:
scenario: rwo-test
spec:
accessModes:
- ReadWriteOnce
storageClassName: ceph-block
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: rwo-test
labels:
scenario: rwo-test
spec:
containers:
- name: app
image: busybox
command: [sh, -c, "echo RWO OK > /mnt/data/test.txt && sleep 3600"]
volumeMounts:
- name: data
mountPath: /mnt/data
volumes:
- name: data
persistentVolumeClaim:
claimName: rwo-pvcMit kubectl apply erstellen wir den beschriebenen Pod, der ein durch den PersistentVolumeClaim angefragtes RWO PersistentVolume mounted, und in diesem eine neue Datei anlegt:
kubectl apply -f pod-rwo.yaml
persistentvolumeclaim/rwo-pvc created
pod/rwo-test created
kubectl get pods -l=scenario=rwo-test
NAME READY STATUS RESTARTS AGE
rwo-test 1/1 Running 0 29s
kubectl get pvc -l=scenario=rwo-test
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
rwo-pvc Bound pvc-3ccb1f8f-470b-44fe-93d4-9429f165edbc 1Gi RWO ceph-block <unset> 32sDer Pod und das Volume scheinen erfolgreich provisioniert worden zu sein. Zusätzlich können wir die vom Pod erstellte Datei im Volume auslesen:
kubectl exec -it rwo-test -- cat /mnt/data/test.txt
RWO OKDer Pod war in der Lage, in das gemountete Volume zu schreiben. Die ceph-block Storageklasse scheint funktional.
Schritt 6.2: Testen von ceph-filesystem
Spannender wird es beim Testen der Storageklasse ceph-filesystem, die RWX-kompatiblen Speicher bereitstellt. Hierfür benötigen wir also mehrere Pods, die das gleiche Volume mounten und mit diesem interagieren. Hierzu legen wir das Manifest pods-rwx.yaml an:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rwx-pvc
labels:
scenario: rwx-test
spec:
accessModes:
- ReadWriteMany
storageClassName: ceph-filesystem
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: rwx-writer
labels:
scenario: rwx-test
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
scenario: rwx-test
topologyKey: kubernetes.io/hostname
containers:
- name: writer
image: busybox
command: [sh, -c, "while true; do date >> /mnt/shared/log.txt; sleep 5; done"]
volumeMounts:
- name: shared
mountPath: /mnt/shared
volumes:
- name: shared
persistentVolumeClaim:
claimName: rwx-pvc
---
apiVersion: v1
kind: Pod
metadata:
name: rwx-reader
labels:
scenario: rwx-test
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
scenario: rwx-test
topologyKey: kubernetes.io/hostname
containers:
- name: reader
image: busybox
command: [sh, -c, "while true; do cat /mnt/shared/log.txt; sleep 10; done"]
volumeMounts:
- name: shared
mountPath: /mnt/shared
volumes:
- name: shared
persistentVolumeClaim:
claimName: rwx-pvcWie im RWO-Test provisionieren wir einen PersistentVolumeClaim, dieses Mal für die ceph-filesystem Storageklasse. Dazu kommen zwei Pods, durch podAntiAffinity auf verschiedene Nodes verteilt, um das gleichzeitige Mounten des Volumes auf verschiedenen Nodes zu testen.
kubectl apply -f pods-rwx.yaml
persistentvolumeclaim/rwx-pvc created
pod/rwx-writer created
pod/rwx-reader created
kubectl get pods -l=scenario=rwx-test
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
rwx-reader 1/1 Running 0 85s 10.2.1.167 shoot--20993--ceph-cluster-default-nodes-z1-85fb4-79xzh <none> <none>
rwx-writer 1/1 Running 0 85s 10.2.0.145 shoot--20993--ceph-cluster-default-nodes-z1-85fb4-b8bbk <none> <none>
kubectl get pvc -l=scenario=rwx-test
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
rwx-pvc Bound pvc-9c754dc5-7084-4d65-b7f5-80bd8f4bf657 1Gi RWX ceph-filesystem <unset> 2m4sDie Pods laufen auf unterschiedlichen Nodes, und das Volume wurde erfolgreich angelegt. Anhand der Ausgabe der beiden Pods können wir feststellen, ob das gleichzeitige Lesen/Schreiben aus verschiedenen Anwendungen funktioniert:
kubectl logs rwx-reader
Tue Feb 24 08:23:15 UTC 2026
Tue Feb 24 08:23:20 UTC 2026
Tue Feb 24 08:23:25 UTC 2026
Tue Feb 24 08:23:15 UTC 2026
Tue Feb 24 08:23:20 UTC 2026
Tue Feb 24 08:23:25 UTC 2026Aus dem Pod rwx-reader heraus können wir also auf die vom Pod rwx-writer geschriebenen Daten zugreifen. Auch die RWX-kompatible Storageklasse funktioniert also.
Schritt 6.3: Testen von ceph-bucket
Die letzte verbleibende Storageklasse, die es zu testen gilt, ist ceph-bucket. Diese provisioniert man normalerweise nicht manuell, sondern nutzt stattdessen die von Rook bereitgestellte CustomResource ObjectBucketClaim. Wir erstellen folgende Manifeste in pod-s3.yaml:
apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
name: my-bucket
spec:
generateBucketName: my-bucket
storageClassName: ceph-bucket
---
apiVersion: v1
kind: Pod
metadata:
name: s3-test
labels:
scenario: s3-test
spec:
containers:
- name: s3
image: amazon/aws-cli
command:
- sh
- -c
- |
aws s3 ls s3://$BUCKET_NAME && \
echo "hello ceph" | aws s3 cp - s3://$BUCKET_NAME/hello.txt && \
aws s3 cp s3://$BUCKET_NAME/hello.txt - && \
echo "Object storage OK" && \
sleep 3600
env:
# ConfigMap injected by OBC controller
- name: BUCKET_NAME
valueFrom:
configMapKeyRef:
name: my-bucket
key: BUCKET_NAME
- name: BUCKET_HOST
valueFrom:
configMapKeyRef:
name: my-bucket
key: BUCKET_HOST
- name: BUCKET_PORT
valueFrom:
configMapKeyRef:
name: my-bucket
key: BUCKET_PORT
# Secret injected by OBC controller
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: my-bucket
key: AWS_ACCESS_KEY_ID
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: my-bucket
key: AWS_SECRET_ACCESS_KEY
- name: AWS_ENDPOINT_URL
value: http://$(BUCKET_HOST):$(BUCKET_PORT)Anhand des Manifests lässt sich erkennen, dass Rook sich bei der Provisionierung eines Objectstorage-Buckets auch um die Bereitstellung der benötigten Informationen (Bucket-Name, -Host, -Port, sowie Access Key und ID) in ConfigMaps bzw. Secrets kümmert, die wir nurnoch in unserem Pod einbinden müssen:
kubectl apply -f pod-s3.yaml
objectbucketclaim.objectbucket.io/my-bucket created
pod/s3-test created
kubectl get pods -l=scenario=s3-test
NAME READY STATUS RESTARTS AGE
s3-test 1/1 Running 0 65s
kubectl get objectbuckets
NAME AGE
obc-default-my-bucket 75sAuch in diesem Szenario wird der angefragte Speicher in Form eines ObjectBuckets anhand unseres ObjectBucketClaims erstellt, und der Pod startet erfolgreich. Die Logs des Pods sollten uns verraten, ob ein Up- und Download aus dem provisionierten S3-Bucket funktioniert:
kubectl logs s3-test
hello ceph
Object storage OKSieht der Output so aus, hat der Up- und Download funktioniert – auch die ceph-bucket Storageklasse funktioniert also wie erwartet.
Fazit
Mit Rook lässt sich ein vollwertiges Ceph-Cluster in wenigen Schritten in einem bestehenden Kubernetes-Cluster provisionieren und betreiben – ohne tiefes Ceph-Expertenwissen vorauszusetzen. Der Operator übernimmt die schwere Arbeit: initiale Einrichtung, Konfiguration von Storageklassen, laufende Verwaltung des Clusters und Updates von Rook und Ceph.
Wie die Tests in diesem Tutorial gezeigt haben, stehen nach der Installation drei vollwertige Speichertypen zur Verfügung: RWO-Block Storage über ceph-block, RWX-fähiger Shared Storage über ceph-filesystem und S3-kompatibler Object Storage über ceph-bucket. Gerade die Möglichkeit, ReadWriteMany-Volumes bereitzustellen, macht Rook Ceph zu einer attraktiven Lösung für Anwendungen, die gemeinsam auf denselben Speicher zugreifen müssen – ein Feature, das viele Cloud-Anbieter nicht ohne Weiteres bieten.
Natürlich bringt Ceph auch Komplexität mit sich: Der Ressourcenbedarf ist nicht zu unterschätzen, und für produktive Umgebungen empfiehlt sich eine sorgfältige Planung hinsichtlich Replikationsfaktor, Fehlerdomänen und Kapazität. Für weiterführende Konfigurationen bietet die Rook-Dokumentation umfangreiche Anleitungen. Und natürlich sind dir auch unsere MyEngineers® gerne behilflich!
0 Kommentare