Гарантии согласованности Kubernetes ConfigMaps?

Question

Пытаюсь решить, где хранить некоторые критические конфигурации шардинга, и я пока не нашел достаточной документации о надежности Kube ConfigMaps, чтобы облегчить мой ум.

Допустим, у меня есть одно кластерный модуль кубических модулей c, который вводит переменную среды со значением записи configmap при запуске модуля (используя configMapKeyRef ). У меня есть много модулей, работающих на основе этой спецификации c.

1. I kubectl edit Запись configmap и ожидаю успешного завершения операции.
2. Я перезапускаю модули.

Гарантируется ли на этих модулях новое значение configmap? (Или, если это не удастся, есть ли время, которое мне нужно подождать, прежде чем перезапускать модули, чтобы убедиться, что они получают новое значение?)

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

Answer 1

Kubernetes - это система окончательной согласованности. рекомендуется - создать новое ConfigMap , когда вы хотите изменить значение.

Рассматривается изменение данных, хранящихся в действующей configMap в кластере. плохая практика. Развертывания не знают, что изменились configMaps, на которые они ссылаются, поэтому такие обновления не действуют.

Использование Декларативное управление конфигурацией с помощью Kustomize , это проще сделать с помощью configMapGenerator

Рекомендуемый способ изменить конфигурацию развертывания -

1. создать новую configMap с новым именем,
2. исправьте развертывание, изменив значение имени соответствующего поля configMapKeyRef.

Deployment

При использовании Kustomize для Deployment и ConfigMap с помощью configMapGenerator имя ConfigMap будет сгенерировано на основе содержимого, а ссылки на ConfigMap в Deployment будут обновлены с созданным именем, так что новый подвижный развертывание будет запущено.