# Визначення значень змінних середовища за допомогою контейнера ініціалізації LLMS index: [llms.txt](/llms.txt) ---

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

Ця сторінка показує, як налаштувати змінні середовища для контейнерів у Pod за допомогою файлу. ## Перш ніж ви розпочнете

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

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

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

## Як працює дизайн {#how-the-design-works} В цьому завданні ви створите 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](/docs/tasks/inject-data-application/define-environment-variable-via-file/#env-file-syntax). Під час ініціалізації контейнера kubelet отримує змінні середовища з вказаних файлів у томі `emptyDir` і надає їх контейнеру.

Примітка:

Всі типи контейнерів (initContainers, звичайні контейнери, sidecars контейнери та ephemeral контейнери) підтримують завантаження змінних середовища з файлів.

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

Створіть Pod: ```shell kubectl apply -f https://k8s.io/examples/pods/inject/envars-file-container.yaml ``` Перевірте, чи контейнер у Pod працює: ```shell kubectl get pods ``` ```shell # Якщо новий Pod ще не справний, повторіть цю команду кілька разів. kubectl get pods ``` Перевірте журнали контейнера на наявність змінних середовища: ```shell kubectl logs envfile-test-pod -c use-envfile | grep DB_ADDRESS ``` Вивід показує значення вибраних змінних середовища: ```console DB_ADDRESS=address ``` ## Синтаксис файлів env {#env-file-syntax} Формат файлу env, який використовує Kubernetes, є чітко визначеним підмножиною семантики змінних середовища для POSIX-сумісного bash. Будь-який файл env, який підтримує Kubernetes, створюватиме ті самі змінні середовища, що й POSIX-сумісний bash. Однак POSIX-сумісний bash підтримує деякі додаткові формати, які Kubernetes не приймає. Приклад: ```env MY_VAR='my-literal-value' ``` ### Правила {#rules} * Оголошення змінної: використовуйте форму `VAR='value'`. Пробіли навколо `=` ігноруються; пробіли на початку рядка ігноруються; порожні рядки ігноруються. * Значення в лапках: значення повинні бути укладені в одинарні лапки (`'`). * Вміст всередині одинарних лапок зберігається буквально. Не застосовується обробка екрануючих послідовностей, згортання пробілів або інтерпретація символів. * Нові рядки всередині одинарних лапок зберігаються (підтримуються багаторядкові значення). * Коментарі: рядки, що починаються з `#`, розглядаються як коментарі та ігноруються. Символ `#` всередині значення в одинарних лапках не є коментарем. Приклади: ```env # comment DB_ADDRESS='address' MULTI='line1 line2' ``` ### Непідтримувані форми {#unsupported-forms} * Значення без лапок **заборонені**: * `VAR=value` — не підтримується. * Значення в подвійних лапках **заборонені**: * `VAR="value"` — не підтримується. * Кілька сусідніх рядків у лапках **не** підтримуються: * `VAR='val1''val2'` — не підтримується. * Будь-яка форма інтерполяції, розширення або конкатенації **не** підтримується: * `VAR='a'$OTHER` або `VAR=${OTHER}` — не підтримується. Сувора вимога щодо використання одинарних лапок гарантує, що kubelet сприймає значення буквально під час завантаження змінних середовища з файлів. ## Що далі * Дізнайтеся більше про [змінні середовища](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). * Ознайомтесь з [Оголошенням змінних середовища для контейнера](/docs/tasks/inject-data-application/define-environment-variable-container/) * Дізнайтеся про [Експонування інформації про Pod для контейнерів через змінні середовища](/docs/tasks/inject-data-application/environment-variable-expose-pod-information)