
Teil 1 Wir stellen die Umgebung für die Arbeit mit Microservices bereit. Teil 1 Installation von Kubernetes HA auf Bare Metal (Debian)
Hallo, liebe Leser von Habr!
In einem früheren Beitrag habe ich darüber gesprochen, wie ein Kubernetes-Failovercluster bereitgestellt wird. Tatsache ist jedoch, dass es in Kubernetes praktisch ist, zustandslose Anwendungen bereitzustellen, die ihren Status nicht beibehalten oder nicht mit Daten arbeiten müssen. In den meisten Fällen müssen wir jedoch Daten speichern und dürfen sie beim Neustart der Herde nicht verlieren.
Kubernetes verwendet für diese Zwecke Volumes. Wenn wir mit Kubernetes Cloud-Lösungen arbeiten, gibt es keine besonderen Probleme. Wir müssen nur das erforderliche Volume bei Google, Amazon oder einem anderen Cloud-Anbieter bestellen und gemäß der Dokumentation die empfangenen Volumes mit den Pods verbinden.
Wenn wir uns mit Bare Metal beschäftigen, sind die Dinge etwas komplizierter. Heute möchte ich über eine der Lösungen sprechen, die auf der Verwendung von Ceph basieren.
In dieser Veröffentlichung werde ich erzählen:
- So stellen Sie verteilten Ceph-Speicher bereit
- Verwendung von Ceph bei der Arbeit mit Kubernetes
Einführung
Zunächst möchte ich erklären, wem dieser Artikel nützlich sein wird. Erstens für Leser, die den Cluster gemäß meiner ersten Veröffentlichung bereitgestellt haben, um weiterhin eine Microservice-Architektur aufzubauen. Zweitens für Personen, die versuchen möchten, einen Ceph-Cluster selbst bereitzustellen und seine Leistung zu bewerten.
In dieser Veröffentlichung werde ich nicht auf das Thema Clusterplanung für irgendwelche Bedürfnisse eingehen, sondern nur auf allgemeine Prinzipien und Konzepte eingehen. Ich werde mich nicht mit "Tuning" und Deep Tuning befassen, es gibt viele Veröffentlichungen zu diesem Thema, einschließlich des Habr. Der Artikel wird einführender sein, aber gleichzeitig wird es Ihnen ermöglichen, eine funktionierende Lösung zu erhalten, die Sie in Zukunft an Ihre Bedürfnisse anpassen können.
- Liste der Hosts, Hostressourcen, Betriebssystem- und Softwareversionen
- Ceph-Cluster-Struktur
- Konfigurieren Sie Clusterknoten vor der Installation
- Installieren Sie ceph-deploy
- Erstellen eines Ceph-Clusters
- Netzwerkeinrichtung
- Installieren Sie Ceph-Pakete
- Installation und Initialisierung von Monitoren
- OSD hinzufügen
- Verbinden Sie Ceph mit Kubernetes
- Erstellen eines Datenpools
- Ein Kundengeheimnis erstellen
- Stellen Sie den ceph rbd-Provisioner bereit
- Erstellen einer Speicherklasse
- Kubernetes + Ceph-Bandtest
- Liste der bei der Erstellung des Artikels verwendeten Materialien
Hostliste und Systemanforderungen
Beim Schreiben eines Artikels verwende ich virtuelle Maschinen mit dieser Konfiguration

