Как KubeSlice реализует multi-tenancy в Kubernetes

Эта статья была написана в соавторстве с Оливией Ракшит и мной для блога Avesha. Вы можете найти ее по этой ссылке.
_

Что такое Multi-tenancy в Kubernetes?

Multi-tenancy в Kubernetes — это способ развертывания нескольких рабочих нагрузок в общем кластере с изолированным сетевым трафиком, ресурсами, доступом пользователей и, наконец, доступом к плоскости управления. Подобная аренда необходима

1. поставщикам SaaS для своих клиентов, которые оркеструют контейнеры с помощью Kubernetes,
2. командам на предприятии, выполняющим различные функции, или
3. приложениям, которые имеют особые требования к соответствию или производительности.

Подобно виртуализации в мире вычислений, многопользовательская доступность в Kubernetes представляет собой форму виртуального кластера на физическом кластере.

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

Сценарий использования многопользовательской аренды

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

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

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

Если перейти к миру Kubernetes, то благодаря эффективности, которую дает Kubernetes, организации быстро переходят от монолитных архитектур приложений к микросервисам. Кластеры Kubernetes, начиная с версии 1.24, могут иметь до 5000 узлов, 110 стручков на узел и 150000 общих стручков.

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

Преимущества многопользовательского подхода

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

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

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

В целом, внедряя многопользовательскую среду в кластерах Kubernetes, вы получаете следующие преимущества:

• Экономия затрат
• Снижение операционных накладных расходов
• Улучшение непрерывной доставки в масштабе

Вводим KubeSlice!

KubeSlice» объединяет службы сети, приложений и развертывания в единую структуру для создания tenancy в кластере Kubernetes и расширения его до мультикластера.

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

KubeSlice управляет предоставлением и управлением арендаторами через контроллер, который функционально изолирован от рабочих нагрузок, развернутых командами разработчиков через рабочий кластер. Поскольку Kubernetes определяет плоскость управления для оркестровки контейнеров на рабочих узлах, плоскость управления KubeSlice определяется как «Контроллер».

KubeSlice в действии

Установка KubeSlice на любой дистрибутив Kubernetes осуществляется с помощью диаграмм Helm. Аренда, управляемая KubeSlice, может быть достигнута в несколько простых шагов после первоначальной установки подсистемы ‘Controller’.

KubeSlice разделен на два компонента: Управляющий кластер и группа рабочих кластеров. Управляющий кластер — это плоскость управления, управляющая рабочими кластерами либо в публичных облаках (поддержка нескольких облаков), либо кластерами на месте. Работа контроллеров заключается в управлении созданием аренды, установлении изоляции, создании оверлейной сети между рабочими кластерами для арендатора, функциональности RBAC для арендатора, выделении ресурсов для арендатора и многом другом.

Шаги для создания арендатора

Многокластерная модель с несколькими арендаторами, показывающая Team Athena Slice и Team Zeus Slice

1) Зарегистрируйте кластер или набор кластеров

Этот шаг определяет кластеры Kubernetes, которые будут управляться контроллером для создания tenancy / Isolation для команд или клиентов.

Первым шагом является регистрация кластеров в контроллере.

—------
Cluster 1: aws-us-east-prod-cluster
—-------
apiVersion: controller.kubeslice.io/v1alpha1
kind: Cluster
metadata:

name: aws-us-east-prod-cluster
namespace: kubeslice-acme
spec:
networkInterface: eth0
clusterProperty:
telemetry:
enabled: true
telemetryProvider: "prometheus"
endpoint: "http://30.2.44.110:32700" ## For example: "http://extrenal IP:32700"
geoLocation:
cloudProvider: "AWS"
cloudRegion: "us-east-1a"
—-----
Cluster 2: gcp-us-east-prod-cluster
—-------
apiVersion: controller.kubeslice.io/v1alpha1
kind: Cluster
metadata:
name: gcp-us-east-prod-cluster
namespace: kubeslice-acme
spec:
networkInterface: eth0
clusterProperty:
telemetry:
enabled: true
telemetryProvider: "prometheus"
endpoint: "http://25.4.32.210:32700" ## For example: "http://extrenal IP:32700"
geoLocation:
cloudProvider: "GCP"
cloudRegion: "us-east"

