File Storage Service - Premiers pas (bêta)

Objectif

OVHcloud propose un service File Storage basé sur OpenStack Manila. Ce service fournit des shares NFS gérés sur des réseaux privés, avec un accès ReadWriteMany (RWX) possible depuis plusieurs instances ou pods Kubernetes.

Il est accessible via les API OVHcloud, OpenStack CLI et API, Manila CSI et Terraform.

Ce service est actuellement en version bêta et disponible uniquement dans les régions SBG5, DE1 et GRA. Les fonctionnalités et la disponibilité peuvent être modifiées.

Pendant la phase bêta, la taille autorisée des shares varie entre 150 Gio à 10 Tio.

Prérequis

Vous disposez déjà d’un réseau privé dans votre projet Public Cloud
Une instance Public Cloud dans votre compte OVHcloud
Un environnement CLI OpenStack prêt à l’emploi

En pratique

Actuellement, le service File Storage ne peut être consulté et géré que via les API OVHcloud et la CLI OpenStack avec le plugin Manila. D’autres interfaces seront disponibles à l’avenir.

Via l'API OVHcloud
Via la CLI OpenStack avec le plugin Manila
Via Manila CSI dans l'environnement K8s
Via Terraform

1. Créer un share

Identifiez votre réseau privé et votre sous-réseau.

Avant de créer ou d'associer un service File Storage, vous devez identifier le réseau privé cible.

Récupérez l'ID du réseau :

GET /cloud/project/{serviceName}/region/{regionName}/network

Exemple de résultat :

[
  {
    "id": "581fad02-158d-4dc6-81f0-c1ec2794bbec",
    "name": "Ext-Net",
    "visibility": "public",
    "vlanId": null
  },
  {
    "id": "[NETWORK_ID]",
    "name": "<my-network-name>",
    "visibility": "private",
    "vlanId": 2701
  }
]

Note : Sélectionnez uniquement un réseau privé.

Récupérez l'ID du sous-réseau à l'aide de l'ID réseau :

GET /cloud/project/{serviceName}/region/{regionName}/network/{networkId}/subnet

Exemple de résultat :

[
  {
    "id": "[SUBNET_ID]",
    "name": "subnet-name",
    "cidr": "10.1.0.0/24",
    "ipVersion": 4,
    "dhcpEnabled": true,
    "gatewayIp": "10.1.0.1",
    "allocationPools": [
      {
        "start": "10.1.0.2",
        "end": "10.1.0.254"
      }
    ],
    "hostRoutes": [],
    "dnsNameServers": [
      "1.1.1.1"
    ]
  }
]

L'ID réseau et l'ID sous-réseau doivent tous deux respecter le format suivant : abc12345-def6-4abc-8def-123456abcdef.

Créez un share NFS de 150 Gio connecté à votre réseau privé :

POST /cloud/project/{serviceName}/region/{regionName}/share

Note : Remplacez par le nom de share que vous avez choisi.

Répertoriez vos actions et attendez que la nouvelle action apparaisse avec le statut available.

GET /cloud/project/{serviceName}/region/{regionName}/share

Exemple de résultat :

{
  "capabilities": [
    {
      ...
    }
  ],
  "createdAt": "2026-01-14T08:23:30.079Z",
  "description": "<my-share-description>",
  "exportLocations": [
    {
      "id": "string",
      "path": "string"
    }
  ],
  "id": "[SHARE_ID]",
  "isPublic": false,
  "name": "<my-share-name>",
  "protocol": "NFS",
  "region": "[REGION]",
  "size": 150,
  "status": "available",
  "type": "standard-1az",
  "updatedAt": "2026-01-14T08:23:30.079Z"
}

Note : L'identifiant du share doit avoir le format abc12345-def6-4abc-8def-123456abcdef.

Récupérez les détails du share à l'aide de l'ID de share :

GET /cloud/project/{serviceName}/region/{regionName}/share/{id}

Exemple de résultat :

{
  "capabilities": [
    {
      "enabled": true,
      "name": "<my-share-name>"
    }
  ],
  "createdAt": "2026-01-14T08:23:30.079Z",
  "description": "<my-share-description>",
  "exportLocations": [
    {
      "id": "string",
      "path": "10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef"
    }
  ],
  "id": "abc12345-def6-4abc-8def-123456abcdef",
  "isPublic": false,
  "name": "string",
  "protocol": "NFS",
  "region": "string",
  "size": 150,
  "status": "available",
  "type": "standard-1az",
  "updatedAt": "2026-01-14T08:23:30.079Z"
}

