Instalacja i uruchomienie NooBaa na klastrze Kubernetes w środowisku NSIS Cloud z jedną chmurą

NooBaa umożliwia utworzenie uogólnionego zaplecza S3 na Kubernetesie. Takie zaplecze może być połączone z wieloma magazynami S3, np. w konfiguracji multi-cloud, co pozwala m.in. na skalowalność przestrzeni dyskowej lub wysoką dostępność, a także inne korzystne funkcje.

W tym artykule poznasz podstawy korzystania z NooBaa:

jak zainstalować go na klastrze Kubernetes,

jak utworzyć bucket NooBaa oparty o magazyn obiektowy S3 w chmurze NSIS Cloud,

jak utworzyć bucket NooBaa, który będzie replikował dane pomiędzy dwiema różnymi chmurami.

Co będziemy omawiać

Instalacja NooBaa w środowisku lokalnym,

Zastosowanie wstępnej konfiguracji,

Instalacja NooBaa na klastrze Kubernetes,

Utworzenie zaplecza (backing store) dla NooBaa,

Utworzenie klasy bucketów (Bucket Class),

Utworzenie ObjectBucketClaim,

Połączenie się z bucketem NooBaa przy pomocy S3cmd,

Testowanie dostępu do bucketa.

Wymagania wstępne

Nr 1 Hosting

Potrzebujesz konta hostingowego NSIS Cloud z interfejsem Horizon https://horizon.cloudferro.com.

Nr 2 Dostęp do klastra Kubernetes

Klastra w chmurze NSIS, na którym uruchomimy instalację NooBaa – postępuj zgodnie z wytycznymi w tym artykule Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum.

Nr 3 Znajomość korzystania z Object Storage

Więcej informacji znajdziesz w Jak korzystać z Object Storage w NSIS

Tradycyjny termin OpenStack dla importowanych lub pobranych plików to Containers w głównym menu Object Store. W tym artykule będziemy używać terminu „bucket” dla kontenerów object storage, aby odróżnić je od kontenerów w sensie Docker/Kubernetes.

Nr 4 kubectl działający operacyjnie

Narzędzie CLI kubectl zainstalowane i wskazujące na twój klaster poprzez zmienną środowiskową KUBECONFIG – więcej informacji znajdziesz w Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.

Nr 5 Dostęp do prywatnych kluczy S3

Możesz również użyć dostępu do CLI OpenStack, aby wygenerować i odczytać prywatne klucze S3 – Jak wygenerować poświadczenia EC2 i zarządzać nimi na NSIS Cloud.

Nr 6 Znajomość narzędzia s3cmd do dostępu do Object Storage

Więcej informacji o s3cmd znajdziesz w Jak uzyskać dostęp do object storage z NSIS za pomocą s3cmd.

Instalacja NooBaa w środowisku lokalnym

Pierwszym krokiem do pracy z NooBaa jest jego instalacja w lokalnym systemie. Pobierzemy instalator, nadamy mu prawa do uruchamiania i przeniesiemy go do ścieżki systemowej:

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

Podaj hasło użytkownika root, jeśli zostaniesz o to poproszony.

Po wykonaniu tej sekwencji kroków powinno być możliwe uruchomienie polecenia testowego:

noobaa help

Wynik będzie podobny do poniższego:

Zastosowanie wstępnej konfiguracji

Będziemy musieli zastosować dodatkową konfigurację na klastrze Magnum, aby uniknąć wyjątku PodSecurityPolicy.

Na początek utwórz dedykowaną przestrzeń nazw dla artefaktów NooBaa:

kubectl create namespace noobaa

Następnie utwórz plik noobaa-rolebinding.yaml z następującą zawartością:

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

i zastosuj poleceniem:

kubectl apply -f noobaa-rolebinding.yaml

Instalacja NooBaa na klastrze Kubernetes

NooBaa mamy już dostępny w naszym środowisku lokalnym, ale musimy go jeszcze zainstalować na klastrze Kubernetes. NooBaa użyje kontekstu KUBECONFIG poprzez kubectl (aktywowanego w Wymaganiu nr 4), więc zainstaluj NooBaa w dedykowanej przestrzeni nazw:

noobaa install -n noobaa

Po kilku minutach NooBaa zostanie zainstalowany i wyświetli dodatkowe informacje o konfiguracji. Sprawdź status NooBaa poleceniem:

noobaa status -n noobaa

Polecenie to wyświetla kilka przydatnych informacji o instalacji NooBaa, z których „najważniejsze fakty” znajdują się pod koniec statusu:

NooBaa utworzył domyślne zaplecze noobaa-default-backing-store, oparte na wolumenie blokowym utworzonym w OpenStack.

Dostarczono dane uwierzytelniające S3 do uzyskania dostępu do bucketa utworzonego z tym domyślnym zapleczem. Takie zaplecze oparte na wolumenach może być przydatne np. przy wykorzystaniu metody dostępu S3 do naszego block storage.

Na potrzeby tego artykułu nie będziemy korzystać z domyślnego zaplecza, lecz nauczymy się tworzyć nowe zaplecze oparte na chmurowym magazynie obiektowym S3. Taki układ można następnie łatwo rozszerzyć, tak aby korzystać z oddzielnych zapleczy w różnych chmurach.

Utworzenie zaplecza NooBaa (backing store)

Krok 1. Utworzenie bucketa Object Storage w chmurze NSIS

Teraz utwórz bucket Object Storage w chmurze NSIS:

przejdź do Horizon,

wybierz opcje Object Store –> Containers –> + Container, aby utworzyć nowy bucket.

