Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

7.4. Cartographie des volumes à l’aide de volumes projetés

Le volume projeté cartographie plusieurs sources de volume existantes dans le même répertoire.

Les types de sources de volume suivants peuvent être projetés:

  • Les secrets
  • Configuration des cartes
  • API descendante
Note

Il faut que toutes les sources soient dans le même espace de noms que le pod.

7.4.1. Comprendre les volumes projetés
Copier lien

Les volumes projetés peuvent cartographier n’importe quelle combinaison de ces sources de volume en un seul répertoire, permettant à l’utilisateur de:

  • installer automatiquement un seul volume avec les clés de plusieurs secrets, configurer des cartes et avec des informations API descendantes, de sorte que je puisse synthétiser un seul répertoire avec diverses sources d’information;
  • remplissez un seul volume avec les clés de plusieurs secrets, configurez des cartes et avec des informations API descendantes, spécifiant explicitement les chemins pour chaque élément, afin que je puisse avoir un contrôle total sur le contenu de ce volume.
Important

Lorsque l’autorisation RunAsUser est définie dans le contexte de sécurité d’une pod basée sur Linux, les fichiers projetés ont les autorisations correctes, y compris la propriété de l’utilisateur du conteneur. Cependant, lorsque l’autorisation RunAsUsername de Windows est définie dans un pod Windows, le kubelet est incapable de définir correctement la propriété sur les fichiers dans le volume projeté.

En conséquence, l’autorisation RunAsUsername définie dans le contexte de sécurité d’un pod Windows n’est pas honorée pour les volumes projetés Windows s’exécutant dans OpenShift Dedicated.

Les scénarios généraux suivants montrent comment vous pouvez utiliser les volumes projetés.

Configurez la carte, les secrets, l’API Downward.
Les volumes projetés vous permettent de déployer des conteneurs avec des données de configuration qui incluent des mots de passe. L’application utilisant ces ressources pourrait être le déploiement de Red Hat OpenStack Platform (RHOSP) sur Kubernetes. Les données de configuration peuvent devoir être assemblées différemment selon que les services seront utilisés pour la production ou pour les tests. Lorsqu’un pod est étiqueté avec la production ou le test, le sélecteur d’API vers le bas métadonnées.labels peut être utilisé pour produire les configurations RHOSP correctes.
Configurez la carte + secrets.
Les volumes projetés vous permettent de déployer des conteneurs impliquant des données de configuration et des mots de passe. À titre d’exemple, vous pouvez exécuter une carte de configuration avec certaines tâches cryptées sensibles qui sont décryptées à l’aide d’un fichier de mot de passe voûte.
ConfigMap + API vers le bas.
Les volumes projetés vous permettent de générer une configuration incluant le nom du pod (disponible via le sélecteur métadonnées.name). Cette application peut ensuite passer le nom de la pod avec des requêtes pour déterminer facilement la source sans utiliser le suivi IP.
Les secrets + l’API Downward.
Les volumes projetés vous permettent d’utiliser un secret comme clé publique pour chiffrer l’espace de noms de la pod (disponible via le sélecteur métadonnées.namespace). Cet exemple permet à l’opérateur d’utiliser l’application pour fournir les informations de l’espace de noms en toute sécurité sans utiliser un transport crypté.

7.4.1.1. Exemple Pod specs
Copier lien

Ce qui suit sont des exemples de spécifications Pod pour créer des volumes projetés.

Dose avec un secret, une API Downward et une carte de configuration

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
1 

    - name: all-in-one
      mountPath: "/projected-volume"
2 

      readOnly: true
3 

    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
4 

  - name: all-in-one
5 

    projected:
      defaultMode: 0400
6 

      sources:
      - secret:
          name: mysecret
7 

          items:
            - key: username
              path: my-group/my-username
8 

      - downwardAPI:
9 

          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
10 

          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config
              mode: 0777
11

1
Ajoutez une section volumeMounts pour chaque conteneur qui a besoin du secret.
2
Indiquez un chemin vers un répertoire inutilisé où le secret apparaîtra.
3
Définir readOnly sur true.
4
Ajoutez un bloc de volumes pour énumérer chaque source de volume projetée.
5
Indiquez n’importe quel nom pour le volume.
6
Définissez l’autorisation d’exécution sur les fichiers.
7
Ajoutez un secret. Entrez le nom de l’objet secret. Chaque secret que vous souhaitez utiliser doit être répertorié.
8
Indiquez le chemin vers le fichier secret sous le MountPath. Ici, le fichier secret est dans /projected-volume/my-group/my-username.
9
Ajoutez une source d’API vers le bas.
10
Ajoutez une source ConfigMap.
11
Définir le mode de projection spécifique
Note

Lorsqu’il y a plusieurs conteneurs dans la gousse, chaque conteneur a besoin d’une section volumeMounts, mais une seule section de volume est nécessaire.

Dose avec plusieurs secrets avec un mode d’autorisation non par défaut

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: all-in-one
    projected:
      defaultMode: 0755
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

