Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

5.3. Ressources partagées Opérateur de conducteur CSI

download PDF

En tant qu'administrateur de cluster, vous pouvez utiliser le pilote Shared Resource CSI dans OpenShift Container Platform pour provisionner des volumes éphémères en ligne qui contiennent le contenu des objets Secret ou ConfigMap. De cette façon, les pods et autres types Kubernetes qui exposent les montages de volumes, et les Builds OpenShift Container Platform peuvent utiliser en toute sécurité le contenu de ces objets à travers potentiellement n'importe quel espace de noms dans le cluster. Pour ce faire, il existe actuellement deux types de ressources partagées : une ressource personnalisée SharedSecret pour les objets Secret et une ressource personnalisée SharedConfigMap pour les objets ConfigMap.

Important

Le pilote CSI de ressources partagées est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Note

Pour activer le pilote CSI de ressources partagées, vous devez activer des fonctionnalités à l'aide de portes de fonctionnalités.

5.3.1. À propos du CSI

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.

5.3.2. Partager des secrets entre espaces de noms

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.

Conditions préalables

Vous devez être autorisé à effectuer les actions suivantes :

  • Créer des instances de la définition de ressource personnalisée (CRD) sharedsecrets.sharedresource.openshift.io au niveau d'un cluster.
  • Gérer les rôles et les liaisons de rôles dans les espaces de noms du cluster afin de contrôler quels utilisateurs peuvent obtenir, répertorier et surveiller ces instances.
  • Gérez les rôles et les liaisons de rôles pour contrôler si le compte de service spécifié par un pod peut monter un volume CSI (Container Storage Interface) qui fait référence à l'instance SharedSecret CR que vous souhaitez utiliser.
  • Accédez aux espaces de noms qui contiennent les Secrets que vous souhaitez partager.

Procédure

  • Créez une instance SharedSecret CR pour l'objet Secret que vous souhaitez partager entre les espaces de noms du cluster : 

    $ oc apply -f - <<EOF
apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedSecret
metadata:
  name: my-share
spec:
  secretRef:
    name: <name of secret>
    namespace: <namespace of secret>
EOF

5.3.3. Utilisation d'une instance de SharedSecret dans un pod

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.

Conditions préalables

  • Vous avez créé une instance SharedSecret CR pour le secret que vous souhaitez partager entre les espaces de noms du cluster.

  • Vous devez être autorisé à effectuer les actions suivantes

    • Créer des configurations de construction et démarrer des constructions.
    • Découvrez quelles instances de SharedSecret CR sont disponibles en entrant la commande oc get sharedsecrets et en obtenant une liste non vide en retour.
    • Déterminez si les comptes de service builder dont vous disposez dans votre espace de noms sont autorisés à utiliser l'instance de CR SharedSecret donnée. En d'autres termes, vous pouvez exécuter oc adm policy who-can use <identifier of specific SharedSecret> pour voir si le compte de service builder de votre espace de noms est répertorié.
Note

Si aucune des deux dernières conditions préalables de cette liste n'est remplie, créez, ou demandez à quelqu'un de créer, le contrôle d'accès basé sur les rôles (RBAC) nécessaire pour découvrir les instances de SharedSecret CR et permettre aux comptes de service d'utiliser les instances de SharedSecret CR.

Procédure

  1. Accorder à un compte de service donné des autorisations RBAC pour utiliser l'instance SharedSecret CR dans son pod en utilisant oc apply avec un contenu YAML :

    Note

    Actuellement, kubectl et oc ont une logique de cas spécial codée en dur qui limite le verbe use aux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliser oc create role …​ pour créer le rôle nécessaire à la consommation des instances CR SharedSecret. 

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. Créez le site RoleBinding associé au rôle en utilisant la commande oc: 

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. Accéder à l'instance SharedSecret CR à partir d'un pod : 

    $ oc apply -f - <<EOF
kind: Pod
apiVersion: v1
metadata:
  name: my-app
  namespace: my-namespace
spec:
  serviceAccountName: default

# containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume

    volumes:
    - name: my-csi-volume
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedSecret: my-share

EOF

5.3.4. Partage d'une carte de configuration entre espaces de noms

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.

Conditions préalables

Vous devez être autorisé à effectuer les actions suivantes :

  • Créer des instances de la définition de ressource personnalisée (CRD) sharedconfigmaps.sharedresource.openshift.io au niveau d'un cluster.
  • Gérer les rôles et les liaisons de rôles dans les espaces de noms du cluster afin de contrôler quels utilisateurs peuvent obtenir, répertorier et surveiller ces instances.
  • Gérez les rôles et les liaisons de rôles dans les espaces de noms du cluster pour contrôler quels comptes de service dans les pods qui montent votre volume CSI (Container Storage Interface) peuvent utiliser ces instances.
  • Accédez aux espaces de noms qui contiennent les Secrets que vous souhaitez partager.

Procédure

  1. Créez une instance CR SharedConfigMap pour la carte de configuration que vous souhaitez partager entre les espaces de noms du cluster : 

    $ oc apply -f - <<EOF
apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedConfigMap
metadata:
  name: my-share
spec:
  configMapRef:
    name: <name of configmap>
    namespace: <namespace of configmap>
EOF

5.3.5. Utilisation d'une instance de SharedConfigMap dans un pod

Prochaines étapes

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

Conditions préalables

  • Vous avez créé une instance SharedConfigMap CR pour la carte de configuration que vous souhaitez partager entre les espaces de noms du cluster.

  • Vous devez être autorisé à effectuer les actions suivantes :

    • Créer des configurations de construction et démarrer des constructions.
    • Découvrez quelles instances de SharedConfigMap CR sont disponibles en entrant la commande oc get sharedconfigmaps et en obtenant une liste non vide en retour.
    • Déterminez si les comptes de service builder dont vous disposez dans votre espace de noms sont autorisés à utiliser l'instance de CR SharedSecret donnée. En d'autres termes, vous pouvez exécuter oc adm policy who-can use <identifier of specific SharedSecret> pour voir si le compte de service builder de votre espace de noms est répertorié.
Note

Si aucune des deux dernières conditions préalables de cette liste n'est remplie, créez, ou demandez à quelqu'un de créer, le contrôle d'accès basé sur les rôles (RBAC) nécessaire pour découvrir les instances de SharedConfigMap CR et permettre aux comptes de service d'utiliser les instances de SharedConfigMap CR.

Procédure

  1. Accorder à un compte de service donné des autorisations RBAC pour utiliser l'instance SharedConfigMap CR dans son pod en utilisant oc apply avec un contenu YAML.

    Note

    Actuellement, kubectl et oc ont une logique de cas spécial codée en dur qui limite le verbe use aux rôles centrés sur la sécurité des pods. Par conséquent, vous ne pouvez pas utiliser oc create role …​ pour créer le rôle nécessaire à la consommation d'une instance CR SharedConfigMap. 

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedconfigmaps
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. Créez le site RoleBinding associé au rôle en utilisant la commande oc: 

    oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. Accéder à l'instance SharedConfigMap CR à partir d'un pod : 

    $ oc apply -f - <<EOF
kind: Pod
apiVersion: v1
metadata:
  name: my-app
  namespace: my-namespace
spec:
  serviceAccountName: default

# containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume

    volumes:
    - name: my-csi-volume
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedConfigMap: my-share

EOF

5.3.6. Limitations supplémentaires du support pour le pilote CSI de ressources partagées

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

  • Le pilote est soumis aux limitations des volumes éphémères en ligne de l'interface de stockage de conteneurs (CSI).
  • La valeur du champ readOnly doit être true. Sinon, lors du provisionnement du volume pendant le démarrage du pod, le pilote renvoie une erreur au kubelet. Cette limitation est conforme aux meilleures pratiques proposées pour le pilote CSI Kubernetes en amont afin d'appliquer les étiquettes SELinux aux volumes associés.
  • Le pilote ignore le champ FSType car il ne prend en charge que les volumes tmpfs.
  • Le pilote ignore le champ NodePublishSecretRef. En revanche, il utilise SubjectAccessReviews avec le verbe use pour déterminer si un pod peut obtenir un volume contenant des instances de ressources personnalisées (CR) SharedSecret ou SharedConfigMap.

