Le stockage

Les pods et les conteneurs sont éphémères ou transitoires et sont conçus pour des applications apatrides. 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. En savoir plus sur l’aperçu, les types et la gestion du stockage éphémère, voir Comprendre le stockage éphémère.

Les applications étatiques déployées dans des conteneurs nécessitent un stockage persistant. Le service OpenShift Red Hat sur AWS utilise un cadre de stockage pré-prévisé appelé volumes persistants (PV) pour permettre aux administrateurs de cluster de fournir un stockage persistant. Les données à l’intérieur de ces volumes peuvent exister au-delà du cycle de vie d’une gousse individuelle. Les développeurs peuvent utiliser des claims de volume persistants (PVC) pour demander des exigences de stockage. En savoir plus sur l’aperçu, la configuration et le cycle de vie du stockage persistant, voir Comprendre le stockage persistant.

Les limites et les demandes de stockage éphémère sont mesurées en quantités d’octets. Il est possible d’exprimer le stockage en entier simple ou en tant que numéro de point fixe en utilisant l’un de ces suffixes: E, P, T, G, M, k. Il est également possible d’utiliser la puissance de deux équivalents: Ei, Pi, Ti, Gi, Mi, Ki.

Ainsi, les quantités suivantes représentent à peu près la même valeur : 128974848, 129e6, 129M et 123Mi.

Le fichier de configuration d’exemple suivant affiche un pod avec deux conteneurs:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 
      limits:
        ephemeral-storage: "4Gi" 
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 

      limits:
        ephemeral-storage: "4Gi" 

    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

Les paramètres dans la spécification de pod affectent à la fois la façon dont le planificateur prend une décision sur la planification des pods et quand kubelet expulse des pods.

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 un stockage et un PV correspondant.

Lorsque vous créez un PVC, vous demandez une quantité spécifique de stockage, spécifiez le mode d’accès requis et créez une classe de stockage pour décrire et classer le stockage. La boucle de commande dans les montres principales pour les nouveaux PVC et lie le nouveau PVC à un PV approprié. En cas d’absence d’un PV approprié, un provisionneur pour la classe de stockage en crée un.

La taille de tous les PV pourrait dépasser votre taille de PVC. Cela est particulièrement vrai avec les PV fournis manuellement. Afin de minimiser l’excès, Red Hat OpenShift Service sur AWS se lie au plus petit PV qui correspond à tous les autres critères.

Les réclamations restent illimitées si un volume correspondant n’existe pas ou ne peut pas être créé avec un fournisseur disponible desservant une classe de stockage. Les revendications sont liées au fur et à mesure que les volumes correspondants deviennent disponibles. À titre d’exemple, un cluster avec de nombreux volumes 50Gi fournis manuellement ne correspondrait pas à un PVC demandant 100Gi. Le PVC peut être lié lorsqu’un PV 100Gi est ajouté au cluster.

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

Lorsque vous avez une réclamation et que cette revendication est liée, le PV lié vous appartient aussi longtemps que vous en avez besoin. Il est possible de programmer des pods et d’accéder aux PV revendiqués en incluant persistantVolumeClaim dans le bloc volumes du pod.

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 revendication est supprimée, mais il n’est pas encore disponible pour une autre revendication. 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 faut faire avec le volume après sa sortie. La politique de récupération d’un volume peut être Retain, Recycle ou Supprimer.

Lorsqu’une revendication 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 parce que les données du précédent demandeur restent sur le volume.

Le PV récupéré est maintenant disponible pour une utilisation par un autre PVC.

Changer la politique de récupération d’un volume persistant:

Le service Red Hat OpenShift sur AWS (ROSA) prend en charge les options de stockage de volume persistantes suivantes:

Fonctions ROSA avec des provisionneurs de volume compatibles Kubernetes Container Storage Interface (CSI) d’autres fournisseurs de stockage. Consultez les volumes Configuring CSI pour plus d’informations sur les pilotes CSI en ROSA.

Généralement, un volume persistant (PV) a une capacité de stockage spécifique. Ceci est défini en utilisant l’attribut de capacité du PV.

