Передача інформації про Pod контейнерам через файли

На цій сторінці показано, як Pod може використовувати том downwardAPI, щоб передавати інформацію про себе контейнерам, які працюють у Podʼі. Том downwardAPI може надавати поля Podʼа й контейнера.

У Kubernetes є два способи надати поля Podʼа та контейнера запущеному контейнеру:

• Змінні середовища
• Файли томів, як пояснено в цьому завданні

Разом ці два способи надання полів Podʼа та контейнера називаються downward API.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• iximiuz Labs
• Killercoda
• KodeKloud

Зберігання полів Podʼа

У цій частині вправи ви створите Pod з одним контейнером і спроєцюєте поля рівня Podʼа в запущений контейнер як файли. Ось маніфест 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:1.27.2
      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

У маніфесті ви бачите, що Pod має том downwardAPI, а контейнер монтує цей том у /etc/podinfo.

Подивіться на масив items у downwardAPI. Кожен елемент масиву визначає том downwardAPI. Перший елемент вказує, що значення поля metadata.labels Podʼа слід зберегти у файлі з назвою labels. Другий елемент вказує, що значення поля annotations Podʼа слід зберегти у файлі з назвою annotations.

Створіть Pod:

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

Перевірте, що контейнер у Podʼі працює:

kubectl get pods

Перегляньте логи контейнера:

kubectl logs kubernetes-downwardapi-volume-example

Вивід показує вміст файлів labels та annotations:

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

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

Отримайте доступ до оболонки в контейнері, який працює у вашому Podʼі:

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

В оболонці перегляньте файл labels:

/# cat /etc/podinfo/labels

Вивід показує, що всі мітки Podʼа записано у файл labels:

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

Аналогічно, перегляньте файл annotations:

/# cat /etc/podinfo/annotations

Перегляньте файли у теці /etc/podinfo:

/# ls -laR /etc/podinfo

У виводі видно, що файли labels та annotations містяться в тимчасовій підтеці: у цьому прикладі ..2982_06_02_21_47_53.299460680. У теці /etc/podinfo ..data є символічним посиланням на тимчасову підтеку. Також у теці /etc/podinfo labels та annotations є символічними посиланнями.

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

Символічні посилання дають змогу динамічно й атомарно оновлювати метадані: оновлення записуються в нову тимчасову теку, а символічне посилання ..data оновлюється атомарно за допомогою rename(2).

Вийдіть з оболонки:

/# exit

Зберігання полів контейнера

У попередній вправі ви зробили поля рівня Podʼа доступними за допомогою downward API. У наступній вправі ви передасте поля, які є частиною визначення Podʼа, але взяті з конкретного контейнера, а не з Podʼа загалом. Ось маніфест Podʼа, який знову має лише один контейнер:

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

У маніфесті ви бачите, що Pod має том downwardAPI, а єдиний контейнер у цьому Podʼі монтує цей том у /etc/podinfo.

Подивіться на масив items у downwardAPI. Кожен елемент масиву визначає файл у томі downward API.

Перший елемент вказує, що в контейнері з назвою client-container значення поля limits.cpu у форматі, заданому 1m, слід опублікувати як файл із назвою cpu_limit. Поле divisor необовʼязкове й має стандартне значення 1. Дільник 1 означає ядра для ресурсів cpu або байти для ресурсів memory.

Створіть Pod:

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

Отримайте доступ до оболонки в контейнері, який працює у вашому Podʼі:

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

В оболонці перегляньте файл cpu_limit:

# Виконайте це в оболонці всередині контейнера
cat /etc/podinfo/cpu_limit

Ви можете використовувати подібні команди, щоб переглянути файли cpu_request, mem_limit та mem_request.

Проєціювання ключів на конкретні шляхи та дозволи файлів

Ви можете проєціювати ключі на конкретні шляхи й задавати конкретні дозволи для кожного файлу окремо. Докладніше дивіться Secrets.

Що далі

• Прочитайте визначення API spec для Pod. Воно містить визначення Container (частина Pod).
• Прочитайте список доступних полів, які можна надати за допомогою downward API.

Прочитайте про томи в застарілій довідці API:

• Перегляньте визначення API Volume, яке описує загальний том у Podʼі, до якого мають доступ контейнери.
• Перегляньте визначення API DownwardAPIVolumeSource, яке описує том з інформацією Downward API.
• Перегляньте визначення API DownwardAPIVolumeFile, яке містить посилання на поля обʼєкта або ресурсу для заповнення файлу в томі Downward API.
• Перегляньте визначення API ResourceFieldSelector, яке визначає ресурси контейнера та формат їх виводу.