🥇Rook või mitte Rook — see on küsimus

Käesoleva kuu alguses, 3. mail, kuulutati välja suurem versioon "Kubernetesi jaotatud andmehoidlate haldussüsteemist" — Rook 1.0.0. Üle aasta tagasi avaldasime juba ülevaate Rookist. Siis paluti meil rääkida selle praktikas kasutamise kogemustest — ja nüüd, sellise olulise saavutuse eel, oleme rõõmsad, et saame jagada meie kogunenud muljeid.

Lühidalt öeldes on Rook komplekt operaatoreid Kubernetesile, mis võtab täielikult enda kanda selliste andmehoidlate nagu Ceph, EdgeFS, Minio, Cassandra, CockroachDB juurutamise, haldamise ja automaatse taastamise.

Praegu on kõige arenenum (ja ainus ühes stabiilne lahendus rook-ceph-operator.

Märkus: Rook 1.0.0 versioonis, mis on seotud Cephiga, on märkimisväärseteks muudatusteks Ceph Nautiluse toe lisamine ja NFS-i kasutamise võimalus CephFS- või RGW-ämbrite jaoks. Teistest on välja toodud EdgeFS toe "küpsus" betastasemeni.

Nii et selles artiklis me:

vastame küsimusele, millised plusspunkte näeme Rooki kasutamisest Cephi juurutamisel Kuberneteses;
jagame kogemusi ja muljeid Rooki kasutamisest tootmises;
Rääkime, miks me ütleme Rook'ile «Jah!» ja millised on meie plaanid selle kohta.

Alustame üldistest kontseptsioonidest ja teooriast.

«Mul on eelis ühe Rook'i üle!» (tundmatu malemängija)

Üks peamisi Rook'i eeliseid on see, et andmehoidlatega suhtlemine toimub läbi Kubernetes'e mehhanismide. See tähendab, et ei ole enam vaja kopeerida käske Ceph'i seadistamiseks paberilt konsooli.

— Tahad CephFS'i klastrisse paigaldada? Lihtsalt kirjuta YAML-fail!
— Mida? Tahad paigaldada ka object store'i S3 API-ga? Lihtsalt kirjuta teine YAML-fail!

Rook on loodud tüüpilise operaatori kõikide reeglite järgi. Suhtlemine selle kaudu toimub CRD (Custom Resource Definitions), milles kirjeldame meie jaoks vajalikud Ceph'i olendite omadused (kuna see on ainus stabiilne teostus, siis artiklis käsitletakse vaikimisi just Ceph'i, kui ei ole selgelt märgitud teisiti). Antud parameetrite põhjal täidab operaator automaatselt vajalikud seadistus käsud.

Konkreetseid asju vaatame objekti salvestamise loomise näitel, täpsemalt — 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 }}

Loetletud parameetrid on piisavalt standardsed ja ei vaja tõenäoliselt kommentaare, kuid tasub pöörata erilist tähelepanu nendele, mis on välja toodud malli muutujaidena.

Üldine tööschema on selline, et YAML-faili kaudu "tellime" ressursse, mille jaoks operaator täidab vajalikke käske ja tagastab meile "mitte päris tõelise" salajase, millega saame edasi töötada. (vt allpool). Ja eelpool toodud muutujaist koostatakse käsk ja salajase nimi.

Mis see käsk siis on? Objektipoe kasutaja loomisel täidab Rook-operaator pod'is järgmist:

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

Selle käsu täitmise tulemusena saadakse JSON-struktuur:

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

Võtmed — see, mida rakendused vajavad tulevikus objektide salvestamiseks juurdepääsu saamiseks S3 API kaudu. Rook-operaator valib need hoolikalt ja salvestab need oma namespace'is salajana nimega rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Selle salajase info kasutamiseks tuleb see konteinerisse lisada keskkonnamuutujatena. Näitena toon ülesande (Job) malli, milles automaatselt loome iga kasutaja keskkonna jaoks bucket'id:

{{- 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 }}

Kõik selles töös loetletud tegevused on teostatud Kubernetes'e piires. YAML-failides kirjeldatud struktuurid on salvestatud Git-reposiitosse ja neid on kasutatud mitu korda. See on suur pluss DevOps-inseneridele ja CI/CD protsessile üldiselt.

Rook ja Rados toovad rõõmu

