Комментарии 10
Привет Андрей, решил потеснить flant?
Итак, предположим вы решили строить ваше собственное облако. Для того чтобы с чего-то начать вам нужен базовый слой. Вам нужно подумать не только о том как вы установите Kubernetes на ваши сервера, но и о том как вы будете его обслуживать и обновлять. Учитывайте тот факт что вам придётся думать о таких вещах как обновление ядра, установке модулей, так и пакетов и патчей безопасности. То есть гораздо больше вещей о которых вам обычно не приходится беспокоиться при использовании готового Kubernetes в облаке.
Облако == биллинг.
Нет биллинга - кластер.
Без биллинга, конечно, никуда. И на данный момент мы не предлагаем решения для этой задачи.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг. А наше решение является своего рода фреймворком, которое легко интегрируется и выступает в роли бэкенда:
Собственно статья больше о том, как такой бэкенд можно реализовать с использованием свободных технологий самостоятельно.
Сейчас мы подразумеваем что у наших клиентов уже есть какой-никакой биллинг и веб-портал для заказа услуг.
И до сих пор нет кубера.
НУ ДА
Будет интересно посмотреть, как будет работать такое решение на крупных инсталляциях и например, когда планировщик kubernetes сработает не так как ожидалось по разным факторам. И со временем также будет интересно посмотреть по раундам обновления kubernetes и стека, который строится на такой основе. Например, https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ будет работать с 1.25 версии. Что то включают в основную ветку, что то нет.
Надеюсь ваше решение не будет в будущем форкать kubernetes с целью "оставить нужные абстракции, без которых очень сложно".
Удачи!
Почему metal3? У Sidero вроде свой инфраструктурный провайдер есть.
Есть ли возможность развернуть для тестов на одном физическом хосте, без стороннего гипервизора?
DIY: Ваше собственное облако на базе Kubernetes (часть 1)