Виртуальные кластеры Kubernetes: новая модель мультиарендности
Попробуйте vcluster — реализацию с открытым исходным кодом, которая решает некоторые аспекты типичных моделей изоляции на основе пространств имен и кластеров.
Если вы поговорите с людьми, использующими Kubernetes в производстве, вы часто услышите одну из жалоб о том, насколько сложна многопользовательская среда. Организации используют две основные модели для совместного использования кластеров Kubernetes с несколькими арендаторами, но обе создают проблемы. Модели:
- Мультиарендность на основе пространства имен
- Мультиарендность на основе кластера
Первая распространенная модель мультиарендности основана на изоляции пространства имен, когда отдельные арендаторы (например, команда, разрабатывающая микросервис) ограничены использованием одного или нескольких пространств имен в кластере. Хотя эта модель может работать для некоторых команд, у нее есть недостатки. Во-первых, ограничение доступа членов команды к ресурсам только в пространствах имен означает, что они не могут администрировать глобальные объекты в кластере, такие как пользовательские определения ресурсов (CRD). Это большая проблема для команд, работающих с CRD как частью своих приложений или в зависимости (например, строящихся поверх Kubeflow или Argo Pipelines).
Во-вторых, гораздо более серьезной проблемой долгосрочного обслуживания является необходимость постоянного добавления исключений в правила изоляции пространства имен. Например, при использовании сетевых политик для блокировки отдельных пространств имен администраторы, скорее всего, обнаружат, что некоторым командам в конечном итоге потребуется запустить несколько микросервисов, которые взаимодействуют друг с другом. Администраторам кластера каким-то образом необходимо добавлять исключения для этих случаев, отслеживать их и управлять всеми этими особыми случаями. Конечно, со временем сложность возрастает, и все больше команд начинают подключаться к Kubernetes.
Другая стандартная модель мультиарендности, использующая изоляцию на уровне кластера, еще более проблематична. В этом сценарии каждая команда получает свой собственный кластер или, возможно, даже несколько кластеров (разработчикский, тестовый, UAT, промежуточный и т. д.). Непосредственной проблемой при использовании изоляции кластера является необходимость управления большим количеством кластеров, что может стать серьезной головной болью. И всем этим кластерам нужны дорогостоящие ресурсы облачных вычислений, даже если их никто активно не использует, например, ночью или в выходные дни. Как отмечает Холли Камминс в своем выступлении на KubeCon 2021, этот взрыв кластеров оказывает опасное воздействие на окружающую среду.
До недавнего времени администраторам кластеров приходилось выбирать между этими двумя неудовлетворительными моделями, выбирая ту, которая лучше соответствует их варианту использования и бюджету. Однако в Kubernetes есть относительно новая концепция под названием виртуальные кластеры, которая лучше подходит для многих случаев использования.
Что такое виртуальные кластеры?
Виртуальный кластер — это общий кластер Kubernetes, который для клиента отображается как выделенный кластер. В 2020 году наша команда Loft Labs выпустила vcluster — реализацию виртуальных кластеров Kubernetes с открытым исходным кодом.
С помощью vcluster инженеры могут создавать виртуальные кластеры поверх общих кластеров Kubernetes. Эти виртуальные кластеры работают внутри обычных пространств имен базового кластера. Таким образом, администратор может развернуть виртуальные кластеры и раздать их арендаторам или — если организация уже использует мультиарендность на основе пространства имен, но пользователи ограничены одним пространством имен — пользователи-арендаторы могут сами развернуть эти виртуальные кластеры внутри своего пространства имен.
Это сочетает в себе лучшее из обоих подходов с несколькими арендаторами, описанных выше: арендаторы ограничены одним пространством имен без каких-либо исключений, поскольку они имеют полный контроль внутри виртуального кластера, но очень ограниченный доступ за пределами виртуального кластера.
Как и администратор кластера, пользователь имеет полный контроль над виртуальным кластером. Это позволяет им делать что угодно в виртуальном кластере, не влияя на других арендаторов базового кластера общего хоста. За кулисами vcluster выполняет это, запуская сервер Kubernetes API и некоторые другие компоненты в модуле внутри пространства имен хост-кластера. Пользователь отправляет запросы на этот сервер API виртуального кластера внутри своего пространства имен, а не на сервер API базового кластера. Состояние виртуального кластера также полностью отделено от базового кластера. Ресурсы, такие как развертывания или входы, созданные внутри виртуального кластера, существуют только в хранилище данных виртуального кластера и не сохраняются в etcd базового кластера.
Эта архитектура предлагает значительные преимущества по сравнению с моделями изоляции пространства имен и изоляции кластера:
- Поскольку пользователь является администратором своего виртуального кластера, он может управлять объектами всего кластера, такими как CRD, что преодолевает это большое ограничение изоляции пространства имен.
- Поскольку пользователи взаимодействуют со своими собственными серверами API, их трафик более изолирован, чем в обычном общем кластере. Это также обеспечивает федерацию, которая может помочь в масштабировании запросов API в кластерах с высоким трафиком.
- Виртуальные кластеры очень быстро подготавливаются и снова отключаются, поэтому пользователи могут извлечь выгоду из использования действительно эфемерных сред и потенциально развернуть многие из них при необходимости.
[ Узнайте, что нужно для разработки облачных приложений с использованием современных инструментов. Загрузите электронную книгу «Микросервисы Kubernetes с Quarkus и MicroProfile». ]
Как использовать виртуальные кластеры
Существует множество вариантов использования виртуальных кластеров, но вот некоторые из них, которые, как мы видели, используют большинство пользователей vcluster.
Среды разработки
Предоставление сред разработки и управление ими в настоящее время является наиболее популярным вариантом использования vcluster. Разработчикам, пишущим сервисы, которые работают в кластерах Kubernetes, нужно где-то запускать свои приложения, пока они находятся в разработке. Хотя можно использовать такие инструменты, как Docker Compose, для оркестрации контейнеров для сред разработки, разработчики, которые пишут код для кластеров Kubernetes, будут иметь опыт, гораздо более близкий к тому, как их сервисы работают в рабочей среде.
Другой вариант локальной разработки — использование такого инструмента, как Minikube или Docker Desktop, для подготовки кластеров Kubernetes, но у него есть некоторые недостатки. Разработчики должны владеть и поддерживать этот локальный стек кластера, что является обузой и отнимает огромное количество времени. Кроме того, этим локальным кластерам может потребоваться большая вычислительная мощность, что затруднительно на локальных компьютерах разработчиков. Мы все знаем, насколько горячими могут быть ноутбуки во время разработки, и добавление Kubernetes в эту смесь, возможно, не лучшая идея.
Запуск виртуальных кластеров в качестве сред разработки в общем кластере разработки решает эти проблемы. Кроме того, как упоминалось выше, виртуальные кластеры быстро создаются и удаляются. Администраторы могут удалить vcluster, просто удалив базовое пространство имен хоста с помощью одной команды kubetctl
или выполнив команду vcluster delete
, предоставляемую с помощью инструмента интерфейса командной строки. Скорость инфраструктуры и инструментов в рабочих процессах разработки имеет решающее значение, поскольку сокращение времени цикла для разработчиков может повысить их производительность и удовлетворенность.
Конвейеры CI/CD
Непрерывная интеграция/непрерывная разработка (CI/CD) — еще один сильный вариант использования виртуальных кластеров. Обычно конвейеры предоставляют тестируемые системы (SUT) для запуска наборов тестов. Часто команды хотят, чтобы это были свежие системы без накопленного мусора, который может помешать тестированию. Команды, использующие длинные конвейеры с множеством тестов, могут несколько раз подготавливать и уничтожать SUT за один тест. Если вы потратили много времени на подготовку кластеров, вы, вероятно, заметили, что развертывание кластера Kubernetes часто является трудоемкой операцией. Даже в самых сложных публичных облаках это может занять более 20 минут.
Виртуальные кластеры можно быстро и легко подготовить с помощью vcluster. При запуске команды vcluster create
для подготовки нового виртуального кластера все, что происходит за кулисами, — это запуск диаграммы Helm и установка нескольких модулей. Это операция, которая обычно занимает всего несколько секунд. Любой, кто запускает длинные наборы тестов, знает, что любое сокращение времени может иметь огромное значение для того, как быстро команда контроля качества и инженеры получат обратную связь.
Кроме того, организации могут использовать скорость vcluster для улучшения любых других процессов, в которых используется множество кластеров, например создания сред для семинаров или обучения клиентов.
Тестирование разных версий Kubernetes
Как упоминалось ранее, vcluster запускает сервер API Kubernetes в пространстве имен базового хоста. По умолчанию он использует API-сервер K3s (Lightweight Kubernetes), но вы также можете использовать k0s, Amazon Elastic Kubernetes Service или обычный вышестоящий API-сервер Kubernetes. При подготовке vcluster вы можете указать версию Kubernetes, с которой он будет запускаться, что открывает множество возможностей. Вы могли бы:
- Запустите новую версию Kubernetes в виртуальном кластере, чтобы посмотреть, как приложение будет вести себя на новом сервере API.
- Запустите несколько виртуальных кластеров с разными версиями Kubernetes, чтобы протестировать оператора в наборе разных дистрибутивов и версий Kubernetes во время разработки или во время сквозного тестирования.
Узнать больше
Возможно, идеального решения для мультиарендности Kubernetes не существует, но виртуальные кластеры решают многие проблемы текущих моделей аренды. Скорость и простота использования Vcluster делают его отличным кандидатом для многих сценариев, в которых вы предпочитаете использовать общий кластер, но также хотите предоставить пользователям гибкость в администрировании своих кластеров. Существует множество вариантов использования vcluster, помимо описанных в этой статье.
Чтобы узнать больше, посетите vcluster.com, а если вы хотите сразу погрузиться в код, загрузите его из репозитория GitHub. Команда Loft Labs поддерживает vcluster, и нам нравится получать идеи по этому поводу. Мы добавили множество функций на основе отзывов пользователей. Пожалуйста, не стесняйтесь открывать вопросы или PR. Если вы хотите сначала поговорить с нами о своих идеях или задать какие-либо вопросы при изучении vcluster, у нас также есть канал vcluster в Slack.