Auf jedem ist ein Debian 9.5-Betriebssystem installiert. Hierbei handelt es sich um Testmaschinen mit jeweils zwei Festplatten, die erste für das Betriebssystem und die zweite für das OSD-Cef.
Ich werde den Cluster über das Dienstprogramm ceph-deploy bereitstellen. Sie können einen Ceph-Cluster im manuellen Modus bereitstellen. Alle Schritte sind in der Dokumentation beschrieben. In diesem Artikel wird jedoch erläutert, wie schnell Sie Ceph bereitstellen und in Kubernetes verwenden können.
Ceph ist ziemlich gefräßig für Ressourcen, insbesondere RAM. Für eine gute Geschwindigkeit ist es ratsam, SSD-Laufwerke zu verwenden.
Weitere Informationen zu den Anforderungen finden Sie in der offiziellen Ceph-Dokumentation.
Ceph-Cluster-Struktur
MON
Ein Monitor ist ein Dämon, der als Koordinator fungiert, von dem aus der Cluster beginnt. Sobald wir mindestens einen funktionierenden Monitor haben, haben wir einen Ceph-Cluster. Der Monitor speichert Informationen über den Zustand und den Zustand des Clusters, indem verschiedene Karten mit anderen Monitoren ausgetauscht werden. Clients wenden sich an Monitore, um herauszufinden, in welches OSD Daten geschrieben / gelesen werden sollen. Wenn Sie einen neuen Speicher bereitstellen, erstellen Sie zunächst einen Monitor (oder mehrere). Der Cluster kann auf einem Monitor ausgeführt werden. Es wird jedoch empfohlen, 3 oder 5 Monitore zu erstellen, um den Ausfall des gesamten Systems aufgrund des Ausfalls eines einzelnen Monitors zu vermeiden. Die Hauptsache ist, dass die Anzahl dieser ungerade sein sollte, um Split-Brain-Situationen zu vermeiden. Monitore arbeiten in einem Quorum. Wenn also mehr als die Hälfte der Monitore ausfällt, wird der Cluster blockiert, um Dateninkonsistenzen zu vermeiden.
Mgr
Der Ceph Manager-Daemon arbeitet mit dem Monitor-Daemon zusammen, um zusätzliche Kontrolle bereitzustellen.
Seit Version 12.x ist der ceph-mgr-Daemon für den normalen Betrieb erforderlich geworden.
Wenn der mgr-Daemon nicht ausgeführt wird, wird eine Warnung angezeigt.
OSD (Object Storage Device)
OSD ist eine Speichereinheit, die die Daten selbst speichert und Clientanforderungen durch Datenaustausch mit anderen OSDs verarbeitet. Dies ist normalerweise eine Festplatte. Normalerweise gibt es für jedes OSD einen separaten OSD-Daemon, der auf jedem Computer ausgeführt werden kann, auf dem diese Festplatte installiert ist.
Alle drei Daemons funktionieren auf jedem Computer in unserem Cluster. Dementsprechend überwachen und verwalten Sie Daemons als Service- und OSD-Daemons für ein Laufwerk unserer virtuellen Maschine.
Konfigurieren Sie Clusterknoten vor der Installation
Die ceph-Dokumentation gibt den folgenden Workflow an:

Ich werde vom ersten Knoten des ceph01-Test-Clusters aus arbeiten, es wird der Admin-Knoten sein, es wird auch Konfigurationsdateien für das Dienstprogramm ceph-deploy enthalten. Damit das Dienstprogramm ceph-deploy ordnungsgemäß funktioniert, müssen alle Clusterknoten über ssh mit dem Admin-Knoten erreichbar sein. Der Einfachheit halber schreibe ich in die Hosts Kurznamen für den Cluster
10.73.88.52 ceph01-test 10.73.88.53 ceph02-test 10.73.88.54 ceph03-tset
Und kopieren Sie die Schlüssel auf die anderen Hosts. Alle Befehle werde ich von root ausführen.
ssh-copy-id ceph02-test ssh-copy-id ceph03-test
Setup-Dokumentation
ceph-deployInstallieren Sie ceph-deploy
Der erste Schritt ist die Installation von ceph-deploy auf dem ceph01-Testcomputer
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
Als Nächstes müssen Sie die Version auswählen, die Sie einfügen möchten. Aber hier gibt es Schwierigkeiten, derzeit unterstützt ceph für Debian OS nur leuchtende Pakete.
Wenn Sie eine neuere Version einfügen möchten, müssen Sie beispielsweise einen Spiegel verwenden
https://mirror.croit.io/debian-mimic/dists/
Fügen Sie auf allen drei Knoten ein Repository mit Mimic hinzu
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-deploy
Wenn Ihnen das Licht ausreicht, können Sie die offiziellen Repositories verwenden
echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list apt-transport-https apt update apt install ceph-deploy
Wir installieren auch NTP auf allen drei Knoten.
da diese empfehlung in der ceph dokumentation stehtWir empfehlen, NTP auf Ceph-Knoten (insbesondere auf Ceph Monitor-Knoten) zu installieren, um Probleme durch Taktdrift zu vermeiden.
apt install ntp
Stellen Sie sicher, dass Sie den NTP-Dienst aktivieren. Stellen Sie sicher, dass jeder Ceph-Knoten denselben NTP-Server verwendet. Weitere Details finden Sie hier
Erstellen eines Ceph-Clusters
Erstellen Sie ein Verzeichnis für Konfigurationsdateien und Dateien ceph-deploy
mkdir my-cluster cd my-cluster
Lassen Sie uns eine neue Cluster-Konfiguration erstellen. Geben Sie beim Erstellen an, dass unser Monitor drei Monitore enthält
ceph-deploy new ceph01-test ceph02-test ceph03-test
Netzwerkeinrichtung
Jetzt ist der wichtige Punkt, es ist Zeit, über das Netzwerk für Ceph zu sprechen. Ceph verwendet zwei öffentliche Netzwerke und ein Clusternetzwerk, um zu arbeiten