Actuellement, la capacité de stockage est la seule ressource pouvant être définie ou demandée. Les attributs futurs peuvent inclure IOPS, le débit, et ainsi de suite.

Le volume persistant peut être monté sur un hôte de quelque manière que ce soit pris 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 sur les modes spécifiques pris en charge par ce volume particulier. À titre d’exemple, NFS peut prendre en charge plusieurs clients en lecture-écriture, mais un NFS PV spécifique peut être exporté sur le serveur en lecture seule. Chaque PV obtient son propre ensemble de modes d’accès décrivant les capacités spécifiques de ce PV.

Les revendications sont appariées à des volumes avec des modes d’accès similaires. Les deux seuls critères correspondants sont les modes d’accès et la taille. Les modes d’accès d’une revendication représentent une demande. Donc, vous pourriez être accordé plus, mais jamais moins. À titre d’exemple, si une revendication demande RWO, mais le seul volume disponible est un NFS PV (RWO+ROX+RWX), la revendication correspondrait alors à NFS parce qu’elle supporte RWO.

Les matchs directs sont toujours tentés en premier. Les modes du volume doivent correspondre ou contenir plus de modes que vous ne l’avez demandé. La taille doit être supérieure ou égale à ce qui est attendu. Lorsque deux types de volumes, tels que NFS et iSCSI, ont le même ensemble de modes d’accès, l’un d’eux peut correspondre à une revendication avec ces modes. Il n’y a pas de commande entre les types de volumes et aucun moyen de choisir un type par rapport à un autre.

Les volumes avec les mêmes modes sont regroupés, puis triés par taille, les plus petits à les plus grands. Le liant obtient le groupe avec des modes assortis et itère sur chacun, dans l’ordre de taille, jusqu’à ce qu’une taille corresponde.

Le tableau suivant répertorie les modes d’accès:

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

oc get pv <pv-name> -o json | jq '.status.lastPhaseTransitionTime'

$ oc get pv <pv-name> -o json | jq '.status.lastPhaseTransitionTime' 

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 

    - 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. Il n’y a que les PV de la classe demandée, ceux qui ont la même classe de stockage que le PVC, peuvent être liés au PVC. L’administrateur du cluster peut configurer des provisionneurs dynamiques pour desservir une ou plusieurs classes de stockage. L’administrateur du 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 explicitement demander que les annotations StorageClass ou StorageClassName définies sur «» soient liées à un PV sans classe de stockage.

Les revendications utilisent les mêmes conventions que les volumes lors de la demande de stockage avec des modes d’accès spécifiques.

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

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

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

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 

        name: mypd 

  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 

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

Avant que Red Hat OpenShift Service sur AWS monte le volume et 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 persistante du volume. Lorsque l’appareil n’est pas formaté avec le système de fichiers, toutes les données de l’appareil sont effacées et l’appareil est automatiquement formaté avec le système de fichiers donné.

Cette vérification vous permet d’utiliser des volumes AWS non formatés comme volumes persistants, car Red Hat OpenShift Service sur AWS les formate avant la première utilisation.

Le service OpenShift Red Hat sur AWS prend en charge un maximum de 39 volumes EBS attachés à un nœud. Cette limite est compatible avec les limites de volume AWS. La limite de volume dépend du type d’instance.

En ce qui concerne l’accès à des options de stockage supplémentaires, telles que des instantanés de volume, qui ne sont pas possibles avec les plug-ins de volume dans l’arbre, consultez AWS Elastic Block Store CSI Driver Operator.

La définition d’une clé KMS pour chiffrer des volumes persistants sur AWS est utile lorsque vous avez des directives de conformité et de sécurité explicites lors du déploiement sur AWS.

Les pilotes CSI sont généralement expédiés sous forme d’images de conteneur. Ces conteneurs ne sont pas au courant de Red Hat OpenShift Service sur AWS où ils s’exécutent. Afin d’utiliser l’arrière de stockage compatible CSI dans Red Hat OpenShift Service sur AWS, l’administrateur du cluster doit déployer plusieurs composants qui servent de pont entre Red Hat OpenShift Service sur AWS et le pilote de stockage.

Le diagramme suivant fournit une vue d’ensemble de haut niveau sur les composants fonctionnant en pods dans le Red Hat OpenShift Service sur AWS cluster.

