Installation und Betrieb von NooBaa auf einem Kubernetes-Cluster in einer Single-Cloud-Umgebung auf EO-Lab

NooBaa ermöglicht die Erstellung eines abstrahierten S3-Backends auf Kubernetes. Ein solches Backend kann mit mehreren S3-Backing-Stores verbunden werden, z. B. in einem Multi-Cloud-Setup, und ermöglicht so u. a. eine Speichererweiterung oder hohe Verfügbarkeit.

In this article you will learn the basics of using NooBaa

  • wie man NooBaa auf einem Kubernetes-Cluster installiert

  • Erstellen eines NooBaa-Buckets mit S3-Objektspeicher in der CREODIAS Cloud

  • wie man einen NooBaa-Bucket erstellt, der Daten in zwei verschiedenen Clouds spiegelt

Was wir behandeln werden

  • NooBaa in einer lokalen Umgebung installieren

  • Vorläufige Konfiguration anwenden

  • Installation von NooBaa auf dem Kubernetes-Cluster

  • Erstellen eines NooBaa-Backing-Stores

  • Erstellen einer Bucket-Klasse

  • Erstellen eines ObjectBucketClaims

  • Verbinden mit dem NooBaa-Bucket über s3cmd

  • Testen des Zugriffs auf den Bucket

Voraussetzungen

Nr. 1 Konto

Sie benötigen ein CREODIAS Konto mit Horizon Schnittstelle https://cloud.fra1-1.cloudferro.com/auth/login/?next=/.

Nr. 2 Zugang zum Kubernetes-Cluster in der FRA1-1-Cloud

Um ein Cluster auf der FRA1-1-Cloud zu erstellen, wo wir unsere NooBaa-Installation ausführen werden, folgen Sie den Richtlinien in diesem Artikel /kubernetes/How-to-Create-a-Kubernetes-Cluster-Using-Creodias-OpenStack-Magnum.

Nr. 3 Kenntnisse über die Verwendung von Objektspeichern in CloudFerro-Clouds

Weitere Informationen unter /s3/How-to-use-Object-Storage-on-Creodias

Der traditionelle OpenStack-Begriff für importierte oder heruntergeladene Dateien ist Container im Hauptmenüpunkt Object Store. Wir werden den Begriff „Bucket“ für Objektspeicher-Container verwenden, um uns von dem Container-Begriff im Sinne von Docker/Kubernetes zu unterscheiden.

Nr. 4 kubectl betriebsbereit

Das CLI-Tool kubectl muss installiert sein und über die Umgebungsvariable KUBECONFIG auf Ihren Cluster verweisen - weitere Informationen unter /kubernetes/How-To-Access-Kubernetes-Cluster-Post-Deployment-Using-Kubectl-On-Creodias-OpenStack-Magnum.

Nr. 5 Zugang zu privaten S3-Schlüsseln in der FRA1-1-Cloud

Sie können auch den Zugang zu OpenStack CLI verwenden, um die privaten S3-Schlüssel zu erzeugen und einzulesen /cloud/How-to-generate-ec2-credentials-on-Creodias.

Nr. 6 Kenntnisse im Umgang mit s3cmd für den Zugriff auf Objektspeicher

Für weitere Informationen über s3cmd siehe /s3/How-to-access-private-object-storage-using-S3cmd-or-boto3-on-Creodias.

NooBaa in der lokalen Umgebung installieren

Der erste Schritt, um mit NooBaa zu arbeiten, besteht darin, es auf unserem lokalen System zu installieren. Wir laden das Installationsprogramm herunter, machen es ausführbar und verschieben es in den Systempfad:

curl -LO https://github.com/noobaa/noobaa-operator/releases/download/v5.11.0/noobaa-linux-v5.11.0
chmod +x noobaa-linux-v5.11.0
sudo mv noobaa-linux-v5.11.0 /usr/local/bin/noobaa

Geben Sie das Passwort für den Root-Benutzer ein, falls erforderlich.

Nach dieser Abfolge von Schritten sollte es möglich sein, einen Testbefehl auszuführen

noobaa help