2. Autoriser une machine virtuelle cliente

Assurez-vous que la machine virtuelle cliente se trouve sur le même réseau privé que le share.

Récupérez l'adresse IP privée de la machine virtuelle.

Accordez l'accès au share à l'aide de l'adresse IP privée de la machine virtuelle (par exemple, 10.1.0.123) via la gestion ACL :

POST /cloud/project/{serviceName}/region/{regionName}/share/{id}/acl

Exemple de résultat :

{
  "accessLevel": "rw",
  "accessTo": "10.1.0.123",
  "createdAt": "2026-01-14T10:26:14.446Z",
  "id": "[ACL_ID]",
  "status": "active",
  "updatedAt": "2026-01-14T10:26:14.446Z"
}

Vérifiez l'accès au share NFS à partir de la machine virtuelle cliente autorisée :

GET /cloud/project/{serviceName}/region/{regionName}/share/{id}/acl/{aclId}

3. Montez le share sur votre machine virtuelle cliente

Connectez-vous à votre machine virtuelle cliente et installez les utilitaires NFS nécessaires pour monter le share :

sudo apt update && sudo apt install -y nfs-common

Créez un point de montage et montez le share :

sudo mkdir -p /mnt/share && sudo mount -t nfs4 10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef /mnt/share

Vérifiez le montage :

df -h /mnt/share

Rendez le montage persistant après les redémarrages :

echo "<NFS_EXPORT_PATH> /mnt/share nfs nfsvers=4 defaults,noauto 0 0" | sudo tee -a /etc/fstab

Cela garantit que le share NFS est automatiquement remonté après le redémarrage de la VM.

4. Vérifier la capacité et l'utilisation

Une fois le share NFS monté, vérifiez son espace disponible et son utilisation :

df -h /mnt/share

Exemple de résultat :

Filesystem                          Size  Used  Avail Use% Mounted on
10.1.0.12:/shares/share-abc1...     150G  100M   150G   1% /mnt/share

Note : Cela vous permet de surveiller la capacité de stockage et l'utilisation de votre share NFS.

Prérequis supplémentaires

Assurez-vous que l'utilisateur OpenStack dispose du rôle `Administrator ou Share operator.

1. Installer le plugin CLI Manila

Si les commandes Manila ne sont pas encore disponibles, installez le plugin :

sudo apt update && sudo apt install -y python3-manilaclient

Vérifiez l’installation :

openstack share --help

Vous devriez voir des commandes telles que :

share create
share list
share network create
share access create

2. Vérifier les types de shares disponibles

Listez les types de shares disponibles dans votre région :

openstack share type list --os-region-name <REGION_NAME>

Sortie attendue :

+----------+-----------+------------+------------+
| ID       | Name      | Visibility | Is Default |
+----------+-----------+------------+------------+
| acceb7b4 | standard-1az | public     | True       |
+----------+-----------+------------+------------+

Remarque : Le type standard-1az utilise driver_handles_share_servers = True, ce qui signifie que vous devez associer un réseau partagé lors de la création d'un share.

3. Créer un Share Network

Identifiez votre réseau privé et votre sous-réseau :

openstack network list --os-region-name <REGION_NAME>
openstack subnet list --os-region-name <REGION_NAME>

Récupérez leurs IDs :

openstack network show --os-region-name <REGION_NAME> -c id -f value <PRIVATE_NETWORK_NAME>
openstack subnet show --os-region-name <REGION_NAME> -c id -f value <PRIVATE_SUBNET_NAME>

Les IDs du réseau et du sous-réseau devraient ressembler à : abc12345-def6-4abc-8def-123456abcdef

Créez un share network lié à votre réseau privé :

openstack share network create \
  --os-region-name <REGION_NAME> \
  --name <my-share-network-name> \
  --neutron-net-id <NETWORK_ID> \
  --neutron-subnet-id <SUBNET_ID>

Remarque : Remplacez <my-share-network-name> par le nom que vous souhaitez donner à votre share network.

Vérifiez le share network :

openstack share network list --os-region-name <REGION_NAME>

4. Créer un share NFS

Créez un share NFS de 150 Go :

