Rook vagy nem Rook – ez itt a kérdés

E hónap elején, május 3-án bejelentésre került a "Kubernetes elosztott adattároló rendszerének kezelője" nevezetű jelentős kiadás — Rook 1.0.0. Több mint egy évvel ezelőtt már közzétettük a Rook általános áttekintését. Akkoriban arra kértetek minket, hogy meséljünk a tapasztalatainkról a gyakorlatban történő használatról — és éppen itt az ideje, hogy egy ilyen jelentős mérföldkőhöz eljussunk a projekt történetében, örömmel osztjuk meg az összegyűjtött tapasztalatainkat.

Röviden, a Rook egy olyan operátorokkal készlet Kuberneteshez, amely teljes mértékben átvállalja az adattároló megoldások telepítését, kezelését, automatikus helyreállítását, mint például a Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Jelenleg a legfejlettebb (és egyetlen be. stabil stádium) megoldás a rook-ceph-operator.

Megjegyzés: a Rook 1.0.0 kiadásának jelentős változásai között, amelyek a Ceph-hez kapcsolódnak, megemlíthető a Ceph Nautilus támogatása és a NFS használatának lehetősége CephFS- vagy RGW-bucketekhez. További kiemelhető, hogy az EdgeFS támogatása a béta szintre "érett".

Tehát ebben a cikkben:

• válaszolunk arra a kérdésre, milyen előnyöket látunk a Rook használatában a Ceph Kubernetes klaszterben való telepítésénél;
• megosztjuk tapasztalatainkat és benyomásainkat a Rook productionban való használatával kapcsolatban;
• elmondjuk, miért mondunk „Igen!” a Rooknak, és milyen terveink vannak vele kapcsolatban.

Kezdjük az általános fogalmakkal és elmélettel.

„Előnyöm van egy Bástyával!” (ismeretlen sakkjátékos)

A Rook egyik legfőbb előnye, hogy az adattárolókkal való interakció a Kubernetes mechanizmusain keresztül történik. Ez azt jelenti, hogy már nem kell parancsokat másolni a Ceph beállításához a papírról a konzolra.

— Szeretnél CephFS-t telepíteni a klaszterbe? Csak írj egy YAML-fájlt!
— Mi? Szeretnél egy S3 API-val rendelkező objektumtárat is telepíteni? Csak írj egy második YAML-fájlt!

A Rookot a tipikus operátorok minden szabálya szerint tervezték. Az interakció a CRD (Egyedi Erőforrás Definíciók)segítségével történik, amiben leírjuk a szükséges Ceph entitások jellemzőit (mivel ez az egyetlen stabil megvalósítás, az írás során alapértelmezés szerint a Cephről lesz szó, ha kifejezetten nem más). A megadott paraméterek szerint az operátor automatikusan végrehajtja a szükséges beállító parancsokat.

A konkrétumokat nézzük meg egy Object Store létrehozásának példáján, pontosabban — CephObjectStoreUser.

apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  metadataPool:
    failureDomain: host
    replicated:
      size: 3
  dataPool:
    failureDomain: host
    erasureCoded:
      dataChunks: 2
      codingChunks: 1
  gateway:
    type: s3
    sslCertificateRef:
    port: 80
    securePort:
    instances: 1
    allNodes: false
---
apiVersion: ceph.rook.io/v1
kind: CephObjectStoreUser
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  store: {{ .Values.s3.crdName }}
  displayName: {{ .Values.s3.username }}

A felsorolt paraméterek eléggé standardnak számítanak, és valószínűleg nem igényelnek további magyarázatot, de érdemes külön figyelmet fordítani azokra, amelyeket sablonváltozókba emeltek.

A munka általános sémája abban áll, hogy a YAML-fájl segítségével "megrendeljük" az erőforrásokat, amire az operátor végrehajtja a szükséges parancsokat, és visszaad nekünk egy "nem teljesen tényleges" titkot, amivel további műveleteket végezhetünk. (see below). A fent említett változók alapján előállításra kerül egy parancs és egy titkos név.

Mi is az a parancs? Az Rook-operator a podban végrehajtja a következőt egy objektumtároló felhasználó létrehozásakor:

radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}"

A parancs végrehajtásának eredményeként egy JSON-struktúra keletkezik:

{
    "user_id": "rook-user",
    "display_name": "{{ .Values.s3.username }}",
    "keys": [
        {
           "user": "rook-user",
           "access_key": "NRWGT19TWMYOB1YDBV1Y",
           "secret_key": "gr1VEGIV7rxcP3xvXDFCo4UDwwl2YoNrmtRlIAty"
        }
    ],
    ...
}

Kulcsok — ezek szükségesek lesznek a jövőben az alkalmazások számára, hogy hozzáférjenek az objektumtárolóhoz az S3 API-n keresztül. A Rook-operator kedvesen kiválasztja őket, és a saját namespace-ében tárolja titkos név alatt: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

