На цій сторінці показано, як налаштувати змінні середовища для контейнерів у Podʼі за допомогою файлу.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.
Для перевірки версії введіть kubectl version.
У цій вправі ви створите Pod, який отримує змінні середовища з файлів, проєцюючи ці значення в запущений контейнер.
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, який використовує 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 сприймає значення дослівно під час завантаження змінних середовища з файлів.