Резервирование в Kubernetes: оно существует

[Goodsmileduck]

А что если разделять поды из деплоймента/даемонсета/стейтфулсета по разным node labes? Каждый лейбл соответсвует своей зоне доступности где находится нода. Использвать nodeSelector и nodeAffinity. В таком случае если упадет одна из зон, будут доступны поды из других зон. Или варианты с несколькими зонами не рассматриваются?

[4umak]

Ну, по факту, примерно такой расклад и предлагается. Только деплоить нужно не всё, определённые вещи, типа кронджобов придётся держать отдельно. А так да, раскатываем релизы параллельно в два разных ведра.

[AlexeyKovyazin]

Привет. Спасибо за статью. Очень хотелось бы небольшую статью-спинофф с более подробным обоснованием «Если мы умные люди и не держим базу в кубере». Сейчас все больше людей, которые хотят держать БД в контейнере… как им объяснить, почему это плохо?

[shurup]

Мы из другой компании, но на эту тему не так давно был довольно подробный доклад (на HighLoad++ 2018): «Базы данных и Kubernetes».

[gto]

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

[Dmitry1987]

Здравствуйте, уточните пожалуйста какую версию «kubernetes federation» вы сравнивали: v1 или v2? Просто похоже что даже 1-я версия (которая уже deprecated) например поддерживает «Federated Secrets», а во второй уже даже поддерживается «Custom Resource Definitions», что подчеркивается в ряде источников. Хочется понимать, если сейчас стартовать multi-dc cluster, — можно уже спокойно использовать «kubernetes federation»?