Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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 à OpenShift Dedicated. 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
# ...

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

      $ oc create -f pod.yaml

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

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
# ...

    2. Créez le pod à partir du fichier volume-pod.yaml: 

      $ oc create -f volume-pod.yaml

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

    Exemple de sortie

    cluster=downward-api-test-cluster1
rack=rack-123
zone=us-east-coast
annotation1=345
annotation2=456
kubernetes.io/config.source=api

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
# ...

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

      $ oc create -f pod.yaml

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
# ...

    2. Créez le pod à partir du fichier volume-pod.yaml: 

      $ oc create -f volume-pod.yaml

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

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

    2. Créez l’objet secret à partir du fichier secret.yaml: 

      $ oc create -f secret.yaml

  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
# ...

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

      $ oc create -f pod.yaml

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_SECRET_USERNAME: 

    $ oc logs -p dapi-env-test-pod

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

    2. Créer la carte de configuration à partir du fichier configmap.yaml: 

      $ oc create -f configmap.yaml

  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
# ...

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

      $ oc create -f pod.yaml

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_CONFIGMAP_VALUE: 

    $ oc logs -p dapi-env-test-pod

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

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
# ...

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

      $ oc create -f pod.yaml

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_ENV_VAR_REF_ENV: 

    $ oc logs -p dapi-env-test-pod

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
# ...

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

      $ oc create -f pod.yaml

La vérification

  • Consultez les journaux du conteneur pour la valeur MY_NEW_ENV: 

    $ oc logs -p dapi-env-test-pod
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