Антипаттерны деплоя в Kubernetes. Часть 2

[DarkHost]

Смешивание кластеров Production и Non-Production

Ну, стагинг с продом иметь в одном кластере — нормально. Если мы конечно под стагингом подразумеваем пре-прод. Это как минимум помогает избежать проблем, когда подключается какой-то новый внешний ресурс, а он оказывается недоступен из кластера. На стагинге это сразу будет заметно.
И вот чего я совсем не понимаю, так это смысл тащить дев окружения в кубер. Как по мне, они прекрасно в докере живут.

[IDWarlock]

Иметь отдельный кластер для Pre Production хороший подход, как минимум для тестирования обновления самого кластера. Автор статьи дал хорошее определение Pre Production — клон Production, но с меньшими ресурсами.

По поводу Dev — как минимум динамические стенды, которые очень удобно создавать в Kubernetes. Завести дополнительный кластер для Dev совсем не трудно, особенно если работаете в облаках и не дорого, если экономно)

[sergey-b]

В предыдущей статье не понял один момент.

Рассмотрим несколько подобных ситуаций:
…
потребность в init или sidecar контейнерах для правильной работы
…

Что с этой потребностью не так, и чем ее следует заменить?

Можете прояснить этот вопрос?

[kost]

Как по волшебству, будет создана динамическая среда: feature-a-b-together.staging.company.com или staging.company.com/feature-a-b-together.

Можно подробнее, как это организовано?