Выполнение команды

kubectl apply -f <cluster registration>.yaml -n kubeslice-<project namespace>

2) Установите оператор KubeSlice в вышеуказанных зарегистрированных кластерах

Отредактируйте приведенный ниже YAML-файл с информацией

## Base64 encoded secret values from controller cluster
controllerSecret:
namespace: <namespace>
endpoint: base64 value of the <controller endpoint>
ca.crt: <ca-cert>

token: <token>
cluster:
name: <worker cluster>
endpoint: <endpoint of control plane of the worker cluster>
# Provide your username, password & email values under imagePullSecrets to create a
secret
imagePullSecrets:
repository: https://index.docker.io/v1/
username: <username>
password: <accesstoken of the user>
email: <email ID>

Выполнение команды

helm install kubeslice-worker kubeslice/kubeslice-worker -f <values>.yaml --
namespace kubeslice-system --create-namespace

3) Установите Slice на двух кластерах

После регистрации кластера или набора кластеров, следуя шагу выше, можно создавать срез на кластере или наборе кластеров. При добавлении более одного кластера KubeSlice будет автоматически устанавливать связь между кластерами.

Приведенный ниже файл YAML помогает создать двух арендаторов для двух команд в зарегистрированных кластерах. Команды ‘Team Athena’ & ‘Team Zeus’ будут совместно использовать кластеры в AWS и GCP.

—-----
Slice 1: team-athena
—-------
apiVersion: controller.kubeslice.io/v1alpha1
kind: SliceConfig
metadata:
name: team-athena
namespace: kubeslice-acme
spec:
sliceSubnet: “192.168.0.0/16”
sliceType: Application
sliceGatewayProvider:
sliceGatewayType: OpenVPN
sliceCaType: Local
sliceIpamType: Local
clusters:

- aws-us-east-prod-cluster
- gcp-us-east-prod-cluster
qosProfileDetails:
queueType: HTB
priority: 1 #keep integer values from 0 to 3
tcType: BANDWIDTH_CONTROL
bandwidthCeilingKbps: 5120
bandwidthGuaranteedKbps: 2560
dscpClass: AF11
namespaceIsolationProfile:
applicationNamespaces:
- namespace: identity-application
- namespace: identity-db-cache
clusters:
- '*'
isolationEnabled: true #make this true in case you want to enable isolation
allowedNamespaces:
- namespace: kube-system
clusters:
- '*'

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

—-----
Slice 2: team-zeus
—-------
apiVersion: controller.kubeslice.io/v1alpha1
kind: SliceConfig
metadata:
name: team-zeus
namespace: kubeslice-acme
spec:
sliceSubnet: “192.168.0.0/16”
sliceType: Application
sliceGatewayProvider:
sliceGatewayType: OpenVPN
sliceCaType: Local
sliceIpamType: Local
clusters:
- aws-us-east-prod-cluster

- gcp-us-east-prod-cluster
qosProfileDetails:
queueType: HTB
priority: 2 #keep integer values from 0 to 3
tcType: BANDWIDTH_CONTROL
bandwidthCeilingKbps: 5120
bandwidthGuaranteedKbps: 2560
dscpClass: AF11
namespaceIsolationProfile:
applicationNamespaces:
- namespace: analytics-application
- namespace: analytics-db
clusters:
- '*'
isolationEnabled: true #make this true in case you want to enable isolation
allowedNamespaces:
- namespace: kube-system
clusters:
- '*'

С помощью описанных выше действий мы создали ДВА ТЕНАНТА (team-athena, team-zeus) на ДВУХ кластерах, основанных на двух разных облачных провайдерах. (aws-us-east-prod-clust, gcp-us-east-prod-cluster).

Мы будем рады, если вы опробуете KubeSlice и оставите нам свои отзывы! Если у вас возникнут какие-либо проблемы, мы будем общаться в канале #kubeslice на Kubernetes slack. Чтобы быть в курсе последних обновлений KubeSlice, следите за нами в Twitter и Reddit.