Сохранение Configmap в kubernetes

У меня есть модуль Kubernetes (назовем его ПОД-А), и я хочу, чтобы он использовал определенный файл конфигурации для выполнения некоторых действий с использованием API k8s. Файл конфигурации будет представлять собой YAML или JSON, который будет анализироваться приложением внутри модуля.

Файл конфигурации размещается на сервере приложений в облаке, и его последнюю версию можно получить на основе триггера. Файл конфигурации содержит сведения о конфигурации всех развертываний в кластере k8s и будет использоваться для обновления развертываний с использованием API k8s в ПОД-А.

Теперь я думаю о том, чтобы сохранить этот файл конфигурации в карте конфигурации, и каждый раз, когда извлекается новый файл конфигурации, модуль создает новую карту конфигурации, использующую API k8s.

Что я хочу сделать, так это обновить предыдущую карту конфигурации с определенным флагом (ключом и значением), который в основном поможет приложению узнать, какая версия развертывания является текущей. Итак, скажем, у меня есть работающий кластер k8s с несколькими модулями в нем, есть карта конфигурации, в которой есть все детали конфигурации для этих модулей (версия образа, пространство имен и т. д.) и флаг, уведомляющий, что это текущее развертывание и приложение внутри ПОД-А узнает об этом, загрузив файл config-map. Теперь, когда извлекается новый файл конфигурации, создается новая карта конфигурации, и для флага текущего развертывания устанавливается значение false для предыдущей карты конфигурации и значение true для последней созданной карты конфигурации. Затем эта карта конфигурации используется для обновления всех модулей в кластере.

Я знаю, что есть много деталей, но мне пришлось объяснить их, чтобы задать следующие вопросы:

1) Можно ли использовать configmaps для этой цели?

2) Можно ли обновить configmaps или нужно их полностью переписывать? Я думаю написать файл в configmap, потому что это было бы намного проще.

3) Я знаю, что configmaps хранятся в etcd, но сохраняются ли они на диске или хранятся в памяти?

4) Допустим, ПОД-А падает, повлияет ли это на configmaps? Связаны ли они каким-либо образом с жизненным циклом стручка?

5) Если сам кластер k8s выходит из строя, что происходит с `configmaps? Поскольку они находятся в и т. д., и если они сохраняются, то будут ли они снова доступны?

Примечание. Существует также ограничение на размер configmaps, поэтому я должен помнить об этом. Хотя я предполагаю, что 1 МБ — это достаточный размер для сохранения файла конфигурации, поскольку обычно он занимает несколько байтов.

Ясно ли мое понимание. Вы хотите использовать карты конфигурации для развертывания и динамического обновления приложения, работающего в модуле, на основе изменения значения в карте конфигурации?

Ankit Deshpande 03.04.2019 13:16

Да, точно, но обновление будет запускаться пользователем из приложения.

el323 03.04.2019 14:01
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
1
2
1 161
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

1) I think you should not use it in this way.

2) ConfigMaps are kubernetes resources. You can update them.

3) If etcd backups to disk are enabled.

4) No. A pod's lifecycle should not affect configmaps, unless pod mutates(deletes) the configmap.

5) If the cluster itself goes down. Assuming etcd is also running on the same cluster, etcd will not be available till the cluster comes back up again. ETCD has an option to persist backups to disk. If this is enabled, when the etcd comes back up, it will have restored the values that were on the backup. So it should be available once the cluster & etcd is up.

Существует несколько способов монтирования configMap в pod, таких как переменные env, файл и т. д. Если вы измените карту конфигурации, значения не будут обновлены в configMaps в виде файлов. Динамически обновляются только значения для configMaps в качестве переменных env. И теперь процесс, работающий в модуле, должен обнаружить, что переменная env была обновлена, и предпринять какие-либо действия.

Поэтому я думаю, что система будет слишком сложной.

Вместо этого инициируйте развертывание, которое убивает старые модули и создает новый модуль, использующий обновленные configMaps.

Другие вопросы по теме