Rook oder net Rook - dat ass d'Fro

Am Ufank vun dësem Mount, den 3. Mee, gouf eng grouss Verëffentlechung vun engem "Gestiounssystem fir verdeelt Datelagerung an Kubernetes" ugekënnegt - Rouer 1.0.0. Viru méi wéi engem Joer hu mer schonn publizéiert allgemeng Iwwersiicht vun Rook. Da si mir gefrot iwwer seng Erfahrung ze schwätzen an der Praxis benotzen - an elo, grad an der Zäit fir esou e bedeitende Meilesteen an der Geschicht vum Projet, si mir frou eis gesammelt Andréck ze deelen.

Kuerz gesot, Rook ass e Set Opérateuren fir Kubernetes, déi voll Kontroll iwwer d'Deployment, d'Gestioun, d'automatesch Erhuelung vun Datenspeicherléisungen wéi Ceph, EdgeFS, Minio, Cassandra, CockroachDB iwwerhuelen.

Am Moment déi meescht entwéckelt (an den eenzegen в stabil Etapp) d'Léisung ass Rook-ceph-Operateur.

Remarque: Ënnert de bedeitende Ännerunge vun der Rook 1.0.0 Verëffentlechung am Zesummenhang mat Ceph, kënne mir Ënnerstëtzung fir Ceph Nautilus an d'Fäegkeet notéieren NFS fir CephFS oder RGW Eemer ze benotzen. Wat ënner anerem erausstécht ass d'Reifung vun der EdgeFS Support op de Beta Niveau.

Also, an dësem Artikel mir:

• Loosst eis d'Fro beäntweren iwwer wéi eng Virdeeler mir gesinn beim Rook ze benotzen fir Ceph an engem Kubernetes Cluster z'installéieren;
• Mir wäerten eis Erfahrung an Impressiounen vun benotzt Rook an Produktioun deelen;
• Loosst eis Iech soen firwat mir "Jo!" zu Rook soen, an iwwer eis Pläng fir hien.

Loosst eis mat allgemenge Konzepter an Theorie ufänken.

"Ech hunn e Virdeel vun engem Rook!" (onbekannte Schachspiller)

Ee vun den Haaptvirdeeler vum Rook ass datt d'Interaktioun mat Datengeschäfter duerch Kubernetes Mechanismen duerchgefouert gëtt. Dëst bedeit datt Dir d'Befehle net méi musst kopéieren fir Ceph vum Blat an d'Konsole ze konfiguréieren.

- Wëllt Dir CephFS an engem Cluster ofsetzen? Schreift einfach eng YAML Datei!
- Waat? Wëllt Dir och en Objektgeschäft mat S3 API ofsetzen? Schreift einfach eng zweet YAML Datei!

Rook gëtt no all de Regele vun engem typesche Bedreiwer erstallt. Interaktioun mat him geschitt benotzt CRD (Custom Resource Definitions), an deem mir d'Charakteristiken vun Ceph Entitéite beschreiwen mir brauchen (well dëst déi eenzeg stabil Ëmsetzung ass, wäert dësen Artikel par défaut iwwer Ceph schwätzen, ausser explizit anescht uginn). No de spezifizéierte Parameteren wäert de Bedreiwer automatesch d'Kommandoen ausféieren, déi fir d'Konfiguratioun néideg sinn.

Loosst eis d'Spezifizitéite kucken mat dem Beispill fir en Object Store ze kreéieren, oder éischter - 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 }}

D'Parameteren, déi an der Oplëschtung uginn sinn, sinn zimmlech Standard a brauche kaum Kommentaren, awer et ass derwäert besonnesch Opmierksamkeet op déi ze bezuelen, déi un d'Schablounvariablen zougewisen sinn.

Den allgemenge Schema vun der Aarbecht kënnt op d'Tatsaach, datt mir Ressourcen duerch eng YAML-Datei "bestellen", fir déi de Bedreiwer déi néideg Kommandoen ausféiert an eis e "net-sou-real" Geheimnis zréckginn, mat deem mir weider kënne schaffen (kuckt ënnen). A vun de Variabelen uewen opgezielt, gëtt de Kommando an de geheime Numm kompiléiert.

Wéi eng Equipe ass dëst? Wann Dir e Benotzer fir Objektlagerung erstellt, wäert de Rook Bedreiwer am Pod déi folgend maachen:

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

D'Resultat vun der Ausféierung vun dësem Kommando wäert eng JSON Struktur sinn:

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

Keys - wat zukünfteg Uwendungen brauchen fir Zougang zu Objektlagerung iwwer d'S3 API. De Rook Bedreiwer wielt se frëndlech a setzt se a sengem Nummraum a Form vun engem Geheimnis mam Numm rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Fir d'Donnéeën aus dësem Geheimnis ze benotzen, füügt se just un de Container als Ëmfeldvariablen. Als Beispill ginn ech eng Schabloun fir Job, an där mir automatesch Eemer fir all Benotzerëmfeld erstellen:

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

All Aktiounen, déi an dësem Job opgezielt sinn, goufen am Kader vu Kubernetes gemaach. D'Strukturen, déi an YAML Dateien beschriwwe ginn, ginn an engem Git Repository gespäichert a vill Mol erëmbenotzt. Mir gesinn dëst als e grousse Plus fir DevOps Ingenieuren an den CI / CD Prozess als Ganzt.

Glécklech mam Rook a Rados

D'Benotzung vun der Ceph + RBD Kombinatioun setzt gewësse Restriktiounen op d'Montage vu Volumen op Pods.

