Injecter des données dans les applications

Spécifier la configuration et paramètres pour les Pods qui exécutent vos charges de travail.

1 - Définir une commande et ses arguments pour un Container

Cette page montre comment définir les commandes et arguments d'un container au sein d'un Pod.

Pré-requis

Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:

Pour consulter la version, entrez kubectl version.

Définir une commande et ses arguments à la création d'un Pod

Lorsque vous créez un Pod, il est possible de définir une commande et des arguments pour les containers qui seront exécutés dans votre Pod. Pour définir une commande, ajoutez un champ command dans le fichier de configuration. Pour définir des arguments, ajoutez le champ args dans le fichier de configuration. La commande et les arguments qui sont définis ne peuvent être changés après la création du Pod.

La commande et les arguments que vous définissez dans le fichier de configuration écraseront la commande et les arguments définis par l'image utilisée par le container. Si vous définissez uniquement des arguments, la commande par défaut sera exécutée avec les arguments que vous avez configurés.

Note:

Le champ command correspond à entrypoint dans certains runtimes de containers.

Dans cet exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration pour le Pod défini une commande ainsi que deux arguments:

pods/commands.yaml

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure

Créez un Pod en utilisant le fichier YAML de configuration suivant:
```
kubectl apply -f https://k8s.io/examples/pods/commands.yaml
```
Listez les Pods
```
kubectl get pods
```
Le résultat montre que le container exécuté dans le Pod nommé container-demo a complété son exécution.
Pour voir le résultat de la commade exécutée dans le container, on peut afficher les logs pour le Pod:
```
kubectl logs command-demo
```
Le résultat montre les valeurs des variables d'environnement HOSTNAME et KUBERNETES_PORT:
```
command-demo
tcp://10.3.240.1:443
```

Utiliser des variables d'environnement dans les arguments

Dans l'exemple précédent, vous avez défini des arguments en donnant directement les valeurs en format chaîne de caractères. Il est aussi possible de définir des arguments en utilisant des variables d'environnement:

env:
- name: MESSAGE
  value: "hello world"
command: ["/bin/echo"]
args: ["$(MESSAGE)"]

Il est donc possible de définir un argument pour un Pod en utilisant n'importe quelle méthode disponible pour définir des variables d'environnements, ce qui inclut les ConfigMaps et les Secrets.

Note:

Les variables d'environnements apparaissent ente parenthèses "$(VAR)". Cette écriture est requise pour que la variable soit correctement développée dans les champs command ou args.

Exécuter une commande à l'intérieur d'un shell

Dans certains cas, certaines commandes nécéssitent d'être exécutées dans un shell. Par exemple, certaines commandes consistent en une chaîne de commandes, ou un script shell. Pour exécuter une commande dans un shell, il est possible d'envelopper la commande comme ceci:

command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10;done"]

A suivre

Aller plus loin dans la configuration des pods et des containers.
Apprendre à exécuter des commandes dans un container.
Voir la documentation de référence sur les containers.

2 - Définir des variables d'environnement dépendantes

Cette page montre comment définir des variables d'environnement interdépendantes pour un container dans un Pod Kubernetes.

Pré-requis

Définir une variable d'environnement dépendante pour un container

Lorsque vous créez un Pod, vous pouvez configurer des variables d'environnement interdépendantes pour les containers exécutés dans un Pod. Pour définir une variable d'environnement dépendante, vous pouvez utiliser le format $(VAR_NAME) dans le champ value de la spécification env dans le fichier de configuration.

Dans cette exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration de ce Pod définit des variables d'environnement interdépendantes avec une ré-utilisation entre les différentes variables. Voici le fichier de configuration de ce Pod:

pods/inject/dependent-envars.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dependent-envars-demo
spec:
  containers:
    - name: dependent-envars-demo
      args:
        - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
      command:
        - sh
        - -c
      image: busybox:1.28
      env:
        - name: SERVICE_PORT
          value: "80"
        - name: SERVICE_IP
          value: "172.17.0.1"
        - name: UNCHANGED_REFERENCE
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: PROTOCOL
          value: "https"
        - name: SERVICE_ADDRESS
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: ESCAPED_REFERENCE
          value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"

Créez un Pod en utilisant ce fichier de configuration:

kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml

pod/dependent-envars-demo created

Listez le Pod:

kubectl get pods dependent-envars-demo

NAME                      READY     STATUS    RESTARTS   AGE
dependent-envars-demo     1/1       Running   0          9s