Ceph + RBD kombinatsiooni kasutamine seab teatud piirangud volüümide mount'imisele pod'idesse.

Eelkõige peab namespace'is olema salajane võtmefail Ceph'i ligipääsu jaoks, et stateful-rakendused saaksid toimida. Kui teil on oma nimeserverites 2-3 keskkonda, on tõenäoliselt normaalne, et saate salajase võtme käsitsi kopeerida. Kuid mis juhtub, kui iga funktsiooni jaoks luuakse arendajatele eraldi keskkond koos oma namespace'iga?

Me lahendasime selle probleemi shell-operator, mis kopeeris automaatselt saladused uutesse namespace'idesse (sarnase hook'i näide on kirjeldatud selles artiklis).

#! /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

Kuid Rook'i kasutamisel ei eksisteeri seda probleemi. Mountimisprotsess toimub oma püsivaatede draiverite abil, mis põhinevad Flexvolume või CSI (praegu beetastaadiumis) ja seetõttu ei nõua salasõnu.

Rook lahendab automaatselt mitmeid probleeme, mis kutsub meid üles seda uutes projektides kasutama.

Rooki piiramine

Keskendume praktilisele osale, paigaldades Rooki ja Cephi, et saaksime teha oma katseid. Selle raske kindluse vallutamiseks on arendajad ette valmistanud Helm-paketi. Laadime selle alla:

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

Failis rook-ceph/values.yaml on palju erinevaid seadeid. Kõige olulisem on määrata toleratsioonid agentide ja otsimise jaoks. Kuidas kasutada taintide/toleratsioonide mehhanismi, oleme üksikasjalikult kirjeldanud selles artiklis.

Lühidalt öeldes ei soovi me, et klientrakenduse pod’d asuksid samades sõlmedes, kus asuvad andmete salvestamise kettad. Põhjus on lihtne: nii ei mõjutaks Rooki agentide töö ise rakendust.

Nii et avame faili rook-ceph/values.yaml oma lemmikredaktoris ja lisame lõpuks järgmise ploki:

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

Iga andmete salvestamise jaoks reserveeritud sõlme kohta lisame vastava tainti:

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

Pärast seda paigaldame Helm-chart käsklusega:

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

Nüüd tuleb luua klaster ja määrata asukoht 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"

Kontrollime Ceph'i olekut — ootame, et näha HEALTH_OK:

$ 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

Samuti kontrollime, et klientrakendustega pod'id ei satuks Ceph'i reserveeritud sõlmedesse:

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

Edasi, soovi korral, seadistatakse täiendavad komponendid. Täiendavad üksikasjad on kirjeldatud dokumentatsioonis. Halduseks soovitame tungivalt installida dashboard'i ja toolbox'i.

Rook'ide konksid: kas Rook'ist piisab kõigist vajadustest?

Nagu näha, on Rook'i arendamine täies hoos. Kuid veel on probleeme, mis ei luba meil Cephi täielikult käsitsi seadistamisest loobuda:

Ükski Rook'i draiver ei oska eksportida kasutatud blokimahtude metrikaid, mis jätab meid jälgimisest ilma.
Flexvolume ja CSI ei oska mahu suurust muuta (erinevalt RBD-st), seetõttu jääb Rook ilma kasulikust (mõnikord ka kriitiliselt vajalikust!) tööriistast.
Rook ei ole endiselt nii paindlik kui tavaline Ceph. Kui soovime konfigureerida, et CephFSi metaandmete bassein salvestatakse SSD-le ja ise andmed HDD-le, tuleb CRUSH kaardile käsitsi eraldi seadmegrupid kirjutada.
Hoolimata sellest, et rook-ceph-operatorit peetakse stabiilseks, on hetkel teatud probleemid Cephi värskendamisega versioonilt 13 versioonile 14.

Järeldused

„Praegu on Laev välismaailma käkitehnikute poolt suletud, kuid usume, et ühel päeval mängib see mängus otsustavat rolli!” (tsitaat on loodud spetsiaalselt selle artikli jaoks)

Projekt Rook on kahtlemata meie südamed võitnud — usume, et [kõikide oma plusse ja miinuseid] väärib see kindlasti ka teie tähelepanu.

Meie edasised plaanid on suunatud sellele, et muuta rook-ceph mooduliks addon-operator, mis muudab selle kasutamise meie paljusid Kubernetesi klastreid veelgi lihtsamaks ja mugavamaks.