🥇Rook ala ez Rook - hori da galdera

Hilabete honen hasieran, maiatzaren 3an, "Kubernetes-en banatutako datuak biltegiratzeko sistema kudeatzeko" bertsio garrantzitsu bat iragarri zen - Rook 1.0.0. Duela urtebete baino gehiago jada argitaratua Rook-en ikuspegi orokorra. Ondoren, bere esperientziaz hitz egiteko eskatu ziguten praktikan erabiltzea — eta orain, proiektuaren historian hain mugarri esanguratsu baterako garaiz, pozik gaude metatutako inpresioak partekatzeko.

Laburbilduz, Rook multzo bat da operadoreak Kubernetesentzat, Ceph, EdgeFS, Minio, Cassandra, CockroachDB bezalako datuak biltegiratzeko soluzioen hedapenaren, kudeaketaren eta berreskuratze automatikoaren kontrol osoa hartzen dutenak.

Momentuz garatuena (eta bakarra в egonkorra etapa) irtenbidea da dorre-ceph-operadore.

Kontuan izan: Ceph-ekin erlazionatutako Rook 1.0.0 bertsioaren aldaketa esanguratsuen artean, Ceph Nautilus-en laguntza eta CephFS edo RGW kuboetarako NFS erabiltzeko gaitasuna nabarmendu ditzakegu. Besteak beste, EdgeFS laguntza beta mailara heldu izana da nabarmentzen dena.

Beraz, artikulu honetan honako hau dugu:

Erantzun diezaiogun zein abantaila ikusten ditugun Rook erabiltzeak Ceph Kubernetes kluster batean zabaltzeko;
Rook ekoizpenean erabiltzearen esperientzia eta inpresioak partekatuko ditugu;
Esan dezagun zergatik esaten diogun “Bai!” Rook-i, eta harentzat ditugun planei buruz.

Has gaitezen kontzeptu eta teoria orokorrekin.

"Rook baten abantaila dut!" (xake jokalari ezezaguna)

Rook-en abantaila nagusietako bat datu biltegiekin elkarrekintza Kubernetes mekanismoen bidez egiten dela da. Horrek esan nahi du jada ez dituzula komandoak kopiatu behar orritik Ceph kontsolara konfiguratzeko.

— CephFS kluster batean zabaldu nahi duzu? Idatzi YAML fitxategi bat!
- Zer? S3 APIarekin objektu denda bat ere zabaldu nahi duzu? Besterik gabe, idatzi bigarren YAML fitxategi bat!

Rook operadore tipiko baten arau guztien arabera sortzen da. Berarekin interakzioa erabiliz gertatzen da CRD (Pertsonalizatutako Baliabideen Definizioak), eta bertan behar ditugun Ceph entitateen ezaugarriak deskribatzen ditugu (Hau inplementazio egonkor bakarra denez, lehenespenez artikulu honek Ceph-i buruz hitz egingo du, esplizituki kontrakoa adierazi ezean). Zehaztutako parametroen arabera, operadoreak automatikoki exekutatuko ditu konfiguratzeko beharrezkoak diren komandoak.

Ikus ditzagun zehaztasunak Objektuen biltegi bat sortzeko adibidea erabiliz, edo hobeto esanda - 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 }}

Zerrendan adierazitako parametroak nahiko estandarrak dira eta ia ez dute komentariorik behar, baina merezi du arreta berezia jartzea txantiloiaren aldagaiei esleitutakoei.

Lan-eskema orokorra baliabideak YAML fitxategi baten bidez "eskatzen" ditugula da, eta horretarako operadoreak beharrezko komandoak exekutatzen ditu eta "ez hain erreala" sekretu bat itzultzen digu, eta horrekin lan egin dezakegu. (ikus behean). Eta goian zerrendatutako aldagaietatik, komandoa eta izen sekretua konpilatuko dira.

Zer talde mota da hau? Objektuak biltegiratzeko erabiltzaile bat sortzean, pod barruko Rook operadoreak honako hau egingo du:

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

Komando hau exekutatzearen emaitza JSON egitura bat izango da:

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

Keys - S3 APIaren bidez objektuen biltegian sartzeko etorkizuneko aplikazioek zer behar duten. Rook operadoreak atsegin handiz hautatzen ditu eta bere izen-eremuan jartzen ditu izenarekin sekretu baten moduan rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Sekretu honetako datuak erabiltzeko, gehitu edukiontzira ingurune-aldagai gisa. Adibide gisa, Job-erako txantiloi bat emango dut, eta bertan automatikoki sortzen ditugu erabiltzaile-ingurune bakoitzeko kuboak:

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

Lan honetan zerrendatutako ekintza guztiak Kubernetes-en esparruan egin ziren. YAML fitxategietan deskribatutako egiturak Git biltegi batean gordetzen dira eta askotan berrerabiltzen dira. Hau DevOps ingeniarientzat eta CI/CD prozesu osoarentzat abantaila handia dela ikusten dugu.