A titkos adatok felhasználásához elegendő egyszerűen hozzáadni őket a konténerhez környezeti változókként. Például itt egy sablon a Job-hoz, amely automatikusan létrehozza a bucketeket minden felhasználói környezethez:

{{- range $bucket := $.Values.s3.bucketNames }}
apiVersion: batch/v1
kind: Job
metadata:
  name: create-{{ $bucket }}-bucket-job
  annotations:
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "2"
spec:
  template:
    metadata:
      name: create-{{ $bucket }}-bucket-job
    spec:
      restartPolicy: Never
      initContainers:
      - name: waitdns
        image: alpine:3.6
        command: ["/bin/sh", "-c", "while ! getent ahostsv4 rook-ceph-rgw-{{ $.Values.s3.crdName }}; do sleep 1; done" ]
      - name: config
        image: rook/ceph:v1.0.0
        command: ["/bin/sh", "-c"]
        args: ["s3cmd --configure --access_key=$(ACCESS-KEY) --secret_key=$(SECRET-KEY) -s --no-ssl --dump-config | tee /config/.s3cfg"]
        volumeMounts:
        - name: config
          mountPath: /config
        env:
        - name: ACCESS-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: AccessKey
        - name: SECRET-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: SecretKey
      containers:
      - name: create-bucket
        image: rook/ceph:v1.0.0
        command: 
        - "s3cmd"
        - "mb"
        - "--host=rook-ceph-rgw-{{ $.Values.s3.crdName }}"
        - "--host-bucket= "
        - "s3://{{ $bucket }}"
        ports:
        - name: s3-no-sll
          containerPort: 80
        volumeMounts:
        - name: config
          mountPath: /root
      volumes:
      - name: config
        emptyDir: {}
---
{{- end }}

Minden cselekvés, amely a Job-ban szerepel, a Kubernetes keretein belül történt. Az YAML-fájlokban leírt struktúrák Git-tárolóba vannak mentve és többször újra felhasználva. Ebben hatalmas előny rejlik a DevOps mérnökök és a CI/CD folyamat számára is.

A Rook és a Rados együttes használata örömet okoz.

A Ceph + RBD kombináció használata bizonyos korlátozásokat jelent a kötetek pod-hoz történő csatlakoztatásában.

Különösen fontos, hogy a namespace-ben legyen egy titkos kulcs a Ceph-hez való hozzáféréshez, hogy a stateful alkalmazások működhessenek. Normális, ha 2-3 környezet van az ön névtérben: akkor át lehet másolni a titkos kulcsot manuálisan. De mi a helyzet akkor, ha minden fejlesztő számára külön környezet jön létre saját névtérrel?

Nálunk ezt a problémát a következővel oldottuk meg Stolon;, amely automatikusan másolta a titkos kulcsokat az új névterekbe (egy hasonló hook leírása található a cikkben).

#! /bin/bash

if [[ $1 == “--config” ]]; then
   cat <<EOF
{"onKubernetesEvent":[
 {"name": "OnNewNamespace",
  "kind": "namespace",
  "event": ["add"]
  }
]}
EOF
else
    NAMESPACE=$(kubectl get namespace -o json | jq '.items | max_by( .metadata.creationTimestamp ) | .metadata.name')
    kubectl -n ${CEPH_SECRET_NAMESPACE} get secret ${CEPH_SECRET_NAME} -o json | jq ".metadata.namespace="${NAMESPACE}"" | kubectl apply -f -
fi

Azonban a Rook használatakor ez a probléma egyszerűen nem létezik. A csatlakozási folyamat a Flexvolume vagy CSI (jelenleg béta állapotban) alapú saját illesztőprogramokon keresztül történik, így nem igényel titkos kulcsokat.

A Rook automatikusan sok problémát megold, ami arra ösztönöz minket, hogy új projektekben használjuk.

A Rook ostroma

Fejezzük be a gyakorlati részét a Rook és Ceph telepítésével, hogy lehetőségünk legyen saját kísérleteink végrehajtására. Annak érdekében, hogy könnyebben meghódíthassuk ezt a megerősített tornyot, a fejlesztők Helm-csomagot készítettek elő. Töltsük le:

$ helm fetch rook-master/rook-ceph --untar --version 1.0.0

A fájlban rook-ceph/values.yaml számos különböző beállítást találhatunk. A legfontosabb az, hogy megadjuk a tolerálásokat az ügynökök és a keresés számára. A taints/tolerations mechanizmusról részletesen beszéltünk a cikkben.

Röviden, nem akarjuk, hogy a kliens alkalmazások podjai azokon a csomópontokon helyezkedjenek el, ahol az adatok tárolására szolgáló lemezek találhatók. Az ok egyszerű: így a Rook ügynökök működése nem befolyásolja magát az alkalmazást.

