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

Käesoleva kuu alguses, 3. mail, kuulutati välja oluline versioon "andmete jaotustehnoloogiate haldamise süsteem Kuberneteses" — Rook 1.0.0. Üks aasta tagasi avaldasime me juba ülevaate Rookist. Sel ajal paluti meil rääkida kogemustest selle kasutamisel praktikas — ja just selle tähtsa verstpalu puhul oleme rõõmsad, et saame jagada omandatud muljeid. Kokkuvõttes esindab Rook komplekti

operaatoreid Kuberneteses, mis võtavad täieliku kontrolli andmesalvestuslahenduste, näiteks Ceph, EdgeFS, Minio, Cassandra, CockroachDB, deploymente, haldamist ja automaatset taastamist. Praegu on kõige arenenum (ja

ainus stabiilse ja faasi) lahendus : Rook 1.0.0 versiooniga seonduvatest olulisest muudatustest Cephiga seoses võib märkida Ceph Nautiluse toetuse ja NFS-i kasutamise võimaluse CephFS- või RGW-konteinerites. Teiste hulgas on silma jääb EdgeFS toe "küpsemine" beta tasemele. rook-ceph-operator.

MärkusNii et selles artiklis me:

vastame küsimusele, millised eelised me näeme Rooki kasutamisel Ceph käitamisel Kubernetes klastris;

• jagame kogemusi ja muljeid Rooki kasutamisest tootmises;
• räägime, miks me ütlevad Rookile "Jah!" ja millised on meie plaanid selle osas.
• Alustame üldiste mõistete ja teooriaga.

"Mul on eelis ühe Torniga!" (tundmatu maletaja)

Üks Rooki peamisi eeliseid on see, et andmesalvestuse haldamine toimub Kuberneteses toimivate mehhanismide kaudu. See tähendab, et ei ole enam vaja käske Ceph’i seadmiseks paberilt konsooli kopeerida.

— Tahad klastrisse CephFS paigaldada? Kirjutage lihtsalt YAML-fail!

— Mis? Tahad paigaldada ka objektide salvestamise süsteemi S3 API-ga? Kirjutage lihtsalt teine YAML-fail!
Rook on loodud vastavalt tüüpilise operaatori reeglitele. Koostöö toimub

CRD (Custom Resource Definitions) , milles kirjeldame vajalikud Ceph'i üksuste omadused,(kuna see on ainus stabiilne rakendus, siis artiklis käsitletakse eelkõige Ceph'i, kui ei öelda teisiti) . Vastavalt antud parameetritele viib operaator automaatselt läbi vajalikud seadistuskorraldused.Konkreetsemalt vaatame, kuidas luua Object Store'i, täpsemalt —

CephObjectStoreUser 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 ning ei vaja tõenäoliselt täiendavat kommentaari, kuid tasub pöörata erilist tähelepanu neile, mis on esitatud mallimuutujates.

Üldine tööskeem näeb ette, et YAML-faili kaudu „tellime“ ressursid, millega operaator täidab vajalikud käsud ning tagastab meile „mitte kõige tõelisema“ salajase, millega saame edaspidi töötada. (vt allpool). Ja eespool kasutatud muutujatest koostatakse käsk ja saladuse nimi.

Milline käsk see on? Rook-operatori poolt objekti salvestuse kasutaja loomise käigus täidab pod'is järgmise:

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

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

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

Võtmed — need on vajalikud tulevikus rakendustele, et pääseda objekti salvestusele ligi S3 API kaudu. Rook-operator valib need ja salvestab oma namespace'is saladusena nimega rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Selle saladuse andmete kasutamiseks piisab nende lisamisest konteinerisse keskkonnamuutujatena. Näiteks toon välja malli Job'ile, mille käigus loome automaatselt bucket'e iga kasutaja keskkonna jaoks:

