Вложенные кластеры TenantCluster#

• Описание

• Контекст использования

  • Контекст для использования подхода kube-in-kube

• Архитектура

• Создание TenantCluster

  • Подготовка окружения

  • Создание TenantCluster с помощью Kubectl

  • Создание TenantCluster с помощью инструмента Console

  • Конфигурация TenantCluster

    • Пример высокодоступного вложенного кластера

    • Полная конфигурация values

• Получение конфигурации KubeConfig к TenantCluster

  • Получение конфигурации с помощью Kubectl

  • Получение конфигурации с помощью инструмента Console

• Работа с TenantCluster

  • Работа с TenantCluster с помощью Kubectl

  • Работа с TenantCluster с помощью инструмента Console

Описание#

TenantCluster (вложенный кластер, виртуальный кластер) — это инструмент для создания виртуальных кластеров DropApp (virtual clusters) внутри существующих физических или логических кластеров, реализующий парадигму kube-in-kube.

Виртуальный кластер предоставляет изолированное окружение, которое функционирует как полноценный Kubernetes-кластер, но использует ресурсы родительского кластера (host cluster). Это клиентский кластер, он «живет» на ресурсах родительского кластера, имеет ограниченную версию Dapp-operator, которая позволяет пользователям разворачивать компоненты для работы с пользовательскими приложениями, не влияя на функционирование и не переопределяя системные компоненты родительского кластера.

Инструмент разработан на базе VCluster.

Контекст использования#

TenantCluster разворачивает минимальный набор компонентов Kubernetes API, таких как API Server, Scheduler и Controller Manager, внутри отдельного пространства имен родительского кластера. Также внутри вложенного кластера разворачивается Dapp-operator, который позволяет устанавливать компоненты и инструменты, доступные для таких вложенных клиентских кластеров, - Auth, Ui, GitOps, DevOps, AiOps.

Это позволяет пользователям взаимодействовать с виртуальным кластером с помощью стандартных инструментов Kubernetes - Kubectl, Helm и операторы. Это значительно оптимизирует использование вычислительных мощностей и повышает общую утилизацию рабочих узлов, поскольку вложенный кластер функционирует на узлах родительского кластера. Все networkpolicy и securitypolicy наследуются от родительского кластера, что позволяет использовать единый стандарт политик для всех кластеров в инфраструктуре. Таким образом, каждый родительский кластер функционирует как микро-приватное облако и платформа для создания кластеров DropApp.

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

Контекст для использования подхода kube-in-kube#

Основной контекст для использования подхода kube-in-kube:

1. Изоляция сред и тенантов:

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

2. Упрощенное тестирование и CI/CD:

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

3. Поддержка GitOps и управления через API:

   Kube-in-kube отлично сочетается с GitOps-подходом. Можно декларативно управлять дочерними кластерами через CRD, Helm-релизы и другие инструменты, что делает инфраструктуру более управляемой и воспроизводимой.

4. Масштабируемость и модульность:

   С ростом инфраструктуры можно масштабировать управление, выделяя отдельные кластеры под конкретные задачи: dev, staging, production, edge-кластеры и т.д., сохраняя при этом централизованное управление через родительский кластер.

5. Обучение и демонстрации:

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

Архитектура#

Основные компоненты:

1. Родительский кластер DropApp:

   • Физический или логический Kubernetes-кластер, предоставляющий ресурсы для работы виртуальных кластеров.

   • Содержит Etcd, Kube-apiserver, Kube-scheduler и другие компоненты control plane.

   • Содержит оператор DropApp (Dapp-operator) с контроллером TenantCluster.

2. TenantCluster:

   • Создается внутри пространства имен родительского кластера с помощью CRD TenantCluster.

   • Использует собственный Syncer для синхронизации объектов между виртуальным и родительским кластерами.

   • Включает упрощенную версию control plane для обработки запросов.

   • Содержит Dapp-operator и базовые компоненты Auth и Ui.

3. Syncer:

   • Компонент, который синхронизирует объекты между виртуальным и родительским кластерами.

   • Отвечает за преобразование объектов (например, Pods, Services, ConfigMaps ) из вложенного кластера в формат, понятный родительскому кластеру.

4. Namespace Isolation:

   • Все ресурсы вложенного кластера размещаются в пределах одного пространства имен родительского кластера.

   • Обеспечивает изоляцию на уровне RBAC, network-политик и других механизмов безопасности.

