ProHoster > Blog > Administration > Praktisk eksempel på tilslutning af lagring baseret på Ceph i et Kubernetes-klynge

Praktisk eksempel på tilslutning af lagring baseret på Ceph i et Kubernetes-klynge

Container Storage Interface (CSI) er et standardiseret interface mellem Kubernetes og lagringssystemer. Vi har allerede givet en kort oversigt om det, fortaltog i dag kigger vi nærmere på integrationen af CSI og Ceph: vi viser, hvordan man tilslutter Ceph-lagring til Kubernetes-klusteret.
Artiklen indeholder virkelige, omend lidt forenklede eksempler for lettere forståelse. Vi vil ikke se på installation og opsætning af Ceph- og Kubernetes-klustre.

Er du interesseret i, hvordan det fungerer?

Praktisk eksempel på tilslutning af lagring baseret på Ceph i et Kubernetes-klynge

Så du har et Kubernetes-kluster til rådighed, oprettet med eksempelvis kubespray.Ved siden af fungerer et Ceph-kluster — det kan også installeres, for eksempel med dette playbook-sæt.Jeg håber, det er unødvendigt at nævne, at der skal være et netværk med en båndbredde på mindst 10 Gbit/s mellem dem i produktion.

Hvis du har alt det, lad os komme i gang!

Først går vi ind på en af noderne i Ceph-klusteret og kontrollerer, at alt er i orden:

ceph health
ceph -s

Dernæst opretter vi straks en pulje til RBD-diske:

ceph osd pool create kube 32
ceph osd pool application enable kube rbd

Vi går videre til Kubernetes-klusteret. Her vil vi først installere Ceph CSI-driveren til RBD. Vi vil installere den ordentligt via Helm.
Vi tilføjer lageret med chartet og får et sæt variabler fra chartet ceph-csi-rbd:

helm repo add ceph-csi https://ceph.github.io/csi-charts
helm inspect values ceph-csi/ceph-csi-rbd > cephrbd.yml

Nu skal vi udfylde filen cephrbd.yml. For at gøre dette finder vi ID for klusteret og IP-adresserne for overvågningsnoderne i Ceph:

ceph fsid  # her finder vi clusterID
ceph mon dump  # dette vil vise IP-adresserne for overvågningsnoderne

De modtagne værdier indsættes i filen cephrbd.yml. Samtidig aktiverer vi oprettelsen af PSP-politikker (Pod Security Policies). Indstillingerne i sektionerne nodeplugin og provisioner er allerede i filen, de kan ændres, som vist nedenfor:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "v2:172.18.8.5:3300/0,v1:172.18.8.5:6789/0"
      - "v2:172.18.8.6:3300/0,v1:172.18.8.6:6789/0"
      - "v2:172.18.8.7:3300/0,v1:172.18.8.7:6789/0"

nodeplugin:
  podSecurityPolicy:
    enabled: true

provisioner:
  podSecurityPolicy:
    enabled: true

Det eneste, vi nu skal gøre, er at installere chartet i Kubernetes-klusteret.

helm upgrade -i ceph-csi-rbd ceph-csi/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespace

Fantastisk, RBD-driveren fungerer!
Vi opretter en ny StorageClass i Kubernetes. Det kræver igen lidt arbejde med Ceph.

Vi opretter en ny bruger i Ceph og giver ham rettigheder til at skrive til puljen kube.:

ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'

Og nu kigger vi på adgangsnøglen, som ligger samme sted:

ceph auth get-key client.rbdkube

Kommandoen vil producere noget som:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Vi indsætter denne værdi i Secret i Kubernetes-klusteret — der, hvor det er nødvendigt userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Værdierne for nøglerne svarer til brugernavnet og dets nøgle, som angivet i
  # Ceph klyngen. Bruger-ID'en skal have adgang til puljen,
  # angivet i storage class
  userID: rbdkube
  userKey:

Og vi opretter vores hemmelighed:

kubectl apply -f secret.yaml

Dernæst har vi brug for et manifest til StorageClass som omtrent dette:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: 
   pool: kube

   imageFeatures: layering

   # Disse hemmeligheder skal indeholde data til autorisation
   # i din pulje.
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret
   csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-rbd

   csi.storage.k8s.io/fstype: ext4

reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - discard

