Rook eller inte Rook — det är frågan

I början av den här månaden, den 3 maj, tillkännagavs en stor release av "hanteringssystemet för distribuerade datalagringslösningar i Kubernetes" — Rook 1.0.0. För mer än ett år sedan publicerade vi en översikt av Rook. Då bad vi om att få dela med oss av erfarenheterna från dess praktiska användning — och nu, precis i tid för denna betydelsefulla milstolpe i projektets historia, är vi glada att dela med oss av våra insikter. Kort sagt, Rook är en uppsättning

operatörer för Kubernetes, som helt tar kontroll över distributionen, hanteringen och den automatiska återställningen av sådana datalagringslösningar som Ceph, EdgeFS, Minio, Cassandra, CockroachDB. För närvarande är den mest avancerade (och

enda stabila på lösningen rook-ceph-operator : bland de betydande förändringarna i Rook 1.0.0 relaterade till Ceph, kan man notera stödet för Ceph Nautilus och möjligheten att använda NFS för CephFS- eller RGW-behållare. Bland annat framhävs "mognaden" av stödet för EdgeFS till beta-nivå..

AnmärkningSå, i denna artikel kommer vi att:

svara på frågan om vilka fördelar vi ser med att använda Rook för distribution av Ceph i ett Kubernetes-kluster;

• dela med oss av erfarenheterna och intrycken av att använda Rook i produktion;
• berätta varför vi säger "Ja!" till Rook, och om våra planer för det.
• Vi börjar med allmänna koncept och teori.

"Jag har en fördel på en Torn!" (okänd schackspelare)

En av de stora fördelarna med Rook är att interaktionen med datalagringslösningarna sker genom Kubernetes-mekanismer. Detta innebär att du inte längre behöver kopiera kommandon från pappret till konsolen för att konfigurera Ceph.

— Vill du distribuera CephFS i klustret? Skriv bara en YAML-fil!

— Vad? Vill du även distribuera en objektlagring med S3 API? Skriv bara en andra YAML-fil!
Rook är skapad enligt alla regler för en typisk operator. Interaktionen med den sker via

CRD (Custom Resource Definitions) , där vi beskriver de egenskaper vi behöver för Ceph-entiteter(eftersom detta är den enda stabila implementeringen kommer artikeln automatiskt att handla om Ceph, om inget annat anges) . Enligt de angivna parametrarna kommer operatören automatiskt att utföra de kommandon som krävs för konfigurationen.Låt oss konkreta det med ett exempel på att skapa ett Object Store, mer specifikt —

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

De angivna parametrarna i listan är ganska standard och behöver knappast kommentarer, men särskild uppmärksamhet bör riktas mot de som är markerade som mallvariabler.

Den övergripande arbetsmodellen är att vi via en YAML-fil "beställer" resurser, som operatören utför nödvändiga kommandon för och returnerar oss ett "inte helt riktigt" hemligt värde som vi sedan kan arbeta med. (se nedan). Från de variabler som ovan anges, kommer ett kommando och namnet på hemligheten att skapas.

Vad är då detta kommando? Vid skapandet av en användare för objektlagring kommer Rook-operatören att inuti podden utföra följande:

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

Resultatet av detta kommando kommer att vara en JSON-struktur:

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

Nycklar — det som framtida applikationer behöver för att få åtkomst till objektlagringen via S3 API. Rook-operatören väljer vänligt dessa och lagrar dem i sitt namespace som en hemlighet med namnet rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

För att använda uppgifterna från denna hemlighet räcker det att lägga till dem i containern som miljövariabler. Som exempel ger jag en mall för en jobb där vi automatiskt skapar bucketar för varje användarmiljö:

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

Alla åtgärder som anges i detta jobb har genomförts utan att gå utanför Kubernetes. Strukturerna som beskrivs i YAML-filerna har lagrats i ett Git-förråd och kan användas om och om igen. Detta är en stor fördel för DevOps-ingenjörer och CI/CD-processen som helhet.

Med Rook och Rados blir det enklare.

Användningen av kombinationen Ceph + RBD innebär vissa begränsningar för att kunna montera volymer till poddar.

Specifikt måste det finnas en hemlighet i namnområdet för att få åtkomst till Ceph, så att stateful-applikationer kan fungera. Det är okej om du har 2-3 miljöer i dina namnområden: du kan gå och kopiera hemligheten manuellt. Men vad gör man om för varje feature för utvecklarna skapas en egen miljö med sitt eget namnområde?

Vi löste detta problem genom shell-operator, som automatiskt kopierade hemligheter till nya namnområden (ett exempel på en sådan hook beskrivs i denna 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

Men vid användning av Rook existerar inte detta problem längre. Monteringsprocessen sker genom egna drivrutiner baserade på Flexvolume eller CSI (fortfarande i betastadiet) och kräver därför inte några hemligheter.

Rook löser automatiskt många problem, vilket driver oss att använda det i nya projekt.

Belägringen av Rook

Vi avslutar den praktiska delen med att installera Rook och Ceph för att möjliggöra egna experiment. För att lättare kunna erövra detta oföränderliga torn har utvecklarna förberett ett Helm-paket. Låt oss ladda ner det:

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

I filen rook-ceph/values.yaml man kan hitta många olika inställningar. Det viktigaste är att ange tolerations för agenter och sökning. Vi har tidigare gått igenom hur mekanismen taints/tolerations fungerar i denna artikel.

Kort sagt, vi vill inte att pods med den klientapplikation som används ska placeras på de noder där lagringsdiskarna finns. Anledningen är enkel: på så sätt påverkar Rook-agenterna inte själva applikationen.

Så, öppna filen rook-ceph/values.yaml i din favorittextredigerare och lägg till följande block i slutet:

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

Till varje nod som reserveras för datalagring lägger vi till motsvarande taint:

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

Därefter installerar vi Helm-diagrammet med kommandot:

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

Nu behöver vi skapa en kluster och ange platsen för 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"

Kontrollera statusen för Ceph — vi förväntar oss att se 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

Därefter kontrollerar vi att pods med klientapplikationen inte hamnar på noder reserverade för Ceph:

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

Vidare kan man valfritt konfigurera ytterligare komponenter. Mer information om dem finns i dokumentationen. För administration rekommenderar vi starkt att installera dashboard och toolbox.

Rook-krokar: räcker Rook till för allt?

Som man kan se, är utvecklingen av Rook i full gång. Men det finns fortfarande problem som hindrar oss från att helt överge manuell konfiguration av Ceph:

• Ingen Rook-drivrutin kan ex exportera mätvärden för användning av monterade block, vilket gör att vi saknar övervakning.
• Flexvolume och CSI kan inte kan inte ändra storlek på volymer (till skillnad från samma RBD), vilket gör att Rook saknar ett användbart (och ibland kritiskt nödvändigt!) verktyg.
• Rook är fortfarande inte lika flexibel som vanlig Ceph. Om vi vill konfigurera så att poolen för CephFS metadata lagras på SSD och själva datan på HDD, måste vi manuellt ange separata enhetsgrupper i CRUSH-kartor.
• Trots att rook-ceph-operator anses stabil, finns det för närvarande vissa problem vid uppgradering av Ceph från version 13 till 14.

Slutsatser

«Just nu är Ladya stängd från omvärlden av bönder, men vi tror att den en dag kommer att spela en avgörande roll i partiet!» (citatet är uppdiktat särskilt för denna artikel)

Projektet Rook har utan tvekan vunnit våra hjärtan — vi anser att [med alla sina fördelar och nackdelar] förtjänar det verkligen också din uppmärksamhet.

Våra framtida planer handlar om att göra rook-ceph till en modul för addon-operator, vilket gör att dess användning i våra många Kubernetes-kluster blir ännu enklare och bekvämare.

P.S.

Läs även i vår blogg:

• «Rook — en "självbetjänande" datalagring för Kubernetes»;
• «Skapa permanent lagring med provisioning i Kubernetes baserat på Ceph»;
• «Databaser och Kubernetes (översikt och videoföreläsning)»;
• «Presenterar shell-operator: att skapa operatörer för Kubernetes har blivit ännu enklare»;
• «Operatörer för Kubernetes: hur man kör stateful-applikationer».

Källa: habr.com