7.5. Autoriser les conteneurs à consommer des objets API


L’API Downward est un mécanisme qui permet aux conteneurs de consommer des informations sur les objets API sans couplage à Red Hat OpenShift Service sur AWS. Ces informations incluent le nom, l’espace de noms et les valeurs de ressource du pod. Les conteneurs peuvent consommer des informations à partir de l’API descendante à l’aide de variables d’environnement ou d’un plugin de volume.

L’API Downward contient des informations telles que le nom, le projet et les valeurs de ressources du pod. Les conteneurs peuvent consommer des informations à partir de l’API descendante à l’aide de variables d’environnement ou d’un plugin de volume.

Les champs dans le pod sont sélectionnés à l’aide du type d’API FieldRef. FieldRef a deux champs:

Expand
Le champDescription

FieldPath

Le chemin du champ à sélectionner, par rapport au pod.

apiVersion

La version API pour interpréter le sélecteur fieldPath à l’intérieur.

Actuellement, les sélecteurs valides dans l’API v1 incluent:

Expand
Le sélecteurDescription

les métadonnées.name

Le nom de la gousse. Ceci est pris en charge tant dans les variables d’environnement que dans les volumes.

espace de métadonnées.nam

L’espace de nom du pod.This est pris en charge dans les variables d’environnement et les volumes.

les métadonnées.labels

Les étiquettes de la gousse. Cela n’est pris en charge que dans les volumes et non dans les variables d’environnement.

les métadonnées.annotations

Les annotations de la gousse. Cela n’est pris en charge que dans les volumes et non dans les variables d’environnement.

État.podIP

L’IP de la gousse. Ceci n’est pris en charge que dans les variables d’environnement et non dans les volumes.

Le champ apiVersion, s’il n’est pas spécifié, par défaut, par défaut, par défaut à la version API du modèle de pod enclosing.

Les conteneurs peuvent consommer des valeurs API à l’aide de variables d’environnement ou d’un plugin de volume. En fonction de la méthode que vous choisissez, les conteneurs peuvent consommer:

  • Le nom du pod
  • Le projet Pod/namespace
  • Annotations de pod
  • Étiquettes de pod

Les annotations et les étiquettes sont disponibles en utilisant uniquement un plugin de volume.

Lorsque vous utilisez les variables d’environnement d’un conteneur, utilisez la valeur du type EnvVar du champ (de type EnvVarSource) pour spécifier que la valeur de la variable devrait provenir d’une source FieldRef au lieu de la valeur littérale spécifiée par le champ de valeur.

Les attributs constants de la gousse peuvent être consommés de cette façon, car les variables d’environnement ne peuvent pas être mises à jour une fois qu’un processus est lancé d’une manière qui permet au processus d’être informé que la valeur d’une variable a changé. Les champs pris en charge à l’aide de variables d’environnement sont:

  • Le nom du pod
  • Le projet Pod/namespace

Procédure

  1. Créez une nouvelle spécification de pod qui contient les variables d’environnement que vous souhaitez que le conteneur consomme:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: env-test-container
            image: gcr.io/google_containers/busybox
            command: [ "/bin/sh", "-c", "env" ]
            env:
              - name: MY_POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: MY_POD_NAMESPACE
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.namespace
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        restartPolicy: Never
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur pour les valeurs MY_POD_NAME et MY_POD_NAMESPACE:

    $ oc logs -p dapi-env-test-pod
    Copy to Clipboard Toggle word wrap

Les conteneurs peuvent consommer des valeurs API à l’aide d’un plugin de volume.

Les conteneurs peuvent consommer:

  • Le nom du pod
  • Le projet Pod/namespace
  • Annotations de pod
  • Étiquettes de pod

Procédure