Det skal udfyldes clusterID, som vi allerede har fundet med kommandoen ceph fsid, og anvende dette manifest i Kubernetes klyngen:

kubectl apply -f storageclass.yaml

For at teste klyngernes funktionalitet, lad os oprette en PVC (Persistent Volume Claim) som denne:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc

Lad os se, hvordan Kubernetes har oprettet den anmodede volumen i Ceph:

kubectl get pvc
kubectl get pv

Det ser ud til at være fint! Men hvordan ser det ud på Ceph-siden?
Henter listen over volumener i puljen og ser på oplysningerne om vores volumen:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # her vil der selvfølgelig være en anden volumen-ID, som den forrige kommando gav

Lad os nu se, hvordan ændringen af størrelsen på RBD-volumenet fungerer.
Ændrer størrelsen på volumenet i manifestet pvc.yaml til 2Gi og anvender det:

kubectl apply -f pvc.yaml

Lad os vente, indtil ændringerne træder i kraft, og se på volumenets størrelse igen.

rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653

kubectl get pv
kubectl get pvc

Vi ser, at størrelsen på PVC ikke er ændret. For at finde årsagen kan vi anmode Kubernetes om at beskrive PVC i YAML-format:

kubectl get pvc rbd-pvc -o yaml

Og her er problemet:

message: Waiting for user to (re-)start a pod to finish file system resize of volume on node. type: FileSystemResizePending

Det vil sige, at diskstørrelsen er steget, men filsystemet på den er ikke.
For at udvide filsystemet skal vi montere volumenet. Den oprettede PVC/PV bruges i øjeblikket ikke.

Vi kan oprette en testpod, for eksempel på denne måde:

---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx:1.17.6
      volumeMounts:
        - name: mypvc
          mountPath: /data
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

Og vi ser nu på PVC:

kubectl get pvc

Størrelsen er ændret, alt er i orden.

I første del arbejdede vi med RBD (det står for Rados Block Device), men det kan ikke gøres, hvis forskellige mikrotjenester skal arbejde med disken samtidig. For filhåndtering er CephFS meget bedre egnet.
Vi vil konfigurere CSI og de andre nødvendige enheder til at arbejde med CephFS med eksempler fra Ceph- og Kubernetes-klynger.

Lad os hente værdierne fra det Helm-diagram, vi har brug for:

helm inspect values ceph-csi/ceph-csi-cephfs > cephfs.yml

Vi skal igen udfylde filen cephfs.yml. Som før vil Ceph-kommandoerne være til hjælp:

ceph fsid
ceph mon dump

Udfyld filen med værdierne på følgende måde:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "172.18.8.5:6789"
      - "172.18.8.6:6789"
      - "172.18.8.7:6789"

nodeplugin:
  httpMetrics:
    enabled: true
    containerPort: 8091
  podSecurityPolicy:
    enabled: true

provisioner:
  replicaCount: 1
  podSecurityPolicy:
    enabled: true

Bemærk, at adressen til monitorer angives i formatet adresse:port. For montering af cephfs på noden sendes disse adresser til kerne-modulet, som endnu ikke kan arbejde med monitor-protokol v2.
Vi ændrer porten til httpMetrics (hvor Prometheus vil hente metrics til overvågning) for at undgå konflikt med nginx-proxy, der installeres af Kubespray. Du måtte ikke have brug for dette.

Vi installerer Helm-diagrammet i Kubernetes-klyngen:

helm upgrade -i ceph-csi-cephfs ceph-csi/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespace

Vi går til Ceph-datalagringen for at oprette en separat bruger. I dokumentationen står der, at CephFS-provisioneren har brug for administratorrettigheder til klyngen. Men vi vil oprette en separat bruger fs med begrænsede rettigheder:

ceph auth get-or-create client.fs mon 'allow r' mgr 'allow rw' mds 'allow rws' osd 'allow rw pool=cephfs_data, allow rw pool=cephfs_metadata'

Og lad os straks se hans adgangsnøgle, som vi senere vil få brug for:

ceph auth get-key client.fs

Vi vil oprette separate Secret og StorageClass.
Intet nyt, det har vi allerede set med RBD:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # nødvendigt for dynamisk oprettede volumener
  adminID: fs
  adminKey:

Vi anvender manifestet:

kubectl apply -f secret.yaml

