Ett praktiskt exempel på anslutning av ett lagringssystem baserat på Ceph i en Kubernetes-kluster.

Container Storage Interface (CSI) är ett enhetligt gränssnitt för interaktion mellan Kubernetes och lagringssystem. Kortfattat har vi redan om hur de tillämpar teknologin för en ovanlig uppgift — att hitta fel i rubriker.) I slutändan lyckades vi automatisera upp till 90 % av flödet beroende på tjänsten., men idag kommer vi att titta närmare på kopplingen mellan CSI och Ceph: vi kommer att visa hur ansluta Ceph-lagring till Kubernetes-klustret.
Artikeln innehåller verkliga, även om de är något förenklade för att underlätta förståelsen exempel. Installationen och konfigurationen av Ceph- och Kubernetes-kluster kommer vi inte att ta upp.

Är du nyfiken på hur det fungerar?

Så, du har ett Kubernetes-kluster tillgängligt, till exempel kubespray. Bredvid det körs ett Ceph-kluster – det kan också installeras, till exempel med detta uppsättning spelböcker. Jag hoppas att det inte behöver nämnas att det mellan dem i produktion bör finnas ett nätverk med en bandbredd på minst 10 Gbit/s.

Om du har allt detta, då kör vi!

Först går vi in på en av noderna i Ceph-klustret och kontrollerar att allt står rätt till:

ceph health
ceph -s

Därefter skapar vi direkt en pool för RBD-diskar:

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

Vi går till Kubernetes-klustret. Där installerar vi först Ceph CSI-drivrutinen för RBD. Vi kommer att installera det, som vi ska, via Helm.
Vi lägger till ett repository med diagrammet och får en uppsättning diagramvariabler för 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 måste vi fylla i filen cephrbd.yml. För detta tar vi reda på ID för klustret och IP-adresserna till monitorerna i Ceph:

ceph fsid  # så får vi clusterID
ceph mon dump  # så ser vi IP-adresserna till monitorerna

De erhållna värdena förs in i filen cephrbd.yml. Samtidigt aktiverar vi skapandet av PSP-policyer (Pod Security Policies). Alternativen i avsnitt nodeplugin och provisioner finns redan i filen, de kan ändras som visas nedan:

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

Därefter är allt vi har kvar att göra att installera diagrammet i Kubernetes-klustret.

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

Perfekt, RBD-drivrutinen fungerar!
Låt oss skapa en ny StorageClass i Kubernetes. För detta kommer vi återigen att behöva arbeta lite med Ceph.

Vi skapar en ny användare i Ceph och ger den rättigheter att skriva till poolen kube:

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

Och nu kan vi se åtkomstnyckeln där:

ceph auth get-key client.rbdkube

Kommandot kommer att ge något liknande:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Vi kommer att lägga detta värde i Secret i Kubernetes-klustret — dit där det behövs userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Värdena för nycklarna motsvarar användarnamn och dess nyckel, som angivits i
  # Ceph-klustret. Användarens ID måste ha åtkomst till poolen,
  # som anges i lagringsklassen
  userID: rbdkube
  userKey:

Och vi skapar vår hemlighet:

kubectl apply -f secret.yaml

Därefter behöver vi en sådan manifest för StorageClass:

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

   imageFeatures: layering

   # Dessa hemligheter måste innehålla data för autentisering
   # mot din pool.
   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 måste fyllas i clusterID, som vi redan har fått veta med kommandot ceph fsid, och vi ska tillämpa denna manifest i Kubernetes-klustret:

kubectl apply -f storageclass.yaml

För att kontrollera hur kluster fungerar tillsammans, låt oss skapa en sådan PVC (Persistent Volume Claim):

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

Låt oss genast se hur Kubernetes skapade den begärda volymen i Ceph:

kubectl get pvc
kubectl get pv

Ser ut som allt är bra! Men hur ser det ut på Ceph-sidan?
Vi får en lista över volymer i poolen och ser information om vår volym:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # här kommer givetvis ett annat volym-ID som gavs av föregående kommando

Låt oss nu se hur storleksändringen av RBD-volymen fungerar.
Vi ändrar storleken på volymen i manifestet pvc.yaml till 2Gi och tillämpar det:

kubectl apply -f pvc.yaml

Låt oss vänta på att ändringarna träder i kraft och se på storleken på volymen igen.

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

kubectl get pv
kubectl get pvc

Vi ser att storleken på PVC inte har ändrats. För att ta reda på orsaken kan vi be Kubernetes beskriva PVC:n i YAML-format:

kubectl get pvc rbd-pvc -o yaml

Och här är problemet:

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

Det vill säga att disken har ökat, men filsystemet på den har inte.
För att öka filsystemet måste volymen monteras. Vår skapade PVC/PV används varken nu.

Vi kan skapa en test-Pod, till exempel så här:

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

Och nu låt oss titta på PVC:

kubectl get pvc

Storleken har ändrats, allt är i sin ordning.

I den första delen arbetade vi med RBD-blockenheten (det står för Rados Block Device), men det går inte att göra så om olika mikrotjänster behöver arbeta med denna disk samtidigt. För att hantera filer, istället för diskavbildningar, är CephFS mycket bättre lämpad.
Vi kommer att konfigurera CSI och andra nödvändiga enheter för att arbeta med CephFS i Exempel på Ceph- och Kubernetes-kluster.