Bucket w chmurze NSIS muszą mieć unikalne nazwy. W naszym przypadku używamy nazwy noobaademo-fra-1, której będziemy używać w całym artykule.

Informacja

Musisz utworzyć bucket o innej nazwie i używać tej wygenerowanej nazwy w trakcie realizacji artykułu.

Krok 2. Skonfiguruj dane uwierzytelniające EC2

Jeśli masz poprawnie skonfigurowane klucze EC2 (S3) dla swojego Object Storage NSIS, odczytaj je poleceniem:

openstack ec2 credentials list

Krok 3. Utwórz nowe zaplecze NooBaa

Mając powyższe dane, możemy utworzyć nowe zaplecze NooBaa o nazwie custom-bs za pomocą poniższego polecenia. Upewnij się, że podmienisz access-key XXXXXX i secret-key YYYYYYY na swoje własne klucze EC2 oraz bucket na własną nazwę bucketa:

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

Dane uwierzytelniające są przechowywane jako sekret Kubernetes w przestrzeni nazw. Możesz sprawdzić, czy zaplecze i sekret zostały utworzone poleceniami:

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

Nazewnictwo artefaktów będzie odpowiadało nazwie zaplecza, na wypadek gdyby w przestrzeni nazw było już więcej takich zasobów.

Przeglądając bucket w Horizon (backing store), możemy zobaczyć, że NooBaa utworzył w nim swoją strukturę folderów:

Krok 4. Utwórz Bucket Class

Gdy mamy już zaplecze, kolejnym krokiem jest utworzenie BucketClass (BC). Taki BucketClass służy jako wzorzec dla bucketów NooBaa: definiuje

które BackingStore będą używane przez te buckety,

jaką strategię rozmieszczania (placement) stosować w przypadku wielu zapleczy.

Strategia rozmieszczania może być Mirror lub Spread. Istnieje także obsługa wielu poziomów (tiers), gdzie dane są domyślnie zapisywane do pierwszego poziomu, a gdy się on zapełni – do kolejnego.

Aby utworzyć BucketClass, przygotuj plik custom-bc.yaml:

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

Następnie zastosuj go poleceniem:

kubectl apply -f custom-bc.yaml

Krok 5. Utwórz ObjectBucketClaim

Ostatnim krokiem jest utworzenie ObjectBucketClaim. Ten bucket claim wykorzystuje storage class noobaa.noobaa.io, który został wdrożony wraz z NooBaa, i odwołuje się do bucket class custom-bc utworzonego w poprzednim kroku. Utwórz plik o nazwie 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

Następnie zastosuj go poleceniem:

kubectl apply -f custom-obc.yaml

Krok 6. Uzyskaj nazwę bucketa NooBaa

W wyniku, oprócz zasobu ObjectBucketClaim, utworzone zostały także configmap i sekret o tej samej nazwie custom-obc w NooBaa. Zobacz configmap poleceniem:

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

Wynik będzie podobny do poniższego:

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:
  ...

Widzimy nazwę bucketa NooBaa my-bucket-7941ba4a-f57b-400a-b870-b337ec5284cf, który jest powiązany z naszym „fizycznym” bucketem NSIS. Zapisz tę nazwę do późniejszego użycia.

Krok 7. Uzyskaj sekret dla bucketa NooBaa

Sekret jest również istotny, ponieważ musimy wyodrębnić z niego klucze S3 dla bucketa NooBaa. Klucz dostępowy i tajny są zakodowane base64 w sekrecie, możemy je odczytać poleceniami:

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

Zanotuj klucz dostępowy i tajny, ponieważ będziemy ich potrzebować w następnym kroku.

Krok 8. Połącz się z bucketem NooBaa przy użyciu S3cmd

NooBaa utworzył kilka usług podczas wdrożenia, co możemy zweryfikować poleceniem:

kubectl get services -n noobaa

Wynik powinien wyglądać podobnie do poniższego:

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

Usługa „s3” zapewnia endpoint, który można wykorzystać do dostępu do pamięci NooBaa (z tyłu obsługiwanej przez rzeczywiste storage w chmurze NSIS). W naszym przypadku ten endpoint to 64.225.133.81. Zastąp go wartością, którą uzyskasz z powyższego polecenia, realizując ten artykuł.

Krok 9. Skonfiguruj S3cmd do dostępu do NooBaa

Mając zarówno endpoint, jak i klucze, możemy skonfigurować s3cmd do dostępu do bucketa utworzonego przez NooBaa. Utwórz plik konfiguracyjny noobaa.s3cfg z następującą zawartością:

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

Następnie z tego samego katalogu zastosuj polecenie:

s3cmd --configure -c noobaa.s3cfg

Jeśli s3cmd nie jest zainstalowany w twoim systemie, zobacz Wymaganie nr 6.

Polecenie s3cmd pozwoli ci zatwierdzić Enterem każdą wartość z pliku konfiguracyjnego i zmienić ją w locie, jeśli różni się od domyślnej.

Pomijając te pytania w wyniku, efekt powinien być podobny do poniższego:

...
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'

Krok 10. Testowanie dostępu do bucketa

Możemy przesłać testowy plik do NooBaa. W naszym przypadku przesyłamy prosty plik tekstowy xyz.txt z treścią „xyz”, używając polecenia:

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

Plik zostaje poprawnie przesłany:

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

Możemy także zobaczyć w Horizon, że do NooBaa zostało dodanych kilka nowych folderów i plików. Nie zobaczymy jednak pliku xyz.txt bezpośrednio tam, ponieważ NooBaa stosuje własne techniki fragmentacji danych.