{{- 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 selle Job'i tegevused toimusid, jäädes Kubernetesi piiridesse. YAML-failides kirjeldatud struktuurid on kogutud Git-repositoriumi ja neid on korduvalt uuesti kasutatud. Näeme selles suurt eelist DevOps-inseneridele ja CI/CD protsessile üldiselt.

Rook ja Rados toovad rõõmu

Ceph + RBD kombinatsiooni kasutamine seab teatud piirangud mahtude mountimisele pod'idesse.

Eelkõige peab namespace'is olema saladus Ceph'i ligipääsu jaoks, et stateful-rakendused saaksid funktsioneerida. On okei, kui sul on 2-3 keskkonda oma nimede ruumides: saad minna ja kopeerida saladuse käsitsi. Aga mis teha, kui iga arendaja funktsionaalsuse jaoks luuakse eraldi keskkond oma nime ruumis?

Me lahendasime selle probleemi shell-operator, mis kopeeris saladused automaatselt uutesse nime ruumidesse (näidis sellisest nahast 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. Mountimise protsess toimub selle enda draiverite abil Flexvolume või on nüüd saadaval (alfa-versioonis) (praegu beetastaadiumis) ja seetõttu ei vaja saladusi.

Rook lahendab automaatselt paljusid probleeme, mis kutsub meid seda kasutada uutes projektides.

Rook'i rünnak

Lõpetame praktilise osa Rook'i ja Ceph'i juurutamisega, et saaksime oma katseid läbi viia. Selle müüri vallutamine on lihtsam, kui arendajad on ette valmistanud Helm-paketi. Laadime selle alla:

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

Failis rook-ceph/values.yaml võib leida palju erinevaid sätteid. Kõige olulisem on välja tuua tolerations agentide ja otsimise jaoks. Kuidas saame kasutada taintide/toleratsioonide mehhanismi, oleme põhjalikult arutanud selles artiklis.

Lühidalt, me ei soovi, et kliendi rakenduse pod'id asuksid samadel sõlmedel, kus asuvad andmete salvestamise kettad. Põhjus on lihtne: nii ei mõjuta Rook'i agentide töö ise rakendust.

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

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

Iga andmete salvestamiseks reserveeritud sõlme jaoks lisame vastava tainti:

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

Pärast seda installime Helm-chart'i käsuga:

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

Nüüd on vaja 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 Cephi olekut — ootame, et näeme 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 kliendi rakenduse pod'id ei satuks Ceph'e jaoks reserveeritud sõlmedele:

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

Edasi on soovi korral võimalik seadistada täiendavaid komponente. Rohkem teavet nende kohta on esitatud dokumentatsioon. Halduseks soovitame tungivalt installida armatuurlaua ja tööriistakasti.

Rook'i-hübrid: kas Rook'ist jätkub?

Nagu näha, Rooki arendamine käib täie hooga. Kuid endiselt on probleeme, mis takistavad meil täielikult loobuda Cephi käsitsi seadistamisest:

• Ükski Rooki draiver ei oska eksporteerida kinnitatud blokke kasutamise mõõdikut, mis võtab meilt jälgimise võimaluse.
• Flexvolume ja CSI ei oska mahu suurust muuta (erinevalt RBD-st), seega jääb Rook ilma kasulikust (mõnikord isegi kriitiliselt vajalikust!) tööriistast.
• Rook ei ole endiselt nii paindlik kui tavaline Ceph. Kui me tahame seadistada, et CephFS-i metaandmete bassein oleks SSD-l ja andmed HDD-l, tuleb eraldi seadmete rühmad CRUSH kaardis käsitsi määrata.
• Kuigi rook-ceph-operator on stabiilseks tunnistatud, on hetkel teatud probleemid Cephi uuendamisel versioonilt 13 versioonile 14.

Järeldused

„Praegu on Laevuke välismaailmast kinni, kuid usume, et ühel päeval mängib see mängus otsustavat rolli!“ (tsitaat on koostatud spetsiaalselt selle artikli jaoks)

Rooki projekt on kahtlemata meie südameid võitnud – usume, et [kõigi oma plusside ja miinustega] väärib see kindlasti ka teie tähelepanu.

Meie edasised plaanid koostavad rook-ceph mooduliks, addon-operator, mis muudab selle kasutamise meie paljudes Kubernetes-klastrites veelgi lihtsamaks ja mugavamaks.

P.S.

Lugege ka meie blogist:

• «Rook on „iseteenindav“ andmesalvestus Kubernetes'i jaoks»;
• «Loome püsiva salvestuse Kubernetese Ceph'i baasprovisioneerimisega»;
• «Andmebaasid ja Kubernetes (ülevaade ja video ettekandest)»;
• «Tutvustame shell-operatorit: Kubernetes'e operaatorite loomine on veelgi lihtsamaks muutunud»;
• «Kubernetes'i operaatorid: kuidas käivitada stateful-rakendusi».

Allikas: habr.com