Как команды платформы устраняют «скрытый налог» в размере 43 800 долларов на инфраструктуру Kubernetes

Возможность развертывать кластер Kubernetes по требованию с полным доступом к API, настраиваемой системой RBAC и изолированными пространствами имен ресурсов — вот что современные команды платформы понимают под самообслуживанием разработчиков. Без этой возможности команды платформы вынуждены контролировать каждую среду, обрабатывать последовательно запросы, которые должны выполняться параллельно, и нести расходы на контрольную плоскость, которые растут с каждым новым клиентом. Благодаря технологии виртуальных кластеров команды платформы могут развертывать десятки изолированных сред Kubernetes, не запуская ни одной дополнительной контрольной плоскости.

Эти модели отражают трансформацию, которую инженеры платформ уже однажды пережили в эпоху виртуализации серверов. До появления гипервизоров каждой рабочей нагрузке требовалась собственная физическая машина. Затраты были очевидны, но более глубокой проблемой были скорость развертывания и степень изоляции. VMware и другие компании не просто сократили расходы на оборудование. Они изменили представление команд о границах рабочих нагрузок. Виртуальные кластеры делают то же самое с инфраструктурой Kubernetes, а инструментами, способствующими этому сдвигу, являются vCluster, Kamaji и k0smotron.

Скрытый налог на инфраструктуру Kubernetes

Математика проста, если ее записать. Управляемая контрольная плоскость Kubernetes на Amazon EKS стоит 0,10 доллара в час, что составляет примерно 876 долларов в год на кластер до запуска даже одного под. Для команды платформы, управляющей 50 кластерами в средах разработки, тестирования и производства, это 43 800 долларов годовых накладных расходов на контрольную плоскость — затраты, которые не отражаются ни в одной бюджетной статье, но накапливаются по командам, средам и арендаторам.

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

«Управляемая плоскость управления Kubernetes на Amazon EKS стоит 0,10 доллара в час, что составляет примерно 876 долларов в год на кластер до запуска даже одного под. Для команды платформы, управляющей 50 кластерами… это 43 800 долларов годовых накладных расходов на плоскость управления — затраты, которые не отражаются ни в одной бюджетной статье, но накапливаются по командам, средам и арендаторам».

Виртуальные кластеры занимают эту середину. Они представляются арендаторам, которые их используют, как полнофункциональные кластеры Kubernetes, укомплектованные собственным сервером API и моделью ресурсов, при этом работая как рабочие нагрузки на общем хост-кластере, расположенном ниже. Расходы на контрольную плоскость снижаются почти до нуля, гарантии изоляции сохраняются, а команда платформы сохраняет единую физическую инфраструктуру для эксплуатации и выставления счетов.

vCluster и подход с использованием пространств имен

vCluster — это проект с открытым исходным кодом от Loft Labs, который запускает виртуальный кластер Kubernetes в виде набора подсистем внутри пространства имен на хост-кластере. Каждый виртуальный кластер имеет собственный сервер API, планировщик и менеджер контроллеров. Арендаторы взаимодействуют с виртуальным кластером через стандартный kubeconfig. С их точки зрения, у них есть реальный кластер без видимых границ с хостом.

Представьте себе vCluster как квартиру арендатора в большом здании. Конструктивные системы здания, электросеть и общие услуги — это узлы и сеть хост-кластера. У каждой квартиры есть своя запертая дверь, своя планировка и свой набор ключей. Арендатор не имеет доступа к техническому помещению здания, а управляющий зданием не управляет мебелью арендатора. Именно таким образом vCluster распределяет обязанности между операторами платформы и командами разработчиков приложений.

Представьте себе финтех-организацию, в которой работают десятки команд микросервисов, каждой из которых требуется среда Kubernetes для тестирования интеграции. С vCluster создание новой среды разработчика сводится к созданию пространства имен. Команда получает полный доступ к API, может устанавливать определения пользовательских ресурсов (CRD) и запускать собственные контроллеры доступа, в то время как команда платформы управляет одним хост-кластером, и никто не платит за десяток простаивающих плоскостей управления.

vCluster синхронизирует минимальный набор ресурсов между виртуальным кластером и хостом. Pods фактически запускаются на узлах хост-кластера через слой синхронизации, что позволяет консолидировать использование вычислительных ресурсов при сохранении изоляции на уровне API. Хранение, сеть и видимость узлов остаются на хосте и невидимы для арендатора.

Среды самообслуживания для разработчиков

vCluster хорошо подходит для платформ, где разработчикам необходимо развертывать временные среды, не дожидаясь участия команды платформы. Конвейер CI/CD может создавать vCluster в начале запуска интеграционного теста и уничтожать его по завершении, оплачивая только те минуты, в течение которых среда существует.

Изоляция определений пользовательских ресурсов

Когда нескольким командам необходимо установить конфликтующие версии CRD, модель общего пространства имен не работает. vCluster предоставляет каждой команде отдельный реестр API, устраняя проблему конфликта версий, которая вызывает столько трений в многопользовательских развертываниях Kubernetes.

