ProHoster > Blog > Administrimi > Rook apo jo Rook — kjo Ă«shtĂ« pyetja

Rook apo jo Rook — kjo Ă«shtĂ« pyetja

Rook apo jo Rook — kjo Ă«shtĂ« pyetja

NĂ« fillim tĂ« kĂ«tij muaji, mĂ« 3 maj, u shpall njĂ« lĂ«shim i rĂ«ndĂ«sishĂ«m i «sistemĂ«s pĂ«r menaxhimin e depozitave tĂ« shpĂ«rndara tĂ« dhĂ«nash nĂ« Kubernetes» — Rook 1.0.0. MĂ« shumĂ« se njĂ« vit mĂ« parĂ« ne tashmĂ« e publikojmĂ« bĂ«jmĂ« njĂ« pĂ«rmbledhje tĂ« pĂ«rgjithshme tĂ« Rook. Po atĂ«herĂ«, na u kĂ«rkua qĂ« tĂ« flasim pĂ«r pĂ«rvojĂ«n e tij nĂ« praktikĂ« — dhe ja, nĂ« kĂ«tĂ« moment tĂ« rĂ«ndĂ«sishĂ«m nĂ« historinĂ« e projektit, ne jemi tĂ« lumtur tĂ« ndajmĂ« pĂ«rvojat e grumbulluara.

Në përmbledhje, Rook paraqet një set operatorësh për Kubernetes, të cilët plotësisht marrin kontrollin e shpërndarjes, menaxhimit, rikuperimit automatik të zgjidhjeve të depozitimit të dhënash si Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Në këtë moment, zgjidhja më e zhvilluar (dhe e vetmja në në fazën e stabilizuar) është rook-ceph-operator.

Shënim: ndër ndryshimet e rëndësishme në lëshimin Rook 1.0.0, të lidhura me Ceph, mund të theksohet mbështetje për Ceph Nautilus dhe mundësia për të përdorur NFS për CephFS- ose RGW-bucket. Nga të tjerat, ndriçohet «pjekuria» e mbështetjes për EdgeFS në nivelin beta.

Pra, në këtë artikull ne:

  • do t'ju pĂ«rgjigjemi pyetjes se çfarĂ« pĂ«rfitimesh shohim nĂ« pĂ«rdorimin e Rook pĂ«r shpĂ«rndarjen e Ceph nĂ« njĂ« klaster Kubernetes;
  • do tĂ« ndajmĂ« pĂ«rvojĂ«n dhe pĂ«rshtypjet tona nga pĂ«rdorimi i Rook nĂ« prodhim;
  • do t'ju tregojmĂ« pse ne i themi Rook-ut «Po!», dhe pĂ«r planet tona pĂ«r tĂ«.

Të fillojmë me konceptet dhe teorinë e përgjithshme.

«Kam një avantazh me një Rook!» (lojtar i panjohur shahu)

Rook apo jo Rook — kjo Ă«shtĂ« pyetja

Një nga avantazhet kryesore të Rook është se ndërveprimi me ruajtjet e të dhënave bëhet përmes mekanizmave Kubernetes. Kjo do të thotë se nuk është më e nevojshme të kopjoni komandat për konfigurimin e Ceph nga një letër në konsol.

— DĂ«shiron tĂ« vendosĂ«sh nĂ« klasĂ«n CephFS? Thjesht shkruaj njĂ« skedĂ« YAML!
­— ÇfarĂ«? DĂ«shiron tĂ« vendosĂ«sh edhe njĂ« dyqan objektesh me S3 API? Thjesht shkruaj njĂ« skedĂ« tĂ« dytĂ« YAML!

Rook është krijuar sipas të gjitha rregullave të një operatori tipik. Ndërveprimi me të ndodh përmes CRD (Definicionet e Burimeve të Personalizuara), ku përshkruajmë karakteristikat e nevojshme të entiteteve Ceph (pasi kjo është implementimi i vetëm stabil, në këtë artikull do të flasim kryesisht për Ceph, përveç nëse citohet ndryshe). Sipas parametrave të caktuar, operatori automatikisht do të ekzekutojë komandat e nevojshme për konfigurim.

