🥇 Vanker või mitte Vanker – selles on küsimus

Selle kuu alguses, 3. mail, kuulutati välja "Kubernetes'i hajutatud andmesalvestuse haldussüsteem" - Vanker 1.0.0. Rohkem kui aasta tagasi me juba avaldatud üldine ülevaade Rookist. Siis paluti meil rääkida tema kogemusest praktikas kasutada — ja nüüd, just õigel ajal projekti ajaloo nii olulise verstaposti jaoks, jagame hea meelega oma kogunenud muljeid.

Lühidalt, Rook on komplekt operaatorid Kubernetese jaoks, kes võtavad täieliku kontrolli andmesalvestuslahenduste (nt Ceph, EdgeFS, Minio, Cassandra, CockroachDB) juurutamise, haldamise ja automaatse taastamise üle.

Praegu kõige arenenum (ja ainus в stabiilne etapp) lahendus on rook-tseph-operaator.

Märkus: Cephiga seotud Rook 1.0.0 versiooni oluliste muudatuste hulgas võime märkida Ceph Nautiluse tuge ja võimalust kasutada NFS-i CephFS-i või RGW-ämbrite jaoks. Muu hulgas paistab silma EdgeFS-i toe küpsemine beetatasemele.

Niisiis, selles artiklis me:

Vastame küsimusele, milliseid eeliseid näeme Rooki kasutamisel Cephi juurutamiseks Kubernetese klastris;
Jagame oma kogemusi ja muljeid Rooki kasutamisest tootmises;
Räägime teile, miks me Rookile "Jah!" ütleme, ja meie plaanidest temaga.

Alustame üldistest mõistetest ja teooriast.

"Mul on üks vanker eelis!" (tundmatu maletaja)

Rooki üks peamisi eeliseid on see, et andmesalvedega suhtlemine toimub Kubernetese mehhanismide kaudu. See tähendab, et te ei pea enam Cephi seadistamise käske lehelt konsooli kopeerima.

— Kas soovite juurutada CephFS-i klastris? Kirjutage lihtsalt YAML-fail!
- Mida? Kas soovite juurutada ka S3 API-ga objektipoodi? Lihtsalt kirjutage teine YAML-fail!

Vanker on loodud kõigi tüüpilise operaatori reeglite järgi. Temaga suhtlemine toimub kasutades CRD (kohandatud ressursi määratlused), milles kirjeldame meile vajalike Ceph-üksuste omadusi (kuna see on ainus stabiilne rakendus, siis vaikimisi räägitakse selles artiklis Cephist, kui pole selgesõnaliselt öeldud teisiti). Vastavalt määratud parameetritele täidab operaator automaatselt konfigureerimiseks vajalikud käsud.

Vaatame üksikasju objektipoe loomise näitel või õigemini - 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 }}

Loendis näidatud parameetrid on üsna standardsed ega vaja peaaegu kommentaare, kuid erilist tähelepanu tasub pöörata malli muutujatele määratud parameetritele.

Üldine tööskeem taandub asjaolule, et "tellime" ressursse YAML-faili kaudu, mille jaoks operaator täidab vajalikud käsud ja tagastab meile "mitte-nii-reaalse" saladuse, millega saame edasi töötada. (vt allpool). Ja ülalloetletud muutujatest koostatakse käsk ja salanimi.

Mis meeskond see selline on? Objektide salvestamiseks kasutajat luues teeb kausta sees olev Rook operaator järgmist:

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

Selle käsu täitmise tulemuseks on JSON-struktuur:

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

Keys - millised tulevased rakendused peavad S3 API kaudu objektide salvestusruumi juurde pääsema. Vankri operaator valib need lahkelt välja ja paneb oma nimeruumi nimega saladuse kujul rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Selle saladuse andmete kasutamiseks lisage need lihtsalt keskkonnamuutujatena konteinerisse. Näitena toon Jobi malli, milles loome automaatselt iga kasutajakeskkonna jaoks ämbrid:

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

Kõik selles töös loetletud toimingud viidi läbi Kubernetese raames. YAML-failides kirjeldatud struktuurid salvestatakse Giti hoidlasse ja neid kasutatakse korduvalt. Näeme seda DevOpsi inseneride ja CI/CD protsessi kui terviku jaoks tohutu plussina.

Rooki ja Radosega rahul

Ceph + RBD kombinatsiooni kasutamine seab teatud piirangud kaunadele paigaldamise mahtudele.

