Я создаю приложение, использующее helm (v3.3.0) + k3s. Программа в контейнере использует разные файлы конфигурации. На данный момент существует всего несколько файлов конфигурации (которые я добавил вручную перед созданием образа), но я хотел бы добавить возможность добавлять их динамически, когда контейнер запущен, и не терять их после того, как контейнер / модуль мертв. В докере я бы сделал это, открыв такую папку:
docker run [image] -v /host/path:/container/path
Есть ли аналог для руля? Если нет, то как бы вы предложили решить эту проблему, не прекращая использовать helm / k3s?
@ rock'nrolla Exatly. Таким образом, я не потеряю новые файлы конфигурации при завершении работы модуля, и я хотел бы использовать тот же каталог для будущих выпусков.
Разве вы не можете добиться того же, используя требование постоянного объема?
Вам в основном нужно использовать hostPath в качестве тома в кубернетах. Вы сохраните данные при завершении работы модуля, а также сможете динамически добавлять файлы. Это должно вам помочь? stackoverflow.com/questions/50001403/…
Некоторая документация по Persistent Volume, особенно типа hostPath: kubernetes.io/docs/tasks/configure-pod-container/…
@dishantmakwana Честно говоря, я новичок в k3s и helm, поэтому не знаю, но думаю, что то, что вы предложили, может помочь.
@ rock'nrolla Мне кажется, я неправильно понял, как использовать helm и kubernetes с самого начала. Могу ли я использовать kubernetes yamls со штурвалом? Я думал, что helm сгенерирует все, указав helm yamls. Спасибо за ссылки
Файлы Helm YAML находятся Файлы Kubernetes YAML, только с дополнительным {{ templating }}.


В Kubernetes (Helm - всего лишь инструмент для этого) вам нужно сделать две вещи, чтобы смонтировать путь к хосту внутри контейнера:
spec:
volumes:
# 1. Declare a 'hostPath' volume under pod's 'volumes' key:
- name: name-me
hostPath:
path: /path/on/host
containers:
- name: foo
image: bar
# 2. Mount the declared volume inside container using volume name
volumeMounts:
- name: name-me
mountPath: /path/in/container
Множество других типов томов и примеров в Kubernetes документация.
Спасибо за ответ. Я видел много руководств о том, как это сделать с кубернетами, но не понимаю, как это отразится на Helm. Прямо сейчас у меня есть значения, configmap, persistentvolume и persistentvolumeclaim yamls (для всего приложения) и yaml развертывания для рассматриваемого контейнера. Где правильное место для установки hostPath?
@Jing Поначалу это немного сложно: при развертывании создаются наборы реплик, которые создают поды, где находятся контейнеры. Итак, ответ заключается в том, что вам нужно поместить его в deployment.yaml под spec.template.spec (это спецификация шаблона пода).
@Jing, и если вы хотите вместо этого использовать Persistent Volume Claim (это похоже на именованный том в Docker, т.е. вы не указываете, где он находится на хосте, просто его имя), вам необходимо использовать другой тип тома в volumes: persistentVolumeClaim . В разделе persistentVolumeClaim вместо path вы используете claimName и указываете имя претензии из persistentvolumeclaim.yaml.
Спасибо, я разберусь. Думаю, я неправильно понял, как правильно пользоваться рулем и k3s.
В Kubernetes есть специальная конструкция для хранения файлов конфигурации, ConfigMaps. Helm, в свою очередь, поддерживает Доступ к файлам внутри шаблонов, который может помочь вам скопировать их в объекты ConfigMap. Минимальная настройка здесь будет выглядеть так:
# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
config.ini: |
{{ .Files.Get "config.ini" | indent 4 }}
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment:
metadata: { ... }
spec:
template:
spec:
volumes:
- name: config-data
configMap:
name: my-config # matches ConfigMap metadata: { name: }
containers:
- volumeMounts:
- name: config-data # matches volume name: in this file
mountPath: /container/path
Здесь вы можете использовать шаблоны шаблонов Helm по-разному: для динамического создания содержимого ConfigMap, для установки переменной среды, указывающей, какой файл использовать, и так далее.
Не используйте здесь тома hostPath. Поскольку Kubernetes спроектирован как кластерная среда, у вас нет особого контроля над тем, на каком узле будет работать данный под; вам придется скопировать эти файлы конфигурации на узел каждый в кластере и попытаться обновить их все при изменении файла. Это огромная проблема обслуживания, особенно если у вас нет прямого доступа файловой системы к узлам.
Спасибо за ответ. Итак, если я правильно понимаю этот подход: configmap yaml берет все файлы, указанные в строке .Files.Get (которая может быть динамической), и вставляет их в том, который будет смонтирован в контейнере по заданному пути "/ container /дорожка". Но если бы я внес изменения в файлы внутри контейнера, то у меня не было бы этих изменений снаружи. Кроме того, я потеряю все изменения после завершения работы модуля, верно?
Изменяет ли приложение эти файлы (поэтому они должны быть постоянными данными) или это просто конфигурация? Если вы измените шаблон и helm upgrade при установке, это изменит ConfigMap в кластере (вам может потребоваться небольшая работа, чтобы перезапустить модули), но если заявление изменяет содержимое, тогда он должен быть в объеме какой-то (но не hostPath, поскольку он не обязательно переживет перезапуск модуля или автоматическое масштабирование кластера, завершающее работу узла).
Да, приложение внутри контейнера обновляет / создает / удаляет эти файлы конфигурации. Я хотел бы сохранить состояние этих файлов после завершения работы с модулем, чтобы я мог использовать их снова при запуске другого модуля.
Я бы сказал, что причина упоминания тома hostPath заключается в том, что это было то, что было задано в вопросе OP (эквивалент сопоставления хоста с каталогом контейнера в кубернетах). Это не лучшая практика, но, насколько я понял, это выходит за рамки этого конкретного вопроса.
Вы просто хотите сопоставить каталог хоста с каталогом контейнера в кубернетах, как вы это делали в докере, а затем использовать эту конфигурацию в диаграмме управления?