В Kubernetes есть специальные типы объектов для такого рода вещей.Файлы учетных данных API, которые вы можете хранить в Secret , а файлы шаблонов (если они еще не встроены в ваш образ Docker) могут быть помещены в ConfigMap .Оба они могут быть переведены в переменные среды или смонтированы как искусственные тома в запущенных контейнерах.
По моему опыту, попытка хранить данные непосредственно на узле не является хорошей практикой.Достаточно часто иметь несколько узлов, чтобы не иметь прямого доступа к этим узлам для входа в систему, и чтобы их можно было создавать и уничтожать вне вашего прямого контроля (представьте себе, что автоскалер работает на облачном провайдере, который создает новый узел, когда все существующиеузлы запланированы на 90%).Вероятность того, что ваши данные не будут (или не будут) находиться на том хосте, на котором вы их ожидаете, вполне вероятна.
Это приводит к увеличению количества объектов Kubernetes и связанных с ними ресурсов, и вы можете найти Хелм диаграмма, чтобы быть хорошим ресурсом, чтобы связать их вместе.Вы можете проверить диаграмму в системе контроля версий вместе со своим приложением и развернуть все это за один раз.Несмотря на то, что у него есть несколько полезных функций, помимо простого объединения ресурсов (система конфигурации во время развертывания, язык шаблонов для самого YAML Kubernetes), вы можете игнорировать их, если они вам не нужны, и просто написать несколько файлов YAML инебольшой контрольный файл.