Tehát nyissuk meg a fájlt rook-ceph/values.yaml a kedvenc szerkesztőnkben, és adjuk hozzá a következő blokkot a végére:

discover:
  toleration: NoExecute
  tolerationKey: node-role/storage
agent:
  toleration: NoExecute
  tolerationKey: node-role/storage
  mountSecurityMode: Any

Minden olyan csomóponthoz, amelyet adatok tárolására fenntartunk, adjunk hozzá a megfelelő taint-et:

$ kubectl taint node ${NODE_NAME} node-role/storage="":NoExecute

Ezután telepítsük a Helm chart-ot a következő paranccsal:

$ helm install --namespace ${ROOK_NAMESPACE} ./rook-ceph

Most létre kell hozni a klasztert és meg kell adni a helyet OSD:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  clusterName: "ceph"
  finalizers:
  - cephcluster.ceph.rook.io
  generation: 1
  name: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v13
  dashboard:
    enabled: true
  dataDirHostPath: /var/lib/rook/osd
  mon:
    allowMultiplePerNode: false
    count: 3
  network:
    hostNetwork: true
  rbdMirroring:
    workers: 1
  placement:
    all:
      tolerations:
      - key: node-role/storage
        operator: Exists
  storage:
    useAllNodes: false
    useAllDevices: false
    config:
      osdsPerDevice: "1"
      storeType: filestore
    resources:
      limits:
        memory: "1024Mi"
      requests:
        memory: "1024Mi"
    nodes:
    - name: host-1
      directories:
      - path: "/mnt/osd"
    - name: host-2
      directories:
      - path: "/mnt/osd"
    - name: host-3
      directories:
      - path: "/mnt/osd"

Ellenőrizzük a Ceph állapotát — azt várjuk, hogy lássuk Ellenőrizzük a képeket a tárolóban::

$ kubectl -n ${ROOK_NAMESPACE} exec $(kubectl -n ${ROOK_NAMESPACE} get pod -l app=rook-ceph-operator -o name -o jsonpath='{.items[0].metadata.name}') -- ceph -s

Egyúttal ellenőrizzük, hogy a kliens alkalmazások podjai nem kerülnek a Ceph számára fenntartott csomópontokra:

$ kubectl -n ${APPLICATION_NAMESPACE} get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName

Ezután opcionálisan beállíthatjuk a további komponenseket. További részletekért lásd dokumentáció. Adminisztrációhoz erősen ajánlott a dashboard és a toolbox telepítése.

Rook-horgok: elegendő-e a Rook mindenre?

Ahogyan látható, a Rook fejlesztése teljes gőzzel zajlik. De még mindig vannak problémák, amelyek megakadályozzák, hogy teljesen elhagyjuk a Ceph manuális beállítását:

• Egyetlen Rook meghajtó nem tud metrikákat exportálni a csatolt blokkok használatáról, ami megfoszt minket a monitoring lehetőségétől.
• A Flexvolume és a CSI nem képes nem tudja módosítani a kötetek méretét (ellentétben az RBD-vel), ezért a Rook hasznos (és néha kritikus fontosságú!) eszköztől esik el.
• A Rook még mindig nem annyira rugalmas, mint a klasszikus Ceph. Ha azt akarjuk, hogy a CephFS metadat pool SSD-n tárolódjon, míg az adatok HDD-n, külön eszközcsoportokat kell kézzel beírni a CRUSH térképekbe.
• Bár a rook-ceph-operator stabilnak számít, jelenleg bizonyos problémák állnak fenn a Ceph 13-ról 14-re történő frissítésekor.

Következtetések

„Jelenleg a Rook zárva van a külső világ előtt gyalogosok által, de hisszük, hogy egyszer döntő szerepet fog játszani a mérkőzésben!” (idézet, amelyet kifejezetten ehhez a cikkhez találtunk ki)

A Rook projekt kétségtelenül meghódította a szívünket – úgy véljük, hogy [minden előnyével és hátrányával] biztosan megérdemli az Ön figyelmét is.

A további terveink pedig az, hogy a rook-ceph-et modulként készítjük el a addon-operator, ami még egyszerűbbé és kényelmesebbé teszi a használatát számos Kubernetes klaszterünkben.

P.S.

Olvasson további információkat a blogunkban:

• «A Rook egy „önkiszolgáló” adattároló Kubernetes számára»;
• «Tartós tárolás létrehozása provisioning-gal Kubernetes alatt Ceph alapján»;
• «Adatbázisok és Kubernetes (áttekintés és videóelőadás)»;
• «Bemutatjuk a shell-operator-t: a Kubernetes operátorok létrehozása még egyszerűbbé vált»;
• «Operátorok a Kubernetes számára: hogyan indítsunk el stateful alkalmazásokat».

Forrás: habr.com