To Rook or not to Rook - það er spurningin

Í byrjun þessa mánaðar, 3. maí, var tilkynnt um meiriháttar útgáfu á „stjórnunarkerfi fyrir dreifða gagnageymslu í Kubernetes“ - Rokkur 1.0.0. Fyrir meira en ári síðan við birt almennt yfirlit yfir Rook. Síðan vorum við beðin um að tala um reynslu hans nota í reynd — og núna, rétt fyrir svo merkan áfanga í sögu verkefnisins, erum við fús til að deila uppsöfnuðum birtingum okkar.

Í stuttu máli, Rook er sett rekstraraðilar fyrir Kubernetes, sem tekur fulla stjórn á dreifingu, stjórnun, sjálfvirkri endurheimt gagnageymslulausna eins og Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Í augnablikinu er mest þróað (og sá eini в stöðugt stigi) lausnin er rokk-ceph-rekstraraðili.

Athugið: Meðal mikilvægra breytinga á Rook 1.0.0 útgáfunni sem tengist Ceph, getum við tekið eftir stuðningi við Ceph Nautilus og getu til að nota NFS fyrir CephFS eða RGW fötu. Það sem stendur upp úr meðal annarra er þroskinn á EdgeFS stuðningi að beta stiginu.

Svo, í þessari grein við:

• Við skulum svara spurningunni um hvaða kosti við sjáum við að nota Rook til að dreifa Ceph í Kubernetes klasa;
• Við munum deila reynslu okkar og tilfinningum af því að nota Rook í framleiðslu;
• Við skulum segja þér hvers vegna við segjum „Já!“ við Rook og um áætlanir okkar um hann.

Byrjum á almennum hugtökum og kenningum.

„Ég hef forskot á einum Hróki! (óþekktur skákmaður)

Einn helsti kosturinn við Rook er að samskipti við gagnageymslur fara fram í gegnum Kubernetes kerfi. Þetta þýðir að þú þarft ekki lengur að afrita skipanirnar til að stilla Ceph af blaðinu inn í stjórnborðið.

— Viltu setja CephFS í þyrpingu? Skrifaðu bara YAML skrá!
- Hvað? Viltu líka setja upp hlutaverslun með S3 API? Skrifaðu bara aðra YAML skrá!

Rook er búið til samkvæmt öllum reglum dæmigerðs rekstraraðila. Samskipti við hann eiga sér stað með því að nota CRD (Custom Resource Definitions), þar sem við lýsum einkennum Ceph-eininga sem við þurfum (þar sem þetta er eina stöðuga útfærslan, mun þessi grein sjálfgefið tala um Ceph, nema annað sé sérstaklega tekið fram). Samkvæmt tilgreindum breytum mun stjórnandinn sjálfkrafa framkvæma þær skipanir sem nauðsynlegar eru fyrir uppsetningu.

Við skulum skoða smáatriðin með því að nota dæmið um að búa til Object Store, eða öllu heldur - 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 }}

Færibreyturnar sem tilgreindar eru í skráningunni eru nokkuð staðlaðar og þarfnast varla athugasemda, en það er þess virði að huga sérstaklega að þeim sem úthlutað er í sniðmátsbreytur.

Almennt vinnufyrirkomulag kemur niður á því að við „pöntum“ auðlindir í gegnum YAML skrá, þar sem rekstraraðilinn framkvæmir nauðsynlegar skipanir og skilar okkur „ekki svo raunverulegu“ leyndarmáli sem við getum unnið frekar með (sjá fyrir neðan). Og úr breytunum sem taldar eru upp hér að ofan verður skipunin og leyndarmálið sett saman.

Hvers konar lið er þetta? Þegar notandi er búinn til fyrir geymslu á hlutum mun Rook-stjórnandinn inni í belgnum gera eftirfarandi:

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

Niðurstaðan af því að framkvæma þessa skipun verður JSON uppbygging:

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

Keys - hvaða framtíðarforrit þurfa til að fá aðgang að geymsluplássi í gegnum S3 API. Rook rekstraraðili velur þá vinsamlega og setur þá í nafnrýmið sitt í formi leyndarmáls með nafninu rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Til að nota gögnin úr þessu leyndarmáli skaltu bara bæta þeim við ílátið sem umhverfisbreytur. Sem dæmi mun ég gefa sniðmát fyrir Job, þar sem við búum sjálfkrafa til fötu fyrir hvert notendaumhverfi:

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

Allar aðgerðir sem taldar eru upp í þessu starfi voru framkvæmdar innan ramma Kubernetes. Mannvirkin sem lýst er í YAML skrám eru geymd í Git geymslu og endurnotuð mörgum sinnum. Við lítum á þetta sem mikinn plús fyrir DevOps verkfræðinga og CI/CD ferlið í heild.

Ánægður með Rook og Rados

Notkun Ceph + RBD samsetningarinnar setur ákveðnar takmarkanir á að festa rúmmál á belg.