Vi får värden från den nödvändiga nya Helm-diagrammet:

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

Det är återigen nödvändigt att fylla i filen cephfs.yml. Precis som tidigare kommer Ceph-kommandon att hjälpa:

ceph fsid
ceph mon dump

Vi fyller i filen med värden ungefär så här:

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

Observera att monitoradresserna anges i enkel form address:port. För att montera cephfs på noden skickas dessa adresser till kärnmodulen, som ännu inte kan hantera v2-monitorprotokollet.
Porten för httpMetrics (där Prometheus kommer att hämta metrics för övervakning) ändrar vi så att den inte konflikterar med nginx-proxy, som installeras av Kubespray. Du kanske inte behöver göra detta.

Vi installerar Helm-diagrammet i Kubernetes-klustret:

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

Vi går till Ceph-lagringen för att skapa en separat användare där. Dokumentationen anger att CephFS-provisioneraren behöver admin-rättigheter till klustret. Men vi kommer att skapa en separat användare fs med begränsade rättigheter:

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'

Och låt oss omedelbart titta på dess åtkomstnyckel, den kommer att vara användbar för oss senare:

ceph auth get-key client.fs

Vi skapar separata Secret och StorageClass.
Inget nytt, vi har redan sett detta på exempelvis RBD:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Nödvändigt för dynamiskt skapade volymer
  adminID: fs
  adminKey:

Vi tillämpar manifestet:

kubectl apply -f secret.yaml

Och nu – en separat StorageClass:

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

  # Namn på CephFS-filsystemet där volymen kommer att skapas
  fsName: cephfs

  # (valfritt) Ceph-pool där data för volymen kommer att lagras
  # pool: cephfs_data

  # (valfritt) Komma-separerade monteringsalternativ för Ceph-fuse
  # exempel:
  # fuseMountOptions: debug

  # (valfritt) Komma-separerade monteringsalternativ för CephFS för kärnan
  # Se man mount.ceph för att se listan över dessa alternativ. Till exempel:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Hemligheterna måste innehålla behörigheter för admin och/eller Ceph-användare.
  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

  # (valfritt) Drivrutinen kan använda antingen ceph-fuse (fuse), 
  # eller ceph kernelclient (kernel).
  # Om det inte anges, kommer standardmontage av volymer att användas,
  # detta bestäms genom att söka efter ceph-fuse och mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Låt oss fylla i det här clusterID och tillämpa det i Kubernetes:

kubectl apply -f storageclass.yaml

Kontroll

För att kontrollera, precis som i det föregående exemplet, skapar vi en PVC:

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

Och vi kontrollerar förekomsten av PVC/PV:

kubectl get pvc
kubectl get pv

Om du vill titta på filer och kataloger i CephFS kan du montera detta filsystem någonstans. Till exempel, som visas nedan.

Vi går till en av Ceph-klusterknutpunkterna och utför följande åtgärder:

# Точка монтирования
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

Självklart, denna montering av FS på en Ceph-nod är endast lämplig för utbildningssyften, vilket vi sysslar med på våra Slurm-kurser. Jag tror inte att någon skulle göra detta i produktion, risken för att av misstag skriva över viktiga filer är stor.

Och sista men inte minst, låt oss kontrollera hur det står till med storleksändring av volymer i CephFS. Vi återvänder till Kubernetes och redigerar vårt manifest för PVC - vi ökar storleken till exempel till 7Gi.

Vi tillämpar den redigerade filen:

kubectl apply -f pvc.yaml

Vi kollar på den monterade katalogen, hur kvoten har förändrats:

getfattr -n ceph.quota.max_bytes

För att köra detta kommando kan du behöva installera paketet attr.

Ögonen är rädda, men händerna gör jobbet

Vid ytan kan alla dessa trollformler och långa YAML-manifest som verkar komplicerade, men i praktiken förstår eleverna på Slurm dem ganska snabbt.
I den här artikeln går vi inte in på detaljer — det finns officiell dokumentation för det. Om du är intresserad av detaljer kring konfiguration av Ceph-lagring tillsammans med Kubernetes-klustret, kan dessa länkar vara till hjälp:

Allmänna principer för hur Kubernetes fungerar med volymer
Dokumentation för RBD
Integration av RBD och Kubernetes ur Ceph:s perspektiv
Integration av RBD och Kubernetes ur CSI:s perspektiv
Allmän dokumentation om CephFS
Integration av CephFS och Kubernetes ur CSI:s perspektiv

På Slurm-kursen Kubernetes Grund kan du gå ett steg längre och implementera en verklig applikation i Kubernetes som använder CephFS som lagring för filer. Genom GET/POST-förfrågningar kan du överföra filer och hämta dem från Ceph.

Och om du är mer intresserad av datalagring, anmäl dig till den nya kursen om Ceph. Under betatestningen kan kursen fås till rabatterat pris och påverka innehållet.

Artikelns författare: Alexander Shvalov, praktiserande ingenjör Southbridge, Certifierad Kubernetes-administratör, författare och utvecklare av Slurm-kurser.

Källa: habr.com