Wie Sie dem Diagramm des öffentlichen Netzwerks entnehmen können, ist dies die Benutzer- und Anwendungsebene, und das Clusternetzwerk ist das Netzwerk, über das Daten repliziert werden.
Es ist sehr wünschenswert, diese beiden Netzwerke voneinander zu trennen. Außerdem ist ein Netzwerkgeschwindigkeits-Cluster-Netzwerk mit mindestens 10 GB wünschenswert.
Natürlich können Sie alles im selben Netzwerk behalten. Dies ist jedoch mit der Tatsache behaftet, dass die Netzwerklast SEHR zunimmt, sobald das Replikationsvolumen zwischen OSDs zunimmt, beispielsweise wenn neue OSDs (Festplatten) fallen oder hinzugefügt werden. Die Geschwindigkeit und Stabilität Ihrer Infrastruktur hängt also stark vom von ceph verwendeten Netzwerk ab.
Leider verfügt mein Virtualisierungscluster nicht über ein separates Netzwerk, und ich werde ein gemeinsames Netzwerksegment verwenden.
Die Netzwerkkonfiguration für den Cluster erfolgt über die Konfigurationsdatei, die wir mit dem vorherigen Befehl generiert haben.
/my-cluster# cat ceph.conf [global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
Wie wir sehen können, hat die cef-Bereitstellung nicht die Standardnetzwerkeinstellungen für uns erstellt, daher werde ich den Parameter public network = {public-network / netmask} zum globalen Abschnitt der Konfiguration hinzufügen. Mein Netzwerk ist 10.73.0.0/16, daher sieht meine Konfiguration nach dem Hinzufügen folgendermaßen aus
[global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 public network = 10.73.0.0/16 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
Wenn Sie das Clusternetzwerk von öffentlich trennen möchten, fügen Sie den Parameter cluster network = {cluster-network / netmask} hinzu
Weitere Informationen zu Netzwerken finden Sie in der Dokumentation.
Installieren Sie Ceph-Pakete
Mit ceph-deploy installieren wir alle benötigten ceph-Pakete auf unseren drei Knoten.
Führen Sie dazu auf ceph01-test aus
Wenn die Version imitiert ist, dann
ceph-deploy install --release mimic ceph01-test ceph02-test ceph03-test
Wenn die Version dann leuchtet
ceph-deploy install --release luminous ceph01-test ceph02-test ceph03-test
Und warten Sie, bis alles feststeht.
Installation und Initialisierung von Monitoren
Nachdem alle Pakete installiert wurden, erstellen und initiieren wir die Monitore unseres Clusters.
C ceph01-Test gehen Sie wie folgt vor
ceph-deploy mon create-initial
Dabei werden Monitore erstellt, Daemons gestartet und ceph-deploy das Quorum überprüft.
Streuen Sie nun die Konfigurationen auf die Clusterknoten.
ceph-deploy admin ceph01-test ceph02-test ceph03-test
Und überprüfen Sie den Status unseres Clusters. Wenn Sie alles richtig gemacht haben, sollte der Status sein
GESUNDHEIT_OK
~/my-cluster# ceph status cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: no daemons active osd: 0 osds: 0 up, 0 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 0 B used, 0 B / 0 B avail pgs:
Erstellen Sie mgr
ceph-deploy mgr create ceph01-test ceph02-test ceph03-test
Und überprüfen Sie den Status erneut
ceph -s
Eine Linie sollte erscheinen
mgr: ceph01-test(active), standbys: ceph02-test, ceph03-test
Wir schreiben die Konfiguration an alle Hosts im Cluster
ceph-deploy admin ceph01-test ceph02-test ceph03-test
OSD hinzufügen
Im Moment haben wir einen funktionierenden Cluster, aber es gibt noch keine Festplatten (osd in der Ceph-Terminologie) zum Speichern von Informationen.
OSD kann mit dem folgenden Befehl hinzugefügt werden (Gesamtansicht)
ceph-deploy osd create --data {device} {ceph-node}
In meinem Testbed wird disk / dev / sdb unter osd zugewiesen. In meinem Fall lauten die Befehle also wie folgt
ceph-deploy osd create --data /dev/sdb ceph01-test ceph-deploy osd create --data /dev/sdb ceph02-test ceph-deploy osd create --data /dev/sdb ceph03-test
Überprüfen Sie, ob alle OSDs funktionieren.
ceph -s
Fazit
cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: ceph01-test(active) osd: 3 osds: 3 up, 3 in
Sie können auch einige nützliche Befehle für OSD ausprobieren.
ceph osd df ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS 0 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 1 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 2 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 TOTAL 15 GiB 3.0 GiB 12 GiB 20.05
und
ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.01469 root default -3 0.00490 host ceph01-test 0 hdd 0.00490 osd.0 up 1.00000 1.00000 -5 0.00490 host ceph02-test 1 hdd 0.00490 osd.1 up 1.00000 1.00000 -7 0.00490 host ceph03-test 2 hdd 0.00490 osd.2 up 1.00000 1.00000
Wenn alles in Ordnung ist, haben wir einen funktionierenden Ceph-Cluster. Im nächsten Teil werde ich erklären, wie man Ceph mit Kubernetes benutzt
Verbinden Sie Ceph mit Kubernetes
Leider kann ich den Betrieb von Kubernetes-Volumes in diesem Artikel nicht detailliert beschreiben, daher werde ich versuchen, in einen Absatz zu passen.
Kubernetes verwendet Speicherklassen, um mit Datenmengen zu arbeiten. Jede Speicherklasse verfügt über einen eigenen Provisioner. Sie können ihn als eine Art „Treiber“ für die Arbeit mit verschiedenen Datenspeichermengen betrachten. Die vollständige Liste, die Kubernetes unterstützt, finden Sie in der offiziellen Dokumentation .
Kubernetes selbst unterstützt auch die Arbeit mit rbd, aber im offiziellen kube-controller-manager-Image ist kein rbd-Client installiert, sodass Sie ein anderes Image verwenden müssen.
Es sollte auch beachtet werden, dass als rbd erstellte Volumes (pvc) nur ReadWriteOnce (RWO) und sein können, was bedeutet, dass Sie das erstellte Volume NUR an einem Herd mounten können.
Damit unser Cluster mit Ceph-Volumes arbeiten kann, benötigen wir:
in einem Ceph-Cluster:
- Erstellen Sie einen Datenpool im Ceph-Cluster
- Erstellen Sie einen Client und greifen Sie auf den Datenpool zu
- Holen Sie sich Ceph Admin Geheimnis
Damit unser Cluster mit Ceph-Volumes arbeiten kann, benötigen wir:
in einem Ceph-Cluster:
- Erstellen Sie einen Datenpool im Ceph-Cluster
- Erstellen Sie einen Client und greifen Sie auf den Datenpool zu
- Holen Sie sich Ceph Admin Geheimnis
im Kubernetes-Cluster:
- Erstellen Sie das Ceph-Administratorgeheimnis und den Ceph-Client-Schlüssel
- Installieren Sie den ceph rbd-Provisioner oder ändern Sie das kube-controller-manager-Image in ein Image, das rbd unterstützt
- Erstellen Sie ein Geheimnis mit dem Ceph-Client-Schlüssel
- Speicherklasse erstellen
- Installieren Sie Ceph-Common auf Kubernetes Worker Notes
Erstellen eines Datenpools
Erstellen Sie im Ceph-Cluster einen Pool für die Kubernetes-Volumes
ceph osd pool create kube 8 8
Hier werde ich eine kleine Erklärung abgeben, die Zahlen 8 8 am Ende sind die Zahlen von pg und pgs. Diese Werte hängen von der Größe Ihres Ceph-Clusters ab. Es gibt spezielle Taschenrechner, die die Menge an pg und pgs berechnen, zum Beispiel offiziell von ceph
Zunächst empfehle ich, es standardmäßig zu belassen, wenn dieser Betrag in Zukunft erhöht werden kann (er kann nur gegenüber der Nautilus-Version reduziert werden).
Erstellen eines Clients für einen Datenpool
Erstellen Sie einen Client für den neuen Pool
ceph auth add client.kube mon 'allow r' osd 'allow rwx pool=kube'
Wir werden einen Schlüssel für den Kunden erhalten, in Zukunft werden wir ihn benötigen, um geheime Kubernetes zu erstellen
ceph auth get-key client.kube AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg==
Admin-Schlüssel erhalten
Und hol dir den Admin-Schlüssel
ceph auth get client.admin 2>&1 |grep "key = " |awk '{print $3'} AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA==
Auf dem Ceph-Cluster sind alle Arbeiten abgeschlossen, und jetzt müssen wir zu einem Computer gehen, der Zugriff auf den Kubernetes-Cluster hat
Ich werde mit dem master01-Test (10.73.71.25) des von mir in der ersten Veröffentlichung bereitgestellten Clusters arbeiten.
Ein Kundengeheimnis erstellen
Erstellen Sie eine Datei mit dem Client-Token, das wir erhalten haben (vergessen Sie nicht, sie durch Ihr Token zu ersetzen).
echo AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg== > /tmp/key.client
Und schaffen Sie ein Geheimnis, das wir in Zukunft nutzen werden
kubectl create secret generic ceph-secret --from-file=/tmp/key.client --namespace=kube-system --type=kubernetes.io/rbd
Admin-Geheimnis erstellen
Erstellen Sie eine Datei mit dem Admin-Token (vergessen Sie nicht, sie durch Ihr Token zu ersetzen).
echo AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA== > /tmp/key.admin
Danach erstellen Sie ein Admin-Geheimnis
kubectl create secret generic ceph-admin-secret --from-file=/tmp/key.admin --namespace=kube-system --type=kubernetes.io/rbd
Überprüfen Sie, ob Geheimnisse erstellt wurden
kubectl get secret -n kube-system | grep ceph ceph-admin-secret kubernetes.io/rbd 1 8m31s ceph-secret kubernetes.io/rbd 1 7m32s
Methode zuerst bereitstellen ceph rbd Provisioner
Wir klonen das Kubernetes-Inkubator / External-Storage-Repository mit Github. Es enthält alles, was Sie benötigen, um den Kubernetes-Cluster mit dem Ceph-Repository anzufreunden.
git clone https://github.com/kubernetes-incubator/external-storage.git cd external-storage/ceph/rbd/deploy/ NAMESPACE=kube-system sed -r -i "s/namespace: [^ ]+/namespace: $NAMESPACE/g" ./rbac/clusterrolebinding.yaml ./rbac/rolebinding.yaml
kubectl -n $NAMESPACE apply -f ./rbac
Fazit
clusterrole.rbac.authorization.k8s.io/rbd-provisioner created clusterrolebinding.rbac.authorization.k8s.io/rbd-provisioner created deployment.extensions/rbd-provisioner created role.rbac.authorization.k8s.io/rbd-provisioner created rolebinding.rbac.authorization.k8s.io/rbd-provisioner created serviceaccount/rbd-provisioner created
Methode zwei: Ersetzen Sie das kube-controller-manager-Image
Es gibt keine rbd-Unterstützung im offiziellen kube-controller-manager-Image, daher müssen wir das controller-manager-Image ändern.
Dazu müssen Sie auf jedem der Kubernetes-Assistenten die Datei kube-controller-manager.yaml bearbeiten und das Bild durch gcr.io/google_containers/hyperkube:v1.15.2 ersetzen. Achten Sie auf die Version des Bildes, die Ihrer Version des Kubernetes-Clusters entsprechen soll.
vim /etc/kubernetes/manifests/kube-controller-manager.yaml
Danach müssen Sie kube-controller-manager neu starten
ubectl get pods -A | grep manager kube-system kube-controller-manager-master01-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master02-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master03-test 1/1 Running 9111 103d
Pods sollten automatisch aktualisiert werden. Wenn dies jedoch aus irgendeinem Grund nicht geschehen ist, können Sie sie durch Löschen manuell neu erstellen.
kubectl delete pod -n kube-system kube-controller-manager-master01-test kubectl delete pod -n kube-system kube-controller-manager-master02-test kubectl delete pod -n kube-system kube-controller-manager-master03-test
Überprüfen Sie, ob alles in Ordnung ist
kubectl describe pod -n kube-system kube-controller-manager-master02-test | grep Image: Image: gcr.io/google_containers/hyperkube:v1.15.2
- -
Erstellen einer Speicherklasse
Methode eins - wenn Sie den Provisioner ceph.com/rbd verwendet haben
Erstellen Sie eine Yaml-Datei mit einer Beschreibung unserer Speicherklasse. Außerdem können alle unten verwendeten Dateien in mein Repository im ceph-Verzeichnis heruntergeladen werden
cat <<EOF >./storage-class.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: ceph.com/rbd parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
Und bette ihn in unseren Cluster ein
kubectl apply -f storage-class.yaml
Überprüfen Sie, ob alles in Ordnung ist
kubectl get sc NAME PROVISIONER AGE ceph-rbd ceph.com/rbd 7s
Methode zwei - wenn Sie den Provisioner kubernetes.io/rbd verwendet haben
Speicherklasse erstellen
cat <<EOF >./storage-class-hyperkube.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: kubernetes.io/rbd allowVolumeExpansion: true parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
Und bette ihn in unseren Cluster ein
kubectl apply -f storage-class-hyperkube.yaml storageclass.storage.k8s.io/ceph-rbd created
Überprüfen Sie, ob alles in Ordnung ist
kubectl get sc NAME PROVISIONER AGE ceph-rbd kubernetes.io/rbd 107s
Kubernetes + Ceph-Bandtest
Bevor Sie ceph + kubernetes testen, müssen Sie das ceph-common-Paket auf JEDEM Workcode des Clusters installieren.
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-common
Erstellen Sie eine Yaml-Datei PersistentVolumeClaim
cat <<EOF >./claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: ceph-rbd resources: requests: storage: 1Gi EOF
Töte ihn
kubectl apply -f claim.yaml
Überprüfen Sie, ob PersistentVolumeClaim erstellt wurde.
bectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim1 Bound pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO ceph-rbd 44m
Und auch automatisch PersistentVolume erstellt.
kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO Delete Bound default/claim1 ceph-rbd 37m
Lassen Sie uns einen Test-Pod erstellen, in dem wir den erstellten PVC in das Verzeichnis / mnt aufnehmen. Führen Sie diese Datei /mnt/test.txt mit dem Text "Hello World!"
cat <<EOF >./create-file-pod.yaml kind: Pod apiVersion: v1 metadata: name: create-file-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "echo Hello world! > /mnt/test.txt && exit 0 || exit 1" volumeMounts: - name: pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
Wir werden ihn töten und überprüfen, ob er seine Aufgabe erfüllt hat
kubectl apply -f create-file-pod.yaml kubectl get pods -w
Warten wir auf den Status
create-file-pod 0/1 Completed 0 16s
Lassen Sie uns ein neues erstellen, unser Volume daran anschließen, aber bereits in / mnt / test, und danach sicherstellen, dass die vom ersten Volume erstellte Datei vorhanden ist
cat <<EOF >./test-pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "sleep 600" volumeMounts: - name: pvc mountPath: "/mnt/test" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
Führen Sie kubectl get po -w aus und warten Sie, bis der Pod ausgeführt wird
Danach gehen wir hinein und überprüfen, ob das Volume verbunden ist und unsere Datei im Verzeichnis / mnt / test
kubectl exec test-pod -ti sh cat /mnt/test/test.txt Helo world!
Vielen Dank für das Lesen bis zum Ende. Entschuldigen Sie die Verzögerung bei der Veröffentlichung.
Ich bin bereit, alle Fragen in persönlichen Nachrichten oder in sozialen Netzwerken zu beantworten, die in meinem Profil angegeben sind.
In der nächsten kleinen Veröffentlichung werde ich Ihnen erklären, wie Sie S3-Speicher basierend auf dem erstellten Ceph-Cluster und dann gemäß dem Plan aus der ersten Veröffentlichung bereitstellen.
Zur Veröffentlichung verwendete Materialien