Хабр, привет!

Меня зовут Алиса, и я руковожу командой разработки контейнерной платформы «Штурвал». В последнее время мы с командой много работали над реализацией мультитенантности и перепробовали множество разных вариантов. Ниже я расскажу, как тенанты помогают закрыть «боли» при работе с K8s на примере трех проблем и поделюсь полезными инструментами.

Эта статья будет интересна тем, кто:

«с ноги» врывается в свой первый кубер;
самостоятельно строит Kubernetes-платформу;
управляет одним или множеством кластеров K8s.

Немного вводных

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

Большой enterprise можно сравнить с торговым центром, у которого есть один владелец. Здание ТЦ делится по этажам, каждый этаж — на помещения. У помещений есть арендаторы. Какие-то помещения сдаются по частям в субаренду. Арендаторы используют помещения по-своему: у них разные время работы, потребление мощностей (например, пиццерия будет потреблять больше электричества, чем магазин), площадь и количество человек в команде. При этом арендаторы не имеют доступ к помещениям друг друга, тогда как субарендаторы делят общую площадь и имеют один ключ. Мы все сталкиваемся с этим в обычной жизни.

*1…N кластеров Kubernetes, множество команд*

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

Что такое мультитенантность?

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

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

Три кита

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

1. Первая проблема — классическая — распределение ресурсов.

Человеческий фактор: когда шарят один кластер между командами, необходимо также поделить worker-ноды, storage, доступ к бэкапам, настроить taint и tolerations, установить квоты. Но при ошибках настройки приложения могут быть не запущены или запущены на узлах неверной команды.

Уязвимости: если пользователи кластерного уровня или сервис-аккаунты с большими привилегиями скомпрометированы, то весь кластер находится под угрозой.

Геораспределенные кластеры: когда есть кластер с геораспределением между ЦОДами или зонами доступности, появляется узкое горлышко в виде сети. В таком случае первый вопрос: как разграничить ресурсы между этими командами?

2. Ограниченность иерархии. По умолчанию кластер K8s имеет плоскую иерархию: кластер → неймспейсы. В «ванильной» сборке и некоторых платформах есть управление только одним кластером, в мультикластерном решении — доступны несколько кластеров и неймспейсов.

Несоответствие структуры: типовая глубина иерархии не позволяет делать глубокой структуру для больших enterprise-решений. В компании не оперируют терминами «кластер» и «неймспейс», а используются такие формулировки, как «система», «подсистема», «команда», «проект» и т.п. Применяя тенанты, появляется возможность привести мультикластерную архитектуру к привычной для компаний структуре.

Затруднение и замедление разработки:

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

В этом проблемы ограниченности иерархии, с которыми тоже могут справиться тенанты. Эту иерархию мы построили у себя в платформе «Штурвал» — она родилась во время больших enterprise-внедрений. Появилась потребность в одну мультикластерную платформу разместить несколько систем, подсистем, приложений и дополнительное окружение.

3. Управление доступами. RBAC в K8s работает на уровне кластера или неймспейса, но не поддерживает делегирование прав на группу неймспейсов. Многие мультикластерные решения переиспользуют особенности «ванильного» кубера, где мы имеем либо ClusterRoles, либо просто Roles.

Мы опять сталкиваемся со сложностями:

При использовании ClusterRoles для назначения прав в кластерах: нужно обеспечить наличие и единообразие ролей и состава их разрешений в каждом кластере.
При использовании ClusterRoles для назначения прав в неймспейсах: в случае изменения одной ClusterRole меняются все права доступа, назначенные в неймспейс. Это не всегда очевидно и удобно для пользователя.
При использовании Roles: в каждый создаваемый неймспейс приходится заводить нужные Roles. Тогда каждый раз нам нужно будет создавать права доступа и назначать конкретных сотрудников. Это ужасно неудобно, долго и главное — небезопасно (привет, человеческий фактор!).

Особенно неудобен процесс выделения прав доступа в эфемерные кластеры/неймспейсы, которые широко распространены в крупных корпорациях.