Кластеры для обучения и экспериментов

Организации, проводящие внутренние программы обучения Kubernetes, могут выделять экземпляры vCluster для каждого участника. Стажеры могут нарушать работу своей среды, не затрагивая других, а инструкторы уничтожают парк в конце сессии, не оставляя на хосте никаких заброшенных ресурсов.

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

Kamaji и масштабируемые хостируемые плоскости управления

Kamaji использует другой подход к той же проблеме, перемещая плоскости управления Kubernetes из выделенных узлов в кластер управления, где они работают как обычные поды. Если vCluster нацелен на самообслуживание разработчиков посредством виртуализации в пределах пространства имен, то Kamaji нацелен на инфраструктурные команды, управляющие большими парками кластеров, которым требуется аренда производственного уровня без инфраструктурных накладных расходов на каждого арендатора.

Аналогия смещается с квартир на колокацию в дата-центрах. В колокации клиенты арендуют место в стойке и электроэнергию, не владея зданием. Объект управляет физическим уровнем; клиент управляет всем в своей клетке. Kamaji предоставляет командам платформы такое же разделение. Кластер управления — это объект колокации. Планы управления арендаторов — это клетки клиентов, профессионально управляемые, отдельно тарифицируемые и невидимые друг для друга с операционной точки зрения.

Рассмотрим управляемого поставщика услуг Kubernetes, который хочет предлагать выделенные кластеры корпоративным клиентам без выделения отдельных виртуальных машин для каждой контрольной плоскости клиента. С Kamaji каждый клиент получает выделенный сервер API, работающий как под в кластере управления поставщика. Клиент подключает свои рабочие узлы обычным образом и управляет своим кластером, не видя общей инфраструктуры. Поставщик управляет десятками контрольных плоскостей на аппаратном обеспечении, на котором раньше работали три.

Kamaji поддерживает многопользовательский etcd, в котором один кластер etcd обслуживает несколько управляемых плоскостей управления через отдельные префиксы. Он интегрируется с Cluster API, что означает, что команды платформы управляют плоскостями управления, размещенными на Kamaji, с помощью тех же декларативных рабочих процессов, которые они используют для всего остального в своем парке.

Поставщики управляемых сервисов Kubernetes

Kamaji — это подходящий инструмент, когда поставщик хочет предложить изоляцию кластеров для каждого клиента без накладных расходов на инфраструктуру для каждого клиента. Уровень управления остается компактным; клиент получает стандартный интерфейс Kubernetes со своим собственным сервером API и границей RBAC.

Многопользовательская инфраструктура SaaS

SaaS-платформы, которые развертывают рабочие нагрузки конкретных клиентов в изолированных средах Kubernetes, могут использовать Kamaji для полного разделения этих сред на уровне API при их запуске на общих вычислительных ресурсах. Требования к изоляции данных клиентов могут быть выполнены без циклов развертывания кластеров для каждого клиента.

Управление парком в больших масштабах

Организации, управляющие сотнями кластеров в пограничных, региональных и облачных развертываниях, используют Kamaji для централизации операций плоскости управления. Обновление плоскости управления становится заменой под, а не сливом и повторным развертыванием узлов, что значительно сокращает окна обслуживания.

k0smotron и виртуализация, встроенная в API кластера

k0smotron — это оператор Kubernetes, построенный на k0s, который управляет размещенными плоскостями управления как ресурсами, встроенными в Kubernetes. Он разработан с нуля для совместимости с Cluster API, рассматривая управление размещенной плоскостью управления как первостепенную задачу автоматизации инфраструктуры, а не как операционную обходную схему, наложенную на существующий инструмент.

Представьте себе k0smotron как слой «инфраструктура как код» поверх концепции виртуализированной плоскости управления. Если vCluster — это многоквартирный дом, а Kamaji — центр колокации, то k0smotron — это система управления зданием, которая интегрируется с вашим существующим набором инструментов автоматизации. Вы объявляете желаемое состояние вашего парка плоскостей управления; k0smotron согласовывает его через стандартные контроллеры Kubernetes.

Команда платформы, использующая Cluster API, добавляет k0smotron для размещения плоскостей управления в своем кластере управления. Пул рабочих узлов в AWS, Azure или локально подключаются через стандартные MachineDeployments Cluster API. Весь парк — размещенные плоскости управления и распределенные рабочие узлы — описывается в YAML и управляется через тот же конвейер GitOps, который команда уже использует.

k0smotron поддерживает удаленных поставщиков машин, что означает, что рабочие узлы не обязательно должны находиться в одном месте с кластером управления. Это делает его практичным для гибридных и пограничных сценариев, где контрольные плоскости находятся в центральном центре обработки данных, а рабочие узлы работают в филиалах или на периферийных локациях.

Гибридные и пограничные развертывания

