Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.

Повернутися до звичайного перегляду сторінки.

Введення даних у застосунки

Визначення конфігурації та інших даних для Podʼів, у яких працює ваше робоче навантаження.

1: Визначення команди та аргументів для контейнера
2: Визначення залежних змінних середовища
3: Визначення змінних середовища для контейнера
4: Визначення значень змінних середовища за допомогою init-контейнера

1 - Визначення команди та аргументів для контейнера

На цій сторінці показано, як визначати команди й аргументи під час запуску контейнера в Pod.

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

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

Для перевірки версії введіть kubectl version.

Визначення команди та аргументів під час створення Podʼа

Під час створення Podʼа ви можете визначити команду й аргументи для контейнерів, які працюють у Podʼі. Щоб визначити команду, додайте поле command у файл конфігурації. Щоб визначити аргументи команди, додайте поле args у файл конфігурації. Команду й аргументи, які ви визначили, не можна змінити після створення Podʼа.

Команда й аргументи, які ви визначаєте у файлі конфігурації, перевизначають стандартну команду й аргументи, надані образом контейнера. Якщо ви визначаєте args, але не визначаєте команду, використовується стандартна команда з вашими новими аргументами.

Примітка:

Поле command відповідає ENTRYPOINT, а поле args — CMD у деяких середовищах виконання контейнерів.

У цій вправі ви створите Pod, який запускає один контейнер. Файл конфігурації Podʼа визначає команду й два аргументи:

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

Створіть Pod на основі файлу конфігурації YAML:
```
kubectl apply -f https://k8s.io/examples/pods/commands.yaml
```
Перегляньте список запущених Podʼів:
```
kubectl get pods
```
Вивід показує, що контейнер, який працював у Podʼі command-demo, завершився.
Щоб побачити вивід команди, яка виконувалася в контейнері, перегляньте логи Podʼа:
```
kubectl logs command-demo
```
Вивід показує значення змінних середовища HOSTNAME та KUBERNETES_PORT:
```
command-demo
tcp://10.3.240.1:443
```

Використання змінних середовища для визначення аргументів

У попередньому прикладі ви визначили аргументи безпосередньо, вказавши рядки. Замість прямого вказування рядків ви можете визначати аргументи за допомогою змінних середовища:

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

Це означає, що ви можете визначити аргумент для Podʼа будь-яким способом, доступним для визначення змінних середовища, зокрема за допомогою ConfigMaps і Secrets.

Примітка:

Змінна середовища вказується в дужках, "$(VAR)". Це потрібно, щоб змінна розгорталася в полі command або args.

Виконання команди в оболонці

Іноді потрібно, щоб команда виконувалася в оболонці. Наприклад, ваша команда може складатися з кількох команд, обʼєднаних у конвеєр, або бути скриптом оболонки. Щоб виконати команду в оболонці, оберніть її так:

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

Що далі

Дізнайтеся більше про налаштування Podʼів та контейнерів.
Дізнайтеся більше про виконання команд у контейнері.
Дивіться Container.

2 - Визначення залежних змінних середовища

На цій сторінці показано, як визначати залежні змінні середовища для контейнера в Podʼі Kubernetes.

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

Визначення залежної змінної середовища для контейнера

Під час створення Podʼа ви можете встановлювати залежні змінні середовища для контейнерів, які працюють у Podʼі. Для цього можна використовувати $(VAR_NAME) у value поля env у файлі конфігурації.

У цій вправі ви створите Pod, який запускає один контейнер. Файл конфігурації Podʼа визначає залежну змінну середовища з поширеним способом використання. Ось маніфест конфігурації 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)"

Створіть Pod на основі цього маніфесту:

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

pod/dependent-envars-demo created

Перегляньте список запущених Podʼів:

kubectl get pods dependent-envars-demo

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

Перевірте логи контейнера, що працює у вашому 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

Як показано вище, ви визначили правильне посилання на залежність SERVICE_ADDRESS, неправильне посилання на залежність UNCHANGED_REFERENCE і пропустили залежні посилання в ESCAPED_REFERENCE.

Якщо змінну середовища вже визначено на момент посилання, посилання можна правильно розвʼязати, як у випадку SERVICE_ADDRESS.

Зверніть увагу, що порядок у списку env має значення. Змінна середовища не вважається «визначеною», якщо вона вказана нижче в списку. Саме тому UNCHANGED_REFERENCE не вдається розвʼязати $(PROTOCOL) у наведеному вище прикладі.

Коли змінна середовища не визначена або включає лише деякі змінні, невизначена змінна середовища розглядається як звичайний рядок, як у випадку UNCHANGED_REFERENCE. Зверніть увагу, що неправильно розібрані змінні середовища зазвичай не блокують запуск контейнера.

Синтаксис $(VAR_NAME) можна екранувати подвійним $, тобто $$(VAR_NAME). Екрановані посилання ніколи не розгортаються, незалежно від того, чи визначена змінна, на яку вони посилаються. Це видно з наведеного вище випадку ESCAPED_REFERENCE.

Що далі

Дізнайтеся більше про змінні середовища.
Перегляньте EnvVarSource.

3 - Визначення змінних середовища для контейнера

На цій сторінці показано, як визначити змінні середовища для контейнера в Podʼі Kubernetes.

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

Визначення змінної середовища для контейнера

Під час створення Podʼа ви можете задати змінні середовища для контейнерів, які працюють у Podʼі. Щоб задати змінні середовища, додайте поле env або envFrom у файл конфігурації.

Поля env та envFrom діють по-різному.

env: дозволяє задати змінні середовища для контейнера, вказавши значення безпосередньо для кожної названої змінної.
envFrom: дозволяє задати змінні середовища для контейнера через посилання на ConfigMap або Secret. Коли ви використовуєте envFrom, усі пари ключ-значення у вказаному ConfigMap або Secret задаються як змінні середовища контейнера. Ви також можете вказати спільний префікс.

Докладніше про ConfigMap та Secret.

На цій сторінці пояснено, як використовувати env.

У цій вправі ви створите Pod, який запускає один контейнер. Файл конфігурації Podʼа визначає змінну середовища з назвою DEMO_GREETING і значенням "Hello from the environment". Ось маніфест конфігурації 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/hello-app:2.0
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"

Створіть Pod на основі цього маніфесту:
```
kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml
```

Перегляньте перелік запущених Podʼів:

kubectl get pods -l purpose=demonstrate-envars

Вивід подібний до такого:

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

Виведіть змінні середовища контейнера Podʼа:

kubectl exec envar-demo -- printenv

Вивід подібний до такого:

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

Примітка:

Змінні середовища, встановлені за допомогою полів env або envFrom, перевизначають будь-які змінні середовища, вказані в образі контейнера.

Примітка:

Змінні середовища можуть посилатися одна на одну, але порядок важливий. Змінні, що використовують інші змінні, визначені в тому самому контексті, мають іти нижче в списку. Так само уникайте циклічних посилань.

Використання змінних середовища у вашій конфігурації

Змінні середовища, які ви визначаєте в конфігурації Podʼа в .spec.containers[*].env[*], можна використовувати в інших частинах конфігурації, наприклад у командах і аргументах, які ви задаєте для контейнерів Podʼа. У наведеному нижче прикладі конфігурації змінні середовища GREETING, HONORIFIC і NAME мають значення Warm greetings to, The Most Honorable і Kubernetes відповідно. Змінна середовища MESSAGE обʼєднує всі ці змінні середовища, а потім використовується як аргумент командного рядка, переданий контейнеру env-print-demo.

Назви змінних середовища можуть складатися з будь-яких друкованих символів ASCII, окрім '='.

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"
    - name: MESSAGE
      value: "$(GREETING) $(HONORIFIC) $(NAME)"
    command: ["echo"]
    args: ["$(MESSAGE)"]

Після створення в контейнері виконується команда echo Warm greetings to The Most Honorable Kubernetes.

Що далі

Дізнайтеся більше про змінні середовища.
Дізнайтеся про використання Secrets як змінних середовища.
Дивіться EnvVarSource.

4 - Визначення значень змінних середовища за допомогою init-контейнера

СТАН ФУНКЦІОНАЛУ: Beta since Kubernetes v1.35; (стандартно увімкнено)

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

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

Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.

Для перевірки версії введіть kubectl version.

Як працює цей підхід

У цій вправі ви створите Pod, який отримує змінні середовища з файлів, проєцюючи ці значення в запущений контейнер.

pods/inject/envars-file-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: envfile-test-pod
spec:
  initContainers:
    - name: setup-envfile
      image:  nginx
      command: ['sh', '-c', "echo \"DB_ADDRESS=\'address\'\nREST_ENDPOINT=\'endpoint\'\" > /data/config.env"]
      volumeMounts:
        - name: config
          mountPath: /data
  containers:
    - name: use-envfile
      image: nginx
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: DB_ADDRESS
          valueFrom:
            fileKeyRef:
              path: config.env
              volumeName: config
              key: DB_ADDRESS
              optional: false
  restartPolicy: Never
  volumes:
    - name: config
      emptyDir: {}

У цьому маніфесті initContainer монтує том emptyDir і записує змінні середовища у файл усередині нього, а звичайні контейнери посилаються і на файл, і на ключ змінної середовища через поле fileKeyRef, не монтуючи том. Коли поле optional має значення false, вказаний key у fileKeyRef має існувати у файлі змінних середовища.

Том монтується лише в контейнер, який записує у файл (initContainer), а контейнер-споживач, який використовує змінну середовища, не матиме змонтованого тому.

Формат файлу env відповідає стандарту файлів env у Kubernetes.

Під час ініціалізації контейнера kubelet отримує змінні середовища зі вказаних файлів у томі emptyDir і надає їх контейнеру.

Примітка:

Усі типи контейнерів (init-контейнери, звичайні контейнери, sidecar-контейнери й ефемерні контейнери) підтримують завантаження змінних середовища з файлів.

Хоча ці змінні середовища можуть зберігати конфіденційну інформацію, томи emptyDir не забезпечують тих самих механізмів захисту, що й окремі обʼєкти Secret. Тому надання конфіденційних змінних середовища контейнерам через цю можливість не вважається рекомендованою практикою безпеки.

Створіть Pod:

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

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

# Якщо новий Pod ще не справний, повторіть цю команду кілька разів.
kubectl get pods

Перевірте логи контейнера на наявність змінних середовища:

kubectl logs envfile-test-pod -c use-envfile | grep DB_ADDRESS

Вивід показує значення вибраних змінних середовища:

DB_ADDRESS=address

Синтаксис файлів env

Формат файлу env, який використовує Kubernetes, є чітко визначеною підмножиною семантики змінних середовища для POSIX-сумісного bash. Будь-який файл env, який підтримує Kubernetes, створює ті самі змінні середовища, що й під час інтерпретації в POSIX-сумісному bash. Однак POSIX-сумісний bash підтримує деякі додаткові формати, які Kubernetes не приймає.

Приклад:

MY_VAR='my-literal-value'

Правила

Оголошення змінної: використовуйте форму VAR='value'. Пробіли навколо = ігноруються; пробіли на початку рядка ігноруються; порожні рядки ігноруються.
Значення в лапках: значення мають бути взяті в одинарні лапки (').
- Вміст в одинарних лапках зберігається дослівно. Обробка екранованих послідовностей, згортання пробілів чи інтерпретація символів не застосовуються.
- Символи нового рядка в одинарних лапках зберігаються (багаторядкові значення підтримуються).
Коментарі: рядки, що починаються з #, розглядаються як коментарі та ігноруються. Символ # всередині значення в одинарних лапках не є коментарем.

Приклади:

# comment
DB_ADDRESS='address'

MULTI='line1
line2'

Непідтримувані форми

Значення без лапок заборонені:
- VAR=value — не підтримується.
Значення в подвійних лапках заборонені:
- VAR="value" — не підтримується.
Кілька сусідніх рядків у лапках не підтримуються:
- VAR='val1''val2' — не підтримується.
Будь-яка форма інтерполяції, розгортання або конкатенації не підтримується:
- VAR='a'$OTHER або VAR=${OTHER} — не підтримується.

Сувора вимога щодо одинарних лапок гарантує, що kubelet сприймає значення дослівно під час завантаження змінних середовища з файлів.

Що далі

Дізнайтеся більше про змінні середовища.
Прочитайте Визначення змінних середовища для контейнера
Прочитайте Використання змінних середовища для передачі контейнерам інформації про Pod