SupportConsoleDéveloppeursCommencer un essaiContact

6.5. Permettre aux conteneurs de consommer des objets API

Le site Downward API est un mécanisme qui permet aux conteneurs de consommer des informations sur les objets API sans être couplés à OpenShift Container Platform. Ces informations comprennent le nom du pod, l'espace de noms et les valeurs des ressources. Les conteneurs peuvent consommer les informations de l'API descendante à l'aide de variables d'environnement ou d'un plugin de volume.

6.5.1. Exposer les informations sur les pods aux conteneurs à l'aide de l'API descendante

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

Les champs du module sont sélectionnés à l'aide du type d'API FieldRef. FieldRef comporte deux champs :

FieldDescription

fieldPath

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

apiVersion

La version de l'API dans laquelle le sélecteur fieldPath doit être interprété.

Actuellement, les sélecteurs valides dans l'API v1 sont les suivants :

SélecteurDescription

metadata.name

Le nom du module. Ceci est supporté à la fois dans les variables d'environnement et les volumes.

metadata.namespace

L'espace de noms du pod est pris en charge à la fois par les variables d'environnement et les volumes.

metadata.labels

Les étiquettes du pod. Ceci n'est possible que dans les volumes et non dans les variables d'environnement.

metadata.annotations

Les annotations du pod. Ceci n'est possible que dans les volumes et non dans les variables d'environnement.

status.podIP

L'IP du pod. Ceci n'est supporté que dans les variables d'environnement et non dans les volumes.

Le champ apiVersion, s'il n'est pas spécifié, prend par défaut la version API du modèle de pod qui l'entoure.

6.5.2. Comprendre comment consommer les valeurs des conteneurs à l'aide de l'API descendante

Les conteneurs peuvent consommer les valeurs de l'API à l'aide de variables d'environnement ou d'un plugin de volume. Selon la méthode choisie, les conteneurs peuvent consommer :

  • Nom du pod
  • Pod projet/espace de noms
  • Annotations sur les pods
  • Étiquettes des gousses

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

6.5.2.1. Consommer des valeurs de conteneurs à l'aide de variables d'environnement

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

Seuls les attributs constants du pod peuvent être consommés de cette manière, car les variables d'environnement ne peuvent pas être mises à jour une fois qu'un processus est lancé d'une manière qui permette au processus d'être informé que la valeur d'une variable a changé. Les champs pris en charge par les variables d'environnement sont les suivants

  • Nom du pod
  • Pod projet/espace de noms

Procédure

Pour utiliser des variables d'environnement

  1. Créer un fichier pod.yaml: 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  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
  restartPolicy: Never

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

    $ oc create -f pod.yaml

  3. Vérifiez les journaux du conteneur pour les valeurs MY_POD_NAME et MY_POD_NAMESPACE: 

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

6.5.2.2. Consommer les valeurs d'un conteneur à l'aide d'un plugin de volume

Les conteneurs peuvent consommer les valeurs de l'API à l'aide d'un plugin de volume.

Les conteneurs peuvent consommer :

  • Nom du pod
  • Pod projet/espace de noms
  • Annotations sur les pods
  • Étiquettes des gousses

Procédure

Pour utiliser le plugin de volume :

  1. Créer un fichier volume-pod.yaml: 

    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:
  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
  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éer le pod à partir du fichier volume-pod.yaml: 

    $ oc create -f volume-pod.yaml

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

6.5.3. Comprendre comment consommer les ressources d'un conteneur à l'aide de l'API descendante

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

Vous pouvez le faire en utilisant une variable d'environnement ou un plugin de volume.

6.5.3.1. Consommer les ressources d'un conteneur à l'aide de variables d'environnement

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

Procédure

Pour utiliser les variables d'environnement :

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

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

    Si les limites de ressources ne sont pas incluses dans la configuration du conteneur, l'API descendante utilise par défaut les valeurs de CPU et de mémoire allouables du nœud.

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

    $ oc create -f pod.yaml

6.5.3.2. Consommer les ressources d'un conteneur à l'aide 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 et les limites des ressources informatiques à l'aide d'un plugin de volume.

Procédure

Pour utiliser le plugin de volume :

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

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

    Si les limites de ressources ne sont pas incluses dans la configuration du conteneur, l'API descendante utilise par défaut les valeurs de l'unité centrale et de la mémoire allouable du nœud.

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

    $ oc create -f volume-pod.yaml

6.5.4. Consommer des secrets à l'aide de l'API descendante

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 fichier secret.yaml: 

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  password: cGFzc3dvcmQ=
  username: ZGV2ZWxvcGVy
type: kubernetes.io/basic-auth

  2. Créer un objet Secret à partir du fichier secret.yaml: 

    $ oc create -f secret.yaml

  3. Créez un fichier pod.yaml qui fait référence au champ username de l'objet Secret ci-dessus : 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  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
  restartPolicy: Never

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

    $ oc create -f pod.yaml

  5. Vérifiez les journaux du conteneur pour la valeur MY_SECRET_USERNAME: 

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

6.5.5. Consommer des cartes de configuration à l'aide de l'API descendante

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 un configmap.yaml fichier : 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  mykey: myvalue

  2. Créer un objet ConfigMap à partir du configmap.yaml fichier : 

    $ oc create -f configmap.yaml

  3. Créer un fichier pod.yaml qui fait référence à l'objet ConfigMap ci-dessus : 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  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
  restartPolicy: Always

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

    $ oc create -f pod.yaml

  5. Vérifiez les journaux du conteneur pour la valeur MY_CONFIGMAP_VALUE: 

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

6.5.6. Référence aux variables d'environnement

Lors de la création de pods, vous pouvez faire référence à la valeur d'une variable d'environnement précédemment définie en utilisant la syntaxe $(). Si la référence à la variable d'environnement ne peut pas être résolue, la valeur sera laissée sous la forme de la chaîne fournie.

Procédure

  1. Créer un fichier pod.yaml qui fait référence à un fichier existant environment variable: 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  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)
  restartPolicy: Never

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

    $ oc create -f pod.yaml

  3. Vérifiez les journaux du conteneur pour la valeur MY_ENV_VAR_REF_ENV: 

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

6.5.7. Échapper aux références aux variables d'environnement

Lors de la création d'un module, vous pouvez échapper à une référence à une variable d'environnement en utilisant un double signe de dollar. La valeur sera alors remplacée par une version avec un seul signe de dollar de la valeur fournie.

Procédure

  1. Créer un fichier pod.yaml qui fait référence à un fichier existant environment variable: 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  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)
  restartPolicy: Never

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

    $ oc create -f pod.yaml

  3. Vérifiez 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.

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.