Что такое эфемерные кластеры или неймспейсы?

Это регулярно пересоздаваемые и недолгоживущие сущности, которые создаются для тестирования фич и гипотез.

Как пасти «китов»?

#1 проблема — разграничение ресурсов

Способ решения

Плюсы

Минусы

Мультикластерный подход с возможностью создания нескольких кластеров (в том числе отдельно стоящих) и управления ими из единого окна.

Реализовано в платформе «Штурвал», китайском решении Alauda, частично в Deckhouse, VMware Tanzu, Karmada (у нее нет графического интерфейса, только управление из консоли) и по умолчанию в любом Managed Kubernetes в облаке.

👉 Сетевая изоляция между кластерами доступна по умолчанию: каждый кластер может жить в своей демилитаризованной зоне.

👉 Простая и понятная изоляция по правам доступа.

👉 Распределение по ресурсам: приложения больше не конкурируют между собой по worker-нодам. 1 приложение = 1 кластер.

👉 Простота работы с бэкапами и storage (с ними работают разные команды): они могут функционировать на базе разной виртуализации и версий Kubernetes.

👉 Отсутствие потребности в настройке и нативная поддержка функционала.

👉 Независимость команд при выборе сервисов и версий.

👉 Потенциальный перерасход ресурсов, а в некоторых платформах — перерасход финансов в части лицензии. Например, в случаях, если возможна оплата по нодам Control Plane или vCPU с учетом Control Plane — когда для каждого кластера нужно создавать свои Master-узлы.

👉 Необходимость наличия сложной сетевой конфигурации для DR-конфигураций. Когда трафик должен подхватываться между двумя кластерами и в случае отказа одного из кластеров перенаправляться в другой.

👉 Сложное сопровождение при большом количестве кластеров. В случае возникновения проблемы не всегда очевидно, откуда она взялась, — особенно если нет централизованного мониторинга или логирования.

Управление в одном кластере по совокупности неймспейсов.

В некоторых решениях это называется тенантами, в других — проектами. Уже реализовано в OpenShift, Rancher, Deckhouse, Capsule.

👉 Изоляция по правам доступа внутри кластера.

👉 Есть возможность выделять resourcequotas или tolerations на тенант.

👉 Простая сетевая настройка трафика между приложениями.

👉 Ограничено одним кластером. Как правило, ни в одном из решений нет разграничения доступа между тенантами, которые объединяли бы в себя что-то большее, чем внутри одного кластера.

👉 Нет разграничения для кластерных ресурсов (storage и бэкапы как минимум).

👉 Кластер/сеть как единая точка отказа, в особенности в условиях большой нагрузки (частые случаи — перегруженность etcd или kube-api сервера).

Разграничение ресурсов по виртуальным (vCluster) или логическим (kcp) кластерам.

Перед внедрением данного подхода, важно ответить на вопрос: а точно ли это вам нужно?

👉 hard multi-tenancy, то есть полная сетевая и ресурсная изоляция.

👉 Изоляция по правам доступа.

👉 Сложная настройка и, соответственно, высокие требования к компетенциям.

👉 Размещение Control plane в одном ЦОД (виртуализации): если один дата-центр падает, то мы можем потерять все наши кластеры.

👉 Кластер/сеть как единая точка отказа.

👉 Перерасход ресурсов.

👉 Необходимость обновления самого vCluster.

👉 Необходимость экспоузить трафик из виртуальных кластеров во внешнюю сеть.

#2 проблема — ограниченная иерархия Kubernetes

Способ решения

Плюсы

Минусы

Проекты.

Позволяют объединять несколько неймспейсов в один тенант.

Реализовано в Rancher, OpenShift, Deckhouse и Capsule.

👉 Сокращение времени и разгрузка администратора кластера за счет того, что администратор проекта может самостоятельно создавать неймспейсы.

👉 Управление ресурсами проекта.

👉 Возможность назначения прав на проект или изолированно на неймспейс.

