Comments 4
Самое интересное - как это всё будет обновляться?
В этой схеме (как и в целом в Kubernetes) большинство компонентов запускается без сохранеия состояния. А значит их можно легко обновлять просто применив в кластер манифесты с новыми версиями.
Перекатывание воркеров происходит так же как и в любом облаке, путем удаления старых виртуалок и введения в кластер новых
Я имел в виду обновление Management Cluster. При таком подходе, на своём железе, нужно будет иметь ещё одну ноду, которая будет не меньше, чем самая производительная нода в кластере(при полной утилизации кластера), только для обновлений?
Наличие хотя бы одной резервной ноды — это хорошая практика, прежде всего потому, что необходимо иметь ресурсы, позволяющие вашей рабочей нагрузке переехать на другую ноду в случае отказа. На самом деле резервная нода не обязана постоянно находиться в режиме простаивания, она может функционировать как обычная нода в кластере. Я бы рекомендовал загружать ваши узлы не более чем на 75%-85% в зависимости от объёма самой ноды, чтобы оставался небольшой запас по ресурсам.
DIY: Ваше собственное облако на базе Kubernetes (часть 3)