Eelkõige peab nimeruum sisaldama Cephile juurdepääsu saladust, et olekupõhised rakendused töötaksid. See on okei, kui teil on nende nimeruumides 2-3 keskkonda: võite minna ja kopeerida saladus käsitsi. Aga mis siis, kui iga funktsiooni jaoks luuakse arendajatele eraldi keskkond oma nimeruumiga?

Lahendasime selle probleemi ise kasutades kesta operaator, mis kopeeris saladused automaatselt uutesse nimeruumidesse (sellise konksu näidet kirjeldatakse artiklis see artikkel).

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

Kuid Rooki kasutamisel seda probleemi lihtsalt ei eksisteeri. Paigaldusprotsess toimub oma draiverite abil, mis põhinevad Flexvolume või CSI (veel beetafaasis) ja seetõttu ei nõua saladusi.

Rook lahendab automaatselt paljud probleemid, mis julgustab meid seda uutes projektides kasutama.

Rooki piiramine

Lõpetame praktilise osa, rakendades Rooki ja Cephi, et saaksime oma katseid läbi viia. Selle immutamatu torni tormimise hõlbustamiseks on arendajad koostanud Helmi paketi. Laadime selle alla:

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

Failis rook-ceph/values.yaml leiate palju erinevaid seadeid. Kõige olulisem on agentide ja läbiotsimise lubade täpsustamine. Kirjeldasime üksikasjalikult, milleks kahjustuste/taluvuste mehhanismi saab kasutada see artikkel.

Lühidalt, me ei taha, et kliendirakendused asuksid samades sõlmedes kui andmesalvestuskettad. Põhjus on lihtne: nii ei mõjuta Rooki agentide töö rakendust ennast.

Niisiis, avage fail rook-ceph/values.yaml oma lemmikredaktoriga ja lisage lõppu järgmine plokk:

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

Lisage iga andmesalvestuseks reserveeritud sõlme jaoks vastav mustus:

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

Seejärel installige Helmi diagramm käsuga:

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

Nüüd peate looma klastri ja määrama asukoha 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"

Cephi staatuse kontrollimine - oodake, et näha 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

Samal ajal kontrollime, et kliendirakendusega kaunad ei satuks Cephi jaoks reserveeritud sõlmedesse:

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

Lisaks saab soovi korral konfigureerida lisakomponente. Lisateavet nende kohta on märgitud dokumentatsioon. Haldamiseks soovitame tungivalt paigaldada armatuurlaud ja tööriistakast.

Vanker ja konksud: kas vanker on kõige jaoks piisav?

Nagu näha, on Rooki areng täies hoos. Kuid endiselt on probleeme, mis ei võimalda meil Cephi käsitsi seadistamisest täielikult loobuda:

Vankrijuhti pole ei saa ekspordimõõdikud monteeritud plokkide kasutamise kohta, mis jätab meid ilma jälgimisest.
Flexvolume ja CSI ei tea kuidas muuta köidete suurust (erinevalt sama RBD-st), nii et Rook jääb ilma kasulikust (ja mõnikord kriitiliselt vajalikust!) tööriistast.
Rook pole ikka veel nii paindlik kui tavaline Ceph. Kui tahame konfigureerida basseini nii, et CephFS-i metaandmed salvestatakse SSD-le ja andmed ise HDD-le, peame CRUSH-kaartidel käsitsi registreerima eraldi seadmete rühmad.
Hoolimata asjaolust, et rook-ceph-operaatorit peetakse stabiilseks, esineb praegu Cephi versioonilt 13 versioonilt 14 uuendamisel probleeme.

Järeldused

"Praegu on Rook välismaailmast etturitega suletud, kuid usume, et ühel päeval on tal mängus otsustav roll!" (tsitaat leiutatud spetsiaalselt selle artikli jaoks)

Projekt Rook on kahtlemata võitnud meie südamed – usume, et [koos oma plusside ja miinustega] väärib see kindlasti teie tähelepanu.

Meie tulevikuplaanid taanduvad rook-cephi mooduli loomisele lisand-operaator, mis muudab selle kasutamise meie arvukates Kubernetese klastrites veelgi lihtsamaks ja mugavamaks.

PS

Loe ka meie blogist:

Allikas: www.habr.com

Rookile või mitte Rookile – selles on küsimus

"Mul on üks vanker eelis!" (tundmatu maletaja)

Rooki ja Radosega rahul

Rooki piiramine

Vanker ja konksud: kas vanker on kõige jaoks piisav?

Järeldused

PS

Lisa kommentaar Tühista vastus