Affichez les logs pour le container exécuté dans votre Pod:

kubectl logs pod/dependent-envars-demo


UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
SERVICE_ADDRESS=https://172.17.0.1:80
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80

Comme montré ci-dessus, vous avez défini une dépendance correcte pour SERVICE_ADDRESS, une dépendance manquante pour UNCHANGED_REFERENCE, et avez ignoré la dépendance pour ESCAPED_REFERENCE.

Lorsqu'une variable d'environnement est déja définie alors qu'elle est référencée par une autre variable, la référence s'effectue correctement, comme dans l'exemple de SERVICE_ADDRESS.

Il est important de noter que l'ordre dans la liste env est important. Une variable d'environnement ne sera pas considérée comme "définie" si elle est spécifiée plus bas dans la liste. C'est pourquoi UNCHANGED_REFERENCE ne résout pas correctement $(PROTOCOL) dans l'exemple précédent.

Lorsque la variable d'environnement n'est pas définie, ou n'inclut qu'une partie des variables, la variable non définie sera traitée comme une chaine de caractères, par exemple UNCHANGED_REFERENCE. Notez que les variables d'environnement malformées n'empêcheront généralement pas le démarrage du conteneur.

La syntaxe $(VAR_NAME) peut être échappée avec un double $, par exemple $$(VAR_NAME). Les références échappées ne sont jamais développées, que la variable référencée soit définie ou non. C'est le cas pour l'exemple ESCAPED_REFERENCE ci-dessus.

A suivre

En savoir plus sur les variables d'environnement.
Lire la documentation pour EnvVarSource.

3 - Définir des variables d'environnement pour un Container

Cette page montre comment définir des variables d'environnement pour un container au sein d'un Pod Kubernetes.

Pré-requis

Définir une variable d'environnement pour un container

Lorsque vous créez un Pod, vous pouvez définir des variables d'environnement pour les containers qui seront exécutés au sein du Pod. Pour les définir, utilisez le champ env ou envFrom dans le fichier de configuration.

Dans cet exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration pour ce Pod contient une variable d'environnement s'appelant DEMO_GREETING et sa valeur est "Hello from the environment". Voici le fichier de configuration du Pod:

pods/inject/envars.yaml

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"

Créez un Pod à partir de ce fichier:

kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml

Listez les Pods:

kubectl get pods -l purpose=demonstrate-envars

Le résultat sera similaire à celui-ci:

NAME            READY     STATUS    RESTARTS   AGE
envar-demo      1/1       Running   0          9s

Listez les variables d'environnement au sein du container:

kubectl exec envar-demo -- printenv

Le résultat sera similaire à celui-ci:

NODE_VERSION=4.4.2
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
HOSTNAME=envar-demo
...
DEMO_GREETING=Hello from the environment
DEMO_FAREWELL=Such a sweet sorrow

Note:

Les variables d'environnement définies dans les champs env ou envFrom écraseront les variables définies dans l'image utilisée par le container.

Note:

Une variable d'environnement peut faire référence à une autre variable, cependant l'ordre de déclaration est important. Une variable faisant référence à une autre doit être déclarée après la variable référencée. De plus, il est recommandé d'éviter les références circulaires.

Utilisez des variables d'environnement dans la configuration

Les variables d'environnement que vous définissez dans la configuration d'un Pod peuvent être utilisées à d'autres endroits de la configuration, comme par exemple dans les commandes et arguments pour les containers. Dans l'exemple ci-dessous, les variables d'environnement GREETING, HONORIFIC, et NAME ont des valeurs respectives de Warm greetings to, The Most Honorable, et Kubernetes. Ces variables sont ensuites utilisées comme arguments pour le container env-print-demo.

apiVersion: v1
kind: Pod
metadata:
  name: print-greeting
spec:
  containers:
  - name: env-print-demo
    image: bash
    env:
    - name: GREETING
      value: "Warm greetings to"
    - name: HONORIFIC
      value: "The Most Honorable"
    - name: NAME
      value: "Kubernetes"
    command: ["echo"]
    args: ["$(GREETING) $(HONORIFIC) $(NAME)"]

Une fois le Pod créé, la commande echo Warm greetings to The Most Honorable Kubernetes sera exécutée dans le container.

A suivre

En savoir plus sur les variables d'environnement.
Apprendre à utiliser des secrets comme variables d'environnement.
Voir la documentation de référence pour EnvVarSource.

4 - Exposer les informations du Pod aux containers via les variables d'environnement

