Ji Rook re an ne ji Rook re - pirs ev e

Di destpêka vê mehê de, di 3ê Gulanê de, serbestberdana mezin a "pergalek rêveberiyê ji bo hilanîna daneya belavkirî li Kubernetes" hate ragihandin - Rook 1.0.0. Zêdetirî salek berê me berê weşandin nêrîna giştî ya Rook. Paşê ji me hat xwestin ku em qala serpêhatiya wî bikin di pratîkê de bikar bînin - û naha, tam di wextê de ji bo qonaxek wusa girîng di dîroka projeyê de, em kêfxweş in ku em bandorên xwe yên berhevkirî parve dikin.

Bi kurtasî, Rook setek e operatorên ji bo Kubernetes, ku bi tevahî kontrolkirina bicîhkirin, rêvebirin, vegerandina otomatîkî ya çareseriyên hilanîna daneyê yên wekî Ceph, EdgeFS, Minio, Cassandra, CockroachDB digire.

Di vê demê de ya herî pêşkeftî (û yekane в stewr qonax) çareserî ye rook-ceph-operator.

bingotin: Di nav guhertinên girîng ên di serbestberdana Rook 1.0.0 de ku bi Ceph ve girêdayî ye, em dikarin piştgiriya Ceph Nautilus û şiyana karanîna NFS-ê ji bo kepçeyên CephFS an RGW destnîşan bikin. Tiştê ku di nav yên din de radiweste, gihîştina piştgiriya EdgeFS ya di asta beta de ye.

Ji ber vê yekê, di vê gotarê de em:

• Ka em bersiva pirsê bidin ka em di karanîna Rook de ji bo bicihkirina Ceph di komek Kubernetes de çi feydeyên dibînin;
• Em ê ezmûn û bandorên xwe yên karanîna Rook di hilberînê de parve bikin;
• Ka em ji we re bibêjin ka çima em ji Rook re dibêjin "Erê!", û li ser planên xwe yên ji bo wî.

Ka em bi têgîn û teoriya giştî dest pê bikin.

"Awantajek min ji yek Rook heye!" (lîstikvanê satrancê yê nenas)

Yek ji avantajên sereke yên Rook ev e ku danûstendina bi dikanên daneyê re bi mekanîzmayên Kubernetes ve tête kirin. Ev tê vê wateyê ku hûn êdî ne hewce ne ku fermanan kopî bikin da ku Ceph ji pelê di konsolê de mîheng bikin.

- Ma hûn dixwazin CephFS di komekê de bicîh bikin? Tenê pelek YAML binivîse!
- Çi? Ma hûn jî dixwazin ku bi S3 API re firotgehek tiştan bicîh bikin? Tenê pelê duyemîn YAML binivîse!

Rook li gorî hemî qaîdeyên operatorek tîpîk tê afirandin. Têkiliya bi wî re tê bikaranîn CRD (Pênaseyên Çavkaniya Xwerû), ku tê de em taybetmendiyên hebûnên Ceph ku em hewce ne diyar dikin (ji ber ku ev yekane pêkanîna stabîl e, ji hêla xwerû ve ev gotar dê li ser Ceph biaxive, heya ku bi eşkereyî wekî din neyê gotin). Li gorî pîvanên diyarkirî, operator dê bixweber fermanên ku ji bo veavakirinê hewce ne bicîh bîne.

Ka em bi mînaka afirandina Firokek Objektîf li taybetmendiyan binihêrin, an bêtir - 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 }}

Parametreyên ku di navnîşê de têne destnîşan kirin pir standard in û ne hewceyî şîroveyan in, lê hêja ye ku bala xwe bidin yên ku ji guhêrbarên şablonê re têne veqetandin.

Pîlana giştî ya xebatê digihîje vê rastiyê ku em çavkaniyan bi navgîniya pelek YAML "ferman dikin", ji bo ku operator fermanên pêwîst pêk tîne û sirekek "ne pir rast" ji me re vedigerîne ku em pê re dikarin bêtir bixebitin. (li jêr binêre). Û ji guherbarên ku li jor hatine destnîşan kirin, dê ferman û navê veşartî were berhev kirin.

Ev çi tîm e? Dema ku bikarhênerek ji bo hilanîna tiştan diafirîne, operatorê Rook di hundurê pod de dê jêrîn bike:

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

Encama pêkanîna vê fermanê dê avahiyek JSON be:

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

Keys - Dê çi serîlêdanên pêşerojê hewce bike ku bi riya S3 API-ê bigihîjin hilanîna tiştan. Operatorê Rook bi dilovanî wan hildibijêre û wan di nav cîhê navên xwe de di forma veşartî ya bi navê xwe de datîne rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Ji bo ku daneyên vê veşartî bikar bînin, tenê wê wekî guhêrbarên hawîrdorê li konteynerê zêde bikin. Wek mînak, ez ê şablonek ji bo Kar bidim, ku tê de em bixweber ji bo her hawîrdora bikarhêner kelek çêdikin:

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

Hemî çalakiyên ku di vê Karê de hatine navnîş kirin di çarçoveya Kubernetes de hatine kirin. Avahiyên ku di pelên YAML de têne vegotin di depoyek Git de têne hilanîn û gelek caran têne bikar anîn. Em vê yekê ji bo endezyarên DevOps û pêvajoya CI/CD bi tevahî wekî plusek mezin dibînin.

Bi Rook û Rados re kêfxweş e

Bikaranîna kombînasyona Ceph + RBD hin sînorkirinan li ser hilanîna cildên li ser podan ferz dike.

