Comments 4
Смешивание кластеров Production и Non-Production
Ну, стагинг с продом иметь в одном кластере — нормально. Если мы конечно под стагингом подразумеваем пре-прод. Это как минимум помогает избежать проблем, когда подключается какой-то новый внешний ресурс, а он оказывается недоступен из кластера. На стагинге это сразу будет заметно.
И вот чего я совсем не понимаю, так это смысл тащить дев окружения в кубер. Как по мне, они прекрасно в докере живут.
+2
Иметь отдельный кластер для Pre Production хороший подход, как минимум для тестирования обновления самого кластера. Автор статьи дал хорошее определение Pre Production — клон Production, но с меньшими ресурсами.
По поводу Dev — как минимум динамические стенды, которые очень удобно создавать в Kubernetes. Завести дополнительный кластер для Dev совсем не трудно, особенно если работаете в облаках и не дорого, если экономно)
По поводу Dev — как минимум динамические стенды, которые очень удобно создавать в Kubernetes. Завести дополнительный кластер для Dev совсем не трудно, особенно если работаете в облаках и не дорого, если экономно)
+2
В предыдущей статье не понял один момент.
Рассмотрим несколько подобных ситуаций:
…
потребность в init или sidecar контейнерах для правильной работы
…
Что с этой потребностью не так, и чем ее следует заменить?
Можете прояснить этот вопрос?
0
Как по волшебству, будет создана динамическая среда: feature-a-b-together.staging.company.com или staging.company.com/feature-a-b-together.
Можно подробнее, как это организовано?
0
Sign up to leave a comment.
Антипаттерны деплоя в Kubernetes. Часть 2