Cette page montre comment un Pod peut utiliser des variables d'environnement pour exposer ses propres informations aux containers qu'il exécute via la
downward API. Vous pouvez utiliser des variables d'environnement pour exposer des champs de configuration du Pod, des containers ou les deux.

Dans Kubernetes, il y a deux façons distinctes d'exposer les champs de configuration de Pod et de container à l'intérieur d'un container:

Via les variables d'environnement, comme expliqué dans cette tâche,
Via un volume

Ensemble, ces deux façons d'exposer des informations du Pod et du container sont appelées la downward API.

Pré-requis

Utiliser les champs du Pod comme variables d'environnement

Dans cette partie de l'exercice, vous allez créer un Pod qui a un container, et vous allez projeter les champs d'informations du Pod à l'intérieur du container comme variables d'environnement.

pods/inject/dapi-envars-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

Dans ce fichier de configuration, on trouve cinq variables d'environnement. Le champ env est une liste de variables d'environnement. Le premier élément de la liste spécifie que la valeur de la variable d'environnement MY_NODE_NAME hérite du champ spec.nodeName du Pod. Il en va de même pour les autres variables d'environnement, qui héritent des autres champs du Pod.

Note:

Les champs de configuration présents dans cet exemple sont des champs du Pod. Ce ne sont pas les champs du container à l'intérieur du Pod.

Créez le Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml

Vérifiez que le container dans le Pod fonctionne:

# Si le nouveau Pod n'est pas fonctionnel, re-exécutez cette commande plusieurs fois
kubectl get pods

Affichez les logs du container:

kubectl logs dapi-envars-fieldref

Le résultat doit afficher les valeurs des variables d'environnement choisies:

minikube
dapi-envars-fieldref
default
172.17.0.4
default

Pour comprendre pourquoi ces valeurs apparaissent dans les logs, regardez les champs command et args du fichier de configuration. Lorsque le container s'exécute, il écrit les valeurs de 5 variables d'environnement vers stdout, avec un interval de 10 secondes.

Ensuite, exécutez un shell à l'intérieur du container:

kubectl exec -it dapi-envars-fieldref -- sh

Dans ce shell, listez les variables d'environnement:

# À exécuter à l'intérieur du container
printenv

Le résultat doit montrer que certaines variables d'environnement contiennent les informations du Pod:

MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref

Utiliser des informations du container comme variables d'environnement

Dans l'exercice précédent, vous avez utilisé les informations du Pod à travers des variables d'environnement. Dans cet exercice, vous allez faire passer des champs appartenant au container qui est exécuté à l'intérieur du Pod.

Voici un fichier de configuration pour un autre Pod qui ne contient qu'un seul container:

pods/inject/dapi-envars-container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-resourcefieldref
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

Dans ce fichier, vous pouvez voir 4 variables d'environnement. Le champ env est une liste de variables d'environnement. Le premier élément de la liste spécifie que la variable d'environnement MY_CPU_REQUEST aura sa valeur à partir du champ requests.cpu du container avec le nom test-container. Il en va de même pour les autres variables d'environnement, qui hériteront des champs du container qui sera exécuté.

Créez le Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml

Vérifiez que le container dans le Pod fonctionne:

# Si le nouveau Pod n'est pas fonctionnel, re-exécutez cette commande plusieurs fois
kubectl get pods

Affichez les logs du container:

kubectl logs dapi-envars-resourcefieldref

Le résultat doit afficher les valeurs des variables selectionnées:

A suivre

Lire Définir des variables d'environnement pour un Container
Lire la documentation de référence des Pod. Elle inclut la documentation pour les containers.
Lire la liste des champs de configuration disponibles qui peuvent être exposés via la downward API.

En savoir plus sur les pods, les containers et les variables d'environnement avec les documentations de référence:

5 - Exposer les informations d'un Pod à ses containers à travers des fichiers

Cette page montre comment un Pod peut utiliser un volume en downwardAPI, pour exposer des informations sur lui-même aux containers executés dans ce Pod. Vous pouvez utiliser un volume downwardAPI pour exposer des champs de configuration du Pod, de ses containers ou les deux.

Dans Kubernetes, il y a deux façons distinctes d'exposer les champs de configuration de Pod et de container à l'intérieur d'un container:

Via les variables d'environnement
Via un volume monté, comme expliqué dans cette tâche

Ensemble, ces deux façons d'exposer des informations du Pod et du container sont appelées la downward API.

Pré-requis

Stocker des champs d'un Pod

