Për Rook apo jo për Rook - kjo është pyetja

Në fillim të këtij muaji, më 3 maj, u njoftua një lëshim i madh i një "sistemi të menaxhimit për ruajtjen e të dhënave të shpërndara në Kubernetes" - Rook 1.0.0. Më shumë se një vit më parë ne tashmë botuar pasqyrë e përgjithshme e Rook. Më pas na kërkuan të flisnim për përvojën e tij përdorni në praktikë — dhe tani, pikërisht në kohën e duhur për një moment historik kaq të rëndësishëm në historinë e projektit, ne jemi të lumtur të ndajmë përshtypjet tona të grumbulluara.

Me pak fjalë, Rook është një grup operatorët për Kubernetes, të cilat marrin kontrollin e plotë të vendosjes, menaxhimit, rikuperimit automatik të zgjidhjeve të ruajtjes së të dhënave si Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Për momentin më të zhvilluarat (dhe i vetmi в të qëndrueshme faza) zgjidhja është rook-ceph-operator.

Shënim: Ndër ndryshimet domethënëse në lëshimin e Rook 1.0.0 në lidhje me Ceph, mund të vërejmë mbështetjen për Ceph Nautilus dhe aftësinë për të përdorur NFS për kova CephFS ose RGW. Ajo që bie në sy ndër të tjera është maturimi i mbështetjes EdgeFS në nivelin beta.

Pra, në këtë artikull ne:

• Le t'i përgjigjemi pyetjes se cilat avantazhe shohim në përdorimin e Rook për të vendosur Ceph në një grupim Kubernetes;
• Ne do të ndajmë përvojën dhe përshtypjet tona për përdorimin e Rook në prodhim;
• Le t'ju tregojmë pse i themi "Po!" Rook-it dhe për planet tona për të.

Le të fillojmë me konceptet dhe teorinë e përgjithshme.

"Unë kam një avantazh të një Rook!" (shahist i panjohur)

Një nga avantazhet kryesore të Rook është se ndërveprimi me dyqanet e të dhënave kryhet përmes mekanizmave Kubernetes. Kjo do të thotë që nuk keni më nevojë të kopjoni komandat për të konfiguruar Ceph nga fleta në tastierë.

— Dëshiron të vendosësh CephFS në një grup? Thjesht shkruani një skedar YAML!
- Çfarë? Dëshironi gjithashtu të vendosni një dyqan objektesh me S3 API? Thjesht shkruani një skedar të dytë YAML!

Rook është krijuar sipas të gjitha rregullave të një operatori tipik. Ndërveprimi me të ndodh duke përdorur CRD (Përkufizimet e burimeve të personalizuara), në të cilën ne përshkruajmë karakteristikat e entiteteve Ceph që na duhen (meqenëse ky është i vetmi zbatim i qëndrueshëm, si parazgjedhje ky artikull do të flasë për Ceph, përveç rasteve kur shprehet ndryshe). Sipas parametrave të specifikuar, operatori do të ekzekutojë automatikisht komandat e nevojshme për konfigurim.

Le të shohim specifikat duke përdorur shembullin e krijimit të një dyqani objektesh, ose më mirë - 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 }}

Parametrat e treguar në listë janë mjaft standarde dhe vështirë se kanë nevojë për komente, por ia vlen t'i kushtohet vëmendje e veçantë atyre që u janë caktuar variablave shabllon.

Skema e përgjithshme e punës zbret në faktin se ne "porositim" burimet përmes një skedari YAML, për të cilin operatori ekzekuton komandat e nevojshme dhe na kthen një sekret "jo shumë real" me të cilin mund të punojmë më tej. (Shikoni më poshtë). Dhe nga variablat e listuara më sipër, komanda dhe emri sekret do të përpilohen.

Çfarë ekipi është ky? Kur krijoni një përdorues për ruajtjen e objekteve, operatori Rook brenda pod do të bëjë sa më poshtë:

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

Rezultati i ekzekutimit të kësaj komande do të jetë një strukturë JSON:

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

Keys - çfarë aplikacionesh të ardhshme do të kenë nevojë për të hyrë në ruajtjen e objekteve nëpërmjet S3 API. Operatori Rook i zgjedh me dashamirësi dhe i vendos në hapësirën e tij të emrave në formën e një sekreti me emrin rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Për të përdorur të dhënat nga ky sekret, thjesht shtoni ato në kontejner si variabla mjedisi. Si shembull, unë do të jap një shabllon për Job, në të cilin ne krijojmë automatikisht kova për çdo mjedis përdoruesi:

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

Të gjitha veprimet e listuara në këtë Punë u kryen brenda kornizës së Kubernetes. Strukturat e përshkruara në skedarët YAML ruhen në një depo Git dhe ripërdoren shumë herë. Ne e shohim këtë si një plus të madh për inxhinierët DevOps dhe procesin CI/CD në tërësi.

I lumtur me Rook dhe Rados

Përdorimi i kombinimit Ceph + RBD imponon kufizime të caktuara në montimin e vëllimeve në pods.