openstack share create \
  --os-region-name <REGION_NAME> \
  --share-type standard-1az \
  --share-network <my-share-network-name> \
  --name <my-first-share-name> \
  NFS 150

Remarque : Remplacez par le nom que vous souhaitez donner à votre share.

Surveillez l’état du share jusqu’à ce qu’il devienne available :

openstack share list --os-region-name <REGION_NAME>

5. Autoriser une VM cliente

Assurez-vous que votre VM cliente se trouve dans le même réseau privé que le share.

Récupérez l’adresse IP privée de la VM :

openstack server show --os-region-name <REGION_NAME> <VM_NAME> -c addresses -f value

Exemple de sortie :

{'my-private-net': ['10.1.0.123', '57.123.88.111']}

Autorisez l’accès au share en utilisant l’IP privée de la VM (par exemple, 10.1.0.123) :

openstack share access create \
  --os-region-name <REGION_NAME> \
  <my-first-share-name> \
  ip 10.1.0.123

Vérifiez les accès :

openstack share access list --os-region-name <REGION_NAME> <my-first-share-name>

6. Récupérer le chemin d’export

Obtenez l’emplacement d’export NFS :

openstack share export location list --os-region-name <REGION_NAME> <my-first-share-name>

Exemple de sortie :

10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef

Remarque : Ce chemin d’export est utilisé pour monter le share sur votre VM cliente.

7. Monter le share sur votre VM cliente

Connectez-vous à votre VM et installez les utilitaires NFS :

sudo apt update && sudo apt install -y nfs-common

Créez un point de montage et montez le share :

sudo mkdir -p /mnt/share
sudo mount -t nfs4 10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef /mnt/share

Vérifiez le montage :

df -h /mnt/share

Remarque : Remplacez le chemin d’export par celui récupéré pour votre share.

8. Vérifier la capacité et l’utilisation

Affichez l’espace disponible sur le share monté :

df -h /mnt/share

Exemple de sortie :

Example:
Filesystem                          Size  Used  Avail Use% Mounted on
10.1.0.12:/shares/share-abc1...     150G  100M   150G   1% /mnt/share

Remarque : Cela vous permet de suivre la capacité de stockage et l’utilisation de votre share NFS.

9. Gérer le cycle de vie du share

Redimensionner le share :

Seule l’extension d’un share est autorisée pour le moment ; la réduction n’est pas supportée.

openstack share resize --os-region-name <REGION_NAME> <my-first-share-name> 200

Supprimer un share :

openstack share delete --os-region-name <REGION_NAME> <my-first-share-name>

Supprimer le share network :

openstack share network delete --os-region-name <REGION_NAME> <my-share-network-name>

Remarque : Assurez-vous qu’aucun share actif n’utilise le réseau avant de le supprimer.

10. Dépannage

Symptôme	Cause	Solution
`Unknown command ['share']`	CLI Manila non installée	Installez-la avec `sudo apt install python3-manilaclient`
`Share network must be set`	Utilisation d’un type de share DHSS=True	Fournissez `--share-network`
Cannot mount NFS	IP non autorisée ou réseau incorrect	Assurez-vous que la VM est sur le même sous-réseau privé et que la règle d’accès est créée
Share stuck in creating	ID de réseau ou sous-réseau invalide	Vérifiez `NETWORK_ID` et `SUBNET_ID`

1. Prérequis supplémentaires :

Helm CLI installé sur votre machine locale.
OpenStack CLI configuré et prêt à l'emploi.
Krew (gestionnaire de plugins kubectl) installé.
Stern (plugin de suivi des logs kubectl) installé via Krew.
Un cluster Kubernetes déployé dans un réseau privé au sein d'une région Public Cloud où les points de terminaison Manila sont accessibles.
Assurez-vous que votre utilisateur OpenStack dispose du rôle Administrateur ou Opérateur de partage.

Ce guide fonctionne à la fois avec les clusters Managed Kubernetes Service (MKS) et les clusters Kubernetes autogérés.

2. Installation de la ligne de commande Helm

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

3. Installation des outils Krew et Stern

Exécutez la commande suivante pour installer Krew dans votre environnement :