D’utiliser le plugin de volume:

  1. Créez une nouvelle spécification de pod qui contient les variables d’environnement que vous souhaitez que le conteneur consomme:

    1. Créez un fichier volume-pod.yaml similaire à ce qui suit:

      kind: Pod
      apiVersion: v1
      metadata:
        labels:
          zone: us-east-coast
          cluster: downward-api-test-cluster1
          rack: rack-123
        name: dapi-volume-test-pod
        annotations:
          annotation1: "345"
          annotation2: "456"
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: volume-test-container
            image: gcr.io/google_containers/busybox
            command: ["sh", "-c", "cat /tmp/etc/pod_labels /tmp/etc/pod_annotations"]
            volumeMounts:
              - name: podinfo
                mountPath: /tmp/etc
                readOnly: false
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        volumes:
        - name: podinfo
          downwardAPI:
            defaultMode: 420
            items:
            - fieldRef:
                fieldPath: metadata.name
              path: pod_name
            - fieldRef:
                fieldPath: metadata.namespace
              path: pod_namespace
            - fieldRef:
                fieldPath: metadata.labels
              path: pod_labels
            - fieldRef:
                fieldPath: metadata.annotations
              path: pod_annotations
        restartPolicy: Never
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créez le pod à partir du fichier volume-pod.yaml:

      $ oc create -f volume-pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur et vérifiez la présence des champs configurés:

    $ oc logs -p dapi-volume-test-pod
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    cluster=downward-api-test-cluster1
    rack=rack-123
    zone=us-east-coast
    annotation1=345
    annotation2=456
    kubernetes.io/config.source=api
    Copy to Clipboard Toggle word wrap

Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites afin que les auteurs d’images et d’applications puissent créer correctement une image pour des environnements spécifiques.

Il est possible de le faire à l’aide d’une variable d’environnement ou d’un plugin de volume.

Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites à l’aide de variables d’environnement.

Lors de la création de la configuration de pod, spécifiez les variables d’environnement qui correspondent au contenu du champ ressources dans le champ spec.container.

Note

Dans le cas où les limites de ressources ne sont pas incluses dans la configuration du conteneur, l’API descendante par défaut vers le CPU du nœud et les valeurs allocatables de mémoire.

Procédure

  1. Créez une nouvelle spécification de pod qui contient les ressources que vous souhaitez injecter:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        containers:
          - name: test-container
            image: gcr.io/google_containers/busybox:1.24
            command: [ "/bin/sh", "-c", "env" ]
            resources:
              requests:
                memory: "32Mi"
                cpu: "125m"
              limits:
                memory: "64Mi"
                cpu: "250m"
            env:
              - name: MY_CPU_REQUEST
                valueFrom:
                  resourceFieldRef:
                    resource: requests.cpu
              - name: MY_CPU_LIMIT
                valueFrom:
                  resourceFieldRef:
                    resource: limits.cpu
              - name: MY_MEM_REQUEST
                valueFrom:
                  resourceFieldRef:
                    resource: requests.memory
              - name: MY_MEM_LIMIT
                valueFrom:
                  resourceFieldRef:
                    resource: limits.memory
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites à l’aide d’un plugin de volume.

Lors de la création de la configuration de pod, utilisez le champ spec.volumes.downwardAPI.items pour décrire les ressources souhaitées qui correspondent au champ spec.resources.

Note

Dans le cas où les limites de ressources ne sont pas incluses dans la configuration du conteneur, l’API Downward par défaut sur le CPU du nœud et les valeurs allocatables de mémoire.

Procédure

  1. Créez une nouvelle spécification de pod qui contient les ressources que vous souhaitez injecter:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        containers:
          - name: client-container
            image: gcr.io/google_containers/busybox:1.24
            command: ["sh", "-c", "while true; do echo; if [[ -e /etc/cpu_limit ]]; then cat /etc/cpu_limit; fi; if [[ -e /etc/cpu_request ]]; then cat /etc/cpu_request; fi; if [[ -e /etc/mem_limit ]]; then cat /etc/mem_limit; fi; if [[ -e /etc/mem_request ]]; then cat /etc/mem_request; fi; sleep 5; done"]
            resources:
              requests:
                memory: "32Mi"
                cpu: "125m"
              limits:
                memory: "64Mi"
                cpu: "250m"
            volumeMounts:
              - name: podinfo
                mountPath: /etc
                readOnly: false
        volumes:
          - name: podinfo
            downwardAPI:
              items:
                - path: "cpu_limit"
                  resourceFieldRef:
                    containerName: client-container
                    resource: limits.cpu
                - path: "cpu_request"
                  resourceFieldRef:
                    containerName: client-container
                    resource: requests.cpu
                - path: "mem_limit"
                  resourceFieldRef:
                    containerName: client-container
                    resource: limits.memory
                - path: "mem_request"
                  resourceFieldRef:
                    containerName: client-container
                    resource: requests.memory
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créez le pod à partir du fichier volume-pod.yaml:

      $ oc create -f volume-pod.yaml
      Copy to Clipboard Toggle word wrap

