Déploiement d'OpenShift Data Foundation sur des clusters classiques
OpenShift Data Foundation est une solution de stockage hautement disponible qui permet de gérer le stockage permanent des charges de travail conteneurisées sur des clusters Red Hat® OpenShift® on IBM Cloud®.
L'installation d'OpenShift Data Foundation (ODF) à partir d'OperatorHub n'est pas prise en charge sur les clusters IBM Cloud. Pour installer ODF, procédez comme suit afin de déployer le module complémentaire de cluster.
Planification de la configuration
Avant d'installer ODF sur votre cluster, vérifiez que vous respectez les conditions prérequises suivantes :
Pour installer OpenShift Data Foundation sur des clusters classiques, vous devez activer VRF dans votre compte.
- Installez ou mettez à jour l'interface de ligne de commande
oc
- Si vous n'avez pas de réacheminement de route virtuelle (VRF) activé dans votre compte, activez VRF.
- Après avoir activé la fonction VRF, activez les noeuds finaux de service.
- Examinez les versions de noeud worker SDS. Dans les tableaux de chaque section de la région métropolitaine, les saveurs des FDS se trouvent dans les onglets Métal nu et se terminent par
.ssd
. - Créez un cluster classique avec au moins un noeud worker par zone sur trois zones. Choisissez des noeuds worker de type
mb4c.32x384.3.8tb.ssd
oumb4c.20x64.2x1.9tb.ssd
qui disposent des disques locaux requis pour ODF. - Préparez votre cluster classique.
Facultatif : Configuration d'une instance de service IBM Cloud Object Storage
Si vous souhaitez configurer IBM Cloud Object Storage en tant que magasin de sauvegarde par défaut sur le cluster de stockage, créez une instance d'IBM Cloud Object Storage. Créez ensuite un ensemble de données d'identification HMAC et un secret Kubernetes qui utilise vos données d'identification HMAC Object Storage. Si vous ne spécifiez pas de données d'identification IBM Cloud Object Storage lors de l'installation, le magasin de sauvegarde par défaut sur le cluster de stockage est créé à l'aide des volumes persistants de votre cluster. Vous pouvez configurer des magasins de sauvegarde supplémentaires après le déploiement d'ODF, mais vous ne pouvez pas modifier le magasin de sauvegarde par défaut.
Accédez à votre cluster Red Hat OpenShift.
- Créez un espace de noms
openshift-storage
dans votre cluster. Les pods de pilotes sont déployés dans cet espace de noms. Copiez le contenu YAML suivant et sauvegardez-le sous le nomos-namespace.yaml
sur votre machine locale :apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-storage
- Créez l'espace de noms
openshift-storage
en utilisant le fichier YAML que vous avez sauvegardé.oc create -f os-namespace.yaml
- Vérifiez que l'espace de noms a été créé.
oc get namespaces | grep storage
- Créez une instance de service IBM Cloud Object Storage.
ibmcloud resource service-instance-create noobaa-store cloud-object-storage standard global
- Créez des données d'identification HMAC. Notez vos données d'identification.
ibmcloud resource service-key-create cos-cred-rw Writer --instance-name noobaa-store --parameters '{"HMAC": true}'
- Créez le secret Kubernetes nommé
ibm-cloud-cos-creds
dans l'espace de nomsopenshift-storage
qui utilise vos données d'identification HMAC Object Storage. Lorsque vous exécutez la commande, spécifiez votre ID de clé d'accès HMAC Object Storage et votre clé d'accès secrète. Notez que votre secret doit se nommeribm-cloud-cos-creds
.oc -n 'openshift-storage' create secret generic 'ibm-cloud-cos-creds' --type=Opaque --from-literal=IBM_COS_ACCESS_KEY_ID=<access_key_id> --from-literal=IBM_COS_SECRET_ACCESS_KEY=<secret_access_key>
- Vérifiez que votre secret a bien été créé.
oc get secrets -A | grep cos
Facultatif : Configuration du chiffrement à l'aide de Hyper Protect Crypto Services
Si vous souhaitez configurer le chiffrement, créez une instance de Hyper Protect Crypto Services ou de Key Protect. Ensuite, créez une clé racine et un secret Kubernetes qui utilise vos informations d'identification Hyper Protect Crypto Services ou Key Protect.
- Votre clé d'API pour Hyper Protect Crypto Services ou Key Protect doit disposer des droits minimum requis suivants:
Reader
Reader Plus
- Si vous utilisez le chiffrement à l'échelle du cluster et le chiffrement de classe de stockage, votre clé d'API doit disposer des droits requis suivants:
Reader
Reader Plus
Writer
-
Créez une instance de service Hyper Protect Crypto Services ou Key Protect.
-
Créer une clé racine
-
Après avoir créé votre instance et votre clé racine, notez le nom de votre instance Hyper Protect Crypto Services ou Key Protect, l'identifiant de l'instance, l'identifiant de la clé racine et le point de terminaison public.
-
Créez un ID de service, une clé d'API et une règle d'accès qui permettent d'accéder à Hyper Protect Crypto Services et à Red Hat OpenShift on IBM Cloud ou à Key Protect et à Red Hat OpenShift on IBM Cloud. Notez l'API que vous créez.
Accédez à votre cluster Red Hat OpenShift.
- Répertoriez vos espaces de nom pour déterminer si vous disposez d'un espace-noms
openshift-storage
. Si vous n'avez pas d'espace de nomopenshift-storage
, créez-le.oc get namespaces | grep openshift-storage
- Créez un espace de noms
openshift-storage
dans votre cluster. Les pods de pilotes sont déployés dans cet espace de noms. Copiez le contenu YAML suivant et sauvegardez-le sous le nomos-namespace.yaml
sur votre machine locale :apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-storage
- Créez l'espace de noms
openshift-storage
en utilisant le fichier YAML que vous avez sauvegardé.oc create -f os-namespace.yaml
- Vérifiez que l'espace de noms a été créé.
oc get namespaces | grep storage
- Créez un espace de noms
- Codez à la fois l'ID de votre clé racine et la clé d'API de l'ID service que vous avez créé en base64.
printf "ROOT-KEY-ID" | base64
printf "SERVICE-ID-API-KEY" | base64
- Créez le secret Kubernetes dans l'espace de nom
openshift-storage
qui utilise vos données d'identification Hyper Protect Crypto Services.- Enregistrez le secret suivant sous la forme d'un fichier YAML appelé
ibm-hpcs-secret.yaml
.apiVersion: v1 data: IBM_KP_CUSTOMER_ROOT_KEY: AaAAAaZAAAAy11AAAyAAkaAaQtAAk0AAA2AzY5AjYaaa67aa # your base64 encoded root key ID IBM_KP_SERVICE_API_KEY: AAAaaajAAAAAncmAAaaaaAAAAdAAId1AtVjBJRU1aAAaAeTh1aEw=AaaaA # your base64 encoded API kind: Secret metadata: name: ibm-hpcs-secret namespace: openshift-storage type: Opaque
- Créez le secret dans votre cluster.
oc apply -f ibm-hpcs-secret.yaml
- Enregistrez le secret suivant sous la forme d'un fichier YAML appelé
- Vérifiez que votre secret a bien été créé.
oc get secrets -A | grep ibm-hpcs-secret
Préparation du cluster pour une installation OpenShift Data Foundation
Avant d'installer OpenShift Data Foundation, préparez votre cluster.
Accédez à votre cluster Red Hat OpenShift.
-
Connectez-vous à chaque noeud worker de votre cluster à l'aide de la commande
oc debug
et procédez comme suit :-
Connectez-vous au noeud worker. Remplacez
<worker_node_IP>
par le nom de votre nœud de travail. Pour obtenir les noms de vos nœuds de travail, exécutez la commandeoc get nodes
la commandeoc debug node/<node name> -- chroot /host rm -rvf /var/lib/rook /mnt/local-storage
-
Pour chaque partition de disque, désélectionnez le système de fichiers
xfs
sur le noeud worker. Si vous n'effacez pas le système de fichiers, l'OSD n'est pas créé.file -sL /dev/<partition> wipefs -a /dev/<partition>
-
Editez le fichier
/etc/kubernetes/kubelet.conf
et remplacez la valeur du paramètreEnableControllerAttachDetach
partrue
.nano /etc/kubernetes/kubelet.conf
-
Enregistrez et fermez à l'aide de
ctrl + X
. -
Redémarrez le kubelet.
systemctl restart kubelet
-
Déconnectez-vous du noeud worker
exit
-
-
Répétez les étapes précédentes pour effacer le système de fichiers de chaque noeud worker que vous souhaitez utiliser dans votre déploiement ODF.
Extraction des détails d'une unité
Vous pouvez utiliser la reconnaissance de disque automatique pour rechercher les unités disponibles pour le fichier de définition d'objets. Toutefois, si vous souhaitez spécifier manuellement des unités de stockage pour ODF, procédez comme suit pour extraire les détails de votre unité de stockage.
Avant d'installer ODF, extrayez les détails des disques locaux sur les noeuds worker.
-
Connectez-vous à votre cluster pour obtenir une liste des noeuds worker disponibles. Notez les noeuds worker que vous souhaitez utiliser dans votre déploiement OCS.
oc get nodes
-
Connectez-vous à chaque noeud worker que vous souhaitez utiliser pour votre environnement ODF.
oc debug node/<node-name>
-
Après avoir déployé le pod de débogage sur le noeud worker, exécutez la commande suivante pour autoriser les fichiers binaires hôte :
chroot /host
-
Répertoriez les disques disponibles sur le noeud worker.
lsblk
-
Recherchez les disques disponibles dans la sortie de la commande. Vous ne pouvez utiliser que des disques non montés pour les déploiements ODF, comme les disques
sdc
dans l'exemple ci-après. Notez que la capacité de stockage initiale de votre déploiement ODF correspond à la taille du disque spécifiée avec le paramètreosd-device-path
. Dans cet exemple, le disquesdc
est démonté et dispose de deux partitions disponibles:sdc1
etsdc2
.NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931G 0 disk |-sda1 8:1 0 256M 0 part /boot |-sda2 8:2 0 1G 0 part -sda3 8:3 0 929.8G 0 part / sdb 8:16 0 744.7G 0 disk -sdb1 8:17 0 744.7G 0 part /disk1 sdc 8:32 0 744.7G 0 disk |-sdc1 8:33 0 18.6G 0 part -sdc2 8:34 0 260.8G 0 part
-
Pour chaque disque non monté que vous souhaitez utiliser dans votre déploiement, recherchez l'ID correspondant. Dans l'exemple ci-après, l'ID de la partition
sdc1
estscsi-3600605b00d87b43027b3bc310a64c6c9-part1
et l'ID de la partitionsdc2
estscsi-3600605b00d87b43027b3bc310a64c6c9-part2
.ls -l /dev/disk/by-id/
Exemple de sortie
total 0 lrwxrwxrwx. 1 root root 9 Feb 9 04:15 scsi-3600605b00d87b43027b3bbb603150cc6 -> ../../sda lrwxrwxrwx. 1 root root 10 Feb 9 04:15 scsi-3600605b00d87b43027b3bbb603150cc6-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 10 Feb 9 04:15 scsi-3600605b00d87b43027b3bbb603150cc6-part2 -> ../../sda2 lrwxrwxrwx. 1 root root 10 Feb 9 04:15 scsi-3600605b00d87b43027b3bbb603150cc6-part3 -> ../../sda3 lrwxrwxrwx. 1 root root 9 Feb 9 04:15 scsi-3600605b00d87b43027b3bbf306bc28a7 -> ../../sdb lrwxrwxrwx. 1 root root 10 Feb 9 04:15 scsi-3600605b00d87b43027b3bbf306bc28a7-part1 -> ../../sdb1 lrwxrwxrwx. 1 root root 9 Feb 9 04:17 scsi-3600605b00d87b43027b3bc310a64c6c9 -> ../../sdc lrwxrwxrwx. 1 root root 10 Feb 11 03:14 scsi-3600605b00d87b43027b3bc310a64c6c9-part1 -> ../../sdc1 lrwxrwxrwx. 1 root root 10 Feb 11 03:15 scsi-3600605b00d87b43027b3bc310a64c6c9-part2 -> ../../sdc2
-
Répétez les étapes précédentes pour chaque noeud worker que vous souhaitez utiliser pour le déploiement OpenShift Data Foundation.
Installation du module complémentaire à partir de l'interface CLI
Vous pouvez installer le module complémentaire à l'aide de la commande ibmcloud oc cluster addon enable
.
Si vous souhaitez utiliser une instance de service IBM Cloud Object Storage comme magasin de sauvegarde par défaut, vérifiez que vous avez créé l'instance de service et que vous avez créé le secret Kubernetes
dans votre cluster. Lorsque vous créez la définition de ressource personnalisée ODF sur le cluster, ODF recherche un secret nommé ibm-cloud-cos-creds
pour configurer le magasin de sauvegarde par défaut à l'aide de vos données
d'identification HMAC Object Storage.
-
Consultez la référence de paramètre. Lorsque vous activez le module complémentaire, vous pouvez remplacer les valeurs par défaut en spécifiant l'option
--param "key=value"
pour chaque paramètre que vous souhaitez remplacer. -
Avant d'activer l'ajout, consultez le fichier Journal des modifications pour obtenir les dernières informations de version. Notez que le module complémentaire prend en charge les versions de cluster
n+1
. Par exemple, vous pouvez déployer la version4.10.0
de l'add-on sur un cluster OCP 4.9 ou 4.11. Si vous disposez d'une version de cluster différente de la version par défaut, vous devez spécifier l'option--version
lorsque vous activez le module complémentaire.- Passez en revue les options complémentaires de la version du module complémentaire que vous souhaitez déployer.
ibmcloud oc cluster addon options --addon openshift-data-foundation --version 4.15.0
Pour de meilleures performances, il est recommandé d'inclure l'option
resourceProfile
spécifiée commeperformance
. Cette option permet d'obtenir des niveaux de performance améliorés en fonction de la disponibilité des ressources pendant le déploiement. Pour plus d'informations sur l'optionresourceProfile
, voir Profils de performance dans la documentation de Red Hat OpenShift ODFNotez que les classes de stockage par défaut pour
monStorageClassName
etosdStorageClassName
sont des classes de stockage Block Storage for VPC.Exemple d'options complémentaires pour la version 4.15.0
Add-on Options Option Default Value osdStorageClassName ibmc-vpc-block-metro-10iops-tier ocsUpgrade false billingType advanced autoDiscoverDevices false hpcsBaseUrl <Please provide the KMS Base (public) URL> taintNodes false enableNFS false resourceProfile performance useCephRBDAsDefaultStorageClass false clusterEncryption false hpcsEncryption false hpcsSecretName <Please provide the KMS secret name> encryptionInTransit false disableNoobaaLB false osdSize 512Gi numOfOsd 1 ignoreNoobaa true addSingleReplicaPool false prepareForDisasterRecovery false workerPool - odfDeploy true osdDevicePaths <Please provide IDs of the disks to be used for OSD pods if using local disks or standard classic cluster> workerNodes all hpcsServiceName <Please provide the KMS Service instance name> hpcsInstanceId <Please provide the KMS Service instance ID> hpcsTokenUrl <Please provide the KMS token URL>
-
Activez l'additif
openshift-data-foundation
. Si vous souhaitez déployer uniquement le module complémentaire ODF, vous pouvez spécifier l'option"odfDeploy=false"
. Si vous souhaitez remplacer l'un des paramètres par défaut, spécifiez l'option--param "key=value"
pour chaque paramètre que vous souhaitez remplacer. Si vous ne souhaitez pas créer le cluster de stockage lorsque vous activez le module complémentaire, vous pouvez d'abord activer le module complémentaire, puis créer le cluster de stockage ultérieurement en créant une définition de ressource personnalisée (CRD).Exemple de commande pour activer le module complémentaire et découvrir automatiquement les volumes locaux, activer l'option de profil de ressources
performance
et activer le chiffrement avec Hyper Protect Crypto Services ou Key Protectibmcloud oc cluster addon enable openshift-data-foundation -c <cluster-name> --version VERSION --param "odfDeploy=true" --param "resourceProfile=performance" --param "osdSize=250" --param "autoDiscoverDevices=true" --param "hpcsTokenUrl=https://iam.cloud.ibm.com/identity/token" --param "hpcsEncryption=true" --param "hpcsBaseUrl=<hpcs-instance-public-endpoint>" --param "hpcsInstanceId=<hpcs-instance-id>" --param "hpcsServiceName=<hpcs-instance-name>" --param "hpcsSecretName=<hpcs-secret-name>"
-
Vérifiez que le module complémentaire est prêt (
Ready
).ibmcloud oc cluster addon ls -c <cluster_name>
-
Vérifiez que le pod
ibm-ocs-operator-controller-manager-*****
est en cours d'exécution dans l'espace de nomskube-system
.oc get pods -A | grep ibm-ocs-operator-controller-manager
-
Si vous avez activé le module complémentaire et défini l'option
odfDeploy=false
, procédez comme suit pour créer une ressource personnalisée ODF.
Installation du module complémentaire OpenShift Data Foundation à partir de la console
Pour installer ODF sur le cluster, procédez comme suit :
La version 4.11 est actuellement disponible uniquement pour les nouveaux clusters. Vous ne pouvez pas mettre à niveau un déploiement 4.10 vers 4.11. Toutefois, vous pouvez continuer à utiliser ODF version 4.10.
- Avant d'activer l'ajout, consultez le fichier Journal des modifications pour obtenir les dernières informations de version. Notez que le module complémentaire
prend en charge les versions de cluster
n+1
. - Consultez la référence des paramètres.
- Dans la console, sélectionnez le cluster dans lequel vous souhaitez installer le module complémentaire.
- Sur la carte OpenShift Data Foundation, cliquez sur Installer. Le panneau Installer ODF s'ouvre.
- Dans le panneau Installer ODF, entrez les paramètres de configuration que vous voulez utiliser pour votre déploiement ODF.
- Sélectionnez Principes fondamentaux ou Avancé comme plan de facturation.
- Pour les clusters classiques, sélectionnez Stockage local pour utiliser les volumes locaux sur les nœuds worker.
- Si vous souhaitez reconnaître automatiquement les unités de stockage disponibles sur vos nœuds worker et les utiliser dans ODF, sélectionnez Reconnaissance de disque local.
- Si vous souhaitez spécifier manuellement les unités de stockage sur les nœuds worker que vous souhaitez utiliser dans ODF, entrez une liste séparée par des virgules des ID de disque que vous souhaitez utiliser. Pour rechercher ces ID de disque, voir Collecte des détails de l'unité.
- Dans la zone nœuds worker, entrez les noms de nœuds worker sur lesquels vous souhaitez déployer ODF. Vous devez entrer au moins 3 noms de nœuds worker. Pour rechercher des noms de nœuds, exécutez la commande
oc get nodes
dans votre cluster. Laissez cette zone vide pour déployer ODF sur tous les nœuds worker. Les noms de Node doivent être séparés par des virgules sans espace entre les noms. Par exemple:10.240.0.24,10.240.0.26,10.240.0.25
. - Dans la zone Nombre de disques OSD requis, entrez le nombre de disques OSD (stockage d'application) à fournir sur chaque nœud worker.
- Si vous réactivez le module complémentaire pour mettre à niveau la version du module complémentaire, sélectionnez l'option Mettre à niveau ODF.
- Si vous souhaitez chiffrer les volumes utilisés par les pods du système ODF, sélectionnez Activer le chiffrement de cluster.
- Si vous souhaitez activer le chiffrement sur les volumes OSD (stockage d'application), sélectionnez Activer le chiffrement de volume.
- Dans le champ Nom de l'instance, saisissez le nom de votre instance Hyper Protect Crypto Services ou Key Protect. Par exemple :
Hyper-Protect-Crypto-Services-eugb
. - Dans le champ ID d' instance, saisissez votre ID d'instance Hyper Protect Crypto Services ou Key Protect. Par exemple :
d11a1a43-aa0a-40a3-aaa9-5aaa63147aaa
. - Dans le champ Nom du secret, saisissez le nom du secret que vous avez créé à l'aide de vos informations d'identification Hyper Protect Crypto Services ou Key Protect. Par exemple :
ibm-hpcs-secret
. - Dans le champ Base URL, entrez le point de terminaison public de votre instance Hyper Protect Crypto Services ou Key Protect. Par exemple :
https://api.eu-gb.hs-crypto.cloud.ibm.com:8389
. - Dans la zone URL du jeton, entrez
https://iam.cloud.ibm.com/identity/token
.
- Dans le champ Nom de l'instance, saisissez le nom de votre instance Hyper Protect Crypto Services ou Key Protect. Par exemple :
Création du cluster de stockage
Si vous souhaitez déployer ODF sur le cluster classique, vous pouvez créer une définition de ressource personnalisée (CRD) pour spécifier les détails des unités de stockage.
Si vous souhaitez utiliser une instance de service IBM Cloud Object Storage comme magasin de sauvegarde par défaut, vérifiez que vous avez créé l'instance de service et que vous avez créé le secret Kubernetes
dans votre cluster. Lorsque vous créez la définition de ressource personnalisée (CRD) ODF sur le cluster, ODF recherche un secret nommé ibm-cloud-cos-creds
pour configurer le magasin de sauvegarde par défaut à l'aide de vos données
d'identification HMAC Object Storage.
-
Créez une définition de ressource personnalisée (CRD) nommée
OcsCluster
. Sauvegardez et éditez la définition de ressource personnalisée ci-après pour en y ajoutant les chemins d'accès d'unité des disques locaux que vous avez extraits précédemment. Si vous n'indiquez pas le paramètre facultatifworkerNodes
, tous les noeuds worker du cluster sont utilisés pour le déploiement ODF. Prenez soin d'inclure le chemin/dev/disk/by-id/
lorsque vous spécifiez vos unités de stockage.- Si votre noeud worker dispose de disques bruts avec partitions, vous avez besoin d'une partition pour OSD et d'une partition pour MON par noeud worker. En tant que meilleure pratique, et pour optimiser la capacité de stockage sur les disques
partitionnés, vous pouvez spécifier la partition ou le disque le plus petit pour MON et la partition ou le disque le plus grand pour OSD. Notez que la capacité de stockage initiale de votre configuration ODF correspond à la taille du
disque que vous spécifiez avec le paramètre
osd-device-path
lorsque vous créez votre configuration. - Si vos unités ne sont pas partitionnées, vous devez spécifier un disque brut pour MON et un pour OSD pour chaque noeud worker que vous voulez utiliser.
Exemple de ressource personnalisée permettant d'installer ODF sur tous les nœuds worker d'un cluster version 4.8 à l'aide de la reconnaissance automatique de disque.
apiVersion: ocs.ibm.io/v1 kind: OcsCluster metadata: name: ocscluster-classic spec: osdStorageClassName: localblock osdSize: "1" autoDiscoverDevices: true
Exemple de ressource personnalisée pour l'installation d'ODF sur tous les nœuds worker dans un cluster version 4.8 avec des disques partitionnés.
apiVersion: ocs.ibm.io/v1 kind: OcsCluster metadata: name: ocscluster # Kubernetes resource names can't contain capital letters or special characters. Specify a name for your resource that uses only lowercase letters, numbers, `-` or `.` spec: osdStorageClassName: localblock osdSize: "1" numOfOsd: 1 billingType: advanced ocsUpgrade: false osdDevicePaths: - <device-by-id> # Example: /dev/disk/by-id/scsi-0000000a00a00a00000a0aa000a00a0a0-part2 - <device-by-id> # Example: /dev/disk/by-id/scsi-1111111a11a11a11111a1aa111a11a1a1-part2 - <device-by-id> # Example: dev/disk/by-id/scsi-2222222a22a22a22222a2aa222a22a2a2-part2
- Si votre noeud worker dispose de disques bruts avec partitions, vous avez besoin d'une partition pour OSD et d'une partition pour MON par noeud worker. En tant que meilleure pratique, et pour optimiser la capacité de stockage sur les disques
partitionnés, vous pouvez spécifier la partition ou le disque le plus petit pour MON et la partition ou le disque le plus grand pour OSD. Notez que la capacité de stockage initiale de votre configuration ODF correspond à la taille du
disque que vous spécifiez avec le paramètre
-
Sauvegardez le fichier et créez la définition de ressource personnalisée
OcsCluster
sur votre cluster.oc create -f <ocs_cluster_filename>
-
Vérifiez que votre ressource personnalisée
OcsCluster
est en cours d'exécution.oc describe OcsCluster ocscluster
Limitations
Vous ne pouvez pas utiliser à la fois le module complémentaire ibmcloud-block-storage-plugin
et le module complémentaire ODF. Pour installer ODF, vous devez d'abord éditer le fichier /etc/kubernetes/kubelet.conf
et
remplacer la valeur du paramètre EnableControllerAttachDetach
par true
, ce qui modifie le comportement de connexion de volume par défaut pour le cluster. Cela signifie que vous ne pouvez pas allouer des volumes de
manière dynamique à l'aide des classes de stockage ibmc-block-*
. A la place, vous devez créer des volumes à l'aide des classes de stockage ODF.