Требования к разработке приложения в Kubernetes

[VolCh]

то просто писать их из приложения в так называемые Stdout/Stderr

Делал как-то разграничение по уровням логированиям, что писать в /dev/stdout, а что в /dev/stderr. На автомате. Но сделал и не понял зачем. Есть какой-то смысл разделять или можно ограничиться только stderr, или только stdout?

Вы запускаете без реквестов ваше приложениие, Kubernetes не знает, сколько у вас чего, на какие ноды можно запихивать. Ну и пихает, пихает, пихает на ноды.

Вот реквесты и лимиты, как по мне, самое сложное. Вот есть условный веб-сервер. В простое потребляет, например, 100 Мб, и на каждый запрос берёт ещё 100 Мб (для дикого упрощения, а по факту от 1Мб до 500Мб). Взял, отработал запрос, отдал. Пускай даже совсем не течёт.

Но он асинхронный и/или многопроцессный/многопоточный, то есть может одновременно обрабатывать много запросов. И мы не знаем сколько у нас может быть одновременных запросов. Реквест, допустим, сделаем по простою плюс один запрос (с учётом дикого упрощения), чтоб минимально мог работать. А лимит? Вполне можем получить ситуацию, что либо контейнер умирает по лимиту, хотя по факту памяти хоть жуй на сервер свободной. Но и вполне можем получить, ччто память кончилась, а лимиты ещё не достигнуты.

[darthslider]

По лимитам круто выглядит verical pod autoscaler на самом деле, но вообще лимиты это больно. Или низкая утилизация ресурсов или странный оверкомит. Надо найти для себя приемлемую середину.

[eugef]

Мы в stdout пишем access logs, а в stderr — все остальное (service logs).
Получается удобно. Эти логи очень сильно по размерам отличаются (access logs гораздо больше), соответсвенно их ротация и индексация настроены по разному

[therb1]

12 факторов растянутые на 12 страниц. Мои аплодисменты.
12factor.net