View larger image

Il est possible d’exécuter plusieurs pilotes CSI pour différentes extrémités de stockage. Chaque pilote a besoin de son propre déploiement de contrôleurs externes et d’un démon défini avec le pilote et le registraire CSI.

Le service OpenShift Red Hat sur AWS installe certains pilotes CSI par défaut, offrant aux utilisateurs des options de stockage qui ne sont pas possibles avec des plugins de volume dans l’arbre.

Afin de créer des volumes persistants fournis par CSI qui s’adaptent à ces actifs de stockage pris en charge, Red Hat OpenShift Service sur AWS installe par défaut l’opérateur de pilotes CSI nécessaire, le pilote CSI et la classe de stockage requise. Consultez la documentation de l’opérateur CSI pour plus de détails sur l’espace de noms par défaut de l’opérateur et du conducteur par défaut.

Le tableau suivant décrit les pilotes CSI qui sont installés avec Red Hat OpenShift Service sur AWS et les fonctionnalités de CSI qu’ils prennent en charge, tels que les instantanés de volume et le redimensionnement.

En plus des pilotes énumérés dans le tableau suivant, ROSA fonctionne avec les pilotes CSI de fournisseurs de stockage tiers. Le Red Hat ne supervise pas les fournisseurs tiers ou les pilotes CSI connectés et les fournisseurs contrôlent entièrement le code source, le déploiement, l’exploitation et la compatibilité Kubernetes. Ces provisionneurs de volume sont considérés comme gérés par le client et les fournisseurs respectifs sont responsables de fournir un soutien. Consultez les responsabilités partagées pour Red Hat OpenShift Service sur la matrice AWS pour plus d’informations.

Le provisionnement dynamique du stockage persistant dépend des capacités du pilote CSI et de l’arrière de stockage sous-jacent. Le fournisseur du pilote CSI doit documenter comment créer une classe de stockage dans Red Hat OpenShift Service sur AWS et les paramètres disponibles pour la configuration.

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

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

La gestion de la classe de stockage par défaut vous permet d’atteindre plusieurs objectifs différents:

Afin d’atteindre ces objectifs, vous modifiez le paramètre du champ spec.storageClassState dans l’objet ClusterCSIDriver. Les paramètres possibles pour ce champ sont:

La procédure suivante permet de modifier la classe de stockage par défaut.

À titre d’exemple, si vous avez deux classes de stockage définies, gp3 et standard, et que vous souhaitez changer la classe de stockage par défaut de gp3 à standard.

Le service OpenShift Red Hat sur AWS est capable de fournir des volumes persistants (PV) à l’aide du pilote AWS EBS CSI.

La familiarité avec le stockage persistant et la configuration des volumes CSI est recommandée lorsque vous travaillez avec un opérateur et un pilote d’interface de stockage de conteneurs (CSI).

Afin de créer des PV fournis par CSI qui sont montés sur les ressources de stockage AWS EBS, Red Hat OpenShift Service sur AWS installe l’opérateur de pilotes AWS EBS CSI (un opérateur Red Hat) 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 l’implémentation de l’interface de stockage de conteneurs (CSI), les fournisseurs tiers peuvent fournir des plugins de stockage à l’aide d’une interface standard sans jamais avoir à modifier le code Kubernetes de base.

Les opérateurs CSI offrent le service OpenShift Red Hat sur les options de stockage des utilisateurs AWS, telles que des instantanés de volume, qui ne sont pas possibles avec les plugins de volume intra-arbre.

Afin d’obtenir des informations sur le provisionnement dynamique des volumes persistants AWS EBS dans Red Hat OpenShift Service sur AWS, consultez le stockage persistant à l’aide d’Amazon Elastic Block Store.

Le service OpenShift de Red Hat sur AWS est capable de fournir des volumes persistants (PV) à l’aide du pilote CSI (Container Storage Interface) pour AWS Elastic File Service (EFS).

La familiarité avec le stockage persistant et la configuration des volumes CSI est recommandée lorsque vous travaillez avec un opérateur CSI et un conducteur.