Besonnesch muss den Nummraum e Geheimnis enthalen fir Zougang zu Ceph fir staatlech Uwendungen ze funktionéieren. Et ass ok wann Dir 2-3 Ëmfeld an hiren Nummraim hutt: Dir kënnt d'Geheimnis manuell kopéieren. Awer wat wann fir all Feature en separaten Ëmfeld mat engem eegene Nummraum fir Entwéckler erstallt gëtt?

Mir geléist dëse Problem selwer benotzt Shell-Operateur, déi automatesch Geheimnisser an nei Nummraim kopéiert hunn (e Beispill vun esou engem Hook gëtt an dësen Artikel).

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

Wéi och ëmmer, wann Dir Rook benotzt, existéiert dëse Problem einfach net. De Montageprozess geschitt mat hiren eegene Chauffeuren baséiert op Flexvolumen oder CSI (nach ëmmer an der Beta-Bühn) a brauch dofir keng Geheimnisser.

Rook léist automatesch vill Problemer, wat eis encouragéiert et an neie Projeten ze benotzen.

Belagerung vum Rook

Loosst eis de prakteschen Deel fäerdeg maachen andeems Dir Rook a Ceph ofsetzt fir datt mir eis eegen Experimenter kënne maachen. Fir et méi einfach ze maachen, dësen impregnable Tuerm ze stiermen, hunn d'Entwéckler e Helm Package virbereet. Loosst eis et eroflueden:

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

Am Dossier rook-ceph/values.yaml Dir kënnt vill verschidden Astellungen fannen. Déi wichtegst Saach ass d'Toleratioune fir Agenten a Sich ze spezifizéieren. Mir hunn am Detail beschriwwen wat d'Tënt / Toleratiounsmechanismus ka benotzt ginn dësen Artikel.

Kuerz gesot, mir wëllen net datt d'Client Applikatioun Pods op déiselwecht Wirbelen wéi d'Datespeicherdisken lokaliséiert sinn. De Grond ass einfach: sou wäert d'Aarbecht vun de Rook Agenten d'Applikatioun selwer net beaflossen.

Also, öffnen d'Datei rook-ceph/values.yaml mat Ärem Liiblingseditor a füügt de folgende Block um Enn bäi:

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

Fir all Node reservéiert fir Datelagerung, füügt de entspriechende Schnéi:

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

Installéiert dann den Helm Diagramm mam Kommando:

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

Elo musst Dir e Stärekoup erstellen an de Standuert spezifizéieren 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"

Iwwerpréift Ceph Status - erwaart ze gesinn 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

Zur selwechter Zäit, loosst eis kontrolléieren datt d'Pods mat der Clientapplikatioun net op Noden ophalen, déi fir Ceph reservéiert sinn:

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

Weider kënnen zousätzlech Komponenten wéi gewënscht konfiguréiert ginn. Méi Detailer iwwer si ginn uginn an Dokumentatioun. Fir d'Administratioun empfeelen mir staark den Dashboard an d'Toolbox z'installéieren.

Rook an Haken: ass Rook genuch fir alles?

Wéi Dir gesitt, ass d'Entwécklung vum Rook amgaang. Awer et ginn nach ëmmer Probleemer déi eis net erlaben d'manuell Konfiguratioun vu Ceph komplett opzeginn:

• Nee Rook Driver kann nët Export Metriken iwwer d'Benotzung vu montéierte Blocken, déi eis d'Iwwerwaachung entzunn.
• Flexvolume an CSI weess net wéi änneren d'Gréisst vun de Bänn (am Géigesaz zu der selwechter RBD), sou datt Rook vun engem nëtzlechen (an heiansdo kritesch néideg!) Tool entzu gëtt.
• Rook ass nach ëmmer net sou flexibel wéi normal Ceph. Wa mir de Pool fir CephFS Metadaten konfiguréieren fir op SSD ze späicheren, an d'Donnéeën selwer op HDD ze späicheren, musse mir separat Gruppen vun Apparater an CRUSH Kaarten manuell registréieren.
• Trotz der Tatsaach, datt de Rook-Ceph-Bedreiwer als stabil ugesi gëtt, ginn et momentan e puer Probleemer beim Upgrade vum Ceph vun der Versioun 13 op 14.

Conclusiounen

"De Moment ass de Rook vun der Äussewelt vu Baueren zougemaach, awer mir gleewen datt si enges Daags eng entscheedend Roll am Spill wäert spillen!" (Zitat speziell fir dësen Artikel erfonnt)

De Rook-Projet huet ouni Zweifel eis Häerzer gewonnen - mir gleewen datt [mat all senge Vir- an Nodeeler] et definitiv Är Opmierksamkeet verdéngt.

Eis Zukunftspläng kachen erof fir Rook-Ceph e Modul ze maachen fir addon-Operateur, wat seng Notzung an eise ville Kubernetes Cluster nach méi einfach a méi praktesch mécht.

PS

Liest och op eisem Blog:

• «Rook - "Self-Service" Datelager fir Kubernetes";
• «Erstellt persistent Späichere mat Bestëmmung a Kubernetes baséiert op Ceph";
• «Datenbanken a Kubernetes (Iwwerpréiwung a Videobericht)";
• «Shell-Bedreiwer aféieren: Bedreiwer fir Kubernetes erstellen ass just méi einfach ginn";
• «Bedreiwer fir Kubernetes: wéi stateful Uwendungen ze lafen".

Source: will.com