👉 Наличие графического интерфейса.

👉 Доступно только внутри одного кластера (не решает проблему полной иерархии).

👉 Создает только один дополнительный уровень иерархии.

HNC (иерархичные неймспейсы)

👉 Доступны бесплатно и могут быть внедрены и на базе «ванильной» версии и на любой коммерческой платформе.

👉Не требуют высоких компетенций.

👉 Позволяют создать множество уровней вложенности.

👉 Не требуют кластерного уровня для создания сабнеймспейсов.

👉 Могут дать только иерархию. Пропагация ресурсов, заявленная в документации, не работает.

👉 Дерево строится только внутри неймспейсов.

👉 Нет графического интерфейса.

👉 Скорее может использоваться как дополнительное решение к какому-то из существующих для возможного расширения иерархии.

Дерево тенантов.

Реализовано в платформе «Штурвал».

У нас получилось следующее дерево:

➖ платформа как управлялка;
➖ внутри — несколько тенантов, объединяющих кластеры и рождающих систему;
➖ в системе несколько тенантов;
➖ тенанты объединяют в себе несколько неймспейсов разных кластеров.

👉 Любой уровень вложенности любых абстракций.

👉 Упрощение управления на больших инсталляциях за счет отсутствия плоских списков.

👉 Совместимо с дополнительными решениями, например, с той же Capsule.

👉 Есть графический интерфейс и бесплатная community-версия.

👉 Сложная специфическая логика — у нас ушел год, чтобы все работало как часы.

👉 Требует дополнительных решений для управления ресурсами.

#3 проблема — управление доступом

Способ решения

Плюсы

Минусы

Проекты.

Реализовано в Rancher, OpenShift, Deckhouse и Capsule.

👉 Включает в себя несколько неймспейсов одного кластера.

👉 Права доступа, созданные в одном проекте, недоступны для использования в другом.

👉 Права доступа заводятся на сам проект, и при создании нового проекта все права доступа надо создавать заново с помощью Helm или вручную. Это может быть неудобно.

Дерево доступов.

Реализовано в платформе «Штурвал».

👉 Позволяет назначить права доступа на любой уровень абстракции.

👉 Включает в себя: все кластеры и неймспейсы платформы; набор кластеров и все неймспейсы кластеров; набор неймспейсов выбранного набора кластеров.

👉 Открывает доступ к: ко всем созданным и всем создаваемым кластерам и неймспейсам; ко всем вложенным кластерам и неймспейсам; ко всем вложенным неймспейсам.

👉 Как и мультикластерная платформа расширяет API Kubernetes, так и дерево тенантов расширяет возможности RBAC.

👉 Изменение прав доступа определенного уровня вызывает изменение этих прав во всех тенантах.

Выводы

Мы рассмотрели довольно много способов для решения трех основных проблем, связанных с ресурсами, иерархией и управлением доступами в большом enterprise. На помощь нам приходят готовые платформы, отдельные инструменты или разработка собственных решений (что, увы, не всегда выстреливает, как пример — проект Kiosk, который закрыли в 2021 году).

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

Эта статья поможет понять, какие проблемы и каким образом при росте бизнеса можно будет нивелировать. Плюс этих подходов в том, что их можно между собой комбинировать по мере возникновения проблем. Одним решением справиться с трудностями по разделению ресурсов, другим — решить проблему построения плоских списков.

Моей целью было сделать обзор существующих подходов. Я не топлю за какое-то конкретное решение — выбирайте то, что подходит именно вам.

Алиса Кириченко

Руководитель разработки платформы «Штурвал»

Выступления на подобные хардкорные темы вы сможете услышать 31 июля на первой независимой конфе Kubernetes Community Day. Она состоится в Москве и соберет спикеров из таких компаний, как Yandex Cloud, Luntry, VK, FUN&SUN, МКБ, «Лаборатория Числитель», ecom.tеch, Cloud ru и др. Участие бесплатное. Регистрация тут.

Мультитенантность в Kubernetes: возможные подходы и инструменты