storage". Зачастую это странность аппа, который хочет перезаписывать конфиг на диске, обычно этот процесс сопровождается хаком initcontainer который из configmap копирует конфиги в emptyDir. Например так делают mattermost и gitlab-minio.
Когда знаешь, что ничего в configmap обновлять не надо - понимаешь что такие поды _можно_ грохать.
Вопросы
1) как узнать какие именно volume блокируют мув контейнера, в идеале в том же сообщении, (у кого еще болит, примут ли они такой mr?)
2) как объяснить куберу, что есть поды которые _можно_ грохать не смотря на локальный volume
3) есть такое emptyDir: medium: Memory - считаются ли такие volume блокирующими для drain?
1) во время дрейна тебе выведется список данных подов 2) либо руками убиваешь, лиьо --delete-local-data= true 3) да, --delete-emptydir-data=true
не, проблема в том, что там все вперемешку, т.е. это я знаю что mattermost & gitlab-minio можно убивать потому что знаю что именно делают initcontainers и зачем, а там еще другие поды, и из манифеста неясно зачем им local storage delete-emptydir-data там подсказывается, но это слишком жестко, не все можно убивать неглядя
Если не можно убивать, этому не место в кубере
не, это максимализм какой-то - я вполне могу себе представить как readreplica постгреса живет в кубере и как и любой базе ей сетевой сторадж не подходит и нода требует maitenance, и вроде убить _можно_ но переналивать зачастую сильно долго если базовый бекап большой. понятно, что база в k8s это особый вид холивара до сих пор, но я к тому что случаи бывают разные. мне бы хватило, если бы я мог пометить все emptyDir с medium: Memory и мог сказать куберу, что такие volumes можно смело грохать
Это нормальный, правильный максимализм. Если всякие нубье хранит ценные данные на empty dir, то лучше, если этот косяк вылезет днем, чем в 5 утра субботы, когда узел упадет
но почему тогда delete-emptydir-data не дефолт? (и я думаю правильно, на всякий случай)
Обсуждают сегодня