Dies führt zu einer Ausgabe ähnlich der untenstehenden:

../_images/install_noobaa_locally.png

Vorläufige Konfiguration anwenden

Auf einem Magnum-Cluster müssen wir zusätzliche Konfigurationen vornehmen, um eine PodSecurityPolicy-Ausnahme zu vermeiden. Siehe dazu Artikel /kubernetes/Installing-JupyterHub-on-Magnum-Kubernetes-cluster-in-{{ brand_name_cloud }}-cloud.

Beginnen wir damit, einen eigenen Namensraum für NooBaa-Artefakte zu erstellen:

kubectl create namespace noobaa

Erstellen Sie dann eine Datei noobaa-rolebinding.yaml mit dem folgenden Inhalt:

noobaa-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: noobaa-rolebinding
  namespace: noobaa
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: magnum:podsecuritypolicy:privileged

und wenden Sie diese an:

kubectl apply -f noobaa-rolebinding.yaml

NooBaa auf dem Kubernetes-Cluster installieren

In unserer lokalen Umgebung ist NooBaa bereits verfügbar, aber wir müssen NooBaa noch auf unserem Kubernetes-Cluster installieren. NooBaa verwendet den Kontext der KUBECONFIG von kubectl (wie in Voraussetzung Nr. 4 aktiviert), also installieren Sie NooBaa im dedizierten namespace:

noobaa install -n noobaa

Nach ein paar Minuten wird NooBaa installiert und es werden zusätzliche Informationen über die Einrichtung angezeigt. Überprüfen Sie den Status von NooBaa mit dem Befehl

noobaa status -n noobaa

Es werden mehrere nützliche Informationen über die NooBaa-Installation ausgegeben, wobei die „wichtigsten Fakten“ gegen Ende des Statusberichts verfügbar sind:

  • NooBaa hat einen Standard-Backing-Store namens noobaa-default-backing-store erstellt, der durch ein in OpenStack erstelltes Block-Volume gesichert wird.

  • S3-Anmeldeinformationen werden bereitgestellt, um auf den mit dem Standard-Backing-Store erstellten Bucket zuzugreifen. Ein solcher volumenbasierter Backing-Store hat seine Berechtigung, z. B. um die S3-Zugriffsmethode auf unseren Blockspeicher zu nutzen.

In diesem Artikel werden wir nicht den Standard-Backing-Store verwenden, sondern leinen neuen Backing-Store erstellen, der auf dem Cloud-S3-Objektspeicher basiert. Eine solche Einrichtung kann leicht erweitert werden, so dass wir am Ende separate Sicherungsspeicher für verschiedene Clouds haben.

Erstellen eines NooBaa-Backing-Stores

Schritt 1. Erstellen eines Objektspeicher-Buckets auf FRA1-1

Erstellen Sie nun einen Objektspeicher-Bucket in der FRA1-1-Cloud:

  • Wechseln Sie zu Horizon,

  • Verwenden Sie die Befehle Objektspeicher –> Container –> + Container, um einen neuen Objektbereich zu erstellen.

../_images/create_object_container1.png

Buckets in der FRA1-1-Cloud müssen eindeutige Namen haben. In unserem Fall verwenden wir den Bucket-Namen noobaademo-fra-1, den wir im gesamten Artikel verwenden werden.

Sie müssen einen Bucket mit einem anderen Namen erstellen und diesen generierten Namen im weiteren Verlauf verwenden.

Schritt 2. EC2-Anmeldedaten einrichten

Sobald Sie EC2 (S3)-Schlüssel für Ihren FRA1-1-Objektspeicher ordnungsgemäß eingerichtet haben, lassen Sie sich diese mit dem folgenden Befehl audgeben:

openstack ec2 credentials list

Schritt 3. Erstellen Sie einen neuen NooBaa-Backing Store

Nun können wir einen neuen NooBaa-Backing-Store namens custom-bs erstellen, indem wir den folgenden Befehl ausführen. Stellen Sie sicher, dass Sie den Access-Key XXXXXX und den Secret-Key YYYYYYY durch Ihre eigenen EC2-Schlüssel und den Bucket durch Ihren eigenen Bucket-Namen ersetzen:

