SupportConsoleDéveloppeursCommencer un essaiContact

6.4. Cartographie des volumes à l'aide des volumes projetés

Un site projected volume met en correspondance plusieurs sources de volume existantes dans le même répertoire.

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

  • Secrets
  • Cartes de configuration
  • API vers le bas
Note

Toutes les sources doivent se trouver dans le même espace de noms que le module.

6.4.1. Comprendre les volumes prévus

Les volumes projetés peuvent représenter n'importe quelle combinaison de ces sources de volume dans un seul répertoire, ce qui permet à l'utilisateur de.. :

  • remplir automatiquement un seul volume avec les clés de plusieurs secrets, les cartes de configuration et les informations de l'API descendante, afin que je puisse synthétiser un seul répertoire avec diverses sources d'informations ;
  • remplir un seul volume avec les clés de plusieurs secrets, les cartes de configuration et les informations de l'API descendante, en spécifiant explicitement les chemins pour chaque élément, de sorte 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'un pod basé sur Linux, les fichiers projetés ont les autorisations correctes, y compris la propriété de l'utilisateur du conteneur. Toutefois, lorsque l'autorisation équivalente de Windows, RunAsUsername, est définie dans un module Windows, le kubelet n'est pas en mesure de définir correctement la propriété des fichiers du volume projeté.

Par conséquent, 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 fonctionnant dans OpenShift Container Platform.

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

Config map, secrets, Downward API.
Les volumes projetés vous permettent de déployer des conteneurs avec des données de configuration comprenant des mots de passe. Une application utilisant ces ressources pourrait déployer 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. Si un pod est étiqueté comme production ou test, le sélecteur d'API descendant metadata.labels peut être utilisé pour produire les configurations RHOSP correctes.
Config map secrets.
Les volumes projetés vous permettent de déployer des conteneurs contenant des données de configuration et des mots de passe. Par exemple, vous pouvez exécuter une carte de configuration avec des tâches sensibles cryptées qui sont décryptées à l'aide d'un fichier de mots de passe du coffre-fort.
ConfigMap Downward API.
Les volumes projetés vous permettent de générer une configuration comprenant le nom du pod (disponible via le sélecteur metadata.name ). Cette application peut alors transmettre le nom du pod avec les requêtes afin de déterminer facilement la source sans utiliser le suivi des adresses IP.
Secrets Downward API.
Les volumes projetés vous permettent d'utiliser un secret comme clé publique pour crypter l'espace de noms du pod (disponible via le sélecteur metadata.namespace ). Cet exemple permet à l'opérateur d'utiliser l'application pour fournir les informations sur l'espace de noms en toute sécurité sans utiliser de transport crypté.

6.4.1.1. Exemple de spécifications d'un pod

Voici des exemples de spécifications Pod pour la création de volumes prévisionnels.

Pod avec un secret, une API descendante et une carte de configuration

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts: 1
    - name: all-in-one
      mountPath: "/projected-volume"2
      readOnly: true 3
  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 le chemin d'accès à un répertoire inutilisé dans lequel le secret apparaîtra.
3
Définir readOnly à true.
4
Ajouter un bloc volumes pour énumérer chaque source de volume projeté.
5
Indiquez un nom quelconque pour le volume.
6
Définir l'autorisation d'exécution sur les fichiers.
7
Ajouter un secret. Saisissez le nom de l'objet secret. Chaque secret que vous souhaitez utiliser doit être répertorié.
8
Indiquez le chemin d'accès au fichier des secrets sous mountPath. Ici, le fichier des secrets se trouve dans /projected-volume/my-group/my-username.
9
Ajouter une source API descendante.
10
Ajouter une source ConfigMap.
11
Régler le mode pour la projection spécifique
Note

S'il y a plusieurs conteneurs dans le module, chaque conteneur a besoin d'une section volumeMounts, mais une seule section volumes est nécessaire.

Pod avec plusieurs secrets dont le mode d'autorisation n'est pas par défaut

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  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 defaultMode ne peut être spécifié qu'au niveau de la projection et non pour chaque source de volume. Cependant, comme illustré ci-dessus, vous pouvez explicitement définir le mode pour chaque projection individuelle.

6.4.1.2. Considérations sur le cheminement

Collisions Between Keys when Configured Paths are Identical

Si vous configurez des clés avec le même chemin d'accès, la spécification du pod ne sera pas acceptée comme valide. Dans l'exemple suivant, le chemin spécifié pour mysecret et myconfigmap est le même : 

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  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

Examinez les situations suivantes relatives aux chemins d'accès aux fichiers de volume.

Collisions Between Keys without Configured Paths
La seule validation en cours d'exécution possible est lorsque tous les chemins sont connus lors de la création du module, comme dans le scénario ci-dessus. Sinon, en cas de conflit, la ressource spécifiée la plus récente écrase tout ce qui la précède (cela vaut également pour les ressources mises à jour après la création du module).
Collisions when One Path is Explicit and the Other is Automatically Projected
En cas de collision due à la correspondance entre un chemin spécifié par l'utilisateur et des données projetées automatiquement, cette dernière ressource écrasera tout ce qui la précède, comme auparavant

6.4.2. Configuration d'un volume projeté pour un pod

Lors de la création de volumes projetés, tenez compte des situations de chemin de fichier de volume décrites à l'adresse Understanding projected volumes.

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

Procédure

Pour utiliser un volume projeté afin de monter une source de volume secrète existante.

  1. Créez des fichiers contenant les secrets, en saisissant ce qui suit, en remplaçant le mot de passe et les informations relatives à l'utilisateur, le cas échéant : 

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

    Les valeurs user et pass peuvent être n'importe quelle chaîne de caractères valide codé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

  2. Utilisez la commande suivante pour créer les secrets : 

    $ oc create -f <secrets-filename>

    Par exemple : 

    $ oc create -f secret.yaml

    Exemple de sortie

    secret "mysecret" created

  3. Vous pouvez vérifier que le secret a été créé à l'aide des commandes suivantes : 

    $ oc get secret <secret-name>

    Par exemple : 

    $ oc get secret mysecret

    Exemple de sortie

    NAME       TYPE      DATA      AGE
mysecret   Opaque    2         17h

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

    Par 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

  4. Créez un fichier de configuration de pod similaire au suivant qui inclut une section volumes: 

    apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:      1
          name: user
      - secret:      2
          name: pass
    1 2
    Le nom du secret que vous avez créé.

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

    oc create -f <votre_fichier_yaml_>.yaml

    Par exemple : 

    $ oc create -f secret-pod.yaml

    Exemple de sortie

    pod "test-projected-volume" created

  6. Vérifiez que le conteneur de pods est en cours d'exécution, puis surveillez les modifications apportées au pod : 

    $ oc get pod <name>

    Par exemple : 

    $ oc get pod test-projected-volume

    Le résultat devrait ressembler à ce qui suit :

    Exemple de sortie

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

  7. Dans un autre terminal, utilisez la commande oc exec pour ouvrir un shell sur le conteneur en cours d'exécution : 

    oc exec -it <pod> <command> $ oc exec -it <pod> <command>

    Par exemple : 

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

  8. Dans votre shell, vérifiez que le répertoire projected-volumes contient les 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.

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.