{"id":94739,"date":"2020-09-20T19:42:27","date_gmt":"2020-09-20T17:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prakticheskij-primer-podklyucheniya-hranilishha-na-baze-ceph-v-klaster-kubernetes"},"modified":"2021-01-02T13:05:08","modified_gmt":"2021-01-02T11:05:08","slug":"prakticheskij-primer-podklyucheniya-hranilishha-na-baze-ceph-v-klaster-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prakticheskij-primer-podklyucheniya-hranilishha-na-baze-ceph-v-klaster-kubernetes","title":{"rendered":"Praktisches Beispiel f\u00fcr die Anbindung eines Ceph-Speichers an ein Kubernetes-Cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Container Storage Interface (CSI) ist ein einheitlicher Schnittstellenstandard f\u00fcr die Interaktion zwischen Kubernetes und Speichersystemen. Wir haben bereits kurz dar\u00fcber gesprochen, und berichteten<\/a><\/noindex>, und heute betrachten wir genauer die Verbindung zwischen CSI und Ceph: wir zeigen, wie man Speicher Ceph<\/a><\/noindex> zum Kubernetes-Cluster hinzuf\u00fcgt.
\nDer Artikel enth\u00e4lt einige reale, wenn auch etwas vereinfachte Beispiele zur besseren Verst\u00e4ndlichkeit. Informationen zur Installation und Konfiguration von Ceph- und Kubernetes-Clustern werden hier nicht behandelt.<\/p>\n

Interessiert es Sie, wie das funktioniert?<\/p>\n

\"Praktisches<\/p>\n

<\/a><\/noindex><\/p>\n

Also haben Sie einen Kubernetes-Cluster, der beispielsweise mit kubespray<\/a><\/noindex>bereits eingerichtet wurde. Nebenan l\u00e4uft ein Ceph-Cluster, das man ebenfalls mit diesem Playbook-Set<\/a><\/noindex>einrichten kann. Ich hoffe, es muss nicht erw\u00e4hnt werden, dass zwischen ihnen ein Netzwerk mit einer Bandbreite von mindestens 10 Gbit\/s bestehen muss.<\/p>\n

Wenn Sie all das haben, legen wir los!<\/p>\n

Zuerst melden wir uns an einem der Knoten des Ceph-Clusters an und \u00fcberpr\u00fcfen, ob alles in Ordnung ist:<\/p>\n

ceph health\nceph -s<\/code><\/pre>\n
Dann erstellen wir sofort einen Pool f\u00fcr RBD-Disketten:<\/p>\n
ceph osd pool create kube 32\nceph osd pool application enable kube rbd<\/code><\/pre>\n
Gehen wir zum Kubernetes-Cluster. Dort installieren wir zun\u00e4chst den Ceph CSI-Treiber f\u00fcr RBD. Wir werden es, wie es sich geh\u00f6rt, \u00fcber Helm installieren.
\nWir f\u00fcgen das Repository mit dem Chart hinzu und erhalten eine Reihe von Variablen f\u00fcr das Chart ceph-csi-rbd:<\/p>\n
helm repo add ceph-csi https:\/\/ceph.github.io\/csi-charts\nhelm inspect values ceph-csi\/ceph-csi-rbd > cephrbd.yml<\/code><\/pre>\n
Jetzt m\u00fcssen wir die Datei cephrbd.yml ausf\u00fcllen. Daf\u00fcr holen wir uns die Cluster-ID und die IP-Adressen der Monitore in Ceph:<\/p>\n
ceph fsid  # so erfahren wir die clusterID\nceph mon dump  # und hier sehen wir die IP-Adressen der Monitore<\/code><\/pre>\n
Die ermittelten Werte tragen wir in die Datei cephrbd.yml ein. Gleichzeitig aktivieren wir die Erstellung von PSPs (Pod Security Policies). Die Optionen in den Abschnitten nodeplugin<\/strong> und provisioner<\/strong> sind bereits in der Datei vorhanden und k\u00f6nnen wie folgt ge\u00e4ndert werden:<\/p>\n
csiConfig:\n  - clusterID: \"bcd0d202-fba8-4352-b25d-75c89258d5ab\"\n    monitors:\n      - \"v2:172.18.8.5:3300\/0,v1:172.18.8.5:6789\/0\"\n      - \"v2:172.18.8.6:3300\/0,v1:172.18.8.6:6789\/0\"\n      - \"v2:172.18.8.7:3300\/0,v1:172.18.8.7:6789\/0\"\n\nnodeplugin:\n  podSecurityPolicy:\n    enabled: true\n\nprovisioner:\n  podSecurityPolicy:\n    enabled: true<\/code><\/pre>\n
Danach bleibt uns nur zu tun \u2014 das Chart im Kubernetes-Cluster installieren.<\/p>\n
helm upgrade -i ceph-csi-rbd ceph-csi\/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespace<\/code><\/pre>\n
Ausgezeichnet, der RBD-Treiber funktioniert!
\nLassen Sie uns eine neue StorageClass in Kubernetes erstellen. Dazu m\u00fcssen wir wieder etwas mit Ceph arbeiten.<\/p>\n
Wir erstellen einen neuen Benutzer in Ceph und gew\u00e4hren ihm Schreibrechte f\u00fcr den Pool kube<\/strong>:<\/p>\n
ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'<\/code><\/pre>\n
Und nun schauen wir uns den Zugriffsschl\u00fcssel dort an:<\/p>\n
ceph auth get-key client.rbdkube<\/code><\/pre>\n
Der Befehl wird etwas \u00c4hnliches ausgeben:<\/p>\n
AQCO9NJbhYipKRAAMqZsnqqS\/T8OYQX20xIa9A==<\/code><\/pre>\n
Wir tragen diesen Wert in einen Secret im Kubernetes-Cluster ein \u2014 dorthin, wo er ben\u00f6tigt wird. userKey<\/strong>:<\/p>\n
---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: csi-rbd-secret\n  namespace: ceph-csi-rbd\nstringData:\n  # Die Schl\u00fcsselwerte entsprechen dem Benutzernamen und dessen Schl\u00fcssel, wie im\n  # Ceph-Cluster angegeben. Die ID des Benutzers muss Zugriffsrechte auf den Pool haben,\n  # der in der Storage Class angegeben ist.\n  userID: rbdkube\n  userKey:<\/code><\/pre>\n
Und wir erstellen unser Geheimnis:<\/p>\n
kubectl apply -f secret.yaml<\/code><\/pre>\n
Wir ben\u00f6tigen als N\u00e4chstes ein ungef\u00e4hr solches Manifest f\u00fcr die StorageClass:<\/p>\n
---\napiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n   name: csi-rbd-sc\nprovisioner: rbd.csi.ceph.com\nparameters:\n   clusterID: \n   pool: kube\n\n   imageFeatures: layering\n\n   # Diese Geheimnisse m\u00fcssen Daten f\u00fcr die Authentifizierung\n   # in Ihren Pool enthalten.\n   csi.storage.k8s.io\/provisioner-secret-name: csi-rbd-secret\n   csi.storage.k8s.io\/provisioner-secret-namespace: ceph-csi-rbd\n   csi.storage.k8s.io\/controller-expand-secret-name: csi-rbd-secret\n   csi.storage.k8s.io\/controller-expand-secret-namespace: ceph-csi-rbd\n   csi.storage.k8s.io\/node-stage-secret-name: csi-rbd-secret\n   csi.storage.k8s.io\/node-stage-secret-namespace: ceph-csi-rbd\n\n   csi.storage.k8s.io\/fstype: ext4\n\nreclaimPolicy: Delete\nallowVolumeExpansion: true\nmountOptions:\n  - discard<\/code><\/pre>\n
Muss ausgef\u00fcllt werden: clusterID<\/strong>, den wir bereits mit dem Befehl ceph fsid<\/em>, und wenden dieses Manifest im Kubernetes-Cluster an:<\/p>\n
kubectl apply -f storageclass.yaml<\/code><\/pre>\n
Um die Funktionalit\u00e4t der Cluster in Verbindung zu \u00fcberpr\u00fcfen, erstellen wir diesen PVC (Persistent Volume Claim):<\/p>\n
apiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: rbd-pvc\nspec:\n  accessModes:\n  - ReadWriteOnce\n  resources:\n    requests:\n      storage: 1Gi\n  storageClassName: csi-rbd-sc<\/code><\/pre>\n
Schauen wir uns sofort an, wie Kubernetes in Ceph das angeforderte Volume erstellt hat:<\/p>\n
kubectl get pvc\nkubectl get pv<\/code><\/pre>\n
Sieht gut aus! Und wie sieht es auf der Ceph-Seite aus?
\nWir holen uns eine Liste der Volumes im Pool und sehen die Informationen zu unserem Volume an:<\/p>\n
rbd ls -p kube\nrbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # hier wird nat\u00fcrlich eine andere ID des Volumes angezeigt, die von dem vorherigen Befehl ausgegeben wurde.<\/code><\/pre>\n
Jetzt schauen wir uns an, wie die Gr\u00f6\u00dfe des RBD-Volumes ver\u00e4ndert wird.
\nWir \u00e4ndern die Gr\u00f6\u00dfe des Volumes im Manifest pvc.yaml auf 2Gi und wenden es an:<\/p>\n
kubectl apply -f pvc.yaml<\/code><\/pre>\n
Warten wir, bis die \u00c4nderungen wirksam werden, und sehen wir uns erneut die Gr\u00f6\u00dfe des Volumes an.<\/p>\n
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653\n\nkubectl get pv\nkubectl get pvc<\/code><\/pre>\n
Wir sehen, dass die Gr\u00f6\u00dfe des PVC unver\u00e4ndert geblieben ist. Um den Grund herauszufinden, k\u00f6nnen wir Kubernetes auffordern, die Beschreibung des PVC im YAML-Format abzurufen:<\/p>\n
kubectl get pvc rbd-pvc -o yaml<\/code><\/pre>\n
Und hier ist das Problem:<\/p>\n
message: Warten auf den Benutzer, um einen Pod (neu) zu starten, um die Gr\u00f6\u00dfen\u00e4nderung des Dateisystems des Volumes auf dem Knoten abzuschlie\u00dfen. type: FileSystemResizePending<\/em><\/p>\n
Das bedeutet, die Disk wurde vergr\u00f6\u00dfert, aber das Dateisystem darauf \u2014 nicht.
\nUm das Dateisystem zu vergr\u00f6\u00dfern, muss das Volume gemountet werden. Unser erstellter PVC\/PV wird zurzeit jedoch nicht genutzt.<\/p>\n
Wir k\u00f6nnen einen Test-Pod erstellen, zum Beispiel so:<\/p>\n
---\napiVersion: v1\nkind: Pod\nmetadata:\n  name: csi-rbd-demo-pod\nspec:\n  containers:\n    - name: web-server\n      image: nginx:1.17.6\n      volumeMounts:\n        - name: mypvc\n          mountPath: \/data\n  volumes:\n    - name: mypvc\n      persistentVolumeClaim:\n        claimName: rbd-pvc\n        readOnly: false<\/code><\/pre>\n
Und jetzt schauen wir uns das PVC an:<\/p>\n
kubectl get pvc<\/code><\/pre>\n
Die Gr\u00f6\u00dfe hat sich ge\u00e4ndert, alles in Ordnung.<\/p>\n
Im ersten Teil haben wir mit dem Blockger\u00e4t RBD gearbeitet (was auch f\u00fcr Rados Block Device steht), aber das ist nicht m\u00f6glich, wenn verschiedene Mikrodienste gleichzeitig auf dieses Laufwerk zugreifen sollen. F\u00fcr die Arbeit mit Dateien, und nicht mit einem Abbild des Laufwerks, ist CephFS viel besser geeignet.
\nAnhand von Ceph- und Kubernetes-Clustern richten wir CSI und andere erforderliche Entit\u00e4ten f\u00fcr die Arbeit mit CephFS ein.<\/p>\n
Wir erhalten die Werte aus dem ben\u00f6tigten neuen Helm-Chart:<\/p>\n
helm inspect values ceph-csi\/ceph-csi-cephfs > cephfs.yml<\/code><\/pre>\n
Wieder m\u00fcssen wir die Datei cephfs.yml ausf\u00fcllen. Wie zuvor helfen uns die Ceph-Befehle:<\/p>\n
ceph fsid\nceph mon dump<\/code><\/pre>\n
Das Ausf\u00fcllen der Datei mit Werten sieht ungef\u00e4hr so aus:<\/p>\n
csiConfig:\n  - clusterID: \"bcd0d202-fba8-4352-b25d-75c89258d5ab\"\n    monitors:\n      - \"172.18.8.5:6789\"\n      - \"172.18.8.6:6789\"\n      - \"172.18.8.7:6789\"\n\nnodeplugin:\n  httpMetrics:\n    enabled: true\n    containerPort: 8091\n  podSecurityPolicy:\n    enabled: true\n\nprovisioner:\n  replicaCount: 1\n  podSecurityPolicy:\n    enabled: true<\/code><\/pre>\n
Bitte beachten Sie, dass die Adressen der Monitore in einfacher Form address:port angegeben werden. F\u00fcr das Einh\u00e4ngen von cephfs auf dem Knoten werden diese Adressen an das Kernel-Modul \u00fcbergeben, das noch nicht mit dem v2-Monitorprotokoll umgehen kann.
\nDen Port f\u00fcr httpMetrics (woher Prometheus Metriken f\u00fcr das Monitoring abruft) \u00e4ndern wir, um Konflikte mit dem nginx-proxy zu vermeiden, der von Kubespray installiert wird. M\u00f6glicherweise ben\u00f6tigen Sie das nicht.<\/p>\n
Wir installieren das Helm-Chart im Kubernetes-Cluster:<\/p>\n
helm upgrade -i ceph-csi-cephfs ceph-csi\/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespace<\/code><\/pre>\n
Wir wechseln zum Ceph-Datenspeicher, um dort einen separaten Benutzer zu erstellen. In der Dokumentation hei\u00dft es, dass der Provisionierer f\u00fcr CephFS Administratorrechte im Cluster ben\u00f6tigt. Aber wir werden einen separaten Benutzer erstellen fs<\/em> mit eingeschr\u00e4nkten Rechten:<\/p>\n
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'<\/code><\/pre>\n
Und wir sehen uns sofort seinen Zugriffsschl\u00fcssel an, der uns sp\u00e4ter n\u00fctzlich sein wird:<\/p>\n
ceph auth get-key client.fs<\/code><\/pre>\n
Wir erstellen separate Secret und StorageClass.
\nNichts Neues, das haben wir bereits am Beispiel von RBD gesehen:<\/p>\n
---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: csi-cephfs-secret\n  namespace: ceph-csi-cephfs\nstringData:\n  # Notwendig f\u00fcr dynamisch erstellte Volumes\n  adminID: fs\n  adminKey:<\/code><\/pre>\n
Wir wenden das Manifest an:<\/p>\n
kubectl apply -f secret.yaml<\/code><\/pre>\n
Und jetzt \u2013 eine separate StorageClass:<\/p>\n
---\napiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: csi-cephfs-sc\nprovisioner: cephfs.csi.ceph.com\nparameters:\n  clusterID: \n\n  # Name des CephFS-Dateisystems, in dem das Volume erstellt wird\n  fsName: cephfs\n\n  # (optional) Ceph-Pool, in dem die Daten des Volumes gespeichert werden\n  # pool: cephfs_data\n\n  # (optional) Durch Kommas getrennte Mount-Optionen f\u00fcr Ceph-fuse\n  # z. B.:\n  # fuseMountOptions: debug\n\n  # (optional) Durch Kommas getrennte Mount-Optionen f\u00fcr das CephFS-Kernel\n  # Siehe man mount.ceph f\u00fcr die Liste dieser Optionen. Zum Beispiel:\n  # kernelMountOptions: readdir_max_bytes=1048576,norbytes\n\n  # Die Geheimnisse m\u00fcssen Zugangsdaten f\u00fcr den Administrator und\/oder Benutzer von Ceph enthalten.\n  csi.storage.k8s.io\/provisioner-secret-name: csi-cephfs-secret\n  csi.storage.k8s.io\/provisioner-secret-namespace: ceph-csi-cephfs\n  csi.storage.k8s.io\/controller-expand-secret-name: csi-cephfs-secret\n  csi.storage.k8s.io\/controller-expand-secret-namespace: ceph-csi-cephfs\n  csi.storage.k8s.io\/node-stage-secret-name: csi-cephfs-secret\n  csi.storage.k8s.io\/node-stage-secret-namespace: ceph-csi-cephfs\n\n  # (optional) Der Treiber kann entweder ceph-fuse (fuse) oder den Ceph-Kernelclient (kernel) verwenden.\n  # Wenn nichts angegeben ist, wird die standardm\u00e4\u00dfige Volume-Montierung verwendet,\n  # dies wird durch die Suche nach ceph-fuse und mount.ceph bestimmt.\n  # mounter: kernel\nreclaimPolicy: Delete\nallowVolumeExpansion: true\nmountOptions:\n  - debug<\/code><\/pre>\n
Wir f\u00fcgen hier etwas hinzu clusterID<\/strong> und wenden es in Kubernetes an:<\/p>\n
kubectl apply -f storageclass.yaml<\/code><\/pre>\n
\u00dcberpr\u00fcfung<\/h2>\n
Zur \u00dcberpr\u00fcfung, wie im vorherigen Beispiel, erstellen wir ein PVC:<\/p>\n
---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: csi-cephfs-pvc\nspec:\n  accessModes:\n    - ReadWriteMany\n  resources:\n    requests:\n      storage: 5Gi\n  storageClassName: csi-cephfs-sc<\/code><\/pre>\n
Und wir \u00fcberpr\u00fcfen das Vorhandensein von PVC\/PV:<\/p>\n
kubectl get pvc\nkubectl get pv<\/code><\/pre>\n
Wenn Sie die Dateien und Verzeichnisse in CephFS ansehen m\u00f6chten, k\u00f6nnen Sie dieses Dateisystem irgendwo einh\u00e4ngen. Zum Beispiel, wie unten gezeigt.<\/p>\n
Gehen wir zu einem der Knoten im Ceph-Cluster und f\u00fchren wir folgende Schritte aus:<\/p>\n
# \u0422\u043e\u0447\u043a\u0430 \u043c\u043e\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f\nmkdir -p \/mnt\/cephfs\n\n# \u0421\u043e\u0437\u0434\u0430\u0451\u043c \u0444\u0430\u0439\u043b \u0441 \u043a\u043b\u044e\u0447\u043e\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430\nceph auth get-key client.admin >\/etc\/ceph\/secret.key\n\n# \u0414\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u043c \u0437\u0430\u043f\u0438\u0441\u044c \u0432 \/etc\/fstab\n# !! \u0418\u0437\u043c\u0435\u043d\u044f\u0435\u043c ip \u0430\u0434\u0440\u0435\u0441 \u043d\u0430 \u0430\u0434\u0440\u0435\u0441 \u043d\u0430\u0448\u0435\u0433\u043e \u0443\u0437\u043b\u0430\necho \"172.18.8.6:6789:\/ \/mnt\/cephfs ceph name=admin,secretfile=\/etc\/ceph\/secret.key,noatime,_netdev    0       2\" >> \/etc\/fstab\n\nmount \/mnt\/cephfs<\/code><\/pre>\n
Nat\u00fcrlich ist solch eine FS-Montage auf einem Ceph-Knoten ausschlie\u00dflich zu Ausbildungszwecken geeignet, was wir auch in unseren Slurm-Kursen<\/a><\/noindex>. Ich denke nicht, dass das jemand in der Produktion machen w\u00fcrde, da die Gefahr besteht, wichtige Dateien versehentlich zu \u00fcberschreiben.<\/p>\n
Und schlie\u00dflich wollen wir \u00fcberpr\u00fcfen, wie es bei CephFS mit der Gr\u00f6\u00dfen\u00e4nderung des Volumes aussieht. Kehren wir zu Kubernetes zur\u00fcck und bearbeiten wir unser Manifest f\u00fcr PVC \u2013 wir erh\u00f6hen die Gr\u00f6\u00dfe beispielsweise auf 7Gi.<\/p>\n
Wenden Sie die bearbeitete Datei an:<\/p>\n
kubectl apply -f pvc.yaml<\/code><\/pre>\n
Sehen wir uns im montierten Verzeichnis an, wie sich das Kontingent ge\u00e4ndert hat:<\/p>\n
getfattr -n ceph.quota.max_bytes<\/code><\/pre>\n
Um diesen Befehl auszuf\u00fchren, m\u00fcssen Sie m\u00f6glicherweise das Paket in Ihrem System installieren attr<\/strong>.<\/p>\n
Die Augen haben Angst, aber die H\u00e4nde machen<\/h2>\n
Auf den ersten Blick erscheinen all diese Zauberspr\u00fcche und langen YAML-Manifeste komplex, aber in der Praxis kommen die Studierenden von Sljorm damit ziemlich schnell zurecht.
\nIn diesem Artikel sind wir nicht ins Detail gegangen \u2013 daf\u00fcr gibt es die offizielle Dokumentation. Wenn Sie an den Einzelheiten der Konfiguration des Ceph-Speichers in Verbindung mit dem Kubernetes-Cluster interessiert sind, helfen Ihnen die folgenden Links:<\/p>\n
Allgemeine Funktionsprinzipien von Kubernetes mit Volumes<\/a><\/noindex>
\nDokumentation zu RBD<\/a><\/noindex>
\nIntegration von RBD und Kubernetes aus der Perspektive von Ceph<\/a><\/noindex>
\nIntegration von RBD und Kubernetes aus der Perspektive von CSI<\/a><\/noindex>
\nAllgemeine Dokumentation zu CephFS<\/a><\/noindex>
\nIntegration von CephFS und Kubernetes aus der Perspektive von CSI<\/a><\/noindex><\/p>\n
Im Sljorm-Kurs Kubernetes Basis<\/a><\/noindex> k\u00f6nnen Sie noch einen Schritt weiter gehen und eine echte Anwendung in Kubernetes bereitstellen, die CephFS als dateispeicher nutzt. Mithilfe von GET\/POST-Anfragen k\u00f6nnen Sie Dateien \u00fcbertragen und aus Ceph abrufen.<\/p>\n
Und wenn Sie sich mehr f\u00fcr die Datenspeicherung interessieren, melden Sie sich f\u00fcr den neuen Kurs zu Ceph<\/a><\/noindex>an. W\u00e4hrend der Beta-Testphase kann der Kurs mit Rabatt erworben werden und Sie k\u00f6nnen auf dessen Inhalt Einfluss nehmen.<\/p>\n
Autor des Artikels: Alexander Schvalov, praktizierender Ingenieur Southbridge<\/a><\/noindex>, Certified Kubernetes Administrator, Autor und Entwickler der Sljorm-Kurse.<\/em><\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
Container Storage Interface (CSI) \u2014 \u044d\u0442\u043e \u0443\u043d\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f Kubernetes \u0438 \u0441\u0438\u0441\u0442\u0435\u043c \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u044b\u0445. \u0412\u043a\u0440\u0430\u0442\u0446\u0435 \u043e \u043d\u0451\u043c \u043c\u044b \u0443\u0436\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u043b\u0438, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u0432\u044f\u0437\u043a\u0443 CSI \u0438 Ceph: \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0438\u0442\u044c \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435 Ceph \u043a \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0443 Kubernetes. \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043d\u044b \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435, \u0445\u043e\u0442\u044f \u0438 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0443\u043f\u0440\u043e\u0449\u0451\u043d\u043d\u044b\u0435 \u0434\u043b\u044f \u0443\u0434\u043e\u0431\u0441\u0442\u0432\u0430 \u0432\u043e\u0441\u043f\u0440\u0438\u044f\u0442\u0438\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u044b. \u0423\u0441\u0442\u0430\u043d\u043e\u0432\u043a\u0443 \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0443 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 Ceph \u0438 Kubernetes […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94740,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94739","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Praktisches Beispiel f\u00fcr die Anbindung eines Ceph-basierten Speichers an ein Kubernetes-Cluster | ProHoster","description":"Die Container Storage Interface (CSI) ist eine einheitliche Schnittstelle f\u00fcr die Interaktion zwischen Kubernetes und Speichersystemen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prakticheskij-primer-podklyucheniya-hranilishha-na-baze-ceph-v-klaster-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u044f \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u043d\u0430 \u0431\u0430\u0437\u0435 Ceph \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 Kubernetes | ProHoster","og:description":"Container Storage Interface (CSI) \u2014 \u044d\u0442\u043e \u0443\u043d\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f Kubernetes \u0438 \u0441\u0438\u0441\u0442\u0435\u043c \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/prakticheskij-primer-podklyucheniya-hranilishha-na-baze-ceph-v-klaster-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-20T17:42:27+00:00","article:modified_time":"2021-01-02T11:05:08+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94739","title":null,"description":"","keywords":"","keyphrases":null,"primary_term":null,"canonical_url":"","og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:19:21","updated":"2022-09-30 10:03:10","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/94739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=94739"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/94739\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/94740"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=94739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=94739"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=94739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}