Le të shqyrtojmë konkretësisht duke e ilustruar me shembullin e krijimit të Dyqanit të Objekteve, që është 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 specifikuara në listë janë mjaft standarde dhe me siguri nuk kanë nevojë për koment, megjithatë është e rëndësishme të kushtohet vëmendje të veçantë atyre që janë të theksuara në variablat e shabllonit.

Schema e përgjithshme e punës përmbledh se përmes skedarit YAML ne "porosisim" burime, për të cilat operatori ekzekuton komandat e nevojshme dhe na kthen një "sekret jo të vërtetë", me të cilin mund të punojmë më tej. (shih më poshtë). Nga variablat e përmendur më lart, do të përbëhet komanda dhe emri i sekretit.

ÇfarĂ« Ă«shtĂ« kjo komandĂ«? Kur krijohet njĂ« pĂ«rdorues pĂ«r depo objektesh, operatori Rook brenda pod-it do tĂ« ekzekutojĂ« kĂ«tĂ«:

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"
        }
    ],
    ...
}

ÇelĂ«sat — ato qĂ« do tĂ« nevojiten nĂ« tĂ« ardhmen nga aplikacionet pĂ«r t'u aksesuar nĂ« depozitat e objekteve pĂ«rmes S3 API. Rook-operatori i zgjedh ato dhe i ruan nĂ« hapĂ«sirĂ«n e tij me emrin e sekretit rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Për të përdorur të dhënat nga ky sekret, mjafton t'i shtoni ato në kontejner si variabla ambienti. Si një shembull, do të jap një shabllon për Job-in, në të cilin automatikisht krijojmë bucket për çdo ambient 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 përmendura në këtë Punë janë realizuar pa dalë nga Kubernetes. Strukturat e përshkruara në skedarët YAML janë ruajtur në një depo Git dhe janë ripërdorur shumë herë. Në këtë, ne shohim një avantazh të madh për inxhinierët DevOps dhe procesin CI/CD në tërësi.

Me Rook dhe Rados në gëzim

PĂ«rdorimi i lidhjes Ceph + RBD imponon disa kufizime nĂ« montimin e volumit nĂ« pod’e.

NĂ« veçanti, nĂ« namespace duhet tĂ« ketĂ« patjetĂ«r njĂ« sekret pĂ«r akses nĂ« Ceph, pĂ«r tĂ« mundĂ«suar funksionimin e aplikacioneve me gjendje. ËshtĂ« normale nĂ«se keni 2-3 ambientet nĂ« emrat tuaj tĂ« hapĂ«sirave: mund tĂ« shkoni dhe tĂ« kopjoni sekretin manualisht. Por çfarĂ« duhet bĂ«rĂ« nĂ«se pĂ«r çdo vefeature pĂ«r zhvilluesit krijohet njĂ« ambient i veçantĂ« me namespace tĂ« tij?