5.3.7. Détails supplémentaires concernant les VolumeAttributes sur les volumes de pods de ressources partagées

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

  • L'attribut refreshResource dans les propriétés volumeAttributes.
  • L'attribut refreshResources dans la configuration du pilote CSI de ressources partagées.
  • Les attributs sharedSecret et sharedConfigMap dans les propriétés volumeAttributes.

5.3.7.1. L'attribut refreshResource

Le pilote CSI de ressources partagées respecte l'attribut refreshResource dans les propriétés volumeAttributes du volume. Cet attribut détermine si les mises à jour du contenu de l'objet sous-jacent Secret ou ConfigMap sont copiées sur le volume after. Le volume est initialement provisionné dans le cadre du démarrage du pod. La valeur par défaut de refreshResource est true, ce qui signifie que le contenu est mis à jour.

Important

Si la configuration du pilote CSI pour les ressources partagées a désactivé le rafraîchissement des instances de ressources personnalisées (CR) partagées SharedSecret et SharedConfigMap, l'attribut refreshResource dans les propriétés volumeAttribute n'a aucun effet. L'objectif de cet attribut est de désactiver le rafraîchissement pour des montages de volumes spécifiques lorsque le rafraîchissement est généralement autorisé.

5.3.7.2. L'attribut refreshResources

Vous pouvez utiliser un commutateur global pour activer ou désactiver le rafraîchissement des ressources partagées. Ce commutateur est l'attribut refreshResources dans la carte de configuration csi-driver-shared-resource-config pour le pilote CSI de ressources partagées, que vous pouvez trouver dans l'espace de noms openshift-cluster-csi-drivers. Si vous donnez à cet attribut refreshResources la valeur false, aucun des contenus liés aux objets Secret ou ConfigMap stockés dans le volume n'est mis à jour après le provisionnement initial du volume.

Important

L'utilisation de cette configuration du Shared Resource CSI Driver pour désactiver le rafraîchissement affecte tous les montages de volumes de la grappe qui utilisent le Shared Resource CSI Driver, indépendamment de l'attribut refreshResource dans les propriétés volumeAttributes de l'un de ces volumes.

5.3.7.3. Validation des volumeAttributes avant le provisionnement d'un volume de ressources partagées pour un pod

Dans le volumeAttributes d'un volume unique, vous devez définir un attribut sharedSecret ou sharedConfigMap à la valeur d'une instance SharedSecret ou SharedConfigMap CS. Sinon, lorsque le volume est provisionné pendant le démarrage du pod, une validation vérifie le volumeAttributes de ce volume et renvoie une erreur au kubelet dans les conditions suivantes :

  • Les attributs sharedSecret et sharedConfigMap ont tous deux des valeurs spécifiées.
  • Les attributs sharedSecret et sharedConfigMap n'ont pas de valeurs spécifiées.
  • La valeur de l'attribut sharedSecret ou sharedConfigMap ne correspond pas au nom d'une instance CR SharedSecret ou SharedConfigMap sur le cluster.

5.3.8. Intégration entre les ressources partagées, Insights Operator et OpenShift Container Platform Builds

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 :

  • La fonction d'accès simple au contenu importe vos identifiants d'abonnement dans un objet Secret bien connu. Voir les liens dans la section suivante "Ressources supplémentaires".
  • L'administrateur du cluster crée une instance de ressource personnalisée (CR) SharedSecret autour de cet objet Secret et accorde des autorisations à des projets ou espaces de noms particuliers. En particulier, l'administrateur du cluster donne au compte de service builder la permission d'utiliser cette instance CR SharedSecret.
  • Les constructions qui s'exécutent dans ces projets ou espaces de noms peuvent monter un volume CSI qui fait référence à l'instance SharedSecret CR et à son contenu RHEL.

Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.