La gestion des volumes persistants devient rapidement critique dès que l’orchestration de conteneurs dépasse quelques nœuds. La contrainte d’affinité, le risque de pod orphelin et la dépendance à un stockage local complexifient l’infrastructure réseau.
Pour connecter un cluster Kubernetes à un environnement distribué de stockage cloud, plusieurs étapes pratiques et vérifiables sont nécessaires. Les points clés pratiques suivent pour guider le déploiement et la mise en service opérationnelle.
A retenir :
- Stockage distribué Ceph pour volumes persistants partagés
- Provisionnement dynamique via provisioner externe pour EKS
- Configurer Kubelet et AMI personnalisées pour rbd
- Sécuriser la connectivité réseau et règles RBAC
Connecter Kubernetes à Ceph RBD pour volumes persistants
Ce point reprend les éléments synthétisés et permet d’enclencher l’installation du stockage Ceph en cloud. L’approche vise à rendre les volumes accessibles à tous les workers sans affinité statique, améliorant la résilience des applications stateful.
Préparatifs pour un cluster Ceph sur cloud AWS
Ceph nécessite des choix d’images et de réseau différents des AMI standards fournies par AWS. Il est recommandé d’opter pour des distributions Ubuntu-like ou RedHat-like et d’isoler les services sur des instances séparées.
Solution
Type
Cas d’usage
Contraintes
Ceph RBD
Bloc distribué
Volumes persistants pour bases de données
Nécessite rbd sur Kubelet et provisioner
CephFS
Fichier distribué
Partage de fichiers entre pods
Performance variable selon metadata servers
Amazon EFS
Fichier managé
Partage simple sans gestion d’OS
Coût élevé pour gros volumes
NFS classique
Fichier
Cas simple, compatibilité large
Point de défaillance central
Avant le déploiement, vérifier les security groups et utiliser des private subnets pour les nœuds Ceph. Configurer les moniteurs, le public_network et les fichiers hosts ou une zone privée Route53 pour garantir la résilience.
Privilégier une keypair dédiée et partager les clés via ssh-copy-id, puis standardiser la version de Ceph sur tous les nœuds. Ces opérations minimisent les incidents de quorum et d’OSD non disponibles.
Prérequis pour Ceph :
- Security groups ouverts pour ports Ceph
- Instances dans private subnets dédiés
- Keypair partagée et .ssh_config standardisée
- Version Ceph homogène sur tous les nœuds
Création des secrets et du pool RBD pour Kubernetes
La liaison nécessite la création d’un pool RBD et de secrets Kubernetes de type kubernetes.io/rbd. Sans le bon type de secret, l’authentification échoue et le provisionnement dynamique devient impossible.
Les commandes d’extraction de clef admin et de création de secrets sont des étapes critiques et doivent s’exécuter avec un namespace cohérent, typiquement kube-system. L’automatisation de ces étapes évite les erreurs manuelles lors des déploiements répétés.
« J’ai créé le pool rbdaws puis les secrets, et le PVC s’est lié immédiatement après vérification des clés. »
Marc L.
Une fois le pool créé et les permissions attribuées au client, Kubernetes peut mapper les images RBD via la StorageClass. Cette configuration prépare le passage au provisionnement dynamique géré ou via un provisioner externe.
Cette préparation facilite le déploiement suivant qui traite du provisionnement dynamique et des contraintes des control-planes managés. La section suivante décrit les solutions pour EKS et les images personnalisées.
Provisionnement dynamique et provisioner RBD pour EKS
Ce chapitre fait suite à la configuration du pool et aborde le contournement des limitations des control-planes managés. L’objectif est d’assurer la création automatique des images RBD sans accès direct au binaire rbd sur le controller-manager.
Limitation du control-plane managé et solutions
Sur EKS, le controller-manager ne permet pas l’ajout du paquet ceph-common contenant l’exécutable rbd. Ce manque bloque le provisionnement dynamique natif des volumes RBD.
Selon la documentation Kubernetes, il est recommandé d’utiliser un provisioner externe rbd-provisioner pour compenser cette limitation. Ce conteneur inclut le binaire rbd et opère au nom du cluster pour créer les images.
Solutions de contournement :
- Déployer rbd-provisioner avec les RBAC appropriés
- Utiliser AMI worker personnalisées contenant rbd
- Installer ceph-common sur control plane On-Premise
- S’assurer de la compatibilité image Ceph et provisioner
Avant le déploiement, vérifier les droits RBAC et ajouter des permissions pour events si nécessaire, comme observé sur des environnements réels. Cette vérification évite des erreurs de démarrage du conteneur provisioner.
Déployer rbd-provisioner et ajuster le RBAC
L’exemple d’image quay.io/external_storage/rbd-provisioner nécessite une variable d’environnement PROVISIONER_NAME alignée sur la StorageClass. Le fichier deployment.yaml doit refléter le provisioner utilisé dans la StorageClass.
Action
Commande ou fichier
But
Créer secret admin
kubectl create secret generic ceph-admin-secret –from-file=/tmp/key
Autoriser création d’images RBD
Créer pool RBD
ceph osd pool create rbdaws 8 8
Zone dédiée aux applications stateful
Déployer provisioner
deployment.yaml avec image rbd-provisioner
Provisionnement dynamique sur EKS
RBAC ajusté
ClusterRole ajout list events
Permet le démarrage sans erreur du conteneur
« Après l’ajout des permissions events, le provisioner s’est lancé sans erreur et les PVC se sont créés. »
Claire D.
Effectuer des tests de provisioning et vérifier le message d’erreur lié à l’exécutable rbd absent pour diagnostiquer rapidement. Cette étape réduit le risque d’indisponibilité des volumes en production.
Le prochain point aborde la connectivité réseau et l’interopérabilité cloud, indispensables pour garantir la disponibilité des volumes sur plusieurs zones. L’attention portée au réseau améliore la latence et la sécurité.
Assurer la connectivité réseau et l’interopérabilité cloud pour le stockage
Ce point élargit la perspective vers l’infrastructure réseau et la sécurité, indispensables pour un stockage distribué fiable. La mise en place correcte du réseau défini par logiciel et des routes privées garantit la communication entre Kubernetes et Ceph.
Configurer la connectivité réseau et sécuriser l’accès
Il est essentiel d’ouvrir les ports Ceph pertinents, comme le port TCP 6789 pour les moniteurs, et d’utiliser des subnets privés pour limiter l’exposition. Le routage et les DNS internes doivent être testés avant toute mise en production.
Selon la documentation Ceph, la cohérence des paramètres public_network et mon_host dans ceph.conf est cruciale pour éviter des partitions réseaux. Les tests de santé Ceph doivent afficher Health OK et quorum respecté.
Bonnes pratiques réseau :
- Ports moniteurs ouverts et règles strictes
- Subnets privés pour nœuds Ceph et Kubernetes
- Zone DNS privée ou /etc/hosts cohérent
- Test de latence et bande passante inter-zones
Kubelet, images personnalisées et interopérabilité cloud
Kubelet doit disposer du binaire rbd pour attacher et détacher les volumes, ce qui implique des AMI worker personnalisées sur AWS. Sur On-Premise, l’installation de ceph-common sur l’hôte suffit pour fournir rbd à Kubelet.
Selon SUSE/Rancher, Longhorn et les plugins CSI modernes offrent une alternative cloud-native pour le provisionnement dynamique et l’interopérabilité. L’adoption d’un CSI compatible Ceph peut simplifier certains scénarios.
« Nous avons standardisé des AMI contenant ceph-common, ce qui a éliminé les erreurs d’attachement de volumes en production. »
Alex P.
« L’intégration Ceph via CSI a réduit notre complexité d’exploitation tout en améliorant la portabilité des données. »
Simon N.
L’attention portée à la connectivité, au provisionnement et à la sécurité diminue significativement les interruptions pour les applications stateful. Cette approche pragmatique permet d’atteindre une interopérabilité cloud robuste.