File Storage Service - Premiers pas

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 :

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
  }
]

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

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 Go connecté à votre réseau privé :

Listez vos shares et attendez que le nouveau share apparaisse avec le statut available.

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"
}

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

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

Récupérez l'adresse IP privée de votre machine virtuelle cliente et assurez-vous qu'elle se trouve sur le même réseau privé que le share.

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 :

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 :

3. Monter 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

Enregistrez la configuration de montage dans fstab pour faciliter le remontage :

echo "10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef /mnt/share nfs nfsvers=4 defaults,noauto 0 0" | sudo tee -a /etc/fstab

Cela vous permet de remonter le share NFS après un redémarrage avec la commande mount /mnt/share.

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

• La CLI OVHcloud doit être installée et configurée.

Installez la CLI OVHcloud :

curl -fsSL https://raw.githubusercontent.com/ovh/ovhcloud-cli/main/install.sh | sh

Authentifiez-vous :

ovhcloud login

1. Identifier votre réseau privé et votre sous-réseau

Listez les réseaux privés disponibles dans votre projet :

ovhcloud cloud network private vrack list --cloud-project <PROJECT_ID>

Récupérez les sous-réseaux associés à votre réseau privé :

ovhcloud cloud network private vrack subnet list <NETWORK_ID> --cloud-project <PROJECT_ID>

2. Créer un réseau partagé

Créez un réseau partagé rattaché à votre réseau privé et à votre sous-réseau :

ovhcloud cloud storage file network create <REGION_NAME> \
  --cloud-project <PROJECT_ID> \
  --name <my-share-network-name> \
  --network-id <NETWORK_ID> \
  --subnet-id <SUBNET_ID>

3. Créer un share NFS

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

ovhcloud cloud storage file share create <REGION_NAME> \
  --cloud-project <PROJECT_ID> \
  --name <my-share-name> \
  --size 150 \
  --share-type STANDARD_1AZ \
  --share-network-id <SHARE_NETWORK_ID>

4. Vérifier le statut du share

Listez vos shares et attendez que le nouveau share apparaisse avec le statut READY :

ovhcloud cloud storage file share list --cloud-project <PROJECT_ID> --region <REGION_NAME>

Récupérez les détails du share, notamment son chemin d'export :

ovhcloud cloud storage file share get <SHARE_ID> --cloud-project <PROJECT_ID> --region <REGION_NAME> -o json

5. Autoriser une machine virtuelle cliente (ACL)

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

ovhcloud cloud storage file share acl create <SHARE_ID> \
  --cloud-project <PROJECT_ID> \
  --region <REGION_NAME> \
  --access-level READ_WRITE \
  --access-to 10.1.0.123

Vérifiez les règles d'accès :

ovhcloud cloud storage file share acl list <SHARE_ID> --cloud-project <PROJECT_ID> --region <REGION_NAME>

Pour supprimer une règle d'accès, récupérez son ID depuis la commande précédente, puis exécutez :

ovhcloud cloud storage file share acl delete <SHARE_ID> <ACL_ID> --cloud-project <PROJECT_ID> --region <REGION_NAME>

6. Monter le share sur votre machine virtuelle cliente

Connectez-vous à votre machine virtuelle cliente 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

Enregistrez la configuration de montage dans fstab pour faciliter le remontage :

echo "10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef /mnt/share nfs nfsvers=4 defaults,noauto 0 0" | sudo tee -a /etc/fstab

Cela vous permet de remonter le share NFS après un redémarrage avec la commande mount /mnt/share.

7. Gérer le cycle de vie du share

Redimensionner le share :

ovhcloud cloud storage file share edit <SHARE_ID> \
  --cloud-project <PROJECT_ID> \
  --region <REGION_NAME> \
  --new-size 200

Supprimer un share :

ovhcloud cloud storage file share delete <SHARE_ID> --cloud-project <PROJECT_ID> --region <REGION_NAME>

1. Prérequis additionnels

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

2. Déclarer le fournisseur OVHcloud

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

vim main.tf

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = ">= 2.20.0"
    }
  }
}