(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

Une fois Krew installé, installez Stern avec :

kubectl krew install stern

4. Installation de la CLI OpenStack

Préparez votre environnement pour utiliser l'API OpenStack en installant python-openstackclient, en suivant ce guide.

Installez le client Manila pour gérer les partages du service File Storage :

pip install python-manilaclient

N'oubliez pas de mettre à jour votre script de complétion de shell pour activer l'autocomplétion OpenStack share.

5. Installation du driver CSI NFS

Ajoutez le référentiel de chart Helm :

helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts
helm repo update

Listez les versions disponibles du chart CSI NFS :

helm search repo -l csi-driver-nfs

Installez la version choisie du chart Helm :

Remplacez les flags facultatifs --wait -v=5 --debug selon vos besoins pour le débogage ou l'installation synchrone.

helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs \
  --namespace kube-system \
  --version v4.11.0 \
  [--wait -v=5 --debug]

Suivez les logs du driver CSI NFS :

kubectl stern -n kube-system -l app.kubernetes.io/instance=csi-driver-nfs

6. Installation du driver CSI Manila

Ajoutez le référentiel de chart Helm :

helm repo add cpo https://kubernetes.github.io/cloud-provider-openstack
helm repo update

Listez les versions disponibles du driver CSI Manila :

helm search repo -l openstack-manila-csi

Installez la version choisie du chart Helm :

helm install manila-csi cpo/openstack-manila-csi --version 2.33.1 --namespace kube-system [--values ./csi-config/helm-chart-values.yaml]

Suivez les logs du driver CSI Manila :

kubectl stern -n kube-system -l app=openstack-manila-csi

7. Préparation des ressources OpenStack pour Manila CSI

7.1. Créez un utilisateur OpenStack dédié pour Manila

Vous avez besoin d'un utilisateur OpenStack séparé pour gérer les ressources Manila. Cet utilisateur peut être créé :

Via l'espace client OVHcloud (Public Cloud > Paramètres > Utilisateurs & Rôles)
Ou via la CLI OVHcloud

7.2. Collectez les détails du projet et de l'utilisateur OpenStack

Téléchargez le fichier openrc de votre projet depuis l'espace client OVHcloud et notez les informations suivantes :

os-userName
os-password
os-domainName
os-projectDomainID
os-projectName
os-projectDomainID

Une fois ces valeurs obtenues, créez un fichier nommé secrets.yaml avec le contenu suivant. Ce secret Kubernetes permet au pilote CSI Manila de s'authentifier auprès d'OpenStack et de gérer les ressources Manila dans votre cluster.

apiVersion: v1
kind: Secret
metadata:
  name: csi-manila-secrets
  namespace: default
stringData:
  # Mandatory
  os-authURL: "https://auth.cloud.ovh.net/v3"
  os-region: "SBG5"

  # Openstack authentication
  os-userName: "<os-userName>"
  os-password: "<os-password>"
  os-domainName: "default"
  os-projectName: "os-projectName"
  os-projectDomainID: "default"

Ensuite, appliquez-le à votre cluster Kubernetes :

kubectl apply -f secrets.yaml

7.3. Configurez le réseau partagé OpenStack

Manila nécessite un réseau partagé car le driver est configuré avec DHSS=true (driver_handles_share_servers).

Cette ressource est gérée par le propriétaire du projet OpenStack.

# Listez les réseaux privés attachés à votre cluster MKS
openstack --os-region-name SBG5 network list

# Récupérez l'ID du réseau
openstack --os-region-name SBG5 network show -c id -f value <PRIVATE_NETWORK_NAME>

# Récupérez l'ID du sous-réseau lié à ce réseau
openstack --os-region-name SBG5 subnet show -c id -f value <PRIVATE_SUBNET_NAME>

# Créez le réseau partagé Manila
openstack --os-region-name SBG5 share network create \
  --name mks-manila-csi-tests \
  --neutron-net-id <PRIVATE_NETWORK_ID> \
  --neutron-subnet-id <PRIVATE_SUBNET_ID>

Exemple de sortie :

+-----------------------------------+----------------------------------------------------------+
| Field                             | Value                                                    |
+-----------------------------------+----------------------------------------------------------+
| created_at                        | 2025-10-04T14:12:25.111776                               |
| description                       | None                                                     |
| id                                | 07363bc7-be2a-4a7d-b675-09844b344b3b                     |
| name                              | mks-manila-csi-tests                                     |
| network_allocation_update_support | True                                                     |
| project_id                        | <PROJECT_ID>                                             |
| security_service_update_support   | True                                                     |
| share_network_subnets             |                                                          |
|                                   | id = 90cf66fc-23eb-4dce-80a3-bf8fa3a912c3                |
|                                   | availability_zone = None                                 |
|                                   | created_at = 2025-10-04T14:12:25.126327                  |
|                                   | updated_at = None                                        |
|                                   | segmentation_id = None                                   |
|                                   | neutron_net_id = <PRIVATE_NETWORK_NAME>                  |
|                                   | neutron_subnet_id = <PRIVATE_SUBNET_NAME>                |
|                                   | ip_version = None                                        |
|                                   | cidr = None                                              |
|                                   | network_type = None                                      |
|                                   | mtu = None                                               |
|                                   | gateway = None                                           |
| status                            | active                                                   |
| updated_at                        | None                                                     |
+-----------------------------------+----------------------------------------------------------+

8. Configuration du driver CSI Manila

Une fois le réseau de share OpenStack créé, et avant de configurer le pilote CSI Manila, vous devez définir la plage CIDR utilisée par vos nœuds Kubernetes. Cela garantit que les nœuds peuvent accéder aux shares Manila.

Éditez la ConfigMap de runtime :

Créez un fichier nommé manila-runtime-configmap.yaml et mettez à jour le champ nfs.matchExportLocationAddress afin qu'il corresponde au CIDR de votre cluster :

apiVersion: v1
kind: ConfigMap
metadata:
  name: manila-csi-runtimeconf-cm
  namespace: default
  annotations:
    meta.helm.sh/release-name: manila-csi
    meta.helm.sh/release-namespace: default
  labels:
    app.kubernetes.io/managed-by: Helm
data:
  runtimeconfig.json: |
    {
      "nfs": {
        # When mounting an NFS share, select an export location with
        # this IP address. No match between this address and
        # at least a single export location for this share will
        # result in an error.
        # Expects a CIDR-formatted address. If prefix is not provided,
        # /32 or /128 prefix is assumed for IPv4 and IPv6 respectively.
        "matchExportLocationAddress": "<SUBNET_CIDR>"
      }
    }

Exemple :

"nfs":
  "matchExportLocationAddress": "10.42.0.0/16"

Appliquez la ConfigMap à votre cluster Kubernetes :

# Optionnel si la configuration de runtime est déjà définie dans les valeurs Helm
kubectl apply -f manila-runtime-configmap.yaml

9. Création de shares NFS via provisionnement dynamique

Pour permettre au driver CSI Manila de créer dynamiquement des shares Manila et de les utiliser comme volumes Kubernetes, vous devez définir une StorageClass dans votre cluster. Cette StorageClass spécifie le réseau partagé qui sera utilisé pour créer et accorder l'accès aux exports NFS.

Récupérez l'ID du réseau partagé en utilisant la CLI OpenStack pour obtenir l'ID de votre réseau partagé :

openstack --os-region-name SBG5 share network list -f value -c ID

Configurez la StorageClass :

Créez un fichier nommé dynamic-storageclass.yaml avec le contenu suivant :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-manila-nfs
provisioner: nfs.manila.csi.openstack.org
allowVolumeExpansion: true
parameters:
  # Manila share type
  # default value: default
  # openstack share type list to find proper value
  type: standard-1az
  # /!\ MANDATORY /!\
  # openstack share network list
  shareNetworkID: "<OS_SHARE_NETWORK_ID>"
  nfs-shareClient: "<SUBNET_CIDR>"

  csi.storage.k8s.io/provisioner-secret-name: csi-manila-secrets
  csi.storage.k8s.io/provisioner-secret-namespace: default
  csi.storage.k8s.io/controller-expand-secret-name: csi-manila-secrets
  csi.storage.k8s.io/controller-expand-secret-namespace: default
  csi.storage.k8s.io/node-stage-secret-name: csi-manila-secrets
  csi.storage.k8s.io/node-stage-secret-namespace: default
  csi.storage.k8s.io/node-publish-secret-name: csi-manila-secrets
  csi.storage.k8s.io/node-publish-secret-namespace: default

Mettez à jour la valeur parameter.shareNetworkID avec l'identifiant réseau partagé.
Mettez à jour la valeur parameter.nfs-shareClient avec le CIDR du sous-réseau défini lors de la création du cluster.

Créez la StorageClass dynamique en appliquant la StorageClass à votre cluster :

# Une StorageClass ne peut pas être mise à jour. Si des modifications sont nécessaires, supprimez-la et recréez-la.
kubectl apply -f dynamic-storageclass.yaml

Une fois la StorageClass créée, créez un fichier nommé nfs-pvc.yaml définissant une PersistentVolumeClaim (PVC) qui utilise cette StorageClass. Par exemple, demandez un volume de 150 Gio avec un accès ReadWriteMany (RWX) :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-share-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi
  storageClassName: csi-manila-nfs

kubectl apply -f nfs-pvc.yaml

Après avoir appliqué la demande de volume, listez les nouveaux shares Manila créés dans votre projet Public Cloud :

openstack --os-region SBG5 share list

Exemple de sortie :

+--------------------------------------+------------------------------------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
| ID                                   | Name                                     | Size | Share Proto | Status    | Is Public | Share Type Name | Host | Availability Zone |
+--------------------------------------+------------------------------------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
| 9484d5f3-7bf7-486b-b88e-40bbedeet9f3 | pvc-78135a68-c6f4-48fe-8644-454b387a3ad4 |   150 | NFS         | available | False     | standard-1az       |      | nova              |
+--------------------------------------+------------------------------------------+------+-------------+-----------+-----------+-----------------+------+-------------------+

Créez un fichier nommé nfs-deployment.yaml avec le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-share
  labels:
    app: nfs-share
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nfs-share
  template:
    metadata:
      labels:
        app: nfs-share
    spec:
      containers:
      - name: web-server
        resources:
          limits:
            cpu: 250m
            memory: 256Mi
          requests:
            cpu: 100m
            memory: 256Mi
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
          - name: nfs-share-pvc
            mountPath: /var/lib/www
      volumes:
      - name: nfs-share-pvc
        persistentVolumeClaim:
          claimName: nfs-share-pvc
          readOnly: false

Déployez le serveur web avec 2 répliques, qui monteront et partageront le volume RWX créé précédemment :

kubectl apply -f nfs-deployment.yaml

Vous pouvez vérifier la fonctionnalité RWX en vous connectant à un pod en utilisant la commande kubectl exec et en créant un fichier dans le répertoire monté (par exemple, /var/lib/www/). Ensuite, connectez-vous au deuxième pod et vérifiez que le fichier est visible. Si c'est le cas, votre share Manila exposé via NFS fonctionne correctement.

10. Redimensionner un share NFS à l'aide du provisionnement dynamique

Le redimensionnement d'un share NFS n'est pris en charge que pour :

Les PersistentVolumeClaims (PVC) provisionnés dynamiquement
Les volumes démontés (vous devez réduire votre déploiement avant de redimensionner pour éviter les erreurs)

À l'heure actuelle, seule l'extension de share est prise en charge — il n'est pas possible de réduire un volume.

Pour redimensionner un share Manila existant :

Réduisez le déploiement pour vous assurer que le volume est démonté :

kubectl scale deployment nfs-share --replicas 0

Modifiez le PVC pour demander une nouvelle taille (par exemple, 42 Gi) :

kubectl patch pvc nfs-share-pvc -p '{ "spec": { "resources": { "requests": { "storage": "42Gi" }}}}'

Vérifiez que le share OpenStack a été mis à jour :

openstack --os-region SBG5 share show <SHARE_ID>

Si le share a été étendu avec succès, redimensionnez le déploiement :

kubectl scale deployment nfs-share --replicas 2

Toute tentative de redimensionnement d'un PVC qui n'est pas provisionné dynamiquement par une StorageClass entraînera une erreur telle que :

error: persistentvolumeclaims "existing-nfs-share-pvc" could not be patched: persistentvolumeclaims "existing-nfs-share-pvc" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize

11. Montage d'un share Manila existant comme volume dans les pods

Comme indiqué précédemment, une StorageClass Kubernetes peut créer dynamiquement des shares Manila exposés via NFS. Alternativement, vous pouvez utiliser un share Manila pré-provisionné et le monter directement dans un pod.

Créez un nouveau share avec la CLI OpenStack :

openstack --os-region SBG5 share create \
  --share-type <SHARE_TYPE> \
  --share-network <SHARE_NETWORK_ID> \
  --name <NFS_SHARE_NAME> \
  SHARE_PROTOCOL SHARE_SIZE

Où :

SHARE_TYPE est standard-1az par défaut. Vous pouvez vérifier les types de share existants avec :

openstack --os-region SBG5 share type list

SHARE_NETWORK_ID est l'identifiant de votre réseau partagé.
NFS_SHARE_NAME est le nom de votre share NFS.
SHARE_PROTOCOL est le protocole à utiliser (actuellement, seul NFS est pris en charge).
SHARE_SIZE est la taille à allouer à votre volume NFS (en GiB).

Créez une règle d'accès au share :

openstack --os-region SBG5 share access create <NFS_SHARE_NAME> ip <SUBNET_CIDR>

Où :

SHARE_ACCESS_NAME est le nom du share.
SUBNET_CIDR est le CIDR utilisé lors de la configuration du runtime Manila CSI.

Récupérez l'ID de share NFS et l'ID d'accès au share, puis créez un fichier nommé static-provisioning.yaml et mettez à jour les paramètres volumeAttributes.shareID et volumeAttributes.shareAccessID :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: preprovisioned-nfs-share
  labels:
    name: preprovisioned-nfs-share
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 150Gi
  csi:
    driver: nfs.manila.csi.openstack.org
    volumeHandle: preprovisioned-nfs-share
    nodeStageSecretRef:
      name: csi-manila-secrets
      namespace: default
    nodePublishSecretRef:
      name: csi-manila-secrets
      namespace: default
    volumeAttributes:
      shareID: <SHARE_ID>
      shareAccessID: <SHARE_ACCESS_ID>
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: existing-nfs-share-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 150Gi
  storageClassName: "" # <--- Prevent default Cinder CSI usage
  selector:
    matchExpressions:
    - key: name
      operator: In
      values: ["preprovisioned-nfs-share"]

Appliquez le manifeste pour créer un volume persistant et sa demande de volume persistant en utilisant le share NFS pré-provisionné. Le share Manila ne sera utilisé que si le pod qui réclame la demande de volume est déployé dans votre cluster :

kubectl apply -f static-provisioning.yaml

Déployez un pod qui monte ce share :

kubectl apply -f pod.yaml

Vous pouvez maintenant utiliser kubectl exec pour accéder au pod et exécuter df -h pour vérifier que le share Manila pré-créé est correctement monté.

CLI utiles

Avec vos informations d'identification OpenStack chargées dans l'environnement, vous pouvez gérer les shares Manila en utilisant la CLI OpenStack. Les commandes courantes incluent :

openstack share list # Liste tous les shares
openstack share type list # Liste les types de share disponibles
openstack share access list|create|delete [${SHARE_ID}] # Gérez les règles d'accès pour un share spécifique
openstack share list|create|delete [${SHARE_ID}] # Créez, listez ou supprimez un share par son ID
openstack share message list # pour voir les erreurs liées aux ressources Manila

Ressources utiles

Votre stockage ReadWriteMany (RWX) dans k8s avec Manila CSI Manila/Concepts Approche générique pour le provisionnement de share Plugin officiel Manila CSI sur GitHub

1. Prérequis additionnels

Vous disposez déjà d'un environnement Terraform fonctionnel.

Vous pouvez trouver des exemples utiles ici

2. Déclarer le fournisseur OpenStack

Ajoutez la configuration suivante à votre main.tf pour spécifier les fournisseurs Terraform requis :

vim main.tf

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
    }

    openstack = {
      source  = "terraform-provider-openstack/openstack"
    }
  }
}