Après avoir installé l’opérateur de pilotes AWS EFS CSI, Red Hat OpenShift Service sur AWS installe le pilote AWS EFS CSI Operator et le pilote AWS EFS CSI par défaut dans l’espace de noms openshift-cluster-csi-drivers. Cela permet à AWS EFS CSI Driver Operator de créer des PV fournis par CSI qui s’adaptent aux actifs AWS EFS.

Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec l’implémentation de l’interface de stockage de conteneurs (CSI), les fournisseurs tiers peuvent fournir des plugins de stockage à l’aide d’une interface standard sans jamais avoir à modifier le code Kubernetes de base.

Les opérateurs CSI offrent le service OpenShift Red Hat sur les options de stockage des utilisateurs AWS, telles que des instantanés de volume, qui ne sont pas possibles avec les plugins de volume intra-arbre.

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

L’opérateur de pilotes AWS EFS CSI (un opérateur Red Hat), après avoir été 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 que vous puissiez les utiliser dans Red Hat OpenShift Service sur AWS.

Le pilote AWS EFS CSI prend en charge une forme de provisionnement dynamique différente de celle des autres pilotes CSI. Il prévoit les nouvelles PV en tant que sous-répertoires d’un volume EFS préexistant. Les PV sont indépendants les uns des autres. Cependant, ils partagent tous le même volume EFS. Lorsque le volume est supprimé, tous les PV mis à disposition de celui-ci sont également supprimés. Le pilote EFS CSI crée un point d’accès AWS pour chaque sous-répertoire. En raison des limites AWS AccessPoint, vous ne pouvez fournir dynamiquement 1000 PV à partir d’un seul volume StorageClass/EFS.

En cas de difficulté à configurer un provisionnement dynamique, consultez le dépannage AWS EFS.

Il est possible d’utiliser un volume Amazon Elastic File Storage (Amazon EFS) comme un seul PV sans provisionnement dynamique. L’ensemble du volume est monté sur des pods.

En cas de problème de configuration des PV statiques, consultez le dépannage AWS EFS.

Les informations suivantes sont importantes pour la sécurité Amazon Elastic File Storage (Amazon EFS).

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

En conséquence, les volumes EFS ignorent silencieusement FSGroup; Red Hat OpenShift Service sur AWS n’est pas en mesure de remplacer les GID des fichiers sur le volume par FSGroup. Chaque pod pouvant accéder à un point d’accès EFS monté peut accéder à n’importe quel fichier dessus.

En dehors de cela, le cryptage en transit est activé par défaut. Consultez https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html pour plus d’informations.

Les informations suivantes fournissent des conseils sur la façon de résoudre les problèmes avec Amazon Elastic File Storage (Amazon EFS):

Les EFS PV sont inaccessibles après avoir désinstallé AWS EFS CSI Driver Operator (un opérateur Red Hat).

La ressource suivante affiche les paramètres et les valeurs par défaut que vous utilisez pour configurer une classe de stockage. Cet exemple utilise la définition d’objet AWS ElasticBlockStore (EBS).

kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata:
  name: <storage-class-name> 
  annotations: 
    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 
parameters: 
  type: gp3
...

kind: StorageClass 

apiVersion: storage.k8s.io/v1 

metadata:
  name: <storage-class-name> 

  annotations: 

    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 

parameters: 

  type: gp3
...

Afin de définir une classe de stockage en tant que par défaut à l’échelle du cluster, ajoutez l’annotation suivante à vos métadonnées de classe de stockage:

storageclass.kubernetes.io/is-default-class: "true"

storageclass.kubernetes.io/is-default-class: "true"

À titre d’exemple:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

Cela permet à toute revendication de volume persistant (PVC) qui ne spécifie pas une classe de stockage spécifique d’être automatiquement fournie par l’intermédiaire de la classe de stockage par défaut. Cependant, votre cluster peut avoir plus d’une classe de stockage, mais un seul d’entre eux peut être la classe de stockage par défaut.

Afin de définir une description de classe de stockage, ajoutez l’annotation suivante à vos métadonnées de classe de stockage:

kubernetes.io/description: My Storage Class Description

kubernetes.io/description: My Storage Class Description

À titre d’exemple:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...