Ce bloc garantit que Terraform utilise le fournisseur OVHcloud, avec une version minimale prenant en charge le chiffrement File Storage (OMK).

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 "ovh_cloud_network_private_vrack" "private_network" {
  service_name = "<YOUR_PROJECT_ID>"
  id           = "<YOUR_PRIVATE_NETWORK_ID>"
}

data "ovh_cloud_network_private_vrack_subnets" "private_subnets" {
  service_name = "<YOUR_PROJECT_ID>"
  network_id   = "<YOUR_PRIVATE_NETWORK_ID>"
}

Ces blocs de données permettent à Terraform d'interroger l'API OVHcloud et de récupérer les détails nécessaires de votre réseau privé et de votre 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 "ovh_cloud_storage_file_share_network" "sharenetwork" {
  service_name = "<YOUR_PROJECT_ID>"
  name         = "<YOUR_SHARE_NETWORK_NAME>"
  region       = "<YOUR_REGION_NAME>"
  network_id   = data.ovh_cloud_network_private_vrack.private_network.id
  subnet_id    = data.ovh_cloud_network_private_vrack_subnets.private_subnets.subnets[0].id
}

Cette ressource associe votre réseau privé et votre sous-réseau existants à un réseau partagé. Elle est nécessaire pour provisionner et gérer des shares File Storage.

5. Créer un share NFS

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

resource "ovh_cloud_storage_file_share" "share" {
  service_name     = "<YOUR_PROJECT_ID>"
  name             = "<YOUR_SHARE_NAME>"
  region           = "<YOUR_REGION_NAME>"
  protocol         = "NFS"
  share_type       = "STANDARD_1AZ"
  size             = 150
  share_network_id = ovh_cloud_storage_file_share_network.sharenetwork.id
}

Cette ressource provisionne un share NFS rattaché au réseau partagé précédemment créé. Ajustez la size selon vos besoins.

resource "ovh_cloud_storage_file_share" "share" {
  # ...
  encryption = {
    enabled = true
  }
}

6. Autoriser une machine virtuelle cliente

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

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 share NFS :

resource "ovh_cloud_storage_file_share_acl" "share_access" {
  service_name = ovh_cloud_storage_file_share.share.service_name
  share_id     = ovh_cloud_storage_file_share.share.id
  access_to    = "10.1.0.123"
  access_level = "READ_WRITE"
}

Cette ressource autorise l'adresse IP cliente spécifiée à accéder au share NFS avec des permissions en lecture / écriture (access_level accepte aussi READ_ONLY).

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 share NFS :

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

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

8. Monter 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 `<NFS_EXPORT_PATH>` /mnt/share

Vérifiez le montage :

df -h /mnt/share

Enregistrez la configuration de montage dans fstab pour faciliter le remontage :

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

Cela vous permet de remonter le share NFS après un redémarrage avec la commande mount /mnt/share.

9. 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

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

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       |
+----------+-----------+------------+------------+

3. Créer un réseau partagé

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>

Créez un réseau partagé 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>

Vérifiez le réseau partagé :

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

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

7. Monter 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

Enregistrez la configuration de montage dans fstab pour faciliter le remontage :

echo "10.1.0.12:/shares/share-abc12345-def6-4abc-8def-123456abcdef /mnt/share nfs nfsvers=4 defaults,noauto 0 0" | sudo tee -a /etc/fstab

Cela vous permet de remonter le share NFS après un redémarrage avec la commande mount /mnt/share.

8. 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

9. Gérer le cycle de vie du share

Redimensionner le share :

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 réseau partagé :

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

10. Dépannage

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.

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 de préparation de l'environnement OpenStack.

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

pip install python-manilaclient

Mettez à 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 :

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 la console OVHcloud (Gestion du projet > Utilisateurs)
• 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 la console OVHcloud (Gestion du projet > Utilisateurs) et notez les informations suivantes :

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

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

Pour vérifier la fonctionnalité RWX, connectez-vous à un pod via kubectl exec et créez un fichier dans le répertoire monté (par exemple, /var/lib/www/). Vérifiez ensuite que ce fichier est visible depuis le deuxième pod : si c'est le cas, votre share Manila exposé via NFS fonctionne correctement.

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

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

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 Go).

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