Sérstaklega verður nafnarýmið að innihalda leyndarmál til að fá aðgang að Ceph til að staðbundin forrit virki. Það er í lagi ef þú ert með 2-3 umhverfi í nafnasvæðum þeirra: þú getur farið og afritað leyndarmálið handvirkt. En hvað ef fyrir hvern eiginleika er búið til sérstakt umhverfi með eigin nafnrými fyrir forritara?

Við leystum þetta vandamál sjálf með því að nota skel-rekstraraðili, sem afritaði sjálfkrafa leyndarmál í ný nafnrými (dæmi um slíkan krók er lýst í Þessi grein).

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

Hins vegar, þegar þú notar Rook, er þetta vandamál einfaldlega ekki til. Uppsetningarferlið á sér stað með því að nota eigin rekla byggt á Flexvolume eða CSI (enn á beta stigi) og þarf því ekki leyndarmál.

Rook leysir sjálfkrafa mörg vandamál, sem hvetur okkur til að nota það í nýjum verkefnum.

Umsátur um Rook

Ljúkum verklega hlutanum með því að beita Rook og Ceph svo að við getum framkvæmt okkar eigin tilraunir. Til að gera það auðveldara að storma þennan óviðráðanlega turn hafa verktakarnir útbúið Helm pakka. Við skulum hlaða því niður:

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

Í skrá rook-ceph/values.yaml þú getur fundið margar mismunandi stillingar. Mikilvægast er að tilgreina þolmörk fyrir umboðsmenn og leit. Við lýstum í smáatriðum í hverju hægt er að nota blettunar-/þolsbúnaðinn Þessi grein.

Í stuttu máli viljum við ekki að biðlaraforritsbelgirnir séu staðsettir á sömu hnútum og gagnageymsludiskarnir. Ástæðan er einföld: þannig mun vinna Rook umboðsmanna ekki hafa áhrif á forritið sjálft.

Svo, opnaðu skrána rook-ceph/values.yaml með uppáhalds ritlinum þínum og bættu eftirfarandi blokk við í lokin:

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

Fyrir hvern hnút sem er frátekinn fyrir gagnageymslu skaltu bæta við samsvarandi bletti:

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

Settu síðan upp Helm töfluna með skipuninni:

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

Nú þarftu að búa til þyrping og tilgreina staðsetningu 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"

Athugar Ceph stöðu - búist við að sjá 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

Á sama tíma skulum við athuga hvort fræbelgarnir með biðlaraforritinu lendi ekki á hnútum sem eru fráteknir fyrir Ceph:

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

Ennfremur er hægt að stilla viðbótaríhluti að vild. Nánari upplýsingar um þá eru tilgreindar í skjöl. Fyrir stjórnun mælum við eindregið með því að setja upp mælaborðið og verkfærakistuna.

Rook and krókar: er Rook nóg fyrir allt?

Eins og þú sérð er þróun Rook í fullum gangi. En það eru enn vandamál sem gera okkur ekki kleift að yfirgefa handvirka uppsetningu Ceph algjörlega:

• Enginn Rook Driver getur ekki útflutningsmælingar um notkun uppsettra blokka, sem sviptir okkur eftirliti.
• Flexvolume og CSI veit ekki hvernig breyta stærð bindi (öfugt við sama RBD), þannig að Rook er sviptur gagnlegu (og stundum bráðnauðsynlegt!) tól.
• Rook er samt ekki eins sveigjanlegur og venjulegur Ceph. Ef við viljum stilla laugina fyrir CephFS lýsigögn til að geyma á SSD, og ​​gögnin sjálf til að vera geymd á HDD, þurfum við að skrá aðskilda hópa tækja í CRUSH kortum handvirkt.
• Þrátt fyrir þá staðreynd að rook-ceph-operator er talinn stöðugur, þá eru nokkur vandamál eins og er þegar Ceph er uppfært úr útgáfu 13 í 14.

Niðurstöður

„Núna er Rook lokuð frá umheiminum með peðum, en við trúum því að einn daginn muni hún gegna afgerandi hlutverki í leiknum! (tilvitnun fundin upp sérstaklega fyrir þessa grein)

Rook verkefnið hefur án efa unnið hjörtu okkar - við teljum að [með öllum kostum og göllum þess] verðskuldi það athygli þína.

Framtíðarplön okkar ganga út á að gera rook-ceph að einingu fyrir addon-rekstraraðili, sem mun gera notkun þess í fjölmörgum Kubernetes þyrpingum okkar enn einfaldari og þægilegri.

PS

Lestu líka á blogginu okkar:

• «Rook - „sjálfsafgreiðslu“ gagnavöruhús fyrir Kubernetes»;
• «Að búa til viðvarandi geymslu með úthlutun í Kubernetes byggt á Ceph»;
• «Gagnagrunnar og Kubernetes (endurskoðun og myndbandsskýrsla)»;
• «Við kynnum skeljarstjóra: að búa til rekstraraðila fyrir Kubernetes er nú orðið auðveldara»;
• «Rekstraraðilar fyrir Kubernetes: hvernig á að keyra staðbundin forrit'.

Heimild: www.habr.com