Ce bloc garantit que Terraform utilise les fournisseurs corrects pour gérer les ressources OVH et OpenStack.

3. Récupérer les informations de votre réseau privé

Ajoutez les blocs suivants à votre fichier main.tf pour récupérer les détails de votre réseau privé et sous-réseau :

data "openstack_networking_network_v2" "private_network" {
  name   = "<YOUR_PRIVATE_NETWORK_NAME>"
  region = "<YOUR_REGION_NAME>"
}

data "openstack_networking_subnet_v2" "private_subnet" {
  name   = "<YOUR_PRIVATE_SUBNET_NAME>"
  region = "<YOUR_REGION_NAME>"
}

Ces blocs de données permettent à Terraform d'interroger OpenStack et de récupérer les détails nécessaires de votre réseau privé et sous-réseau, requis pour configurer le service File Storage.

4. Créer un réseau partagé

Ajoutez la ressource suivante à votre main.tf pour créer un réseau partagé pour votre service File Storage :

resource "openstack_sharedfilesystem_sharenetwork_v2" "sharenetwork" {
  name              = "<YOUR_SHARE_NETWORK_NAME>"
  region            = "<YOUR_REGION_NAME>"
  neutron_net_id    = data.openstack_networking_network_v2.private_network.id
  neutron_subnet_id = data.openstack_networking_subnet_v2.private_subnet.id
}

Cette ressource crée un réseau partagé dans OpenStack, l'associant à votre réseau privé et sous-réseau existants. Elle est nécessaire pour provisionner et gérer des systèmes de fichiers partagés.

5. Créer un partage NFS

Ajoutez la ressource suivante à votre main.tf pour créer un partage NFS sur votre service File Storage :

vim main.tf


resource "openstack_sharedfilesystem_share_v2" "share" {
  name             = "<YOUR_SHARE_NAME>"
  region           = "<YOUR_REGION_NAME>"
  share_type       = "standard-1az"
  share_proto      = "NFS"
  size             = 150
  share_network_id = openstack_sharedfilesystem_sharenetwork_v2.sharenetwork.id
}

Cette ressource provisionne un partage NFS dans OpenStack, lié au réseau partagé précédemment créé. Ajustez la size et share_type selon vos besoins.

6. Autoriser une machine virtuelle cliente

Assurez-vous que votre machine virtuelle cliente est connectée au même réseau privé que votre partage.

Récupérez l'adresse IP privée de la machine virtuelle :

openstack server show --os-region-name <YOUR_REGION_NAME> <YOUR_CLIENT_VM_NAME> -c addresses -f value

Exemple de sortie :

{'my-private-net': ['10.1.0.123', '57.123.88.111']}