Ne e zgjidhëm këtë problem përmes shell-operator, i cili kopjon automatikisht sekretet në namespace të reja (një shembull i tillë i këtij hook-u është përshkruar në këtë 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

Megjithatë, me përdorimin e Rook, ky problem thjesht nuk ekziston. Procesi i montimit ndodh përmes drejtorëve të vetë dhe Flexvolume ose CSI (aktualisht në fazën beta) dhe prandaj nuk kërkon sekrete.

Rook automatikisht zgjidh shumë probleme, që na nxit të përdorim atë në projektet e reja.

Rrethimi Rook

Të përfundojmë pjesën praktike me instalimin e Rook dhe Ceph për të mundësuar eksperimente të veta. Për ta lehtësuar marrjen me forcë të kësaj kulle të papërshkueshme, zhvilluesit përgatitën një paketë Helm. Le të shkarkojmë atë:

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

Në skedar rook-ceph/values.yaml mund të gjeni shumë konfigurime të ndryshme. Më e rëndësishmja është të tregoni tolerations për agjentët dhe kërkimin. Për çfarë mund të përdoret mekanizmi taints/tolerations, e kemi shpjeguar në detaje në këtë artikull.

NĂ«se e shikoni shkurt, ne nuk duam qĂ« pod’at me aplikacionin klient tĂ« vendosen nĂ« tĂ« njĂ«jtat node ku ndodhen diskĂ«t pĂ«r ruajtjen e tĂ« dhĂ«nave. Arsyeja Ă«shtĂ« e thjeshtĂ«: kĂ«shtu puna e agjentĂ«ve Rook nuk do tĂ« ndikojĂ« nĂ« vetĂ« aplikacionin.

Pra, hapim skedarin rook-ceph/values.yaml me redaktorin tonë të preferuar dhe shtojmë 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 çdo nod që është rezervuar për ruajtjen e të dhënave, shtojmë taintin përkatës:

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

Pas pas kemi instaluar Helm chart me komandën:

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

Tani është e nevojshme të krijoni një klaster dhe të tregoni 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"

Kontrolloni statusin Ceph — presim tĂ« shohim 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

Po ashtu do të kontrollojmë që pod-ët me aplikacionin e klientit nuk po shkojnë në nodet e rezervuara për Ceph:

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

Të tjera komponente konfigurohen sipas dëshires. Informacione më të detajuara rreth tyre janë të dhëna në dokumentacion. Për administrim, rekomandojmë të instaloni dashboard-in dhe toolbox.

Rook’о-kryqi: a i jep Rook gjithçka?

Siç duket, zhvillimi i Rook është në plot zhvillim. Por akoma ekzistojnë probleme që nuk na lejojnë të heqim dorë plotësisht nga konfigurimi manual i Ceph:

  • AsnjĂ« driver i Rook nuk di tĂ« eksportojĂ« metrikat pĂ«r pĂ«rdorimin e blloqeve tĂ« montuara, gjĂ« qĂ« na privon nga monitorimi.
  • Flexvolume dhe CSI nuk di tĂ« ndryshojĂ« madhĂ«sinĂ« e volumit (nĂ« dallim nga RBD), kĂ«shtu qĂ« Rook humbet njĂ« mjet tĂ« dobishĂ«m (dhe ndonjĂ«herĂ« edhe kritik!).
  • Rook akoma nuk Ă«shtĂ« aq fleksibĂ«l sa Ceph-i i zakonshĂ«m. NĂ«se dĂ«shirojmĂ« tĂ« konfigurojmĂ« qĂ« pula pĂ«r metadatat CephFS tĂ« ruhet nĂ« SSD, ndĂ«rsa tĂ« dhĂ«nat vetĂ« nĂ« HDD, do tĂ« kĂ«rkohet tĂ« shkruhen grupe tĂ« veçanta pajisjesh nĂ« hartat CRUSH manualisht.
  • PavarĂ«sisht se rook-ceph-operatori konsiderohet i stabilizuar, nĂ« momentin e tanishĂ«m ekzistojnĂ« disa probleme gjatĂ« pĂ«rmirĂ«simit tĂ« Ceph nga versioni 13 nĂ« 14.

PĂ«rfundimet

"Tani, Ladya është e mbyllur nga bota e jashtme me pejsa, por ne besojmë se një ditë ajo do të luajë një rol vendimtar në lojë!" (cita e shpikur veç për këtë artikull)

Projektin Rook, pa dyshim, e ka fituar zemrat tona — ne besojmĂ« se [me tĂ« gjitha pĂ«rfitimet dhe disavantazhet e tij] ai me siguri meritohet kujdesi juaj.

Planifikimet tona përtej janë që ta bëjmë rook-ceph modul për addon-operator, duke e bërë përdorimin e tij në shumë Kubernetes-klastër më të lehtë dhe më të rehatshëm.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster