Stockage

Les pods et les conteneurs sont de nature éphémère ou transitoire et sont conçus pour des applications sans état. Le stockage éphémère permet aux administrateurs et aux développeurs de mieux gérer le stockage local pour certaines de leurs opérations. Pour plus d'informations sur la présentation, les types et la gestion du stockage éphémère, voir Comprendre le stockage éphémère.

Les applications avec état déployées dans des conteneurs nécessitent un stockage persistant. OpenShift Container Platform utilise un cadre de stockage pré-provisionné appelé volumes persistants (PV) pour permettre aux administrateurs de cluster de provisionner le stockage persistant. Les données contenues dans ces volumes peuvent exister au-delà du cycle de vie d'un pod individuel. Les développeurs peuvent utiliser des réclamations de volumes persistants (PVC) pour demander des exigences de stockage. Pour plus d'informations sur la présentation, la configuration et le cycle de vie du stockage persistant, voir Comprendre le stockage persistant.

En réponse aux demandes d'un développeur défini dans un PVC, un administrateur de cluster configure un ou plusieurs provisionneurs dynamiques qui fournissent du stockage et un PV correspondant.

Un administrateur de cluster peut également créer à l'avance un certain nombre de PV qui contiennent les détails du stockage réel disponible pour l'utilisation. Les PV existent dans l'API et peuvent être utilisés.

Lorsque vous créez un PVC, vous demandez une quantité spécifique de stockage, vous spécifiez le mode d'accès requis et vous créez une classe de stockage pour décrire et classer le stockage. La boucle de contrôle du maître surveille les nouveaux PVC et lie le nouveau PVC à un PV approprié. S'il n'existe pas de PV approprié, un provisionneur de la classe de stockage en crée un.

La taille de tous les PV peut dépasser la taille de votre PVC. Cela est particulièrement vrai pour les PV provisionnés manuellement. Pour minimiser l'excès, OpenShift Container Platform se lie au plus petit PV qui correspond à tous les autres critères.

Les demandes restent indéfiniment non liées si un volume correspondant n'existe pas ou ne peut pas être créé avec un provisionneur disponible desservant une classe de stockage. Les demandes sont liées au fur et à mesure que des volumes correspondants sont disponibles. Par exemple, un cluster avec de nombreux volumes de 50Gi provisionnés manuellement ne correspondrait pas à un PVC demandant 100Gi. Le PVC peut être lié lorsqu'un PV de 100Gi est ajouté au cluster.

Les modules utilisent les revendications comme des volumes. Le cluster inspecte la revendication pour trouver le volume lié et monte ce volume pour un pod. Pour les volumes qui prennent en charge plusieurs modes d'accès, vous devez spécifier le mode qui s'applique lorsque vous utilisez la revendication comme volume dans un module.

Une fois que vous avez une revendication et que cette revendication est liée, le PV lié vous appartient aussi longtemps que vous en avez besoin. Vous pouvez planifier des pods et accéder aux PV revendiqués en incluant persistentVolumeClaim dans le bloc de volumes du pod.

La fonction de protection des objets de stockage en cours d'utilisation garantit que les PVC utilisés activement par un pod et les PV liés aux PVC ne sont pas supprimés du système, ce qui pourrait entraîner une perte de données.

La protection des objets de stockage en cours d'utilisation est activée par défaut.

Si un utilisateur supprime un PVC qui est utilisé activement par un pod, le PVC n'est pas supprimé immédiatement. La suppression du PVC est reportée jusqu'à ce que le PVC ne soit plus utilisé activement par aucun pod. De même, si un administrateur de cluster supprime un PV lié à un PVC, le PV n'est pas supprimé immédiatement. La suppression de la PV est reportée jusqu'à ce que la PV ne soit plus liée à un PVC.

Lorsque vous avez terminé avec un volume, vous pouvez supprimer l'objet PVC de l'API, ce qui permet la récupération de la ressource. Le volume est considéré comme libéré lorsque la demande est supprimée, mais il n'est pas encore disponible pour une autre demande. Les données du demandeur précédent restent sur le volume et doivent être traitées conformément à la politique.

La politique de récupération d'un volume persistant indique au cluster ce qu'il doit faire du volume après sa libération. La politique de récupération d'un volume peut être Retain, Recycle, ou Delete.

Lorsqu'une demande de volume persistant (PVC) est supprimée, le volume persistant (PV) existe toujours et est considéré comme "libéré". Cependant, le PV n'est pas encore disponible pour une autre demande, car les données du demandeur précédent restent sur le volume.

Le PV récupéré est maintenant disponible pour être utilisé par un autre PVC.

Pour modifier la politique de récupération d'un volume persistant :

OpenShift Container Platform prend en charge les plugins de volumes persistants suivants :

En général, un volume persistant (PV) a une capacité de stockage spécifique. Celle-ci est définie à l'aide de l'attribut capacity du PV.

Actuellement, la capacité de stockage est la seule ressource qui peut être définie ou demandée. À l'avenir, les attributs pourront inclure l'IOPS, le débit, etc.

Un volume persistant peut être monté sur un hôte de n'importe quelle manière prise en charge par le fournisseur de ressources. Les fournisseurs ont des capacités différentes et les modes d'accès de chaque PV sont définis en fonction des modes spécifiques pris en charge par ce volume particulier. Par exemple, NFS peut prendre en charge plusieurs clients en lecture-écriture, mais un PV NFS spécifique peut être exporté sur le serveur en lecture seule. Chaque PV dispose de son propre ensemble de modes d'accès décrivant ses capacités spécifiques.

Les demandes sont associées à des volumes dont les modes d'accès sont similaires. Les deux seuls critères de correspondance sont les modes d'accès et la taille. Les modes d'accès d'une demande représentent une requête. Par conséquent, il se peut que l'on vous accorde plus, mais jamais moins. Par exemple, si une requête demande RWO, mais que le seul volume disponible est un PV NFS (RWO ROX RWX), la requête correspondra alors à NFS parce qu'il prend en charge RWO.

Les correspondances directes sont toujours tentées en premier. Les modes du volume doivent correspondre ou contenir plus de modes que ce que vous avez demandé. La taille doit être supérieure ou égale à celle attendue. Si deux types de volumes, tels que NFS et iSCSI, disposent du même ensemble de modes d'accès, l'un ou l'autre peut correspondre à une demande avec ces modes. Il n'y a pas d'ordre entre les types de volumes et il n'y a aucun moyen de choisir un type plutôt qu'un autre.

Tous les volumes présentant les mêmes modes sont regroupés, puis triés par taille, du plus petit au plus grand. Le relieur récupère le groupe dont les modes correspondent et itère sur chacun d'entre eux, par ordre de taille, jusqu'à ce qu'une taille corresponde.

Le tableau suivant énumère les modes d'accès :

Les volumes peuvent être trouvés dans l'une des phases suivantes :

Vous pouvez afficher le nom du PVC lié à la PV en exécutant la commande suivante

$ oc get pv <pv-claim>

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 1
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

Les revendications peuvent éventuellement demander une classe de stockage spécifique en spécifiant le nom de la classe de stockage dans l'attribut storageClassName. Seuls les PV de la classe demandée, ceux qui ont le même storageClassName que le PVC, peuvent être liés au PVC. L'administrateur de cluster peut configurer des provisionneurs dynamiques pour desservir une ou plusieurs classes de stockage. L'administrateur de cluster peut créer un PV à la demande qui correspond aux spécifications du PVC.

L'administrateur du cluster peut également définir une classe de stockage par défaut pour tous les PVC. Lorsqu'une classe de stockage par défaut est configurée, le PVC doit demander explicitement des annotations StorageClass ou storageClassName définies sur "" pour être lié à un PV sans classe de stockage.

Les revendications utilisent les mêmes conventions que les volumes pour demander un stockage avec des modes d'accès spécifiques.

Les demandes, telles que les pods, peuvent demander des quantités spécifiques d'une ressource. Dans ce cas, il s'agit d'une demande de stockage. Le même modèle de ressource s'applique aux volumes et aux demandes.

Les pods accèdent au stockage en utilisant la revendication comme un volume. Les revendications doivent exister dans le même espace de noms que le module qui les utilise. Le cluster trouve la revendication dans l'espace de noms du module et l'utilise pour obtenir le site PersistentVolume qui soutient la revendication. Le volume est monté sur l'hôte et dans le module, par exemple :

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 1
        name: mypd 2
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 3

Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, les utilisateurs peuvent obtenir des volumes persistants provisionnés dynamiquement.

Avant que OpenShift Container Platform ne monte le volume et ne le transmette à un conteneur, il vérifie que le volume contient un système de fichiers tel que spécifié par le paramètre fsType dans la définition du volume persistant. Si le périphérique n'est pas formaté avec le système de fichiers, toutes les données du périphérique sont effacées et le périphérique est automatiquement formaté avec le système de fichiers donné.

Cette vérification permet d'utiliser des volumes AWS non formatés en tant que volumes persistants, car OpenShift Container Platform les formate avant la première utilisation.

Par défaut, OpenShift Container Platform prend en charge un maximum de 39 volumes EBS attachés à un nœud. Cette limite est cohérente avec les limites de volume AWS. La limite de volume dépend du type d'instance.

Pour plus d'informations sur l'accès à des options de stockage supplémentaires, telles que les instantanés de volume, qui ne sont pas possibles avec les plug-ins de volume dans l'arborescence, voir AWS Elastic Block Store CSI Driver Operator.

La définition d'une clé KMS pour chiffrer les volumes persistants des conteneurs sur AWS est utile lorsque vous disposez de directives explicites en matière de conformité et de sécurité lors du déploiement sur AWS.

Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, les utilisateurs peuvent obtenir des volumes persistants provisionnés dynamiquement.

Avant que OpenShift Container Platform ne monte le volume et ne le transmette à un conteneur, il vérifie qu'il contient un système de fichiers tel que spécifié par le paramètre fsType dans la définition du volume persistant. Si le périphérique n'est pas formaté avec le système de fichiers, toutes les données du périphérique sont effacées et le périphérique est automatiquement formaté avec le système de fichiers donné.

Cela permet d'utiliser des volumes Azure non formatés comme volumes persistants, car OpenShift Container Platform les formate avant la première utilisation.

Vous pouvez créer un jeu de machines fonctionnant sur Azure qui déploie des machines avec des ultra-disques. Les disques ultra sont des systèmes de stockage haute performance destinés à être utilisés avec les charges de travail les plus exigeantes.

Le plugin in-tree et le pilote CSI prennent tous deux en charge l'utilisation des PVC pour activer les ultra-disques. Vous pouvez également déployer des machines avec des ultra-disques en tant que disques de données sans créer de PVC.

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.

Pour créer la revendication de volume persistant, vous devez d'abord définir un objet Secret qui contient le compte et la clé Azure. Ce secret est utilisé dans la définition de PersistentVolume et sera référencé par la revendication de volume persistant pour être utilisé dans les applications.

Une fois que la demande de volume persistant a été créée, elle peut être utilisée à l'intérieur par une application. L'exemple suivant montre le montage de ce partage à l'intérieur d'un pod.

Le stockage doit exister dans l'infrastructure sous-jacente avant de pouvoir être monté en tant que volume dans OpenShift Container Platform.

Pour provisionner des volumes Fibre Channel à l'aide de l'API PersistentVolume, les éléments suivants doivent être disponibles :

Un volume persistant et un LUN ont une correspondance univoque entre eux.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  fc:
    wwids: [scsi-3600508b400105e210000900000490000] 1
    targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5'] 2
    lun: 2 3
    fsType: ext4

Un pilote FlexVolume est un fichier exécutable qui réside dans un répertoire bien défini sur tous les nœuds du cluster. OpenShift Container Platform appelle le pilote FlexVolume chaque fois qu'il doit monter ou démonter un volume représenté par un objet PersistentVolume dont la source est flexVolume.

Le premier argument de la ligne de commande du pilote FlexVolume est toujours un nom d'opération. Les autres paramètres sont spécifiques à chaque opération. La plupart des opérations prennent en paramètre une chaîne JavaScript Object Notation (JSON). Ce paramètre est une chaîne JSON complète, et non le nom d'un fichier contenant les données JSON.

Le pilote FlexVolume contient

{
	"fooServer": "192.168.0.1:1234", 1
        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 2
	"kubernetes.io/readwrite": "ro", 3
	"kubernetes.io/secret/<key name>": "<key value>", 4
	"kubernetes.io/secret/<another key name>": "<another key value>",
}

OpenShift Container Platform attend des données JSON sur la sortie standard du pilote. Si rien n'est spécifié, la sortie décrit le résultat de l'opération.

{
	"status": "<Success/Failure/Not supported>",
	"message": "<Reason for success/failure>"
}

Le code de sortie du pilote doit être 0 en cas de succès et 1 en cas d'erreur.

Les opérations doivent être idempotentes, ce qui signifie que le montage d'un volume déjà monté doit aboutir à une opération réussie.

Les pilotes FlexVolume qui sont utilisés pour étendre OpenShift Container Platform sont exécutés uniquement sur le nœud. Pour mettre en œuvre FlexVolumes, une liste d'opérations à appeler et le chemin d'installation sont tout ce qui est nécessaire.

Cet appel ne passe pas les "secrets" spécifiés dans la spécification FlexVolume. Si votre pilote exige des secrets, n'implémentez pas cet appel.

Par exemple, pour installer le pilote FlexVolume pour le stockage foo, placez le fichier exécutable à l'adresse suivante : /etc/kubernetes/kubelet-plugins/volume/exec/openshift.com~foo/foo.

Chaque objet PersistentVolume dans OpenShift Container Platform représente un actif de stockage dans le back-end de stockage, tel qu'un volume.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 1
spec:
  capacity:
    storage: 1Gi 2
  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: openshift.com/foo 3
    fsType: "ext4" 4
    secretRef: foo-secret 5
    readOnly: true 6
    options: 7
      fooServer: 192.168.0.1:1234
      fooVolumeName: bar

Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, les utilisateurs peuvent obtenir des volumes persistants provisionnés dynamiquement.

Avant que OpenShift Container Platform ne monte le volume et ne le transmette à un conteneur, il vérifie que le volume contient un système de fichiers tel que spécifié par le paramètre fsType dans la définition du volume persistant. Si le périphérique n'est pas formaté avec le système de fichiers, toutes les données du périphérique sont effacées et le périphérique est automatiquement formaté avec le système de fichiers donné.

Cette vérification permet d'utiliser des volumes GCE non formatés comme volumes persistants, car OpenShift Container Platform les formate avant la première utilisation.

Vérifiez que le stockage existe dans l'infrastructure sous-jacente avant de le monter en tant que volume dans OpenShift Container Platform. Tout ce qui est nécessaire pour l'iSCSI est le portail cible iSCSI, un nom qualifié iSCSI (IQN) valide, un numéro LUN valide, le type de système de fichiers et l'API PersistentVolume.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
     targetPortal: 10.16.154.81:3260
     iqn: iqn.2014-12.example.server:storage.target00
     lun: 0
     fsType: 'ext4'

Utilisez les partitions LUN pour appliquer les quotas de disque et les contraintes de taille. Chaque LUN est un volume persistant. Kubernetes impose des noms uniques pour les volumes persistants.

L'application de quotas de cette manière permet à l'utilisateur final de demander un stockage persistant d'un montant spécifique (par exemple, 10Gi) et d'obtenir un volume correspondant d'une capacité égale ou supérieure.

Les utilisateurs demandent du stockage avec un objet PersistentVolumeClaim. Cette demande n'existe que dans l'espace de noms de l'utilisateur et ne peut être référencée que par un pod dans ce même espace de noms. Toute tentative d'accès à une demande de volume persistant à travers un espace de noms entraîne l'échec du module.

Chaque LUN iSCSI doit être accessible par tous les nœuds du cluster.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    chapAuthDiscovery: true 1
    chapAuthSession: true 2
    secretRef:
      name: chap-secret 3

Pour le stockage basé sur iSCSI, vous pouvez configurer plusieurs chemins en utilisant le même IQN pour plusieurs adresses IP de portail cible. Les chemins multiples garantissent l'accès au volume persistant en cas de défaillance d'un ou de plusieurs composants d'un chemin.

Pour spécifier des chemins multiples dans la spécification du pod, utilisez le champ portals. Par exemple :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260'] 1
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    readOnly: false

Configurez le nom qualifié iSCSI (IQN) de l'initiateur personnalisé si les cibles iSCSI sont limitées à certains IQN, mais que les nœuds auxquels les PV iSCSI sont attachés ne sont pas garantis d'avoir ces IQN.

Pour spécifier un IQN d'initiateur personnalisé, utilisez le champ initiatorName.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260']
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    initiatorName: iqn.2016-04.test.com:custom.iqn 1
    fsType: ext4
    readOnly: false

Le stockage doit exister dans l'infrastructure sous-jacente avant de pouvoir être monté en tant que volume dans OpenShift Container Platform. Pour provisionner des volumes NFS, il suffit de disposer d'une liste de serveurs NFS et de chemins d'exportation.

Vous pouvez utiliser des partitions de disque pour appliquer des quotas de disque et des contraintes de taille. Chaque partition peut constituer sa propre exportation. Chaque exportation est un PV. OpenShift Container Platform impose des noms uniques pour les PV, mais l'unicité du serveur et du chemin du volume NFS est laissée à l'appréciation de l'administrateur.

L'application de quotas de cette manière permet au développeur de demander un stockage persistant d'un montant spécifique, par exemple 10Gi, et d'obtenir un volume correspondant d'une capacité égale ou supérieure.

Cette section traite de la sécurité des volumes NFS, notamment des permissions correspondantes et des considérations SELinux. L'utilisateur est censé comprendre les bases des autorisations POSIX, des UID de processus, des groupes supplémentaires et de SELinux.

Les développeurs demandent un stockage NFS en référençant soit un PVC par son nom, soit le plugin de volume NFS directement dans la section volumes de leur définition Pod.

Le fichier /etc/exports du serveur NFS contient les répertoires NFS accessibles. Le répertoire NFS cible possède des identifiants POSIX de propriétaire et de groupe. Le plugin NFS d'OpenShift Container Platform monte le répertoire NFS du conteneur avec la même propriété et les mêmes autorisations POSIX que celles trouvées sur le répertoire NFS exporté. Cependant, le conteneur n'est pas exécuté avec son UID effectif égal au propriétaire du montage NFS, ce qui est le comportement souhaité.

Par exemple, si le répertoire NFS cible apparaît sur le serveur NFS sous la forme suivante :

$ ls -lZ /opt/nfs -d

drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs

$ id nfsnobody

uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

Le conteneur doit alors correspondre aux étiquettes SELinux et fonctionner avec un UID de 65534, le propriétaire de nfsnobody, ou avec 5555 dans ses groupes supplémentaires pour accéder au répertoire.

spec:
  containers:
    - name:
    ...
  securityContext: 1
    supplementalGroups: [5555] 2

spec:
  containers: 1
  - name:
  ...
    securityContext:
      runAsUser: 65534 2

NFS implémente l'interface du plugin OpenShift Container Platform Recyclable. Des processus automatiques gèrent les tâches de remise en état en fonction des politiques définies sur chaque volume persistant.

Par défaut, les PV sont réglés sur Retain.

Une fois que les droits sur un PVC sont supprimés et que le PV est libéré, l'objet PV ne doit pas être réutilisé. Au lieu de cela, un nouveau PV doit être créé avec les mêmes détails de volume de base que l'original.

Par exemple, l'administrateur crée un PV nommé nfs1:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

L'utilisateur crée PVC1, qui se lie à nfs1. L'utilisateur supprime ensuite PVC1, ce qui libère nfs1. Le résultat est que nfs1 est Released. Si l'administrateur souhaite rendre le même partage NFS disponible, il doit créer un nouveau PV avec les mêmes détails de serveur NFS, mais un nom de PV différent :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

Il est déconseillé de supprimer le PV original et de le recréer sous le même nom. Tenter de modifier manuellement l'état d'un PV de Released à Available entraîne des erreurs et une perte potentielle de données.

Selon la version de NFS utilisée et la manière dont elle est configurée, des étapes de configuration supplémentaires peuvent être nécessaires pour une exportation et un mappage de sécurité corrects. En voici quelques-unes qui peuvent s'appliquer :

Le provisionnement dynamique des volumes VMware vSphere est la méthode recommandée.

Vous pouvez utiliser l'une des procédures suivantes pour approvisionner dynamiquement ces volumes à l'aide de la classe de stockage par défaut.

Pour provisionner statiquement des volumes VMware vSphere, vous devez créer les disques de la machine virtuelle pour qu'ils soient référencés par la structure de volumes persistants.

OpenShift Container Platform peut être approvisionné avec un stockage persistant en utilisant des volumes locaux. Les volumes persistants locaux vous permettent d'accéder aux périphériques de stockage locaux, tels qu'un disque ou une partition, en utilisant l'interface standard de demande de volume persistant.

Les volumes locaux peuvent être utilisés sans qu'il soit nécessaire de planifier manuellement les pods sur les nœuds, car le système est conscient des contraintes liées aux nœuds de volume. Toutefois, les volumes locaux restent soumis à la disponibilité du nœud sous-jacent et ne conviennent pas à toutes les applications.

Un volume hostPath dans un cluster OpenShift Container Platform monte un fichier ou un répertoire du système de fichiers du nœud hôte dans votre pod. La plupart des pods n'auront pas besoin d'un volume hostPath, mais il offre une option rapide pour les tests si une application le nécessite.

apiVersion: v1
kind: Pod
metadata:
  name: test-host-mount
spec:
  containers:
  - image: registry.access.redhat.com/ubi8/ubi
    name: test-container
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /host
      name: host-slash
  volumes:
   - name: host-slash
     hostPath:
       path: /
       type: ''

Logical volume manager storage (LVM Storage) utilise le pilote TopoLVM CSI pour provisionner dynamiquement le stockage local sur les clusters OpenShift à nœud unique.

LVM Storage crée des volumes à provisionnement fin à l'aide de Logical Volume Manager et fournit un provisionnement dynamique du stockage en bloc sur un cluster OpenShift à nœud unique aux ressources limitées.

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  tolerations:
  - effect: NoSchedule
    key: xyz
    operator: Equal
    value: "true"
  storage:
    deviceClasses: 1
    - name: vg1  2
      nodeSelector: 3
        nodeSelectorTerms: 4
        - matchExpressions:
          - key: mykey
            operator: In
            values:
            - ssd
      deviceSelector: 5
        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
      thinPoolConfig: 6
        name: thin-pool-1 7
        sizePercent: 90 8
        overprovisionRatio: 10 9
status:
    deviceClassStatuses: 10
    - name: vg1
      nodeStatus: 11
      - devices: 12
        - /dev/nvme0n1
        - /dev/nvme1n1
        - /dev/nvme2n1
        node: my-node.example.com 13
        status: Ready 14
    ready: true 15
    state: Ready 16

Les pilotes CSI sont généralement livrés sous forme d'images de conteneurs. Ces conteneurs ne savent pas où s'exécute OpenShift Container Platform. Pour utiliser un back-end de stockage compatible CSI dans OpenShift Container Platform, l'administrateur du cluster doit déployer plusieurs composants qui servent de pont entre OpenShift Container Platform et le pilote de stockage.

Le diagramme suivant fournit une vue d'ensemble des composants fonctionnant dans les pods du cluster OpenShift Container Platform.

Il est possible d'exécuter plusieurs pilotes CSI pour différents backends de stockage. Chaque pilote a besoin de son propre déploiement de contrôleurs externes et d'un démon configuré avec le pilote et le registraire CSI.

OpenShift Container Platform installe certains pilotes CSI par défaut, offrant aux utilisateurs des options de stockage qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Pour créer des volumes persistants provisionnés par CSI qui se montent sur ces ressources de stockage prises en charge, OpenShift Container Platform installe par défaut l'opérateur de pilote CSI nécessaire, le pilote CSI et la classe de stockage requise. Pour plus de détails sur l'espace de noms par défaut de l'opérateur et du pilote, voir la documentation de l'opérateur de pilote CSI spécifique.

Le tableau suivant décrit les pilotes CSI installés avec OpenShift Container Platform et les fonctionnalités CSI qu'ils prennent en charge, telles que les instantanés de volume, le clonage et le redimensionnement.

1.

2.

3.

Le provisionnement dynamique du stockage persistant dépend des capacités du pilote CSI et du back-end de stockage sous-jacent. Le fournisseur du pilote CSI devrait documenter la façon de créer une classe de stockage dans OpenShift Container Platform et les paramètres disponibles pour la configuration.

La classe de stockage créée peut être configurée pour permettre le provisionnement dynamique.

L'exemple suivant installe un modèle MySQL par défaut sans aucune modification du modèle.

Les créateurs de volumes utilisent le champ datasource dans une demande de volume persistant (PVC) pour créer des volumes pré-remplis.

La population de volume est actuellement activée et prise en charge en tant que fonctionnalité d'aperçu technologique. Cependant, OpenShift Container Platform n'est pas livré avec des populateurs de volume.

Pour plus d'informations sur les populateurs de volume, voir Populateurs de volume Kubernetes.

Traditionnellement, les volumes soutenus par des pilotes CSI (Container Storage Interface) ne peuvent être utilisés qu'avec une combinaison d'objets PersistentVolume et PersistentVolumeClaim.

Cette fonctionnalité vous permet de spécifier les volumes CSI directement dans la spécification Pod, plutôt que dans un objet PersistentVolume. Les volumes en ligne sont éphémères et ne persistent pas lors des redémarrages de pods.

Vous pouvez intégrer un volume éphémère en ligne CSI dans la spécification Pod dans OpenShift Container Platform. Au moment de l'exécution, les volumes en ligne imbriqués suivent le cycle de vie éphémère de leurs pods associés, de sorte que le pilote CSI gère toutes les phases des opérations de volume au fur et à mesure que les pods sont créés et détruits.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.

Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Pour partager un secret entre les espaces de noms d'un cluster, vous créez une instance de ressource personnalisée (CR) SharedSecret pour l'objet Secret que vous souhaitez partager.

Pour accéder à une instance de ressource personnalisée (CR) SharedSecret à partir d'un pod, vous accordez à un compte de service donné des autorisations RBAC pour utiliser cette instance de CR SharedSecret.

Pour partager une carte de configuration entre les espaces de noms d'un cluster, vous créez une instance de ressource personnalisée (CR) SharedConfigMap pour cette carte de configuration.

Le pilote CSI de ressources partagées présente les limitations suivantes :

Les attributs suivants affectent les volumes de pods de ressources partagées de différentes manières :

L'intégration entre les ressources partagées, Insights Operator et OpenShift Container Platform Builds facilite l'utilisation des abonnements Red Hat (droits RHEL) dans OpenShift Container Platform Builds.

Auparavant, dans OpenShift Container Platform 4.9.x et les versions antérieures, vous deviez importer manuellement vos informations d'identification et les copier dans chaque projet ou espace de noms où vous exécutiez des builds.

Désormais, dans OpenShift Container Platform 4.10 et les versions ultérieures, les Builds OpenShift Container Platform peuvent utiliser les abonnements Red Hat (droits RHEL) en référençant les ressources partagées et la fonction d'accès simple au contenu fournie par Insights Operator :

Un site snapshot représente l'état d'un volume de stockage dans un cluster à un moment donné. Les instantanés de volume peuvent être utilisés pour approvisionner un nouveau volume.

OpenShift Container Platform prend en charge par défaut les instantanés de volume de l'interface de stockage des conteneurs (CSI). Cependant, un pilote CSI spécifique est nécessaire.

Avec les instantanés de volume CSI, un administrateur de cluster peut :

Avec les instantanés de volume CSI, un développeur d'application peut :

Les points suivants doivent être pris en compte lors de l'utilisation d'instantanés de volume :

OpenShift Container Platform fournit un contrôleur d'instantané qui est déployé dans le plan de contrôle. En outre, votre fournisseur de pilote CSI fournit le sidecar d'instantané CSI sous la forme d'un conteneur d'aide qui est installé lors de l'installation du pilote CSI.

Le contrôleur d'instantanés CSI et le sidecar fournissent des instantanés de volume par le biais de l'API OpenShift Container Platform. Ces composants externes s'exécutent dans le cluster.

Le contrôleur externe est déployé par le CSI Snapshot Controller Operator.

Le CSI Snapshot Controller Operator s'exécute dans l'espace de noms openshift-cluster-storage-operator. Il est installé par défaut par l'opérateur de version de cluster (CVO) dans tous les clusters.

L'opérateur du contrôleur d'instantanés CSI installe le contrôleur d'instantanés CSI, qui s'exécute dans l'espace de noms openshift-cluster-storage-operator.

Il y a deux façons d'approvisionner les instantanés : dynamiquement et manuellement.

Lorsque vous créez un objet VolumeSnapshot, OpenShift Container Platform crée un instantané de volume.

Pour approvisionner manuellement un instantané :

Vous pouvez configurer la façon dont OpenShift Container Platform supprime les instantanés de volume.

Le contenu du CRD VolumeSnapshot peut être utilisé pour restaurer le volume existant dans un état antérieur.

After your VolumeSnapshot CRD is bound and the readyToUse value is set to true, you can use that resource to provision a new volume that is pre-populated with data from the snapshot. .Prerequisites * Logged in to a running OpenShift Container Platform cluster. * A persistent volume claim (PVC) created using a Container Storage Interface (CSI) driver that supports volume snapshots. * A storage class to provision the storage back end. * A volume snapshot has been created and is ready to use.

Un clone de volume de l'interface de stockage de conteneurs (CSI) est un duplicata d'un volume persistant existant à un moment donné.

Le clonage de volume est similaire aux instantanés de volume, mais il est plus efficace. Par exemple, un administrateur de cluster peut dupliquer un volume de cluster en créant une autre instance du volume de cluster existant.

Le clonage crée une copie exacte du volume spécifié sur le périphérique dorsal, plutôt que de créer un nouveau volume vide. Après le provisionnement dynamique, vous pouvez utiliser un clone de volume comme vous le feriez avec n'importe quel volume standard.

Aucun nouvel objet API n'est nécessaire pour le clonage. Le champ dataSource existant dans l'objet PersistentVolumeClaim est étendu de manière à pouvoir accepter le nom d'un PersistentVolumeClaim existant dans le même espace de noms.

Lorsque vous créez un objet API de réclamation de volume persistant (PVC) cloné, vous déclenchez le provisionnement d'un clone de volume CSI. Le clone est pré-rempli avec le contenu d'un autre PVC, en respectant les mêmes règles que tout autre volume persistant. La seule exception est que vous devez ajouter une adresse dataSource qui fait référence à un PVC existant dans le même espace de noms.

Les volumes qui sont provisionnés en utilisant des plugins de stockage dans l'arborescence, et qui sont pris en charge par cette fonctionnalité, sont migrés vers leurs pilotes homologues de l'interface de stockage de conteneur (CSI). Ce processus n'effectue aucune migration de données ; OpenShift Container Platform ne fait que traduire l'objet de volume persistant en mémoire. Par conséquent, l'objet de volume persistant traduit n'est pas stocké sur le disque, et son contenu n'est pas modifié.

Les pilotes d'arborescence à CSI suivants sont pris en charge :

La migration automatique de l'ICS devrait être transparente. Cette fonctionnalité ne modifie pas la façon dont vous utilisez tous les objets API existants : par exemple, PersistentVolumes, PersistentVolumeClaims, et StorageClasses.

L'activation de la migration automatique CSI pour les volumes persistants (PV) ou les réclamations de volumes persistants (PVC) dans l'arborescence ne permet pas d'activer de nouvelles fonctionnalités du pilote CSI, telles que les instantanés ou l'expansion, si le plugin de stockage dans l'arborescence d'origine ne les prenait pas en charge.

OpenShift Container Platform prend en charge la migration automatique et transparente des types de volumes in-tree suivants vers leur contrepartie de pilote Container Storage Interface (CSI) :

La migration CSI pour ces types de volumes est considérée comme généralement disponible (GA) et ne nécessite aucune intervention manuelle.

Pour les nouvelles installations d'OpenShift Container Platform 4.11 et suivantes, la classe de stockage par défaut est la classe de stockage CSI. Tous les volumes provisionnés à l'aide de cette classe de stockage sont des volumes persistants (PV) CSI.

Pour les clusters mis à niveau de la version 4.10 ou antérieure vers la version 4.11 ou ultérieure, la classe de stockage CSI est créée et devient la classe par défaut si aucune classe de stockage par défaut n'a été définie avant la mise à niveau. Dans le cas très improbable où il existe une classe de stockage portant le même nom, la classe de stockage existante reste inchangée. Toutes les classes de stockage existantes dans l'arborescence sont conservées et peuvent être nécessaires pour que certaines fonctionnalités, telles que l'extension de volume, fonctionnent pour les PV existants dans l'arborescence. Bien que le référencement de la classe de stockage au plugin de stockage dans l'arborescence continue de fonctionner, nous vous recommandons de remplacer la classe de stockage par défaut par la classe de stockage CSI.

Si vous souhaitez tester la migration Container Storage Interface (CSI) dans des clusters OpenShift Container Platform de développement ou de staging, vous devez activer manuellement la migration in-tree to CSI pour les types de volumes in-tree suivants :

Après la migration, la classe de stockage par défaut reste la classe de stockage dans l'arborescence.

La migration automatique CSI sera activée par défaut pour tous les plugins de stockage dans l'arborescence dans une prochaine version d'OpenShift Container Platform, il est donc fortement recommandé de la tester dès maintenant et de signaler tout problème.

OpenShift Container Platform est capable de provisionner des volumes persistants (PV) à l'aide du pilote Container Storage Interface (CSI) pour Alibaba AliCloud Disk Storage.

Il est recommandé de se familiariser avec le stockage persistant et la configuration des volumes CSI lorsque l'on travaille avec un opérateur et un pilote CSI.

Pour créer des PV provisionnés CSI qui se montent sur des ressources de stockage AliCloud Disk, OpenShift Container Platform installe l'opérateur AliCloud Disk CSI Driver et le pilote AliCloud Disk CSI, par défaut, dans l'espace de noms openshift-cluster-csi-drivers.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.

Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

OpenShift Container Platform est capable de provisionner des volumes persistants (PV) à l'aide du pilote Container Storage Interface (CSI) pour AWS Elastic Block Store (EBS).

Il est recommandé de se familiariser avec le stockage persistant et la configuration des volumes CSI lorsqu'on travaille avec un opérateur et un pilote d'interface de stockage de conteneurs (CSI).

Pour créer des PV provisionnés CSI qui se montent sur des ressources de stockage AWS EBS, OpenShift Container Platform installe l'opérateur AWS EBS CSI Driver et le pilote AWS EBS CSI par défaut dans l'espace de noms openshift-cluster-csi-drivers.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.

Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Pour plus d'informations sur le provisionnement dynamique des volumes persistants AWS EBS dans OpenShift Container Platform, voir Stockage persistant à l'aide d'AWS Elastic Block Store.

OpenShift Container Platform est capable de provisionner des volumes persistants (PV) à l'aide du pilote Container Storage Interface (CSI) pour AWS Elastic File Service (EFS).

Il est recommandé de se familiariser avec le stockage persistant et la configuration des volumes CSI lorsque l'on travaille avec un opérateur et un pilote CSI.

Après avoir installé l'opérateur de pilote AWS EFS CSI, OpenShift Container Platform installe l'opérateur AWS EFS CSI et le pilote AWS EFS CSI par défaut dans l'espace de noms openshift-cluster-csi-drivers. Cela permet à l'opérateur de pilote AWS EFS CSI de créer des PV provisionnées CSI qui se montent sur des actifs AWS EFS.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.

Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, les utilisateurs peuvent obtenir des volumes persistants provisionnés dynamiquement.

Le site AWS EFS CSI Driver Operator, une fois installé, ne crée pas de classe de stockage par défaut. Cependant, vous pouvez créer manuellement la classe de stockage AWS EFS.

Cette procédure explique comment créer et configurer des volumes EFS dans AWS afin de pouvoir les utiliser dans OpenShift Container Platform.

Le pilote CSI AWS EFS prend en charge une forme de provisionnement dynamique différente de celle des autres pilotes CSI. Il provisionne de nouveaux PV en tant que sous-répertoires d'un volume EFS préexistant. Les PV sont indépendantes les unes des autres. Cependant, ils partagent tous le même volume EFS. Lorsque le volume est supprimé, toutes les parties privatives provisionnées à partir de celui-ci sont également supprimées. Le pilote EFS CSI crée un point d'accès AWS pour chacun de ces sous-répertoires. En raison des limites imposées par les points d'accès AWS, vous ne pouvez provisionner dynamiquement que 1 000 PV à partir d'un seul volume StorageClass/EFS.

Si vous rencontrez des problèmes lors de la configuration du provisionnement dynamique, consultez la section Dépannage d'AWS EFS.

Il est possible d'utiliser un volume AWS EFS en tant que PV unique sans provisionnement dynamique. L'ensemble du volume est monté sur des pods.

Si vous rencontrez des problèmes lors de la configuration des PV statiques, consultez la section Dépannage d'AWS EFS.

Les informations suivantes sont importantes pour la sécurité d'AWS EFS.

Lors de l'utilisation de points d'accès, par exemple en utilisant le provisionnement dynamique comme décrit précédemment, Amazon remplace automatiquement les GID des fichiers par le GID du point d'accès. En outre, EFS prend en compte l'ID de l'utilisateur, l'ID du groupe et les ID du groupe secondaire du point d'accès lors de l'évaluation des autorisations du système de fichiers. EFS ignore les ID du client NFS. Pour plus d'informations sur les points d'accès, voir https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html.

Par conséquent, les volumes EFS ignorent silencieusement FSGroup ; OpenShift Container Platform n'est pas en mesure de remplacer les GID des fichiers sur le volume par FSGroup. Tout pod qui peut accéder à un point d'accès EFS monté peut accéder à n'importe quel fichier qui s'y trouve.

Sans rapport avec cela, le cryptage en transit est activé par défaut. Pour plus d'informations, voir https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html.

Les informations suivantes indiquent comment résoudre les problèmes liés à AWS EFS :

Tous les PV EFS sont inaccessibles après la désinstallation de AWS EFS CSI Driver Operator.

OpenShift Container Platform est capable de provisionner des volumes persistants (PV) à l'aide du pilote Container Storage Interface (CSI) pour Microsoft Azure Disk Storage.

Il est recommandé de se familiariser avec le stockage persistant et la configuration des volumes CSI lorsque l'on travaille avec un opérateur et un pilote CSI.

Pour créer des PV provisionnés CSI qui se montent sur des ressources de stockage Azure Disk, OpenShift Container Platform installe l'opérateur Azure Disk CSI Driver et le pilote Azure Disk CSI par défaut dans l'espace de noms openshift-cluster-csi-drivers.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.

Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, vous pouvez obtenir des volumes persistants provisionnés dynamiquement.

Lors de la création d'une classe de stockage, vous pouvez désigner le type de compte de stockage. Cela correspond au niveau SKU de votre compte de stockage Azure. Les options valides sont Standard_LRS, Premium_LRS, StandardSSD_LRS, UltraSSD_LRS, Premium_ZRS et StandardSSD_ZRS. Pour plus d'informations sur la recherche de votre niveau d'UGS Azure, voir Types d'UGS.

ZRS a des limitations régionales. Pour plus d'informations sur ces limitations, voir Limitations de ZRS.