Utilisez l'adresse IP privée (par exemple : 10.1.0.123) pour accorder l'accès au partage NFS :

resource "openstack_sharedfilesystem_share_access_v2" "share_access" {
  share_id     = openstack_sharedfilesystem_share_v2.share.id
  region       = "<YOUR_REGION_NAME>"
  access_type  = "ip"
  access_to    = "10.1.0.123"
  access_level = "rw"
}

Cette ressource autorise la machine virtuelle cliente spécifiée à accéder au partage NFS avec des permissions en lecture / écriture.

7. Récupérer le chemin d'exportation

Ajoutez le bloc de sortie suivant à votre main.tf pour récupérer le chemin d'exportation du partage NFS :

output "export_path" {
  value = openstack_sharedfilesystem_share_v2.share.export_locations[0].path
}

Cette sortie fournit le chemin d'exportation NFS, utilisable par les machines virtuelles clientes pour monter le partage.

8. Monter le partage sur votre machine virtuelle cliente

Connectez-vous à votre machine virtuelle cliente et installez les utilitaires NFS nécessaires :

sudo apt update && sudo apt install -y nfs-common

Créez un point de montage et montez le partage :

sudo mkdir -p /mnt/share
sudo mount -t nfs4 <NFS_EXPORT_PATH> /mnt/share

Remplacez par le chemin d'exportation récupéré via Terraform (par exemple : 10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef).

Vérifiez le montage :

df -h /mnt/share

Rendez le montage persistant après les redémarrages :

echo "<NFS_EXPORT_PATH> /mnt/share nfs nfsvers=4 defaults,noauto 0 0" | sudo tee -a /etc/fstab

Cela garantit que votre partage NFS est automatiquement remonté après les redémarrages de la machine virtuelle.

9. Vérifier la capacité et l'utilisation

Une fois le partage NFS monté, vérifiez son espace disponible et son utilisation :

df -h /mnt/share

Exemple de sortie :

Filesystem                          Size  Used  Avail Use% Mounted on
10.1.0.12:/shares/share-abc1...     150G  100M   150G   1% /mnt/share

Cette commande affiche la taille totale, l'espace utilisé et l'espace disponible sur votre partage NFS monté.

Aller plus loin

Échangez avec notre communauté d'utilisateurs.

Base de connaissances

Catégorie

File Storage Service - Premiers pas (bêta)

Objectif

Prérequis

En pratique

Aller plus loin

Articles associés