Në veçanti, hapësira e emrave duhet të përmbajë një sekret për të hyrë në Ceph në mënyrë që aplikacionet shtetërore të funksionojnë. Është mirë nëse keni 2-3 mjedise në hapësirat e tyre të emrave: mund të shkoni dhe ta kopjoni sekretin manualisht. Por, çka nëse për çdo veçori krijohet një mjedis i veçantë me hapësirën e vet të emrave për zhvilluesit?

Ne e zgjidhëm këtë problem vetë duke përdorur shell-operator, i cili automatikisht kopjoi sekretet në hapësirat e reja të emrave (një shembull i një goditjeje të tillë përshkruhet në Ky artikull).

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

Sidoqoftë, kur përdorni Rook, ky problem thjesht nuk ekziston. Procesi i montimit ndodh duke përdorur drejtuesit e tij bazuar në Flexvolume ose CSI (ende në fazën beta) dhe për këtë arsye nuk kërkon sekrete.

Rook zgjidh automatikisht shumë probleme, gjë që na inkurajon ta përdorim atë në projekte të reja.

Rrethimi i Rook

Le të përfundojmë pjesën praktike duke vendosur Rook dhe Ceph në mënyrë që ne të mund të kryejmë eksperimentet tona. Për ta bërë më të lehtë sulmin me stuhi mbi këtë kullë të pathyeshme, zhvilluesit kanë përgatitur një paketë Helm. Le ta shkarkojmë:

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

Në dosje rook-ceph/values.yaml mund të gjeni shumë cilësime të ndryshme. Gjëja më e rëndësishme është të specifikoni tolerimet për agjentët dhe kërkimin. Ne përshkruam në detaje se për çfarë mund të përdoret mekanizmi i njollave/tolerimeve Ky artikull.

Shkurtimisht, ne nuk duam që podat e aplikacionit të klientit të vendosen në të njëjtat nyje si disqet e ruajtjes së të dhënave. Arsyeja është e thjeshtë: në këtë mënyrë puna e agjentëve të Rook nuk do të ndikojë në vetë aplikacionin.

Pra, hapni skedarin rook-ceph/values.yaml me redaktorin tuaj të preferuar dhe shtoni bllokun e mëposhtëm në fund:

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

Për secilën nyje të rezervuar për ruajtjen e të dhënave, shtoni njollën përkatëse:

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

Pastaj instaloni grafikun Helm me komandën:

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

Tani ju duhet të krijoni një grup dhe të specifikoni vendndodhjen 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"

Kontrollimi i statusit të Ceph - prisni të shihni 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

Në të njëjtën kohë, le të kontrollojmë që pods me aplikacionin e klientit të mos përfundojnë në nyjet e rezervuara për Ceph:

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

Më tej, komponentët shtesë mund të konfigurohen sipas dëshirës. Më shumë detaje rreth tyre tregohen në dokumentacionin. Për administrim, ne rekomandojmë fuqimisht instalimin e pultit dhe kutisë së veglave.

Rook dhe grepa: a mjafton Rook për gjithçka?

Siç mund ta shihni, zhvillimi i Rook është në lëvizje të plotë. Por ka ende probleme që nuk na lejojnë të braktisim plotësisht konfigurimin manual të Ceph:

• Pa Shofer Rook nuk mundet matjet e eksportit për përdorimin e blloqeve të montuara, gjë që na privon nga monitorimi.
• Flexvolume dhe CSI nuk di si ndryshoni madhësinë e vëllimeve (në krahasim me të njëjtin RBD), kështu që Rook privohet nga një mjet i dobishëm (dhe ndonjëherë në mënyrë kritike!).
• Rook nuk është ende aq fleksibël sa Cefi i zakonshëm. Nëse duam të konfigurojmë grupin që metadatat e CephFS të ruhen në SSD dhe vetë të dhënat të ruhen në HDD, do të na duhet të regjistrojmë manualisht grupe të veçanta pajisjesh në hartat CRUSH.
• Përkundër faktit se operatori rook-ceph konsiderohet i qëndrueshëm, aktualisht ka disa probleme kur përmirësoni Ceph nga versioni 13 në 14.

Gjetjet

“Për momentin Rook është i mbyllur nga bota e jashtme nga pengjet, por ne besojmë se një ditë ajo do të luajë një rol vendimtar në lojë!” (citati i shpikur posaçërisht për këtë artikull)

Projekti Rook padyshim që ka fituar zemrat tona - ne besojmë se [me të gjitha të mirat dhe të këqijat e tij] patjetër që meriton vëmendjen tuaj.

Planet tona të së ardhmes përfundojnë në bërjen e rook-ceph një modul për të shtesë-operator, i cili do ta bëjë përdorimin e tij në grupimet tona të shumta Kubernetes edhe më të thjeshtë dhe më të përshtatshëm.

PS

Lexoni edhe në blogun tonë:

• «Rook - depo e të dhënave "vetë-shërbim" për Kubernetes"?
• «Krijimi i ruajtjes së vazhdueshme me sigurim në Kubernetes bazuar në Ceph"?
• «Bazat e të dhënave dhe Kubernetes (rishikim dhe raport video)"?
• «Prezantimi i operatorit guaskë: krijimi i operatorëve për Kubernetes sapo u bë më i lehtë"?
• «Operatorët për Kubernetes: si të ekzekutoni aplikacione shtetërore'.

Burimi: www.habr.com