Благодаря поддержке удаленных машин k0smotron является идеальным инструментом для архитектур, в которых централизованные плоскости управления управляют географически распределенными рабочими нагрузками. Плоскость управления остается в хорошо подключенном центре обработки данных; рабочие узлы работают там, где требуются рабочие нагрузки, без необходимости использования VPN-туннеля или частного соединения между сайтами.

Управление жизненным циклом кластера на основе GitOps

Команды, уже использующие Cluster API для автоматизации инфраструктуры, могут внедрить k0smotron без изменения своих рабочих процессов. Развертывание плоскости управления становится YAML-декларацией в том же репозитории, который управляет пулами узлов, сетевыми политиками и классами хранения, сохраняя единый источник достоверной информации, на который уже полагается команда.

Единая наблюдаемость всех размещенных плоскостей управления

k0smotron предоставляет информацию о работоспособности контрольной плоскости и задержке API-сервера через стандартные API Kubernetes. Команды платформы, запускающие десятки размещенных контрольных плоскостей, могут отслеживать весь парк с одной панели Grafana, без необходимости создания отдельных сборщиков метрик для каждой среды.

Выбор подходящего инструмента

Эти три инструмента решают одну и ту же основную проблему с разных сторон, и правильный выбор зависит от того, где находится команда в организации и для чего она проводит оптимизацию. vCluster подходит для команд, которым нужны быстрые, кратковременные среды, ориентированные на разработчиков, с минимальными эксплуатационными затратами. Kamaji подходит для инфраструктурных команд, управляющих производственными многопользовательскими парками, где надежность контрольной плоскости и управление etcd являются первостепенными задачами. k0smotron подходит для команд, уже инвестировавших в Cluster API и рабочие процессы GitOps, которые хотят, чтобы размещенные контрольные плоскости работали как любой другой инфраструктурный ресурс.

Производственные среды часто сочетают в себе более одного подхода. Команда платформы может запускать Kamaji для производственных кластеров арендаторов, одновременно используя vCluster для обслуживания сред самообслуживания разработчиков на той же хост-инфраструктуре. Эти инструменты комбинируются, а не исключают друг друга.

«Команды платформы, которые внедряют технологию виртуальных кластеров, не просто сокращают расходы на облачные услуги. Они меняют отношения между инфраструктурой платформы и разработкой приложений».

Что виртуальные кластеры открывают для команд платформы

Разговор начинается с аргумента о стоимости, но заканчивается аргументом об эксплуатации. Команды платформы, которые внедряют технологию виртуальных кластеров, не просто сокращают свои расходы на облачные услуги. Они меняют отношения между инфраструктурой платформы и разработкой приложений. Самообслуживание разработчиков, при котором команда развертывает среду Kubernetes без подачи заявки, становится операционно осуществимым, когда развертывание кластера влечет за собой затраты на пространство имен, а не на плоскость управления. Распространение кластеров, когда-то представлявшее проблему управления, становится преимуществом. Команды запускают среды, когда они нужны, и удаляют их, когда они больше не нужны.

Изоляция арендаторов также достигает нового уровня точности. В модели общего пространства имен неправильно настроенный CRD или перераспределенный LimitRange влияет на каждую команду в кластере. Виртуальные кластеры предоставляют каждому арендатору границу зоны воздействия на уровне API. Арендатор может исчерпать свою квоту, установить конфликтующую версию оператора или вывести из строя свой контроллер допуска, не затрагивая среду других пользователей. Для команд, управляющих многоарендаторской инфраструктурой SaaS или внутренними платформами для разработчиков, эта гарантия изоляции является обязательным условием для безопасного самообслуживания, а не просто приятным бонусом.

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

Виртуальные кластеры приносят в Kubernetes ту же экономическую выгоду, что и виртуализация серверов для «голого железа»: фиксированная физическая площадь, эластичная логическая емкость и модель управления, которая масштабируется вместе с организацией, а не против нее.

Что дальше

Для инженеров платформы эти шаблоны знакомы. vCluster ведет себя как пространство имен с полным набором API. Kamaji напоминает модель хостируемого сервиса для плоскостей управления. k0smotron служит уровнем «инфраструктура как код» для управления жизненным циклом кластеров. Вместе они отражают зрелость подхода отрасли к аренде Kubernetes, переходя от одного кластера на одну задачу к одной плоскости управления на один парк.

По мере того как команды платформ переходят к внутренним платформам для разработчиков и порталам самообслуживания инфраструктуры, экономика развертывания кластеров становится ключевым фактором, определяющим, будут ли эти платформы действительно использоваться. Технология виртуальных кластеров сводит это трение практически к нулю. Следующий вопрос заключается в том, как эти хостируемые плоскости управления интегрируются с более широкими фреймворками оркестрации платформ, и как будут выглядеть управление и обеспечение соблюдения политик, когда любой разработчик сможет развернуть кластер за считанные секунды. Следите за новостями.