7.5.4. Consommer des secrets à l’aide de l’API Downward

Lors de la création de pods, vous pouvez utiliser l’API descendante pour injecter des secrets afin que les auteurs d’images et d’applications puissent créer une image pour des environnements spécifiques.

Procédure

  1. Créer un secret à injecter:

    1. Créez un fichier secret.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Secret
      metadata:
        name: mysecret
      data:
        password: <password>
        username: <username>
      type: kubernetes.io/basic-auth
      Copy to Clipboard Toggle word wrap
    2. Créez l’objet secret à partir du fichier secret.yaml:

      $ oc create -f secret.yaml
      Copy to Clipboard Toggle word wrap
  2. Créez un pod qui fait référence au champ nom d’utilisateur à partir de l’objet secret ci-dessus:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: env-test-container
            image: gcr.io/google_containers/busybox
            command: [ "/bin/sh", "-c", "env" ]
            env:
              - name: MY_SECRET_USERNAME
                valueFrom:
                  secretKeyRef:
                    name: mysecret
                    key: username
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        restartPolicy: Never
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_SECRET_USERNAME:

    $ oc logs -p dapi-env-test-pod
    Copy to Clipboard Toggle word wrap

Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des valeurs de carte de configuration afin que les auteurs d’images et d’applications puissent créer une image pour des environnements spécifiques.

Procédure

  1. Créer une carte de configuration avec les valeurs à injecter:

    1. Créez un fichier configmap.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: myconfigmap
      data:
        mykey: myvalue
      Copy to Clipboard Toggle word wrap
    2. Créer la carte de configuration à partir du fichier configmap.yaml:

      $ oc create -f configmap.yaml
      Copy to Clipboard Toggle word wrap
  2. Créez un pod qui fait référence à la carte de configuration ci-dessus:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: env-test-container
            image: gcr.io/google_containers/busybox
            command: [ "/bin/sh", "-c", "env" ]
            env:
              - name: MY_CONFIGMAP_VALUE
                valueFrom:
                  configMapKeyRef:
                    name: myconfigmap
                    key: mykey
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        restartPolicy: Always
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_CONFIGMAP_VALUE:

    $ oc logs -p dapi-env-test-pod
    Copy to Clipboard Toggle word wrap

7.5.6. Les variables d’environnement de référencement

Lors de la création de pods, vous pouvez référencer la valeur d’une variable d’environnement définie précédemment en utilisant la syntaxe $(). Lorsque la référence de la variable d’environnement ne peut pas être résolue, la valeur sera laissée en tant que chaîne fournie.

Procédure

  1. Créer un pod qui fait référence à une variable d’environnement existante:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: env-test-container
            image: gcr.io/google_containers/busybox
            command: [ "/bin/sh", "-c", "env" ]
            env:
              - name: MY_EXISTING_ENV
                value: my_value
              - name: MY_ENV_VAR_REF_ENV
                value: $(MY_EXISTING_ENV)
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        restartPolicy: Never
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_ENV_VAR_REF_ENV:

    $ oc logs -p dapi-env-test-pod
    Copy to Clipboard Toggle word wrap

Lors de la création d’une gousse, vous pouvez échapper à une référence variable d’environnement en utilisant un signe double dollar. La valeur sera ensuite définie sur une version de signe d’un seul dollar de la valeur fournie.

Procédure

  1. Créer un pod qui fait référence à une variable d’environnement existante:

    1. Créez un fichier pod.yaml similaire à ce qui suit:

      apiVersion: v1
      kind: Pod
      metadata:
        name: dapi-env-test-pod
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
          - name: env-test-container
            image: gcr.io/google_containers/busybox
            command: [ "/bin/sh", "-c", "env" ]
            env:
              - name: MY_NEW_ENV
                value: $$(SOME_OTHER_ENV)
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: [ALL]
        restartPolicy: Never
      # ...
      Copy to Clipboard Toggle word wrap
    2. Créer le pod à partir du fichier pod.yaml:

      $ oc create -f pod.yaml
      Copy to Clipboard Toggle word wrap

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_NEW_ENV:

    $ oc logs -p dapi-env-test-pod
    Copy to Clipboard Toggle word wrap
Retour au début
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

© 2025 Red Hat