noobaa -n noobaa backingstore create s3-compatible custom-bs --endpoint https://s3.fra1-1.cloudferro.com --signature-version v4 --access-key XXXXXX \
--secret-key YYYYYYY --target-bucket noobaademo-fra1-1

Beachten Sie, dass die Anmeldeinformationen als Kubernetes Secret im Namespace gespeichert werden. Sie können überprüfen, ob der Backing Store und das Secret erstellt wurden, indem Sie die folgenden Befehle ausführen:

kubectl get backingstore -n noobaa
kubectl get secret -n noobaa

Die Benennung der Artefakte folgt dem Namen des Backing Store, falls bereits mehrere solcher Ressourcen im namespace vorhanden sind.

Wenn wir uns den Bucket in Horizon (Backing Store) ansehen, können wir sehen, dass NooBaa seine Ordnerstruktur aufgefüllt hat:

../_images/image2023-7-20_11-58-221.png

Schritt 4. Erstellen einer Bucket-Klasse

Nach dem Backing Store erstellen wir eine BucketClass (BC). Eine solche BucketClass dient als Blaupause für NooBaa-Buckets: Sie definiert

  • welche(r) BackingStore(s) diese Buckets verwenden werden, und

  • welche Platzierungsstrategie im Falle von mehreren Bucket Stores verwendet werden soll.

Die Platzierungsstrategie kann Mirror oder Spread sein. Unterstützt werden mehrerer Ebenen, wobei die Daten standardmäßig in die erste Ebene verschoben werden und wenn diese voll ist, in die nächste.

Um eine BucketClass zu erstellen, bereiten Sie die folgende Datei custom-bc.yaml vor:

custom-bc.yaml

apiVersion: noobaa.io/v1alpha1
kind: BucketClass
metadata:
  labels:
    app: noobaa
  name: custom-bc
  namespace: noobaa
spec:
  placementPolicy:
    tiers:
    - backingStores:
      - custom-bs
      placement: Spread

Anschließend ausführen mit:

kubectl apply -f custom-bc.yaml

Schritt 5. Erstellen eines ObjectBucketClaims

Als letzten Schritt erstellen wir einen ObjectBucketClaim. Dieser Bucket Claim verwendet die noobaa.noobaa.io Speicherklasse, die mit NooBaa bereitgestellt wurde, und referenziert die im vorherigen Schritt erstellte custom-bc Bucket-Klasse. Erstellen Sie eine Datei namens custom-obc.yaml:

custom-obc.yaml

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: custom-obc
  namespace: noobaa
spec:
  generateBucketName: my-bucket
  storageClassName: noobaa.noobaa.io
  additionalConfig:
    bucketclass: custom-bc

Anschließend ausführen mit:

kubectl apply -f custom-obc.yaml

Schritt 6. Name des NooBaa-Buckets abfragen

Als Ergebnis wurden neben der ObjectBucket-Claim-Ressource auch eine Configmap und ein Secret mit demselben Namen custom-obc in NooBaa erstellt. Schauen wir uns die configmap an:

kubectl get configmap custom-obc -n noobaa -o yaml

Das Ergebnis ist ähnlich wie das folgende:

apiVersion: v1
data:
  BUCKET_HOST: s3.noobaa.svc
  BUCKET_NAME: my-bucket-7941ba4a-f57b-400a-b870-b337ec5284cf
  BUCKET_PORT: "443"
  BUCKET_REGION: ""
  BUCKET_SUBREGION: ""
kind: ConfigMap
metadata:
  ...

Wir sehen den Namen des NooBaa-Buckets my-bucket-7941ba4a-f57b-400a-b870-b337ec5284cf, das unser „physisches“ FRA1-1-Bucket sichert. Speichern Sie diesen Namen für die spätere Verwendung in diesem Artikel.

Schritt 7. Secret für den NooBaa-Bucket erhalten

Das Secret ist auch für uns relevant, da wir die S3-Schlüssel für den NooBaa-Bucket extrahieren müssen. Der Zugangs- und der Secret-Schlüssel sind im Secret base64-kodiert, wir können sie mit den folgenden Befehlen entschlüsselt abrufen:

