Я не приверженец DevOps, но с точки зрения разработчика:
Если у вас много контейнеров в POD:
, вам следует знать: проблемы жизненного цикла - какой контейнер запускается первым, какой заканчивается первым и т. д.
как оценить «работоспособность» модуля как логической единицы. Если в модуле один контейнер, то все ясно - если контейнер работает - это нормально. Но если их много, то какие пробы (готовность, живучесть) вы определяете? Что произойдет, если один контейнер мертв, весь ли под все еще работает?
потенциально легче найти место в кластере кубернетов для реплики маленьких подов, чем больших (имеющих много констейнеров) и поэтому, вероятно, потребляет гораздо больше ресурсов)
вы жертвуете потенциальной гибкостью масштабируемости. Скажем, контейнеры A и B находятся в одном контейнере. Что, если вы хотите масштабировать только контейнер A.
тот же элемент, что и выше, применяется к гибкости управления выпусками (развертывание, канареечные выпуски, откат к предыдущей версии - все это)
вам нужно будет подумать о решении сбора журналов / метрик из контейнеров внутри модуля. Это может быть легко или утомительно в зависимости от фактического стека технологий, но это вопрос, который вам все равно придется решить. Возможно, когда у вас есть несколько контейнеров в модуле, решение может стать более сложным.
несколько менее удобная работа с kubectl. Хорошо, это мелочь, но все же. Вам всегда придется добавлять этот флаг -c. Хотите увидеть журналы работы модуля? Добавьте -c <container-name>. Хочешь сделать kubectl exec -it - опять -c <container-name>.
Конечно, иногда допустимым является запуск контейнера sidecar (например, для служебных заторов). Но в целом это инструмент для работы.
Интересно, что я нашел статью , в которой говорится о придании бортовым контейнерам «особого отношения». Это может быть в некоторой степени актуальным, хотя из вопроса я понимаю, что вы не рассматриваете «боковые автомобили», если я правильно понял