Comments 16
Окей, у нас в Deployment’е 6 реплик, поэтому мы можем по очереди, вручную сделать всем delete pod.
Вместо ручного удаления подов, лучше просто добавить/изменить аннотацию деплоймента (не все хелм используют), что-то рандомное:
kubectl patch deploy <deployemnt-name> -p \
"{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
Важный момент с ConfigMap состоит в том, что в них нельзя положить файлы неограниченного размера.
Так как ConfigMap хранятся в базе etcd, то лимит на их размер равен 1 мегабайту.
Я конечно извиняюсь, но зачем ручное удаление пода? Можно же напрямую сказать "перезапусти deployment":
kubectl rollout restart deployment deployment-name
Этот примитив K8s позволяет использовать Go templates в конфигах, т.е. рендерить их подобно HTML-страницам
Кажется, рендеринг с помощью Go templates позволяет всё же Helm, а не непосредственно сам Кубернетес.
kubectl set env deployment/nginx --env='LAST_UPDATE'=$(date +%d.%m.%y-%H:%M:%S) --namespace=default
Ниже мое личное мнение. Не претендую на абсолютную истину.
С появлением ConfigMap в Kubernetes конфиги перешли на очередной виток развития: использование шаблонизатора принесло им гибкость, сопоставимую с рендерингом HTML-страниц. Благо, такие усложнения не заменили существующие решения, а стали их дополнением. Поэтому для администраторов (а скорее — даже разработчиков), которые считают новые возможности излишними, по-прежнему доступны старые добрые файлы.
Для собственных приложений конфигмапы не нужны. И даже более того вредны. Аргументы
- Чтобы перезапустить приложение при изменении конфигмапы, мы выяснили из статьи, необходимы костыли — вроде патча деплоймента хешом конфига или использование сторонних сайдкаров.
- конфигмапы ограничены по размеру
- как развитие темы конфигмапов — секреты — ничерта они в кластере не хранятся безопасным образом. Это фикция. Если мы хотим безопасно — нужно делать как Авито — выносить секреты во внешнее хранилище типа vault и оттуда его втаскивать.
- если мы используем хельм — мы с тем же успехом можем портянку конфигов инжектировать через env в самом описании деплоймента. Какая нам разница — вкидывать 1, 10 или 100 переменных, если это делает шаблонизатор?
Зачем могут понадобиться конфигмапы — точно, если мы хотим засунуть в кубернетес кластер легаси. Ну, там nginx, постгрес или что-то подобное — что ест конфиги в виде файлов. Конфигмапу можно подключать как файл и это РЕАЛЬНО удобно. Но BEWARE! Subpath может дать очень неожиданные эффекты. С другой стороны, есть же сборки от bitnami, которые уже приведены к концепции 12 факторов и принимают конфиги не в виде файлов, а виде env'ов и тогда см. предыдущие соображения.
Вот бест пректис и хотелось увидеть в настойщей статье, а не какие-то оторванные от жизни выкладки
Накину еще мыслю, пока не заснул. В случае prometheus и nginx — программ, которые умеют не применять конфиг, если он некорректный — можно на еще одну граблю наступить. Меняем мы configmap, reloader срабатывает и дает команду на применение нового конфига, но мы где-то облажались и конфиг неверный. Сервис его не применяет — как мы про это узнаем? Т.е. нам нужен еще один шаг — проверка того, что конфиг не применился.
Если же сделать как предложил я — зашить конфиг БЕЗ конфигмапы в само описание деплоймента — кубернетес увидит, что деплоймент поменялся, триггернет апдейт и поды начнут падать в случае кривого конфига, произойдет откат до предыдущей версии (* тут нюансы, но пойдет) — и мы увидим проблему.
По мне так наоборот, писать конфиги напрямую в деплойменте это по меньшей мере неудобно.
Если у нас конфиги — это километровые yaml или, чем черт не шутит, легаси xml с вкраплением go темплейтинга — то манифест деплоймента превращается в нечитаемую кашу. А когда конфиги в конфигмапах в отдельных файлах в гите — это нагляднее, понятнее кто куда делал изменения, удобнее писать пайплайны (на определенные тесты при изменении конфигов и другие тесты при изменении деплойментов или других компонентов).
Плюс разграничения в правах. Допустим мы хотим девелоперам на этом окружении дать права на изменения конфигмапов, но не на изменения самих деплойментов.
Плюс разграничения в правах. Допустим мы хотим девелоперам на этом окружении дать права на изменения конфигмапов, но не на изменения самих деплойментов.
Это выглядит как минимум странно. Как они отлаживаться будут? Ну, и раз есть доступ к конфигмапам — значит, они смогут сломать этот деплоймент.
Если у нас конфиги — это километровые yaml или, чем черт не шутит, легаси xml с вкраплением go темплейтинга
Повторю свой тезис. Если это Легаси с конфиг файлами, неважно — хмл, свой формат, ямл или что-то другое — да, конфигмапы рулят, т.к. их можно смонтировать как файл. Не нужно переписывать докерфайл и энтрипойнт. Если же у нас софт свой со 100500 ручек — какая разница куда инжектировать параметры? Вы говорите всерьез, будто люди в деплойменте в кубере что-то глазами смотрят. Постоянно.
А когда конфиги в конфигмапах в отдельных файлах в гите — это нагляднее, понятнее кто куда делал изменения, удобнее писать пайплайны (на определенные тесты при изменении конфигов и другие тесты при изменении деплойментов или других компонентов).
Не аргумент, если используется хельм. Там все параметры в values.yaml сплошной портянкой.
Можете попробовать переубедить :-)
Это выглядит как минимум странно. Как они отлаживаться будут? Ну, и раз есть доступ к конфигмапам — значит, они смогут сломать этот деплоймент.
Например, у меня есть неймспейс с системными утилитами, ну там кронджобы которые делают чистку артифкатори, которые суспендят окружения по вечерам и в конце недели и так далее. Я тоже не любитель конфиг файлов, считаю что параметризировать свои приложениия удобнее энв переменными. Но зачем мне давать доступ разработчикам к правке своих огромных манифестов, где сотни строк кода? Я им говорю, если вам нужно свою группу енвайронментов добавить в suspend-list — вот в этом секрете/конфигмапе одна строчка, добавьте туда через пробел регэксп на свои неймспейсы и все. Это гораздо проще как для разработчика так и для меня, повышается и читаемость кода и уменьшается шанс на ошибку.
А какие нибудь часто применяемые действия, например если разработчик хочет чтобы его энв сегодня саспендился в 23-00, а не в обычные 19-00, так вообще лучше на уровень аннотаций к неймспейсу выносить, чем править конфиг самого приложения.
Если же у нас софт свой со 100500 ручек — какая разница куда инжектировать параметры? Вы говорите всерьез, будто люди в деплойменте в кубере что-то глазами смотрят. Постоянно.
Люди не смотрят, а автоматизация смотрит. Допустим если у нас в коммите поменялся манифест деплоймента, то гитлаб-сиай установит новое окружение в отдельный неймспейс и прогонит инфраструктурные тесты. А если только файлик с конфигмапом, то деплоймент останется тот же и запустятся только тесты по хелсчекам самого приложения.
Не аргумент, если используется хельм. Там все параметры в values.yaml сплошной портянкой.
В Helm тоже можно использовать обвзяки, чтобы был не один сплошной values.yaml, а много values файлов где параметры сгруппированы по своим задачам/по смыслу.
Люди не смотрят, а автоматизация смотрит
автоматизация может посмотреть изменился ли сам деплоймент по факту или просто конфиг, даже если он переменными. Плюс конфиг в теории нужно валидировать — выше я уже писал, что там могут какую-либо белиберду написать и все сломается. Вопрос только лишь в сложности этой самой автоматизации.
А какие нибудь часто применяемые действия, например если разработчик хочет чтобы его энв сегодня саспендился в 23-00, а не в обычные 19-00, так вообще лучше на уровень аннотаций к неймспейсу выносить, чем править конфиг самого приложения.
У нас нет таких проблем. Развернули окружение. Оно посуществовало какое время. И убили его. Или автоматом подчистилось — в зависимости от того какое это окружение
ConfigMaps в Kubernetes: нюансы, о которых стоит знать