[LINUX] Einführung von Ceph mit Kubernetes auf Raspberry Pi 4B (ARM64)
Einführung
Ich wollte den dauerhaften Speicher meines Raspeye-Kubernetes-Clusters zu Hause loswerden, also habe ich Ceph durcheinander gebracht. Es war ziemlich viel Arbeit, also werde ich es aufschreiben.
Voraussetzung Umgebung
Es ist eine einfache Figur. Es gibt einen Kubernetes-Cluster über WLAN mit schlechter Leitungsqualität, der auch als IoT-Experiment dient.
- Himbeer-Pi 4B (RAM: 4 GB) * 5 Einheiten (1 Master-Knoten, 4 Worker-Knoten) --Boot von USB SSD (250GB)
- Einer ist fern und wird als Überwachungskamera verwendet (diesmal werde ich ihn nicht verwenden) --OS ist Raspberry Pi OS 64bit (Beta)
# 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
Erstellen Sie eine Partition für Ceph
Erstellen Sie eine neue Partition auf der SSD des Worker-Knotens. In meiner Konfiguration werden alle Knoten nur über eine SSD (250 GB) betrieben, die über einen USB-Start verbunden ist. Diesmal habe ich das Raspberry Pi-Betriebssystem von microSD gestartet und gearbeitet.
# 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
* Drücken Sie "p", um Partitionsinformationen anzuzeigen. ""/"Partition(/dev/sda2)Überprüfen Sie die Startposition von.
* Verwenden Sie "d", um die zweite Partition zu löschen.
* Erstellen Sie erneut eine zweite Partition von derselben Startposition. Die Endposition ist "+Spezifiziert durch "100G".
* Speichern Sie die Partitionsänderung mit "w".
# partprobe
# e2fsck -f /dev/sda2
* Wenn hier ein Fehler auftritt, drücken Sie "Strg", ohne zu reparieren.+Beenden Sie mit "c", diesmal mit getrennt/dev/Das Nachschneiden von sda2 kann funktionieren.
# fdisk /dev/sda
* Mit "n" den Rest/dev/Erstellen Sie sda3. Der Partitionstyp ist 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
Dies erfolgt mit 3 Worker-Knoten. Ich wollte den Dienst nicht beenden, also habe ich die Kubernetes einzeln abgelassen und sie wieder beitreten lassen. Der Worker-Knoten (Chiya) wird nicht in einem anderen Raum verwendet, der über den Ethernet-Konverter dem Kubernetes-Cluster beitritt.
Wenn es kein Problem mit der Stromversorgung gibt, besteht beim Hinzufügen einer weiteren SSD zu USB nicht das Risiko, mit resize2fs zu brechen, und die Arbeit ist schneller. ... Dieses Mal ist resize2fs fehlgeschlagen und zwei Worker-Knoten werden neu erstellt.
Gebäude Ceph
Ich habe wie im Artikel "Ich habe Ceph in Kubernetes auf Raspeye gesetzt" beschrieben. Da sich die Dokument-URL von Ceph geändert hat, gibt es viele tote Links in Ceph-bezogenen Informationen, aber es wäre sehr hilfreich, solche Informationen auf Japanisch zu haben.
Das Folgende ist die Arbeit am Masterknoten. Ich habe gerade das Passwort eingegeben, während ich den Befehl ausgeführt habe.
# 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
Pool erstellen.
# ceph osd pool create kubernetes 128
Erstellen einer 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
* Das erstellte Yaml ist wie folgt.
# 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
Geheime Schöpfung.
# 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==
* Das erstellte Yaml ist wie folgt.
# 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
Erstellen einer ConfigMap (leer).
# cat kms-config.yaml
apiVersion: v1
kind: ConfigMap
data:
config.json: |-
{
}
metadata:
name: ceph-csi-encryption-kms-config
# kubectl apply -f kms-config.yaml
Vielleicht ist "# kubectl create configmap ceph-csi-encryption-kms-config" in Ordnung.
# 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
Ich werde schreiben, indem ich das Verfahren von der Seite, auf die ich mich hier beziehe, leicht ändere. Es ist besser, nicht am Masterknoten zu arbeiten, aber ich habe es am Masterknoten gemacht. Holen Sie sich zuerst Yaml von CSI und ändern Sie Cephcsi in 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
Überprüfen Sie die Version des im Bild verwendeten Container-Images.
# 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
- Ich wusste nicht, wie ich Attacher bekommen soll: v2.2.1, also habe ich es auf 2.1 gesetzt.
Download go. https://golang.org/dl/ Wie ich bereits erwähnt habe, scheint "go-1.13" in der Marke des Container-Images der oben erhaltenen Version angenommen zu werden.
# 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
Ich denke, es hängt von der Generation ab, aber go wird in meinem Herzen als "Ngo" gelesen.
# 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 .
Nur Snapshotter war verwirrt über Dockerfile. ... Wahrscheinlich ist die Arbeitsweise anders, aber ich habe gewaltsam ein Bild gemacht. Das Image befindet sich im Docker. Speichern Sie es also und laden Sie es in das Docker des Worker-Knotens.
# 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
(Folgendes wird weggelassen)
# 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
Kopieren Sie scp oder sftp auf den Worker-Knoten. Führen Sie nach dem Kopieren den folgenden Befehl auf jedem Arbeitsknoten aus. Zur Zeit lege ich es in einen Worker-Knoten, den ich nicht benutze.
# 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
Kommen wir nun wieder zur Arbeit mit ceph-deploy. Der Teil "image:" von "csi-rbdplugin-provisor.yaml" und "csi-rbdplugin.yaml" wurde wie folgt in das Repository-Tag des erstellten Images geändert.
# 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
Lassen Sie uns jetzt bereitstellen. Es gibt nur erfolgreiche Beispiele, aber ...
# 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>
Es wird empfohlen, bei der Bereitstellung "# kubectl get events -w" festzulegen. Erstellen Sie eine Speicherklasse. So wie es jetzt ist, ist es möglicherweise besser, dass der Namespace nicht der Standard ist.
# 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
Geben Sie danach "storageClassName" als "csi-rbd-sc" an, wenn Sie PVC auf der Anwendungsseite erstellen. Kann nicht mit dynamischer Bereitstellung verwendet werden .... Ich konnte es nicht mit der PVC-Definition der Site bestätigen, auf die ich mich beziehe, aber als ich "Volume Mode: Block" im Raw-Modus löschte, wurde das folgende Ereignis ausgegeben.
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.....
Zurück zur Annahme, wir brauchen ein Kernelmodul namens "rbd". Und in Raspberry Pi OS 64bit (Beta) wird das "rbd" -Modul überhaupt nicht kompiliert. Das heißt, Sie müssen den Kernel kompilieren.
Der Grund, warum das Kernelmodul erforderlich ist, obwohl der Befehl von jedem Client verwendet werden kann, ist "Deep Dive Into Cephs Kernel Client. edea75787528) ”Ich habe verstanden. (Ungefähr die Hälfte) Der Befehl kann in der Bibliothek verwendet werden, und es scheint, dass das Kernelmodul in der Containerumgebung erforderlich ist.
Kernel Build
Kompilieren des Linux-Kernels, was früher eine tägliche Aufgabe war. Als es noch kein Konzept für ein Kernelmodul gab, gab es eine Begrenzung für die Größe des Kernels, der geladen werden konnte, und jeder kompilierte in letzter Minute einen Kernel, der zu seinem Computer passt. Sie haben jedes Mal, wenn Sie ein neues Gerät hinzugefügt haben, eine Kernel-Kompilierung durchgeführt.
Also habe ich es geschafft, aber was ist jetzt los? Ich habe so gearbeitet. Das Handbuch lautet "Kernel-Erstellung", aber da es sich immer noch um eine 64-Bit-Version der Beta handelt, [Gepostet von der Person, die es tatsächlich tut]( Ich habe auf https://www.raspberrypi.org/forums/viewtopic.php?t=280341 verwiesen. Die Arbeit dauerte ungefähr eine Stunde.
# 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=Fügen Sie "m" entsprechend hinzu.)
# grep RBD .config
CONFIG_BLK_DEV_DRBD=m
＃ CONFIG_DRBD_FAULT_INJECTION is not set
CONFIG_BLK_DEV_RBD=m
# make -j4
(Ich denke, dass die Frage nach Cephfs im Zusammenhang mit der Aktivierung von RBD auftauchen wird, aber ich habe es nicht gut verstanden, also habe ich es auf "N" gesetzt.)
# 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
(Im Forumsbeitrag "#"Es ist angehängt...Erstens, wenn es sich um einen Kommentar handelt, sollte es nicht notwendig sein, ihn zu schreiben, also werde ich ihn entfernen.)
# 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
Früher habe ich neu gestartet, während ich "Hahhh" gesagt habe, aber ich werde es schnell tun. Ich bin zuversichtlich, dass ich mich erholen kann ... (Aber ich habe die ganze Zeit von einer anderen Maschine aus gepingt.)
# reboot
Ich werde alles überprüfen. Da es sich um einen benutzerdefinierten Kernel handelt, können Sie keinen bezahlten Support mehr erhalten. (Es gibt keine solche Sache)
# 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)
Bereitstellen von Apps mit Ceph CSI StorageClass
Versuchen wir nun die Bereitstellung erneut, die einmal fehlgeschlagen ist, weil das rbd-Kernelmodul fehlte.
# 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
Überprüfen Sie den Status des Pods.
# 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
Ereignisüberwachung.
# 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
Speicherbezogene Bestätigung.
# 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
Insbesondere blieb die erstellte Datei auch nach dem Löschen und erneuten Bereitstellen des Pods erhalten. (Natürlich) Es reicht nicht aus, ein separates Element zu erstellen, aber es ist ein Leistungsaspekt. Ursprünglich bin ich nicht gut in Hardware und ich habe hier nicht viel Know-how, aber ich werde das mit dd geschriebene Ergebnis schreiben.
# dd if=/dev/zero of=aaa bs=4096 count=100000
| Erstes Mal | Zweites Mal | Drittes Mal | 4 .. | 5. Mal | |
|---|---|---|---|---|---|
| Dd auf die Diskette des Workers im Betriebssystem des Workers | 186 MB/s | 133 MB/s | 141 MB/s | 140 MB/s | 133 MB/s |
| dd aus dem Container im Hostpfadverzeichnis | 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 kam zum Zeitpunkt der Messung nicht heraus, aber manchmal sind es 50 MB / s, und die Rückgabe des Befehls ist langsam, sodass es sich spitz anfühlt. Was beeinflusst ...
abschließend
Wenn möglich, denke ich, dass der mit ROOK (Operator) erstellte Typ durch Ändern des Container-Images irgendwie verschoben werden kann. Das wäre eine gute Möglichkeit, OpenShift Container Storage zu studieren ... (aber es wird schwerer ...) Dieses Mal bezog ich mich auf die Materialien verschiedener Leute, aber ich war überrascht, dass es auch ein Material von Mr. Yuryu aus der Red Hat-Ära gab: "Ich frage mich, ob ich vor so langer Zeit Ceph gemacht habe." Einer der Menschen, die ich persönlich bewundere, ist mir seit "Linux Kernel Updates" zu Dank verpflichtet.
Es gibt einen Teil, in dem das endgültige Leistungsergebnis "?" Ist ... Nun, angesichts der Leistung verwende ich Raspeye nicht und wollte ursprünglich CSI als Funktion verwenden, daher bin ich mit dem Ergebnis zufrieden. Auf diese Weise können Pods, die persistenten Speicher verwenden, redundant gemacht werden, indem hostPath verlassen wird.
Recommended Posts