Bi taybetî, cîhê navan divê ji bo gihîştina Ceph veşariyek hebe da ku serîlêdanên dewletî kar bikin. Ger 2-3 hawîrdorên we di nav cîhên navên wan de hebin baş e: hûn dikarin herin û veşartî bi destan kopî bikin. Lê heke ji bo her taybetmendiyê hawîrdorek cihê bi navên xwe ji bo pêşdebiran were afirandin?

Me bi xwe ev pirsgirêk çareser kir shell-operator, ku bixweber nehênî li cîhên navên nû kopî kir (mînakek çengek wusa tê de tête diyar kirin vê gotara).

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

Lêbelê, dema ku Rook bikar tîne ev pirsgirêk bi hêsanî tune. Pêvajoya lêdanê bi karanîna ajokarên xwe yên li ser bingeha pêk tê Flexvolume an CSI (hîn di qonaxa betayê de ye) û ji ber vê yekê nepenî hewce nake.

Rook bixweber gelek pirsgirêkan çareser dike, ku me teşwîq dike ku em wê di projeyên nû de bikar bînin.

Siege of Rook

Werin em beşa pratîkî bi bicîhkirina Rook û Ceph biqedînin da ku em karibin ceribandinên xwe bikin. Ji bo hêsankirina bahozê li ser vê birca netewandî, pêşdebiran pakêtek Helm amade kirine. Ka em wê dakêşin:

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

Di pelê de rook-ceph/values.yaml hûn dikarin gelek mîhengên cûda bibînin. Tişta herî girîng ev e ku meriv tolerasyonên ji bo ajan û lêgerînê diyar bike. Me bi hûrgulî diyar kir ku mekanîzmaya tansiyonê / tolerasyonê ji bo çi dikare were bikar anîn vê gotara.

Bi kurtasî, em naxwazin ku pêlavên serîlêdana xerîdar li ser heman girêkên wekî dîskên hilanîna daneyê cih bigirin. Sedem hêsan e: bi vî rengî dê karê ajanên Rook bandorê li serîlêdanê bixwe neke.

Ji ber vê yekê, pelê vekin rook-ceph/values.yaml bi edîtorê xweya bijare re û di dawiyê de bloka jêrîn lê zêde bikin:

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

Ji bo her girêkek ku ji bo hilanîna daneyê hatî veqetandin, tîrêjê têkildar lê zêde bike:

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

Dûv re bi fermanê nexşeya Helm saz bikin:

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

Naha hûn hewce ne ku komek biafirînin û cîhê diyar bikin 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"

Kontrolkirina rewşa Ceph - li bendê bin ku bibînin 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

Di heman demê de, bila em kontrol bikin ka pêlên bi serîlêdana xerîdar li ser girêkên ku ji bo Ceph hatine veqetandin naqedin:

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

Wekî din, hêmanên zêde dikarin li gorî xwestinê werin mîheng kirin. Agahiyên bêtir di derbarê wan de têne destnîşan kirin belgekirin. Ji bo rêveberiyê, em bi tundî pêşniyar dikin ku dashboard û toolbox saz bikin.

Rok û çeng: gelo Rook têra her tiştî ye?

Wekî ku hûn dikarin bibînin, pêşkeftina Rook bi tevahî tevger e. Lê dîsa jî pirsgirêk hene ku nahêlin em bi tevahî dev ji veavakirina destan a Ceph berdin:

• No Driver Rook nikare metrîkên hinardekirinê li ser karanîna blokên siwarkirî, ku me ji çavdêriyê bêpar dihêle.
• Flexvolume û CSI nizanin çawa mezinahiya cildan biguhezînin (berevajî heman RBD), ji ber vê yekê Rook ji amûrek bikêr (û carinan jî bi rexneyî hewcedar!) bêpar dimîne.
• Rook hîn jî ne bi qasî Cephê birêkûpêk maqûl e. Ger em bixwazin hewzê mîheng bikin ku metadata CephFS li ser SSD-ê were hilanîn, û dane bixwe jî li ser HDD-ê were hilanîn, em ê hewce bikin ku komên cihê yên cîhazan di nexşeyên CRUSH de bi destan tomar bikin.
• Tevî vê rastiyê ku rook-ceph-operator bi îstîqrar tê hesibandin, dema ku Ceph ji guhertoya 13-an heya 14-an nûve dike, niha hin pirsgirêk hene.

vebiguherin

"Niha Rook ji cîhana derve ji hêla piyan ve hatî girtin, lê em bawer dikin ku rojek ew ê di lîstikê de rolek diyarker bilîze!" (gotara ku bi taybetî ji bo vê gotarê hatî çêkirin)

Projeya Rook bê guman dilê me qezenc kiriye - em bawer dikin ku [bi hemî başî û xirabiyên xwe re] ew bê guman bala we heq dike.

Planên me yên paşerojê ji bo çêkirina rook-ceph modulek e addon-operator, ku dê karanîna wê di gelek komên me yên Kubernetes de hê hêsantir û hêsantir bike.

PS

Li ser bloga me jî bixwînin:

• «Rook - depoya daneya "xwe-karûbar" ji bo Kubernetes»;
• «Afirandina hilanîna domdar bi peydakirina li Kubernetes li ser bingeha Ceph»;
• «Databases û Kubernetes (vedîtin û rapora vîdyoyê)»;
• «Nasandina shell-operator: afirandina operatoran ji bo Kubernetes hêsantir bû»;
• «Operatorên ji bo Kubernetes: Meriv çawa serîlêdanên dewletî dimeşîne".

Source: www.habr.com