Og nu – en separat StorageClass:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-cephfs-sc
provisioner: cephfs.csi.ceph.com
parameters:
  clusterID: 

  # Navn på CephFS-filsystemet, hvor volumenet vil blive oprettet
  fsName: cephfs

  # (valgfrit) Pool i Ceph, hvor data for volumenet vil blive gemt
  # pool: cephfs_data

  # (valgfrit) Komma-separerede monteringsmuligheder for Ceph-fuse
  # f.eks.:
  # fuseMountOptions: debug

  # (valgfrit) Komma-separerede monteringsmuligheder for CephFS til kernen
  # Se man mount.ceph for en liste over disse muligheder. F.eks.:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Hemmeligheder skal indeholde adgang for admin og/eller Ceph-bruger.
  csi.storage.k8s.io/provisioner-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/controller-expand-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/node-stage-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-cephfs

  # (valgfrit) Driveren kan bruge enten ceph-fuse (fuse) 
  # eller ceph kernelclient (kernel).
  # Hvis ikke angivet, anvendes standard monteringsmetoden,
  # som bestemmes ved at lede efter ceph-fuse og mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Lad os fylde noget herud clusterID og anvende det i Kubernetes:

kubectl apply -f storageclass.yaml

Kontrol

For at kontrollere, som i det tidligere eksempel, opretter vi en PVC:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-cephfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: csi-cephfs-sc

Og vi kontrollerer tilgængeligheden af PVC/PV:

kubectl get pvc
kubectl get pv

Hvis du ønsker at se på filer og mapper i CephFS, kan du montere dette filsystem et sted. For eksempel, som vist nedenfor.

Vi tager til en af Ceph-klyngeknudepunkterne og udfører disse handlinger:

# Точка монтирования
mkdir -p /mnt/cephfs

# Создаём файл с ключом администратора
ceph auth get-key client.admin >/etc/ceph/secret.key

# Добавляем запись в /etc/fstab
# !! Изменяем ip адрес на адрес нашего узла
echo "172.18.8.6:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev    0       2" >> /etc/fstab

mount /mnt/cephfs

Naturligvis er en sådan montering af FS på Ceph-knuden kun til uddannelsesmæssige formål, hvilket er, hvad vi arbejder med på vores Slurm-kurser.. Jeg tror ikke, at nogen vil gøre dette i produktion, da der er stor risiko for ved et uheld at overskrive vigtige filer.

Og sidst, lad os se på, hvordan det går med at ændre volumenstørrelsen i tilfælde af CephFS. Vi går tilbage til Kubernetes og redigerer vores manifest for PVC — vi vil øge størrelsen til for eksempel 7Gi.

Vi anvender den redigerede fil:

kubectl apply -f pvc.yaml

Lad os se på den monterede mappe og se, hvordan kvoten er ændret:

getfattr -n ceph.quota.max_bytes

For at få denne kommando til at fungere, skal du muligvis installere pakken attr.

Øjnene frygter, men hænderne handler

Ved første øjekast kan disse magiske formularer og lange YAML-manifester virke komplicerede, men i praksis klarer Slørm-studerende sig hurtigt med dem.
I denne artikel har vi ikke dykket ned i detaljer - det har den officielle dokumentation til. Hvis du er interesseret i detaljer om opsætning af Ceph-lagring sammen med et Kubernetes-cluster, kan disse links hjælpe:

Generelle principper for Kubernetes med volumener
Dokumentation om RBD
Integration af RBD og Kubernetes set fra Ceph
Integration af RBD og Kubernetes set fra CSI
Generel dokumentation for CephFS
Integration af CephFS og Kubernetes set fra CSI

På Slørm-kurset Kubernetes Basis kan du gå et skridt videre og implementere en rigtig applikation i Kubernetes, der bruger CephFS som lagring til filer. Gennem GET/POST-anmodninger kan du overføre filer og hente dem fra Ceph.

Og hvis du er mere interesseret i datalagring, så tilmeld dig et nyt kursus om Ceph. Mens beta-testen pågår, kan kurset fås med rabat, og du kan påvirke indholdet.

Forfatter til artiklen: Alexander Shvalov, praktiserende ingeniør Southbridge, Certified Kubernetes Administrator, forfatter og udvikler af Slørm-kurser.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster