Используя некоторое время kubernetes и helm, я нахожу весьма неестественным обрабатывать конфигурацию приложения в мире kubernetes только с помощью helm.
Вот несколько причин:
- Конфигурация управляется вне кластера, используя helm client и дополнительные yamls для пользовательских настроек. Файлы yaml дополнительных значений не проверены и могут со временем стать достаточно большими.
- Дополнительные значения не проверяются и не сохраняются, вам необходимо найти собственный способ отслеживания последней примененной пользовательской конфигурации.
- Обновление конфигурации не удобно для пользователя: вам придется обновить дополнительные значения yaml, выполнить обновление helm, дождаться перезапуска ваших служб (и это только в том случае, если вы правильно написали диаграмму helm для повторного развертывания рабочих нагрузок в конфигурации. карта обновлений). И это только для того, чтобы обновить что-то вроде порога в вашем приложении.
- Использование etcd в качестве базы данных для вашего приложения больше похоже на анти-шаблон, так как etcd уже очень чувствителен к задержке записи на диск из-за требований к последовательному вводу-выводу .
- Беспорядок повторного использования / сброса значений поведение повторного использования сброса шлема
Мне было интересно, если использовать гибридное решение, такое как
- helm для обработки только конфигурации ресурсов kubernetes
- для конфигурации приложения c используйте централизованную службу конфигурации внутри кластера (например, что-то построенное поверх Spring Cloud Config или аналогичных проектов)
может лучше подходить для этой экосистемы.
Как вы управляете конфигурацией на уровне приложений в k8s? Ты доволен только шлемом? Есть ли лучшее решение, которое вы применили на практике, и оно окупилось?