Architecture et Prérequis
A partir de la version 1.13 de Kubernetes, le support natif pour Ceph s'est formalisé via l'interface Container Storage Interface (CSI). L'intégration de solutions de stockage cloud-native repose souvent sur des composants tels que Rook ou l'utilisation directe du driver officiel Ceph-CSI. Ce guide détaille la mise en œuvre d'un volume RBD (RADOS Block Device) accessible par les pods.
L'architecture repose sur la communication entre le contrôleur maître de Kubernetes et le cluster Ceph à travers le pilote CSI. Il est impératif de respecter la matrice de compatibilité entre les versions de Kubernetes, de Ceph et du driver CSI lui-même avant toute installation.
Configuration du Cluster Ceph
Avant de déployer les ressources côté Kubernetes, il faut préparer l'infrastructure de stockage Ceph. Cela inclut la création du pool logique et des identifiants d'accès sécurisés.
# Création du pool de stockage dédié aux applications Kubernetes
[root@ceph-mgr ~]# ceph osd pool create volumes-prod 128 128
pool 'volumes-prod' created
# Génération des identifiants et clés pour le service Kubernetes
[root@ceph-mgr ~]# ceph auth get-or-create client.storage-svc mon 'allow r' osd 'allow rw pool=volumes-prod' mgr 'allow rw pool=volumes-prod'
[client.storage-svc]
key = AQDxYz123456EXAMPLEKEYabcdefghijklmnopqrstuvwxyz==
# Récupération de l'identifiant unique du cluster (FSID)
[root@ceph-mgr ~]# ceph fsid
a1b2c3d4-e5f6-7890-abcd-ef1234567890
# Identification des adresses IP des moniteurs (Monitors)
# Il est recommandé d'utiliser les ports v1 pour une compatibilité maximale
[root@ceph-mgr ~]# ceph mon stat
e5: 3 mons at {
node-alpha=[v1:192.168.10.1:6789/0,v2:192.168.10.1:3300/0],
node-beta=[v1:192.168.10.2:6789/0,v2:192.168.10.2:3300/0],
node-gamma=[v1:192.168.10.3:6789/0,v2:192.168.10.3:3300/0]}
Préparation des Ressources Kubernetes
Le déploiement nécessite la préparation de plusieurs objets configurationnels au sein de l'espace de noms dédié. Nous utiliserons ici l'espace de noms storage-system.
- Création de l'espace de noms :
kubectl create namespace storage-system
- Configuration du cluster (ConfigMap) : Cet objet contient les métadonnées essentielles pour que le pilote localise le cluster Ceph.
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-info
namespace: storage-system
data:
config.json: |
[
{
"clusterID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"monitors": [
"192.168.10.1:6789",
"192.168.10.2:6789",
"192.168.10.3:6789"
]
}
]
---
# Gestion du chiffrement (optionnel mais recommandé)
apiVersion: v1
kind: ConfigMap
metadata:
name: encryption-config
namespace: storage-system
data:
config.json: |-
{}
---
- Configuration Ceph (ConfigMap secondaire) : Nécessaire pour définir les paramètres globaux de connexion si la gestion centralisée n'est pas activée.
apiVersion: v1
kind: ConfigMap
metadata:
name: ceph-settings
namespace: storage-system
data:
ceph.conf: |
[global]
fsid = a1b2c3d4-e5f6-7890-abcd-ef1234567890
public_network = 192.168.0.0/16
cluster_network = 192.168.0.0/16
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
keyring: ""
---
- Crédentiels sécurisés (Secret) : Ici sont stockés les identifiants sensibles générés précédemment.
apiVersion: v1
kind: Secret
metadata:
name: secret-ceph-auth
namespace: storage-system
stringData:
userID: client.storage-svc
userKey: AQDxYz123456EXAMPLEKEYabcdefghijklmnopqrstuvwxyz==
---
Installation du Pilote CSI
Téléchargez les définitions de manifestation officielles correspondant à votre version cible (par exemple v3.5.x pour une compatibilité étendue). Une étape critique consiste à adapter les sources d'images si elles ne sont pas accessibles directement.
# Mise à jour des références d'image vers un registre local ou accessible
find ./deploy -type f -exec grep -l "k8s.gcr.io" {} \; | xargs sed -i 's/k8s.gcr.io\/sig-storage\/my-private-registry\/csi\//' .
# Application des permissions RBAC requises
kubectl apply -n storage-system -f csi-provisioner-rbac.yaml
kubectl apply -n storage-system -f csi-nodeplugin-rbac.yaml
# Déploiement des contrôleurs et des agents nodaux
kubectl apply -n storage-system -f csi-rbdplugin-provisioner.yaml
kubectl apply -n storage-system -f csi-rbdplugin.yaml
# Vérification de l'état des pods
kubectl get pods -n storage-system -l app=csi-rbdplugin
Définitoin de la Classe de Stockage
Une fois le pilote actif, créez la StorageClass qui servira de modèle pour la provisionnement dynamique. Assurez-vous que les paramètres correspondent exactement à ceux configurés dans les ConfigMaps.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ceph-rbd-standard
provisioner: rbd.csi.ceph.com
parameters:
clusterID: a1b2c3d4-e5f6-7890-abcd-ef1234567890
pool: volumes-prod
imageFeatures: layering, exclusive-lock
fsType: ext4
# Références aux secrets pour l'authentification
csi.storage.k8s.io/provisioner-secret-name: secret-ceph-auth
csi.storage.k8s.io/provisioner-secret-namespace: storage-system
csi.storage.k8s.io/controller-expand-secret-name: secret-ceph-auth
csi.storage.k8s.io/node-stage-secret-name: secret-ceph-auth
csi.storage.k8s.io/node-publish-secret-name: secret-ceph-auth
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- discard
Consommation du Stockage
Pour valider l'installation, déclarez une revendication de volume persistant (PVC) référençant la classe créée. Le provisioneur créera automatiquement l'image RBD correspondante.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-vol-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: ceph-rbd-standard
resources:
requests:
storage: 10Gi
Vérifiez l'état de la ressource pour confirmer qu'elle est liée (Bound) et prête à l'usage par vos applications.
kubectl get pvc test-vol-claim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-vol-claim Bound pvc-a1b2c3d4-e5f6-7890 10Gi RWO ceph-rbd-standard 2m