Dans cette partie de l'exercice, vous allez créer un Pod qui a un container, et vous allez projeter les champs d'informations du Pod à l'intérieur du container via des fichiers dans le container. Voici le fichier de configuration du Pod:

pods/inject/dapi-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: client-container
      image: registry.k8s.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          if [[ -e /etc/podinfo/annotations ]]; then
            echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

Dans la configuration, on peut voir que le Pod a un volume de type downward API, et que le container monte ce volume sur le chemin /etc/podinfo.

Dans la liste items sous la définition downwardAPI, on peut voir que chaque élément de la liste définit un fichier du volume Downward API. Le premier élément spécifie que le champ metadata.labels doit être exposé dans un fichier appelé labels. Le second élement spécifie que les champs annotations du Pod doivent être stockés dans un fichier appelé annotations.

Note:

Les champs de configuration présents dans cet exemple sont des champs du Pod. Ce ne sont pas les champs du container à l'intérieur du Pod.

Créez le Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml

Vérifiez que le container dans le Pod fonctionne:

kubectl get pods

Affichez les logs du container:

kubectl logs kubernetes-downwardapi-volume-example

Le résultat doit afficher le contenu des fichiers labels et annotations:

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

build="two"
builder="john-doe"

Exécutez un shell à l'intérieur du container de votre Pod:

kubectl exec -it kubernetes-downwardapi-volume-example -- sh

Dans ce shell, affichez le contenu du ficher labels:

/# cat /etc/podinfo/labels

Le résultat doit montrer que tous les labels du Pod ont été écrits dans le fichier labels:

cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

Il en va de même pour le fichier annotations:

/# cat /etc/podinfo/annotations

Listez les fichiers présents dans le dossier /etc/podinfo:

/# ls -laR /etc/podinfo

Dans le résultat, vous pouvez voir que les fichiers labels et annotations sont dans un sous-dossier temporaire. Dans cet exemple, ..2982_06_02_21_47_53.299460680. Dans le dossier /etc/podinfo, le dossier ..data est un lien symbolique au dossier temporaire. De plus, dans le dossier /etc/podinfo, les fichiers labels et annotations sont eux aussi des liens symboliques.

drwxr-xr-x  ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels

/etc/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r--  ... Feb  6 21:47 annotations
-rw-r--r--  ... Feb  6 21:47 labels

L'utilisation de liens symboliques permet une mise à jour atomique des données. Les mises à jour sont écrites dans un nouveau dossier temporaire, puis les liens symboliques sont mis à jour avec rename(2).

Note:

Un container utilisant la Downward API via un volume monté dans un subPath ne recevra pas de mise à jour de la Downward API.

Quittez la session shell:

/# exit

Stocker des champs d'un container

Dans l'exercice précedent, vous avez rendu accessible des champs d'un Pod via la Downward API. Dans l'exercice suivant, vous allez faire passer de la même manière des champs qui appartiennent au container, plutôt qu'au Pod. Voici un fichier de configuration pour un Pod qui n'a qu'un seul container:

pods/inject/dapi-volume-resources.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-downwardapi-volume-example-2
spec:
  containers:
    - name: client-container
      image: registry.k8s.io/busybox:1.24
      command: ["sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          if [[ -e /etc/podinfo/cpu_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
          if [[ -e /etc/podinfo/cpu_request ]]; then
            echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
          if [[ -e /etc/podinfo/mem_limit ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
          if [[ -e /etc/podinfo/mem_request ]]; then
            echo -en '\n'; cat /etc/podinfo/mem_request; fi;
          sleep 5;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
              divisor: 1m
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
              divisor: 1m
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
              divisor: 1Mi
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory
              divisor: 1Mi

Dans cette configuration, on peut voir que le Pod a un volume de type downwardAPI, et que le container monte ce volume sur le chemin /etc/podinfo.

Dans la liste items sous la définition downwardAPI, on peut voir que chaque élément de la liste définit un fichier du volume Downward API.

Le premier élément spécifie que dans le container nommé client-container, la valeur du champ limits.cpu dans un format spécifié par 1m sera exposé dans un fichier appelé cpu_limit. Le champ divisor est optionnel et a une valeur par défaut de 1. Un diviseur de 1 spécifie l'unité coeur pour la ressource cpu, et l'unité bytes pour la ressource memory.

Créez le Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml

Exécutez un shell à l'intérieur du container de votre Pod:

kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh

Dans le shell, affichez le contenu du fichier cpu_limit:

# À exécuter à l'intérieur du container
cat /etc/podinfo/cpu_limit

Vous pouvez utiliser des commandes similaires pour afficher les fichiers cpu_request, mem_limit et mem_request.

Projection de champs sur des chemins spécifiques et droits d'accès

Vous pouvez projeter des champs sur des chemins spécifiques, et assigner des permissions pour chacun de ces chemins. Pour plus d'informations, regardez la documentation des Secrets.

A suivre

Lire la documentation de référence des Pod qui inclut la documentation pour les containers.
Lire la liste des champs de configuration disponibles qui peuvent être exposés via la downward API.
Lire la documentation de l'API Volumes qui définit les Volumes accessibles par des containers.
Lire la documentation de l'API DownwardAPIVolumeSource qui définit un volume contenant des informations de la Downward API.
Lire la documentation de l'API DownwardAPIVolumeFile qui définit les champs disponibles pour un Volume Downward API.
Lire la documentation de l'API ResourceFieldSelector qui spécifie les ressources des containers et leur format.

6 - Distribuer des données sensibles de manière sécurisée avec les Secrets

Cette page montre comment injecter des données sensibles comme des mots de passe ou des clés de chiffrement dans des Pods.

Pré-requis

Encoder vos données en format base64

Supposons que vous avez deux données sensibles: un identifiant my-app et un mot de passe 39528$vdg7Jb. Premièrement, utilisez un outil capable d'encoder vos données dans un format base64. Voici un exemple en utilisant le programme base64:

echo -n 'my-app' | base64
echo -n '39528$vdg7Jb' | base64

Le résultat montre que la représentation base64 de l'utilisateur est bXktYXBw, et que la représentation base64 du mot de passe est Mzk1MjgkdmRnN0pi.

Avertissement:

Utilisez un outil local approuvé par votre système d'exploitation afin de réduire les risques de sécurité liés à l'utilisation d'un outil externe.

Créer un Secret

Voici un fichier de configuration que vous pouvez utiliser pour créer un Secret qui contiendra votre identifiant et mot de passe:

pods/inject/secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: bXktYXBw
  password: Mzk1MjgkdmRnN0pi

Créez le Secret:

kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml

Listez les informations du Secret:

kubectl get secret test-secret

Résultat:

NAME          TYPE      DATA      AGE
test-secret   Opaque    2         1m

Affichez les informations détaillées du Secret:

kubectl describe secret test-secret

Résultat:

Name:       test-secret
Namespace:  default
Labels:     <none>
Annotations:    <none>

Type:   Opaque

Data
====
password:   13 bytes
username:   7 bytes

Créer un Secret en utilisant kubectl

Si vous voulez sauter l'étape d'encodage, vous pouvez créer le même Secret en utilisant la commande kubectl create secret. Par exemple:

kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'

Cette approche est plus pratique. La façon de faire plus explicite montrée précédemment permet de démontrer et comprendre le fonctionnement des Secrets.

Créer un Pod qui a accès aux données sensibles à travers un Volume

Voici un fichier de configuration qui permet de créer un Pod:

pods/inject/secret-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
        # name must match the volume name below
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
  # The secret data is exposed to Containers in the Pod through a Volume.
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret

Créez le Pod:

kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml

Vérifiez que le Pod est opérationnel:

kubectl get pod secret-test-pod

Résultat:

NAME              READY     STATUS    RESTARTS   AGE
secret-test-pod   1/1       Running   0          42m

Exécutez une session shell dans le Container qui est dans votre Pod:
```
kubectl exec -i -t secret-test-pod -- /bin/bash
```
Les données sont exposées au container à travers un Volume monté sur /etc/secret-volume.

Dans votre shell, listez les fichiers du dossier /etc/secret-volume:
```
# À exécuter à l'intérieur du container
ls /etc/secret-volume
```
Le résultat montre deux fichiers, un pour chaque donnée du Secret:
```
password username
```

Toujours dans le shell, affichez le contenu des fichiers username et password:

# À exécuter à l'intérieur du container
echo "$( cat /etc/secret-volume/username )"
echo "$( cat /etc/secret-volume/password )"

Le résultat doit contenir votre identifiant et mot de passe:

my-app
39528$vdg7Jb

Vous pouvez alors modifier votre image ou votre ligne de commande pour que le programme recherche les fichiers contenus dans le dossier du champ mountPath. Chaque clé du Secret data sera exposée comme un fichier à l'intérieur de ce dossier.

Monter les données du Secret sur des chemins spécifiques

Vous pouvez contrôler les chemins sur lesquels les données des Secrets sont montées. Utilisez le champ .spec.volumes[].secret.items pour changer le chemin cible de chaque donnée:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

Voici ce qu'il se passe lorsque vous déployez ce Pod:

La clé username du Secret mysecret est montée dans le container sur le chemin /etc/foo/my-group/my-username au lieu de /etc/foo/username.
La clé password du Secret n'est pas montée dans le container.

Si vous listez de manière explicite les clés en utilisant le champ .spec.volumes[].secret.items, il est important de prendre en considération les points suivants:

Seules les clés listées dans le champ items seront montées.
Pour monter toutes les clés du Secret, toutes doivent être définies dans le champ items.
Toutes les clés définies doivent exister dans le Secret. Sinon, le volume ne sera pas créé.

Appliquer des permissions POSIX aux données

Vous pouvez appliquer des permissions POSIX pour une clé d'un Secret. Si vous n'en configurez pas, les permissions seront par défaut 0644. Vous pouvez aussi définir des permissions pour tout un Secret, et redéfinir les permissions pour chaque clé si nécessaire.

Par exemple, il est possible de définir un mode par défaut:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 0400

Le Secret sera monté sur /etc/foo; tous les fichiers créés par le secret auront des permissions de type 0400.

Note:

Si vous définissez un Pod en utilisant le format JSON, il est important de noter que la spécification JSON ne supporte pas le système octal, et qu'elle comprendra la valeur 0400 comme la valeur décimale 400. En JSON, utilisez plutôt l'écriture décimale pour le champ defaultMode. Si vous utilisez le format YAML, vous pouvez utiliser le système octal pour définir defaultMode.

Définir des variables d'environnement avec des Secrets

Il est possible de monter les données des Secrets comme variables d'environnement dans vos containers.

Si un container consomme déja un Secret en variables d'environnement, la mise à jour de ce Secret ne sera pas répercutée dans le container tant qu'il n'aura pas été redémarré. Il existe cependant des solutions tierces permettant de redémarrer les containers lors d'une mise à jour du Secret.

Définir une variable d'environnement à partir d'un seul Secret

Définissez une variable d'environnement et sa valeur à l'intérieur d'un Secret:

kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'

Assignez la valeur de backend-username définie dans le Secret à la variable d'environnement SECRET_USERNAME dans la configuration du Pod.

pods/inject/pod-single-secret-env-variable.yaml

apiVersion: v1
kind: Pod
metadata:
  name: env-single-secret
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: SECRET_USERNAME
      valueFrom:
        secretKeyRef:
          name: backend-user
          key: backend-username

Créez le Pod:

kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml

À l'intérieur d'une session shell, affichez le contenu de la variable d'environnement SECRET_USERNAME:
```
kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
```
Le résultat est:
```
backend-admin
```

Définir des variables d'environnement à partir de plusieurs Secrets

Comme précédemment, créez d'abord les Secrets:

kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
kubectl create secret generic db-user --from-literal=db-username='db-admin'

Définissez les variables d'environnement dans la configuration du Pod.

pods/inject/pod-multiple-secret-env-variable.yaml

apiVersion: v1
kind: Pod
metadata:
  name: envvars-multiple-secrets
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: BACKEND_USERNAME
      valueFrom:
        secretKeyRef:
          name: backend-user
          key: backend-username
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-user
          key: db-username

Créez le Pod:

kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml

Dans un shell, listez les variables d'environnement du container:

kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'

Le résultat est:

DB_USERNAME=db-admin
BACKEND_USERNAME=backend-admin

Configurez toutes les paires de clé-valeur d'un Secret comme variables d'environnement

Note:

Cette fonctionnalité n'est disponible que dans les versions de Kubernetes égales ou supérieures à v1.6.

Créez un Secret contenant plusieurs paires de clé-valeur:

kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'

Utilisez envFrom pour définir toutes les données du Secret comme variables d'environnement. Les clés du Secret deviendront les noms des variables d'environnement à l'intérieur du Pod.

pods/inject/pod-secret-envFrom.yaml

apiVersion: v1
 kind: Pod
 metadata:
   name: envfrom-secret
 spec:
   containers:
   - name: envars-test-container
     image: nginx
     envFrom:
     - secretRef:
         name: test-secret

Créez le Pod:

kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml

Dans votre shell, affichez les variables d'environnement username et password:

kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'

Le résultat est:

username: my-app
password: 39528$vdg7Jb

Références

A suivre

En savoir plus sur les Secrets.
En savoir plus sur les Volumes.