[LINUX] Introduction de Ceph avec Kubernetes sur Raspberry Pi 4B (ARM64)
introduction
Je voulais me débarrasser du stockage persistant de mon cluster Raspeye kubernetes à la maison, alors j'ai foiré Ceph. C'était beaucoup de travail, alors je vais l'écrire.
Environnement prérequis
C'est un chiffre simple. Il existe un cluster kubernetes via wifi avec une qualité de ligne médiocre, qui sert également d'expérience IoT.
--Raspberry Pi 4B (RAM: 4 Go) * 5 unités (1 nœud maître, 4 nœuds de travail) -Boot à partir d'un SSD USB (250 Go)
- L'un est distant et est utilisé comme caméra de surveillance (je ne l'utiliserai pas cette fois) --OS est Raspberry Pi OS 64 bits (bêta)
# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
chino Ready master 8d v1.19.2 10.0.0.1 <none> Debian GNU/Linux 10 (buster) 5.4.51-v8+ docker://19.3.13
chiya Ready worker 8d v1.19.2 10.0.0.5 <none> Debian GNU/Linux 10 (buster) 5.4.51-v8+ docker://19.3.13
cocoa Ready worker 46h v1.19.2 10.0.0.2 <none> Debian GNU/Linux 10 (buster) 5.4.51-v8+ docker://19.3.13
rize Ready worker 2d2h v1.19.2 10.0.0.3 <none> Debian GNU/Linux 10 (buster) 5.4.51-v8+ docker://19.3.13
syaro Ready worker 42h v1.19.2 10.0.0.4 <none> Debian GNU/Linux 10 (buster) 5.4.51-v8+ docker://19.3.13
# uname -a
Linux chino 5.4.51-v8+ ＃1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64 GNU/Linux
Créer une partition pour Ceph
Créez une nouvelle partition sur le SSD du nœud worker. Dans ma configuration, tous les nœuds sont exploités uniquement par SSD (250 Go) connecté par démarrage USB, donc cette fois j'ai démarré le Raspberry Pi OS de microSD et travaillé.
# e2fsck -f /dev/sda2
# resize2fs /dev/sda2 100G
# fdisk /dev/sda
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 488397167 487864688 233G 83 Linux
* Appuyez sur "p" pour afficher les informations de partition. "/"cloison(/dev/sda2)Vérifiez la position de départ de.
* Utilisez "d" pour supprimer la deuxième partition.
* Créez à nouveau une deuxième partition à partir de la même position de départ. La position finale est "+Spécifié par "100G".
* Enregistrez le changement de partition avec "w".
# partprobe
# e2fsck -f /dev/sda2
* Si une erreur se produit ici, appuyez sur "Ctrl" sans réparer.+Sortir avec "c", cette fois avec parted/dev/La recoupe sda2 peut fonctionner.
# fdisk /dev/sda
* Avec "n", tout le reste/dev/Créez sda3. Le type de partition est 8e "Linux LVM".
# partprobe
# fdisk -l /dev/sda
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 210247679 209715200 100G 83 Linux
/dev/sda3 210247680 488397167 278149488 132.6G 8e Linux LVM
Cela se fait avec 3 nœuds de travail. Je ne voulais pas arrêter le service, j'ai donc vidé les kubernetes un par un et les ai laissés rejoindre à nouveau. Il n'utilise pas le nœud worker (chiya) dans une autre pièce qui rejoint le cluster kubernetes via le convertisseur Ethernet.
De plus, s'il n'y a pas de problème d'alimentation, l'ajout d'un autre SSD à l'USB ne présente pas de risque de rupture avec resize2fs, et le travail est plus rapide. ... Cette fois, resize2fs a échoué et deux nœuds de travail sont en cours de reconstruction.
Bâtiment Ceph
J'ai travaillé comme décrit dans l'article "J'ai mis Ceph dans Kubernetes sur Raspeye". Depuis que l'URL du document de Ceph a changé, il existe de nombreux liens morts dans les informations relatives à Ceph, mais il serait très utile d'avoir de telles informations en japonais.
Ce qui suit est le travail sur le nœud maître. Je viens de taper le mot de passe lors de l'exécution de la commande.
# mkdir ceph-deploy
# cd ceph-deploy
# pip install ceph-deploy
# ceph-deploy --username pi new cocoa rize syaro
# ceph-deploy --username pi install cocoa rize syaro
# ceph-deploy install chino
# ceph-deploy --username pi mon create-initial
# ceph-deploy --username pi admin cocoa rize syaro
# ceph-deploy admin chino
# ceph-deploy --username pi osd create cocoa --data /dev/sda3
# ceph-deploy --username pi osd create rize --data /dev/sda3
# ceph-deploy --username pi osd create syaro --data /dev/sda3
# ceph-deploy --username pi mds create cocoa
Créer une piscine.
# ceph osd pool create kubernetes 128
Création d'un ConfigMap.
# ceph mon dump
dumped monmap epoch 2
epoch 2
fsid 56b03534-e602-4856-8734-8bcdf5cc8670
last_changed 2020-09-20 01:24:55.648189
created 2020-09-20 01:24:08.811926
0: 10.0.0.2:6789/0 mon.cocoa
1: 10.0.0.3:6789/0 mon.rize
2: 10.0.0.4:6789/0 mon.syaro
* Le yaml créé est le suivant.
# cat csi-config-map.yaml
apiVersion: v1
kind: ConfigMap
data:
config.json: |-
[
{
"clusterID": "56b03534-e602-4856-8734-8bcdf5cc8670",
"monitors": [
"10.0.0.2:6789",
"10.0.0.3:6789",
"10.0.0.4:6789"
]
}
]
metadata:
name: ceph-csi-config
# kubectl apply -f csi-config-map.yaml
Création secrète.
# ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'
[client.kubernetes]
key = AQBrNmZfVCowLBAAeN3EYjhOPBG9442g4NF/bQ==
* Le yaml créé est le suivant.
# cat csi-rbd-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: csi-rbd-secret
namespace: default
stringData:
userID: kubernetes
userKey: AQBrNmZfVCowLBAAeN3EYjhOPBG9442g4NF/bQ==
# kubectl apply -f csi-rbd-secret.yaml
Création d'un ConfigMap (vide).
# cat kms-config.yaml
apiVersion: v1
kind: ConfigMap
data:
config.json: |-
{
}
metadata:
name: ceph-csi-encryption-kms-config
# kubectl apply -f kms-config.yaml
Peut-être que "# kubectl create configmap ceph-csi-encryption-kms-config" convient.
# wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml
# kubectl apply -f csi-provisioner-rbac.yaml
# wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
# kubectl apply -f csi-nodeplugin-rbac.yaml
J'écrirai en modifiant légèrement la procédure du site auquel je me réfère à partir d'ici. Il vaut mieux ne pas travailler sur le nœud maître, mais je l'ai fait sur le nœud maître. Obtenez d'abord yaml de csi et changez cephcsi en arm64.
# wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
# sed -i -e 's/quay.io\/cephcsi\/cephcsi:canary/quay.io\/cephcsi\/cephcsi:canary-arm64/g' csi-rbdplugin-provisioner.yaml
# wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
# sed -i -e 's/quay.io\/cephcsi\/cephcsi:canary/quay.io\/cephcsi\/cephcsi:canary-arm64/g' csi-rbdplugin.yaml
Vérifiez la version de l'image du conteneur utilisée dans l'image.
# grep image: csi-rbdplugin-provisioner.yaml csi-rbdplugin.yaml
csi-rbdplugin-provisioner.yaml: image: quay.io/k8scsi/csi-provisioner:v1.6.0
csi-rbdplugin-provisioner.yaml: image: quay.io/k8scsi/csi-snapshotter:v2.1.0
csi-rbdplugin-provisioner.yaml: image: quay.io/k8scsi/csi-attacher:v2.1.1
csi-rbdplugin-provisioner.yaml: image: quay.io/k8scsi/csi-resizer:v0.5.0
csi-rbdplugin-provisioner.yaml: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin-provisioner.yaml: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin.yaml: image: quay.io/k8scsi/csi-node-driver-registrar:v1.3.0
csi-rbdplugin.yaml: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin.yaml: image: quay.io/cephcsi/cephcsi:canary-arm64
# git clone --single-branch --branch release-1.6 https://github.com/kubernetes-csi/external-provisioner
# git clone --single-branch --branch release-2.1 https://github.com/kubernetes-csi/external-snapshotter
# git clone --single-branch --branch release-2.1 https://github.com/kubernetes-csi/external-attacher
# git clone --single-branch --branch release-0.5 https://github.com/kubernetes-csi/external-resizer
# git clone --single-branch --branch release-1.3 https://github.com/kubernetes-csi/node-driver-registrar
- Je ne savais pas comment obtenir attacher: v2.2.1, donc je l'ai réglé sur 2.1.
Téléchargez go. https://golang.org/dl/ Comme je l'ai mentionné précédemment, il semble que "go-1.13" soit supposé dans la marque de l'image du conteneur de la version obtenue ci-dessus.
# wget https://dl.google.com/go/go1.15.1.linux-arm64.tar.gz
# tar xzvf go1.15.1.linux-arm64.tar.gz
# rm go1.15.1.linux-arm64.tar.gz
# echo 'export GOPATH=$HOME/go' >> ~/.bashrc
# echo 'export PATH=$GOPATH/bin:$PATH' >> ~/.bashrc
# source ~/.bashrc
# go version
go version go1.15.1 linux/arm64
Je pense que cela dépend de la génération, mais go est lu comme "Ngo" dans mon cœur.
# cd external-provisioner
# make
# docker build -t csi-provisioner:v1.6.0 .
# cd ../external-snapshotter
# make
# cp cmd/csi-snapshotter/Dockerfile .
# docker build -t csi-snapshotter:v2.1.0 .
# cd ../external-attacher
# make
# docker build -t csi-attacher:v2.1.0 .
# cd ../external-resizer
# make
# docker build -t csi-resizer:v0.5.0 .
# cd ../node-driver-registrar
# make
# docker build -t csi-node-driver-registrar:v1.3.0 .
Seul le snapshotter a été confus à propos de Dockerfile. ... La procédure de travail est probablement différente, mais j'ai créé une image de force. L'image sera dans le docker, donc enregistrez-la et chargez-la dans le docker du nœud worker.
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
csi-node-driver-registrar v1.3.0 a6e114649cf9 33 hours ago 14.2MB
csi-resizer v0.5.0 d6b561c2aa0a 34 hours ago 41.6MB
csi-attacher v2.1.0 807c3900bf76 34 hours ago 41.7MB
csi-snapshotter v2.1.0 653dbf034d1d 34 hours ago 41.8MB
csi-provisioner v1.6.0 4b18fda1685c 34 hours ago 43.4MB
(Ce qui suit est omis)
# docker save csi-node-driver-registrar:v1.3.0 -o csi-node-driver-registrar.tar
# docker save csi-resizer:v0.5.0 -o csi-resizer.tar
# docker save csi-attacher:v2.1.0 -o csi-attacher.tar
# docker save csi-snapshotter:v2.1.0 -o csi-snapshotter.tar
# docker save csi-provisioner:v1.6.0 -o csi-provisioner.tar
Copiez scp ou sftp sur le nœud worker. Après la copie, exécutez la commande suivante sur chaque nœud de travail. Pour le moment, je le mets dans un nœud worker que je n'utilise pas.
# docker load -i csi-node-driver-registrar.tar
# docker load -i csi-resizer.tar
# docker load -i csi-attacher.tar
# docker load -i csi-snapshotter.tar
# docker load -i csi-provisioner.tar
Revenons maintenant à travailler avec ceph-deploy. Modification de la partie "image:" de "csi-rbdplugin-provisioner.yaml" et "csi-rbdplugin.yaml" en balise de référentiel de l'image créée comme suit.
# grep -n image: csi-rbdplugin-provisioner.yaml csi-rbdplugin.yaml
csi-rbdplugin-provisioner.yaml:35: image: csi-provisioner:v1.6.0
csi-rbdplugin-provisioner.yaml:52: image: csi-snapshotter:v2.1.0
csi-rbdplugin-provisioner.yaml:68: image: csi-attacher:v2.1.0
csi-rbdplugin-provisioner.yaml:82: image: csi-resizer:v0.5.0
csi-rbdplugin-provisioner.yaml:102: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin-provisioner.yaml:142: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin.yaml:28: image: csi-node-driver-registrar:v1.3.0
csi-rbdplugin.yaml:50: image: quay.io/cephcsi/cephcsi:canary-arm64
csi-rbdplugin.yaml:102: image: quay.io/cephcsi/cephcsi:canary-arm64
Maintenant, déployons. Il n'y a que des exemples réussis, mais ...
# kubectl apply -f csi-rbdplugin-provisioner.yaml
# kubectl apply -f csi-rbdplugin.yaml
# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
csi-rbdplugin-hm9bm 3/3 Running 3 24h 10.0.0.4 syaro <none> <none>
csi-rbdplugin-provisioner-54dd99dd97-f9x2s 6/6 Running 6 24h 172.16.4.40 syaro <none> <none>
csi-rbdplugin-provisioner-54dd99dd97-flbh9 6/6 Running 0 24h 172.16.2.28 cocoa <none> <none>
csi-rbdplugin-provisioner-54dd99dd97-s9qf4 6/6 Running 0 24h 172.16.3.54 rize <none> <none>
csi-rbdplugin-t7569 3/3 Running 0 24h 10.0.0.3 rize <none> <none>
csi-rbdplugin-x4fzk 3/3 Running 3 24h 10.0.0.5 chiya <none> <none>
csi-rbdplugin-xwrnx 3/3 Running 0 24h 10.0.0.2 cocoa <none> <none>
Il est recommandé de définir "# kubectl get events -w" lors du déploiement. Créez une classe de stockage. Dans l'état actuel des choses, il peut être préférable que l'espace de noms ne soit pas par défaut.
# cat csi-rbd-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
clusterID: "56b03534-e602-4856-8734-8bcdf5cc8670"
pool: kubernetes
csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
csi.storage.k8s.io/provisioner-secret-namespace: default
csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete
mountOptions:
- discard
# kubectl apply -f csi-rbd-sc.yaml
Après cela, veuillez spécifier "storageClassName" comme "csi-rbd-sc" lors de la création du PVC du côté de l'application. Ne peut pas être utilisé avec l'approvisionnement dynamique ... Je n'ai pas pu le confirmer avec la définition PVC du site auquel je fais référence, mais lorsque j'ai supprimé "Volume Mode: Block" en mode Raw, l'événement suivant était sorti.
default 0s Warning FailedMount pod/es-cluster-0 MountVolume.MountDevice failed for volume "pvc- ...
...... rbd error output: modinfo: ERROR: Module rbd not found.
modprobe: FATAL: Module rbd not found in directory /lib/modules/5.4.51-v8+
rbd: failed to load rbd kernel module (1)
rbd: sysfs write failed
rbd: map failed: (2) No such file or directory
deault 0s Warning FailedMount pod/es-cluster-0 Unable to attach or mount volumes: unmounted.....
Pour revenir à l'hypothèse, nous avons besoin d'un module noyau appelé "rbd". Et dans Raspberry Pi OS 64bit (Beta), le module "rbd" n'est pas compilé en premier lieu. Autrement dit, vous devez compiler le noyau.
La raison pour laquelle le module noyau est requis même si la commande peut être utilisée à partir de chaque client est "[Deep Dive Into Ceph's Kernel Client](https://engineering.salesforce.com/deep-dive-into-cephs-kernel-client-" edea75787528) »J'ai compris. (Environ la moitié) La commande peut être utilisée dans la bibliothèque et il semble que le module noyau soit requis dans l'environnement du conteneur.
build du noyau
Compiler le noyau Linux, qui était autrefois une tâche quotidienne. Quand il n'y avait pas encore de concept de module de noyau, il y avait une limite à la taille du noyau qui pouvait être chargé, et tout le monde a compilé un noyau qui correspond à sa machine à la dernière minute. Vous avez effectué une compilation du noyau à chaque fois que vous avez ajouté un nouveau périphérique.
Alors je l'ai fait, mais que se passe-t-il maintenant? J'ai travaillé comme ça. Le manuel est "Construction du noyau", mais comme il s'agit toujours d'une version 64 bits de la bêta, [Publié par la personne qui le fait réellement]( J'ai fait référence à https://www.raspberrypi.org/forums/viewtopic.php?t=280341). Le travail a duré environ une heure.
# git clone --depth=1 -b rpi-5.4.y https://github.com/raspberrypi/linux.git
# cd linux/
# make bcm2711_defconfig
# vi .config
(「CONFIG_BLK_DEV_RBD=Ajoutez "m" de manière appropriée.)
# grep RBD .config
CONFIG_BLK_DEV_DRBD=m
＃ CONFIG_DRBD_FAULT_INJECTION is not set
CONFIG_BLK_DEV_RBD=m
# make -j4
(Je pense que la question de cephfs se posera par rapport à l'activation de RBD, mais je n'ai pas bien compris, alors je l'ai mis à "N".)
# make modules_install
# make dtbs_install
# cp /boot/kernel8.img /boot/kernel8_old.img
# cp arch/arm64/boot/Image /boot/kernel8.img
# vi /boot/config.txt
(Dans le message du forum, "#"Est attaché...En premier lieu, s'il s'agit d'un commentaire, il ne devrait pas être nécessaire de l'écrire, je vais donc le supprimer.)
# head -n 10 /boot/config.txt
＃ For more options and information see
＃ http://rpf.io/configtxt
＃ Some settings may impact device functionality. See link above for details
device_tree=dtbs/5.4.65-v8+/broadcom/bcm2711-rpi-4-b.dtb
overlay_prefix=dtbs/5.4.65-v8+/overlays/
kernel=kernel8.img
＃ uncomment if you get no picture on HDMI for a default "safe" mode
＃hdmi_safe=1
Autrefois, je recommençais en disant "Hahhh", mais je vais le faire rapidement. Je suis convaincu que je peux récupérer ... (Mais je ping depuis une autre machine tout le temps.)
# reboot
Je vais tout vérifier. Puisqu'il s'agit d'un noyau personnalisé, vous ne pouvez plus recevoir de support payant. (Il n'y a pas une telle chose)
# uname -a
Linux syaro 5.4.65-v8+ ＃1 SMP PREEMPT Mon Sep 21 01:04:01 JST 2020 aarch64 GNU/Linux
# modprobe rbd
# lsmod | grep rbd
rbd 98304 0
libceph 278528 1 rbd
# modinfo rbd
filename: /lib/modules/5.4.65-v8+/kernel/drivers/block/rbd.ko
license: GPL
description: RADOS Block Device (RBD) driver
author: Jeff Garzik <[email protected]>
author: Yehuda Sadeh <[email protected]>
author: Sage Weil <[email protected]>
author: Alex Elder <[email protected]>
srcversion: BC90D52477A5CE4593C5AC3
depends: libceph
intree: Y
name: rbd
vermagic: 5.4.65-v8+ SMP preempt mod_unload modversions aarch64
parm: single_major:Use a single major number for all rbd devices (default: true) (bool)
Déployer des applications avec Ceph CSI StorageClass
Maintenant, réessayons le déploiement qui a échoué une fois parce que le module du noyau rbd était manquant.
# cat es_master_sts.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: es-cluster
spec:
selector:
matchLabels:
app: es
serviceName: "es-cluster"
replicas: 1
template:
metadata:
labels:
app: es
spec:
containers:
- name: es
image: elasticsearch:7.9.1
env:
- name: discovery.type
value: single-node
ports:
- containerPort: 9200
name: api
- containerPort: 9300
name: gossip
volumeMounts:
- name: data
mountPath: /usr/share/elasticsearch/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: csi-rbd-sc
# kubectl apply -f es_master_sts.yaml
Vérifiez l'état du pod.
# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
csi-rbdplugin-hm9bm 3/3 Running 3 25h
csi-rbdplugin-provisioner-54dd99dd97-f9x2s 6/6 Running 6 25h
csi-rbdplugin-provisioner-54dd99dd97-flbh9 6/6 Running 0 25h
csi-rbdplugin-provisioner-54dd99dd97-s9qf4 6/6 Running 0 25h
csi-rbdplugin-t7569 3/3 Running 0 25h
csi-rbdplugin-x4fzk 3/3 Running 3 25h
csi-rbdplugin-xwrnx 3/3 Running 0 25h
es-cluster-0 0/1 Pending 0 0s
es-cluster-0 0/1 Pending 0 0s
es-cluster-0 0/1 Pending 0 2s
es-cluster-0 0/1 ContainerCreating 0 2s
es-cluster-0 1/1 Running 0 8s
Surveillance des événements.
# kubectl get events -w
LAST SEEN TYPE REASON OBJECT MESSAGE
0s Normal SuccessfulCreate statefulset/es-cluster create Claim data-es-cluster-0 Pod es-cluster-0 in StatefulSet es-cluster success
0s Normal ExternalProvisioning persistentvolumeclaim/data-es-cluster-0 waiting for a volume to be created, either by external provisioner "rbd.csi.ceph.com" or manually created by system administrator
0s Normal Provisioning persistentvolumeclaim/data-es-cluster-0 External provisioner is provisioning volume for claim "default/data-es-cluster-0"
0s Normal SuccessfulCreate statefulset/es-cluster create Pod es-cluster-0 in StatefulSet es-cluster successful
0s Warning FailedScheduling pod/es-cluster-0 0/5 nodes are available: 5 pod has unbound immediate PersistentVolumeClaims.
0s Warning FailedScheduling pod/es-cluster-0 0/5 nodes are available: 5 pod has unbound immediate PersistentVolumeClaims.
0s Normal ProvisioningSucceeded persistentvolumeclaim/data-es-cluster-0 Successfully provisioned volume pvc-1c1abfad-87fa-4882-a840-8449c6d50326
0s Normal Scheduled pod/es-cluster-0 Successfully assigned default/es-cluster-0 to syaro
0s Normal SuccessfulAttachVolume pod/es-cluster-0 AttachVolume.Attach succeeded for volume "pvc-1c1abfad-87fa-4882-a840-8449c6d50326"
0s Normal Pulled pod/es-cluster-0 Container image "elasticsearch:7.9.1" already present on machine
0s Normal Created pod/es-cluster-0 Created container es
0s Normal Started pod/es-cluster-0 Started container es
Confirmation liée au stockage.
# kubectl get sc,pv,pvc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
storageclass.storage.k8s.io/csi-rbd-sc rbd.csi.ceph.com Delete Immediate false 25h
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-1c1abfad-87fa-4882-a840-8449c6d50326 1Gi RWO Delete Bound default/data-es-cluster-0 csi-rbd-sc 78s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/data-es-cluster-0 Bound pvc-1c1abfad-87fa-4882-a840-8449c6d50326 1Gi RWO csi-rbd-sc 78s
En particulier, le fichier créé est resté même après la suppression et le redéploiement du pod. (Bien sûr) Il ne suffit pas de créer un élément séparé, mais c'est un aspect de performance. A l'origine je ne suis pas doué en matériel, et je n'ai pas beaucoup de savoir-faire ici, mais j'écrirai le résultat écrit avec dd.
# dd if=/dev/zero of=aaa bs=4096 count=100000
| Première fois | Deuxième fois | Troisième fois | 4e | 5ème fois | |
|---|---|---|---|---|---|
| dd sur le disque du travailleur sur le système d'exploitation du travailleur | 186 MB/s | 133 MB/s | 141 MB/s | 140 MB/s | 133 MB/s |
| dd du conteneur sur le répertoire hostpath | 120 MB/s | 121 MB/s | 134 MB/s | 131 MB/s | 131 MB/s |
| ceph-csi | 186 MB/s | 185 MB/s | 174 MB/s | 178 MB/s | 180 MB/s |
Ceph-csi n'est pas sorti au moment de la mesure, mais parfois il est de 50 Mo / s, et le retour de la commande est lent, donc ça fait un pic. Ce qui affecte ...
en conclusion
Peut-être, si possible, je pense que le type construit avec ROOK (opérateur) peut en quelque sorte être déplacé en changeant l'image du conteneur. Ce serait un bon moyen d'étudier OpenShift Container Storage ... (mais ce sera plus lourd ...) Cette fois, j'ai évoqué les documents de diverses personnes, mais j'ai été surpris qu'il y ait aussi un matériel de M. Yuryu de l'ère Red Hat, "Je me demande si je faisais Ceph il y a si longtemps." Une des personnes que j'admire personnellement, je suis redevable depuis l'époque des "Linux Kernel Updates".
Il y a une partie où le résultat final de la performance est "?" ... Eh bien, vu les performances, je n'utilise pas Raspeye, et je voulais à l'origine utiliser CSI en tant que fonction, donc je suis satisfait du résultat. Enfin, les pods qui utilisent le stockage persistant peuvent être rendus redondants en quittant hostPath.
Recommended Posts