Pozik Rook eta Radosekin

Ceph + RBD konbinazioa erabiltzeak zenbait murrizketa ezartzen ditu bolumenak muntatzeko.

Bereziki, izen-espazioak Ceph atzitzeko sekretu bat eduki behar du egoera-aplikazioak funtzionatu ahal izateko. Ondo dago haien izen-espazioetan 2-3 ingurune badituzu: joan zaitezke sekretua eskuz kopiatu. Baina zer gertatzen da ezaugarri bakoitzerako bere izen-espazio propioa duen ingurune bereizia sortzen bada garatzaileentzat?

Arazo hau guk geuk konpondu dugu shell-operadore, sekretuak automatikoki kopiatzen zituen izen-espazio berrietara (halako kako baten adibidea atalean deskribatzen da Artikulu honetan).

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

Hala ere, Rook erabiltzean arazo hau ez da existitzen. Muntatze-prozesua oinarritutako kontrolatzaile propioak erabiliz egiten da Flexobolumena edo CSI (oraindik beta fasean) eta, beraz, ez du sekreturik behar.

Rook automatikoki arazo asko konpontzen ditu, eta horrek proiektu berrietan erabiltzera bultzatzen gaitu.

Rook setioa

Osa dezagun zati praktikoa Rook eta Ceph zabalduz, gure esperimentuak egin ahal izateko. Dorre erasoezin hau errazago erasotzeko, Helm pakete bat prestatu dute garatzaileek. Deskarga dezagun:

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

Fitxategian rook-ceph/values.yaml ezarpen ezberdin asko aurki ditzakezu. Garrantzitsuena agenteen eta bilaketaren tolerantziak zehaztea da. Zehazki deskribatu dugu zertarako erabil daitekeen kutsadura/tolerantzia mekanismoa Artikulu honetan.

Laburbilduz, ez dugu nahi bezero-aplikazioen podak datuak biltegiratzeko diskoen nodo berdinetan kokatuta egotea. Arrazoia sinplea da: horrela Rook agenteen lanak ez dio aplikazioari berari eragingo.

Beraz, ireki fitxategia rook-ceph/values.yaml zure gogoko editorearekin eta gehitu bloke hau amaieran:

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

Datuak gordetzeko erreserbatutako nodo bakoitzeko, gehitu dagokion kutsadura:

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

Ondoren, instalatu Helm diagrama komandoarekin:

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

Orain kluster bat sortu eta kokapena zehaztu behar duzu 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"

Ceph-en egoera egiaztatzen - ikusi espero 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

Aldi berean, egiaztatu dezagun bezeroaren aplikazioa duten podak Ceph-entzat gordetako nodoetan amaitzen ez direla:

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

Gainera, osagai osagarriak nahi bezala konfigura daitezke. atalean adierazten dira haiei buruzko xehetasun gehiago dokumentazioa. Administraziorako, aginte-panela eta tresna-kutxa instalatzea gomendatzen dugu.

Rook eta amuak: Rook nahikoa al da denetarako?

Ikus dezakezunez, Rook-en garapena pil-pilean dago. Baina oraindik Ceph-en eskuzko konfigurazioa guztiz alde batera uzten ez diguten arazoak daude:

Rook Driverrik ez ezin esportatu neurriak muntatutako blokeen erabilerari buruz, eta horrek monitorizazioa kentzen digu.
Flexbolumena eta CSI ez dakit nola aldatu bolumenen tamaina (RBD beraren aurka), beraz, Rook tresna erabilgarria (eta batzuetan ezinbestekoa!) tresnarik gabe geratzen da.
Rook oraindik ez da Ceph arrunta bezain malgua. CephFS metadatuak SSD-n gordetzeko eta datuak berak HDD-an gordetzeko igerilekua konfiguratu nahi badugu, CRUSH mapetan gailu talde bereiziak eskuz erregistratu beharko ditugu.
Rook-ceph-operator egonkortzat jotzen den arren, gaur egun arazo batzuk daude Ceph 13 bertsiotik 14ra eguneratzean.

Findings

"Oraintxe Rook peoiek kanpotik itxita daukate, baina uste dugu egunen batean paper erabakigarria izango duela jokoan!" (artikulu honetarako bereziki asmatutako aipua)

Rook proiektuak, dudarik gabe, gure bihotzak irabazi ditu - uste dugu [bere alde on eta txar guztiekin] zure arreta merezi duela zalantzarik gabe.

Gure etorkizuneko planak rook-ceph-ren modulu bihurtzera mugatzen dira gehigarri-eragile, eta horrek bere erabilera gure Kubernetes kluster ugaritan are errazagoa eta erosoagoa izango du.

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Rook edo ez Rook - hori da galdera

"Rook baten abantaila dut!" (xake jokalari ezezaguna)

Pozik Rook eta Radosekin

Rook setioa

Rook eta amuak: Rook nahikoa al da denetarako?

Findings

PS

Gehitu iruzkin berria Idatzi