Что вас ждёт до, после и во время перехода на Kubernetes – бизнесу на заметку

[VolCh]

Насколько критично по-вашему иметь именно (микро)сервисную архитектуру? Если без неё получилось «загнать» систему частично в stateless контейнеры, частично с монтируемыми volume, то что ещё нужно чтобы доработать её до использования в k8s?

[true_engineering]

Вы можете развернуть систему в K8S и так, если уже упаковали её в Docker. Цель нашей статьи рассказать про K8S как про один из инструментов, позволяющий достичь цели time to market (быстрой доставки решений до продашна): быстро и надёжно разворачивать приложения на любой инфраструктуре, обеспечивать высокую степень отказоустойчивости, обновлять систему незаметно для пользователей. Но для того чтобы воспользоваться всеми этими возможностями, мы рекомендуем разделить систему на микросервисы.

[KirEv]

Вы бы примеров добавили…

[true_engineering]

В этой статье рассказали о самой концепции, а о тонкостях и примерах обязательно расскажем в следующих материалах.

[Valeriy_tw3eX]

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

[true_engineering]

БД мы вынесли за пределы контейнеров/Кубернетиса, так как у нее свои регламенты обновления/бэкапа/администирования. В тестовых окружениях мы разворачивали её вне контейнеров, а в проде вынесли на отдельную виртуальную машину.

[markeloff86]

Каким образом проводилось тестирование стабильности конфигурации компонентов и версий кластера Kubernetes?
P.S. Это у вас в пункте 2 написано.

[true_engineering]

Разворачивание кластера, анализ ошибок/предупреждений в логах докера/кубернетиса, запуск тестовых приложений и снова анализ логов.

В связке Oracle Linux + docker + k8s из стандартных репозиториев не было ошибок вообще, а предупреждений было 7 штук и все они совершенно некритичные. После этого мы развернули нашу микросервисную систему и провели нагрузочное тестирование (смоделировали работу приложения в пиковом режиме нагрузки) — ничего не упало, ошибок в логах платформы не было, а сама система отработала в расчетное время с верными результатами.

[amdmax]

Про минусы не увидел. k8s это сплошные плюсы?

[VolCh]

Прежде всего это дорого. По крайней мере, если текущая команда о контейнейрации и оркестрации вообще и k8s в частности первый раз слышит. А если решите пойти по пути «всё в интернете есть, пускай гуглят», то может оказаться очень дорого, и хорошо если придётся просто выкинуть несколько человеко-месяцев на обучение и эксперименты, а не будет фатальных простоев, а то и чего хуже, типа выставленной наружу продакшен базу без паролей для рута

[andreyverbin]

Основная проблема в том, что на практике реализуется смесь из этих двух сценариев:
а) У вас есть девопс команда, которая общается с k8s и крутит его по запросам разработки и бизнеса. Тогда теряется гибкость, возрастает количество коммуникаций, скорость работы снижается. Теперь кластер надо крутить силами девопс, а это значит ставить таски, принимать работу.
б) Ваша команда разработки должна выучить helm, k8s и docker. А это несколько недель на каждого разработчика.

В итоге k8s это модно, гибко и очень дорого.