Создание TenantCluster#

Для развертывания TenantCluster необходимо создать в родительском кластере CR TenantCluster. Имя этого ресурса будет именем самого вложенного кластера, а также пространства имен родительского кластера, где будут расположены все ресурсы (Pods, Secrets, Services, ConfigMaps, Ingress и др.) вложенного кластера.

Подготовка окружения#

Поскольку адрес control plane, а также адреса компонентов Console и Auth выставляются в качестве Ingress-контролеров, то в DNS должна быть запись для создаваемого кластера, указывающего на адрес Metallb.

Маска доменного имени для адресов вложенного кластера будет: *.team-x.my-cluster,dapp.test, где:

• team-x - имя вложенного кластера;

• my-cluster - имя родительского кластера;

• dapp.test - имя publicDomain.

Создание TenantCluster с помощью Kubectl#

Для создания TenantCluster с помощью Kubectl выполните следующие команды:

1. Создайте файл tc.yaml:

   tc.yaml

   apiVersion: cluster.dropapp.ru/v1alpha1
   kind: TenantCluster
   metadata:
     name: team-x
   

2. Примените файл:

   kubectl apply -f tc.yaml
   

Создание TenantCluster с помощью инструмента Console#

Для создания TenantCluster с помощью инструмента Console выполните следующие шаги:

1. Перейдите в консоль на страницу https://<console-address>/k8s/cluster/cluster.dropapp.ru~v1alpha1~TenantCluster, где <console-address> - адрес консоли из примера https://console.da-cluster.domain.ru.

2. Нажмите Create TenantCluster и вставьте манифест в появившееся поле:

   Create TenantCluster

   apiVersion: cluster.dropapp.ru/v1alpha1
   kind: TenantCluster
   metadata:
     name: team-x
   

   

3. Нажмите Create.

Конфигурация TenantCluster#

В конфигурации TenantCluster можно настроить необходимые значения в секции spec.values:

apiVersion: cluster.dropapp.ru/v1alpha1
kind: TenantCluster
metadata:
  name: team-x
spec:
  values:
    ...

Пример высокодоступного вложенного кластера#

Пример высокодоступного вложенного кластера с настройкой storage и повышенным количеством реплик для Etcd и control plane:

apiVersion: cluster.dropapp.ru/v1alpha1
kind: TenantCluster
metadata:
  name: team-x
spec:
  values:
    controlPlane:
      backingStore:
        etcd:
          deploy:
            statefulSet:
              highAvailability:
                replicas: 2
      statefulSet:
        highAvailability:
          replicas: 2
        persistence:
          volumeClaim:
            storageClass: nfs-csi # Значение для примера, если установлен инструмент Csi-driver-nfs
            enabled: true

Полная конфигурация values#

Полная конфигурация параметров TenantCluster представлена в разделе «Полная конфигурация values TenantCluster».

Получение конфигурации KubeConfig к TenantCluster#

KubeConfig для подключения к кластеру можно получить:

• с помощью Kubectl;

• в Console на вкладке Details, в разделе TenantCluster.

Получение конфигурации с помощью Kubectl#

Извлеките содержимое поля config из секрета и сохраните декодированные данные в файл конфигурации KubeConfig, выполнив команду:

kubectl get secret -n team-x vc-team-x -o jsonpath='{.data.config}' | base64 -d > team-x-kubeconfig

Получение конфигурации с помощью инструмента Console#

Для получения KubeConfig, используя инструмент Console, выполните следующие шаги:

1. Перейдите в Console родительского кластера.

2. Раскройте раздел Cluster Management.

3. В раскрывшемся списке перейдите в TenantClusters.

4. Выберите необходимый TenantCluster.

5. Перейдите на вкладку Details.

6. Для скачивания и копирования KubeConfig нажмите соответствующую кнопку в секции Kubeconfig:

   

Работа с TenantCluster#

Подключиться к вложенному кластеру можно, используя:

• Kubectl.

• отдельную Console, которая создается для вложенного кластера.

Работа с TenantCluster с помощью Kubectl#

Для подключения к вложенному кластеру, используя Kubectl, выполните команду:

kubectl get pods -A --kubeconfig ./team-x-kubeconfig

Работа с TenantCluster с помощью инструмента Console#

Получить адрес DropApp Console, логин и пароль можно во вкладке Details для вложенного кластера: