Nested-кластер

Кластер Nested — подчиненный Kubernetes-кластер, control-plane которого развёрнут в виде подов внутри управляющего кластера платформы. При этом рабочие узлы (worker-ноды) создаются с использованием любого инфраструктурного провайдера (baremetal, vsphere, vk и т.д.).

Преимущества Nested-кластера:

экономия ресурсов: так как control-plane это поды в управляющем кластере, а не отдельные физические или виртуальные сервера, экономия может достигать 70%;
повышенная безопасность: control-plane изнутри такого кластера не виден, он полностью скрыт и доступ к нему есть только со стороны управляющего кластера платформы;
парадигма KaaS: платформа превращается в настоящий Kubernetes-as-a-Service.

Схема организации работы Nested-кластера

Управляющий кластер: на своих рабочих узлах несет запущенные поды, выполняющие функцию control-plane для подчиненного кластера.
Control-plane поды: API server, etcd, konnectivity-server, controller-manager, scheduler, controller-manager работают в отдельном пространстве имен. Для каждого подчиненного Nested-кластера используется свое пространство имен с собственным набором подов Control-plane.
Load balancer: отвечает за связь между компонентами подчиненного кластера с control-plane подами. Два виртуальных адреса в управляющем кластере используются для доступа к API кластера (порт 6443 TCP) и специализированному Konnectivity-компоненту (порт 8132 TCP). В случае использования инфраструктурных провайдеров Yandex и VK данный компонент не будет создан в управляющем кластере, вместо этого будет использоваться балансировщик облачного провайдера.
Подчиненный кластер: не имеет своих control-plane нод, только рабочие узлы.

Ограничения:

CIDR вложенного кластера (podsCidrBlocks, servicesCidrBlocks) не должны пересекаться с CIDR управляющего кластера и физической сетью;
при отказе управляющего кластера вложенный кластер также становится недоступным;
В случае использования инфраструктурного провайдеров (кроме baremetal) для создания рабочих узлов nested-кластера требуется доступ к API этого провайдера со всех нод управляющего кластера, так как поды control-plane работают на его узлах.

Пререквизиты для развертывания

Управляющий кластер должен быть установлен и полностью работоспособен.
В управляющем кластере должен быть создан StorageClass с возможностью создания PVC. Например: longhorh.
В управляющем кластере должны быть установлены аддоны kube-vip и kube-vip Cloud Provider.

Для kube-vip Cloud Provider необходимо настроить пул адресов (параметр range-global), емкостью не менее двух IP-адресов.

В Web-интерфейсе ConfigMap kube-vip-cloud-provider должен выглядеть следующим образом:

При планировании развертывания нескольких Nested-кластеров, необходимо следить за емкостью пула адресов в аддоне kube-vip Cloud Provider (на каждый кластер необходимо два свободных адреса).

Внимание!

В случае использования инфраструктурных провайдеров Yandex или VK пропустите данный пункт.
Балансировщик, предоставляемый облачным провайдером, будет создан и сконфигурирован автоматически.

В управляющий кластер должен быть установлен Nested-провайдер с помощью утилиты bootsmanctl:
```
bootsmanctl mgmt provider install -p b6nested -c bootsman.config.yaml --cluster <имя-управляющего-кластера> -v
```
В управляющем кластере необходимо выдать разрешение на использование Nested-провайдера:
```
kubectl patch flags.features.bootsman.tech f-bootsman-nested-enabled --type=merge \
  -p '{"spec":{"value":true}}'
```

Ссылки

Развертывание Nested-кластера