Note

Le mode par défaut ne peut être spécifié qu’au niveau prévu et non pour chaque source de volume. Cependant, comme illustré ci-dessus, vous pouvez définir explicitement le mode de chaque projection individuelle.

7.4.1.2. Considérations de cheminement
Copier lien

Collisions entre les clés lorsque les chemins configurés sont identiques

Lorsque vous configurez des touches avec le même chemin, le pod spec ne sera pas accepté comme valide. Dans l’exemple suivant, le chemin spécifié pour mysecret et myconfigmap sont les mêmes: 

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/data
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/data

Considérez les situations suivantes liées aux chemins de fichiers de volume.

Collisions entre les clés sans parcours configurés
La seule validation d’exécution qui peut se produire est lorsque tous les chemins sont connus à la création de pod, similaire au scénario ci-dessus. Dans le cas contraire, lorsqu’un conflit se produit, la ressource spécifiée la plus récente écrasera tout ce qui précède (cela est vrai pour les ressources qui sont mises à jour après la création de pod).
Collisions quand un chemin est explicite et l’autre est projeté automatiquement
Dans le cas d’une collision due à un utilisateur spécifié des données de correspondance de chemin qui est automatiquement projetée, cette dernière ressource écrasera tout ce qui précède comme avant.

7.4.2. Configuration d’un volume projeté pour un Pod
Copier lien

Lors de la création de volumes projetés, considérez les situations de chemin de fichier de volume décrites dans Comprendre les volumes projetés.

L’exemple suivant montre comment utiliser un volume projeté pour monter une source de volume secrète existante. Les étapes peuvent être utilisées pour créer un nom d’utilisateur et des secrets de mot de passe à partir de fichiers locaux. Ensuite, vous créez un pod qui exécute un conteneur, en utilisant un volume projeté pour monter les secrets dans le même répertoire partagé.

Le nom d’utilisateur et les valeurs de mot de passe peuvent être n’importe quelle chaîne valide qui est encodée base64.

L’exemple suivant montre admin en base64: 

$ echo -n "admin" | base64

Exemple de sortie

YWRtaW4=

L’exemple suivant montre le mot de passe 1f2d1e2e67df en base64: 

$ echo -n "1f2d1e2e67df" | base64

Exemple de sortie

MWYyZDFlMmU2N2Rm

Procédure

D’utiliser un volume projeté pour monter une source de volume secrète existante.

  1. Créer le secret:

    1. Créez un fichier YAML similaire à ce qui suit, en remplaçant le mot de passe et les informations d’utilisateur selon le cas: 

      apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=

    2. Faites appel à la commande suivante pour créer le secret: 

      $ oc create -f <secrets-filename>

      À titre d’exemple: 

      $ oc create -f secret.yaml

      Exemple de sortie

      secret "mysecret" created

    3. Il est possible de vérifier que le secret a été créé à l’aide des commandes suivantes: 

      $ oc get secret <secret-name>

      À titre d’exemple: 

      $ oc get secret mysecret

      Exemple de sortie

      NAME       TYPE      DATA      AGE
mysecret   Opaque    2         17h
       

      $ oc get secret <secret-name> -o yaml

      À titre d’exemple: 

      $ oc get secret mysecret -o yaml
       
      apiVersion: v1
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2017-05-30T20:21:38Z
  name: mysecret
  namespace: default
  resourceVersion: "2107"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 959e0424-4575-11e7-9f97-fa163e4bd54c
type: Opaque

  2. Créez un pod avec un volume projeté.

    1. Créez un fichier YAML similaire à ce qui suit, y compris une section des volumes: 

      kind: Pod
metadata:
  name: test-projected-volume
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test-projected-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
      1
      1
      Le nom du secret que vous avez créé.

    2. Créer le pod à partir du fichier de configuration: 

      $ oc create -f <your_yaml_file>.yaml

      À titre d’exemple: 

      $ oc create -f secret-pod.yaml

      Exemple de sortie

      pod "test-projected-volume" created

  3. Assurez-vous que le conteneur de la gousse est en cours d’exécution, puis surveillez les modifications apportées à la gousse: 

    $ oc get pod <name>

    À titre d’exemple: 

    $ oc get pod test-projected-volume

    Le produit devrait apparaître comme suit:

    Exemple de sortie

    NAME                    READY     STATUS    RESTARTS   AGE
test-projected-volume   1/1       Running   0          14s

  4. Dans un autre terminal, utilisez la commande oc exec pour ouvrir un shell au conteneur en cours d’exécution: 

    $ oc exec -it <pod> <command>

    À titre d’exemple: 

    $ oc exec -it test-projected-volume -- /bin/sh

  5. Dans votre shell, vérifiez que le répertoire des volumes projetés contient vos sources projetées: 

    / # ls

    Exemple de sortie

    bin               home              root              tmp
dev               proc              run               usr
etc               projected-volume  sys               var

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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2026 Red HatRetour au début