Container Storage Interface (CSI) on yhtenäinen käyttöliittymä Kubernetesin ja tallennusjärjestelmien välillä. Olemme jo puhuneet siitä lyhyesti , ja tänään tarkastelemme tarkemmin CSI:n ja Cephin yhdistelmää: näytämme, miten Kubernetes-klusteriin.
Artikkeli tarjoaa todellisia, vaikkakin hieman yksinkertaistettuja esimerkkejä havainnoinnin helpottamiseksi. Emme harkitse Ceph- ja Kubernetes-klustereiden asentamista ja määrittämistä.
Mietitkö kuinka se toimii?
Joten sinulla on käden ulottuvillasi Kubernetes-klusteri, joka on otettu käyttöön esimerkiksi . Lähistöllä toimii Ceph-klusteri - voit myös asentaa sen esimerkiksi tällä . Toivottavasti ei tarvitse mainita, että tuotantoa varten niiden välillä tulee olla verkko, jonka kaistanleveys on vähintään 10 Gbit/s.
Jos sinulla on kaikki tämä, mennään!
Siirrytään ensin yhteen Ceph-klusterin solmuista ja tarkistetaan, että kaikki on kunnossa:
ceph health
ceph -sSeuraavaksi luomme välittömästi poolin RBD-levyille:
ceph osd pool create kube 32
ceph osd pool application enable kube rbdSiirrytään Kubernetes-klusteriin. Siellä asennamme ensin Ceph CSI -ohjaimen RBD:lle. Asennamme odotetusti Helmin kautta.
Lisäämme arkiston kaaviolla, saamme joukon muuttujia ceph-csi-rbd-kaaviolle:
helm repo add ceph-csi https://ceph.github.io/csi-charts
helm inspect values ceph-csi/ceph-csi-rbd > cephrbd.ymlNyt sinun on täytettävä cephrbd.yml-tiedosto. Voit tehdä tämän selvittämällä Cephin monitorien klusterin tunnukset ja IP-osoitteet:
ceph fsid # так мы узнаем clusterID
ceph mon dump # а так увидим IP-адреса мониторовSyötämme saadut arvot cephrbd.yml-tiedostoon. Samalla sallimme PSP-käytäntöjen (Pod Security Policies) luomisen. Vaihtoehdot osioissa nodeplugin и huolehtija jo tiedostossa, ne voidaan korjata alla olevan kuvan mukaisesti:
csiConfig:
- clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
monitors:
- "v2:172.18.8.5:3300/0,v1:172.18.8.5:6789/0"
- "v2:172.18.8.6:3300/0,v1:172.18.8.6:6789/0"
- "v2:172.18.8.7:3300/0,v1:172.18.8.7:6789/0"
nodeplugin:
podSecurityPolicy:
enabled: true
provisioner:
podSecurityPolicy:
enabled: trueSeuraavaksi meidän on vain asennettava kaavio Kubernetes-klusteriin.
helm upgrade -i ceph-csi-rbd ceph-csi/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespaceHienoa, RBD-ohjain toimii!
Luodaan uusi StorageClass Kubernetesiin. Tämä vaatii taas vähän puuhailua Cefin kanssa.
Luomme uuden käyttäjän Cephiin ja annamme hänelle oikeudet kirjoittaa pooliin kuutio:
ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'Katsotaan nyt, että pääsyavain on edelleen olemassa:
ceph auth get-key client.rbdkubeKomento tulostaa jotain tällaista:
AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==Lisätään tämä arvo Secretiin Kubernetes-klusterissa - siellä, missä sitä tarvitaan userKey:
---
apiVersion: v1
kind: Secret
metadata:
name: csi-rbd-secret
namespace: ceph-csi-rbd
stringData:
# Значения ключей соответствуют имени пользователя и его ключу, как указано в
# кластере Ceph. ID юзера должен иметь доступ к пулу,
# указанному в storage class
userID: rbdkube
userKey: <user-key>Ja me luomme salaisuutemme:
kubectl apply -f secret.yamlSeuraavaksi tarvitsemme tällaisen StorageClass-luettelon:
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
clusterID: <cluster-id>
pool: kube
imageFeatures: layering
# Эти секреты должны содержать данные для авторизации
# в ваш пул.
csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret
csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-rbd
csi.storage.k8s.io/fstype: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- discardOn täytettävä clusterID, jonka tiimi on jo oppinut ceph fsid, ja käytä tätä manifestia Kubernetes-klusteriin:
kubectl apply -f storageclass.yamlVoit tarkistaa, kuinka klusterit toimivat yhdessä, luomalla seuraava PVC (Persistent Volume Claim):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rbd-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: csi-rbd-scKatsotaanpa heti, kuinka Kubernetes loi pyydetyn taltion Cephissä:
kubectl get pvc
kubectl get pvKaikki näyttää olevan hienoa! Miltä tämä näyttää Cefin puolella?
Saamme luettelon altaassa olevista osista ja tarkastelemme volyymiämme koskevia tietoja:
rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653 # тут, конечно же, будет другой ID тома, который выдала предыдущая командаKatsotaan nyt, kuinka RBD-taltion koon muuttaminen toimii.
Muuta pvc.yaml-luettelon tilavuuden kooksi 2Gi ja ota se käyttöön:
kubectl apply -f pvc.yamlOdotetaan muutosten voimaantuloa ja katsotaan äänenvoimakkuuden kokoa uudelleen.
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653
kubectl get pv
kubectl get pvcNäemme, että PVC:n koko ei ole muuttunut. Voit selvittää miksi voit kysyä Kubernetesilta PVC:n YAML-kuvauksen:
kubectl get pvc rbd-pvc -o yamlTässä on ongelma:
viesti: Odotetaan, että käyttäjä käynnistää podin (uudelleen) suorittaakseen tiedostojärjestelmän koon muuttamisen loppuun solmussa. tyyppi: FileSystemResizePending
Eli levy on kasvanut, mutta sen tiedostojärjestelmä ei.
Jos haluat kasvattaa tiedostojärjestelmää, sinun on asennettava asema. Maassamme luotua PVC/PV:tä ei tällä hetkellä käytetä millään tavalla.
Voimme luoda testikotelon esimerkiksi näin:
---
apiVersion: v1
kind: Pod
metadata:
name: csi-rbd-demo-pod
spec:
containers:
- name: web-server
image: nginx:1.17.6
volumeMounts:
- name: mypvc
mountPath: /data
volumes:
- name: mypvc
persistentVolumeClaim:
claimName: rbd-pvc
readOnly: falseJa nyt katsotaan PVC:tä:
kubectl get pvcKoko on muuttunut, kaikki on hyvin.
Ensimmäisessä osassa työskentelimme RBD-lohkolaitteen kanssa (se tulee sanoista Rados Block Device), mutta tätä ei voida tehdä, jos eri mikropalvelujen on toimittava tämän levyn kanssa samanaikaisesti. CephFS sopii paljon paremmin tiedostojen kuin levykuvien käsittelyyn.
Ceph- ja Kubernetes-klusterien esimerkin avulla määritämme CSI:n ja muut tarvittavat entiteetit toimimaan CephFS:n kanssa.
Otetaan arvot uudesta Helm-kaaviosta, joita tarvitsemme:
helm inspect values ceph-csi/ceph-csi-cephfs > cephfs.ymlJälleen sinun on täytettävä cephfs.yml-tiedosto. Kuten ennenkin, Ceph-komennot auttavat:
ceph fsid
ceph mon dumpTäytä tiedosto seuraavasti:
csiConfig:
- clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
monitors:
- "172.18.8.5:6789"
- "172.18.8.6:6789"
- "172.18.8.7:6789"
nodeplugin:
httpMetrics:
enabled: true
containerPort: 8091
podSecurityPolicy:
enabled: true
provisioner:
replicaCount: 1
podSecurityPolicy:
enabled: trueHuomaa, että monitorien osoitteet määritetään yksinkertaisessa muodossa osoite:portti. Cephf:ien asentamiseksi solmuun nämä osoitteet siirretään ydinmoduuliin, joka ei vielä osaa toimia v2-valvontaprotokollan kanssa.
Muutamme httpMetricsin porttia (Prometheus menee sinne mittausten seurantaan), jotta se ei ole ristiriidassa Kubesprayn asentaman nginx-proxyn kanssa. Et ehkä tarvitse tätä.
Asenna Helm-kaavio Kubernetes-klusteriin:
helm upgrade -i ceph-csi-cephfs ceph-csi/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespaceSiirrytään Ceph-tietokauppaan luodaksesi sinne erillinen käyttäjä. Dokumentaatiossa todetaan, että CephFS-hallintaohjelma vaatii klusterin järjestelmänvalvojan käyttöoikeudet. Mutta luomme erillisen käyttäjän fs rajoitetuilla oikeuksilla:
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'Ja katsotaan heti hänen pääsyavaimensa, tarvitsemme sitä myöhemmin:
ceph auth get-key client.fsLuodaan erilliset Secret ja StorageClass.
Ei mitään uutta, olemme jo nähneet tämän RBD-esimerkissä:
---
apiVersion: v1
kind: Secret
metadata:
name: csi-cephfs-secret
namespace: ceph-csi-cephfs
stringData:
# Необходимо для динамически создаваемых томов
adminID: fs
adminKey: <вывод предыдущей команды>Manifestin soveltaminen:
kubectl apply -f secret.yamlJa nyt - erillinen StorageClass:
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: csi-cephfs-sc
provisioner: cephfs.csi.ceph.com
parameters:
clusterID: <cluster-id>
# Имя файловой системы CephFS, в которой будет создан том
fsName: cephfs
# (необязательно) Пул Ceph, в котором будут храниться данные тома
# pool: cephfs_data
# (необязательно) Разделенные запятыми опции монтирования для Ceph-fuse
# например:
# fuseMountOptions: debug
# (необязательно) Разделенные запятыми опции монтирования CephFS для ядра
# См. man mount.ceph чтобы узнать список этих опций. Например:
# kernelMountOptions: readdir_max_bytes=1048576,norbytes
# Секреты должны содержать доступы для админа и/или юзера Ceph.
csi.storage.k8s.io/provisioner-secret-name: csi-cephfs-secret
csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-cephfs
csi.storage.k8s.io/controller-expand-secret-name: csi-cephfs-secret
csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-cephfs
csi.storage.k8s.io/node-stage-secret-name: csi-cephfs-secret
csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-cephfs
# (необязательно) Драйвер может использовать либо ceph-fuse (fuse),
# либо ceph kernelclient (kernel).
# Если не указано, будет использоваться монтирование томов по умолчанию,
# это определяется поиском ceph-fuse и mount.ceph
# mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- debugTäytetään se tähän clusterID ja sovelletaan Kubernetesissa:
kubectl apply -f storageclass.yamlПроверка
Tarkistaaksesi, kuten edellisessä esimerkissä, luodaan PVC:
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-cephfs-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
storageClassName: csi-cephfs-scJa tarkista PVC/PV:n läsnäolo:
kubectl get pvc
kubectl get pvJos haluat tarkastella tiedostoja ja hakemistoja CephFS:ssä, voit asentaa tämän tiedostojärjestelmän jonnekin. Esimerkiksi alla olevan kuvan mukaisesti.
Siirrytään yhteen Ceph-klusterin solmuista ja suoritetaan seuraavat toiminnot:
# Точка монтирования
mkdir -p /mnt/cephfs
# Создаём файл с ключом администратора
ceph auth get-key client.admin >/etc/ceph/secret.key
# Добавляем запись в /etc/fstab
# !! Изменяем ip адрес на адрес нашего узла
echo "172.18.8.6:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2" >> /etc/fstab
mount /mnt/cephfsTietenkin FS:n asentaminen Ceph-solmuun näin soveltuu vain harjoitustarkoituksiin, mitä teemme . En usko, että kukaan tekisi tätä tuotannossa; on suuri vaara, että tärkeät tiedostot poistetaan vahingossa.
Ja lopuksi, tarkistetaan kuinka asiat toimivat volyymien koon muuttamisen kanssa CephFS: n tapauksessa. Palataan Kubernetesiin ja muokataan luetteloa PVC:lle - suurenna koko siellä esimerkiksi 7Gi:iin.
Otetaan muokattu tiedosto käyttöön:
kubectl apply -f pvc.yamlKatsotaanpa liitettyä hakemistoa nähdäksesi kuinka kiintiö on muuttunut:
getfattr -n ceph.quota.max_bytes <каталог-с-данными>Jotta tämä komento toimisi, sinun on ehkä asennettava paketti järjestelmääsi attr.
Silmät pelkäävät, ja kädet tekevät
Kaikki nämä loitsut ja pitkät YAML-manifestit näyttävät pinnalta monimutkaisilta, mutta käytännössä Slurm-opiskelijat saavat niistä selvää melko nopeasti.
Tässä artikkelissa emme menneet syvälle viidakkoon - siitä on olemassa virallinen dokumentaatio. Jos olet kiinnostunut Ceph-tallennustilan määrittämisestä Kubernetes-klusterin kanssa, nämä linkit auttavat:
Slurm-kurssilla voit mennä hieman pidemmälle ja ottaa Kubernetesissa käyttöön todellisen sovelluksen, joka käyttää CephFS:ää tiedostojen tallennustilana. GET/POST-pyyntöjen avulla voit siirtää tiedostoja Cephille ja vastaanottaa niitä sieltä.
Ja jos olet enemmän kiinnostunut tietojen tallentamisesta, rekisteröidy . Kun beta-testi on käynnissä, kurssin saa alennuksella ja voit vaikuttaa sen sisältöön.
Artikkelin kirjoittaja: Alexander Shvalov, insinööri , Sertifioitu Kubernetes-järjestelmänvalvoja, Slurm-kurssien kirjoittaja ja kehittäjä.
Lähde: will.com