kubectl get secret custom-obc -n noobaa -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 --decode
kubectl get secret custom-obc -n noobaa -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 --decode

Notieren Sie sich die Zugangs- und Secret-Schlüssel, da wir sie im nächsten Schritt verwenden werden.

Schritt 8. Verbinden mit NooBaa Bucket mit s3cmd

NooBaa hat bei der Bereitstellung ein paar Dienste erstellt, was wir mit dem folgenden Befehl überprüfen können:

kubectl get services -n noobaa

Die Ausgabe sollte in etwa so aussehen wie die folgende:

NAME           TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                                                    AGE
noobaa-db-pg   ClusterIP      10.254.158.217   <none>           5432/TCP                                                   3h24m
noobaa-mgmt    LoadBalancer   10.254.145.9     64.225.135.152   80:31841/TCP,443:31736/TCP,8445:32063/TCP,8446:32100/TCP   3h24m
s3             LoadBalancer   10.254.244.226   64.225.133.81    80:30948/TCP,443:31609/TCP,8444:30079/TCP,7004:31604/TCP   3h24m
sts            LoadBalancer   10.254.23.154    64.225.135.92    443:31374/TCP                                              3h24m

Der Dienst „s3“ stellt den Endpunkt zur Verfügung, über den auf den Nooba-Speicher zugegriffen werden kann (der durch den eigentlichen Speicher in FRA1-1 gesichert wird). In unserem Fall lautet die URL dieses Endpunkts 64.225.133.81. Ersetzen Sie ihn durch den Wert, den Sie mit dem obigen Befehl erhalten, wenn Sie diesen Artikel durcharbeiten.

Schritt 9. Konfigurieren Sie s3cmd für den Zugriff auf NooBaa

Da wir nun sowohl den Endpunkt als auch die Schlüssel haben, können wir s3cmd für den Zugriff auf den von NooBaa erstellten Bucket konfigurieren. Erstellen Sie eine Konfigurationsdatei noobaa.s3cfg mit folgendem Inhalt:

check_ssl_certificate = False
check_ssl_hostname = False
access_key = XXXXXX
secret_key = YYYYYY
host_base = 64.225.133.81
host_bucket = 64.225.133.81
use_https = True
verbosity = WARNING
signature_v2 = False

Führen Sie dann von der gleichen Stelle aus mit:

s3cmd --configure -c noobaa.s3cfg

Wenn s3cmd nicht auf Ihrem System installiert ist, siehe Voraussetzung Nr. 6.

Mit dem Befehl s3cmd können Sie jeden Wert aus der Konfigurationsdatei durch Drücken der Eingabetaste bestätigen und bei Abweichungen von der Standardeinstellung sofort ändern.

Das Ergebnis sollte ähnlich wie das folgende sein:

...
Success. Your access key and secret key worked fine :-)

Now verifying that encryption works...
Not configured. Never mind.

Save settings? [y/N] y
Configuration saved to 'noobaa.s3cfg'

Schritt 10. Testen des Zugriffs auf den Bucket

Wir können eine Testdatei auf NooBaa hochladen. In unserem Fall laden wir eine einfache Textdatei xyz.txt mit dem Textinhalt „xyz“ hoch, indem wir den folgenden Befehl verwenden:

s3cmd put xyz.txt s3://my-bucket-7941ba4a-f57b-400a-b870-b337ec5284cf -c noobaa.s3cfg

Die Datei wird korrekt hochgeladen:

upload: 'xyz.txt' -> 's3://my-bucket-7941ba4a-f57b-400a-b870-b337ec5284cf/xyz.txt'  [1 of 1]
 4 of 4   100% in    0s     5.67 B/s  done

In Horizon können wir auch sehen, dass einige neue Ordner und Dateien zu NooBaa hinzugefügt wurden. Allerdings wird die Datei xyz.txt dort nicht direkt angezeigt, da NooBaa seine eigenen Fragmentierungstechniken auf die Daten anwendet.