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

Развертывание Nested-кластера подразумевает создание рабочих узлов в необходимой инфраструктуре.

Подготовка конфигурации подчиненного кластера

Для разверывания Nested-кластера необходимо заполнить форму создания кластера в Web-интерфейсе или подготовить объекты Cluster.yaml и Workerpool.yaml согласно необходимому типу развертывания.

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

• Baremetal
• VSphere
• Brest
• VMManager
• VK
• Yandex

Внесение дополнительных изменений в настройки работы control plane

Необходимо активировать использование провайдера Nested для развертывания данного кластера.

При создании кластера через WEB-интерфейс необходимо в блоке Провайдер Control Plane изменить значение с kubeadm на BootsmanNested.

Выбор данного значения также добавляет ниже блок Настройки для BootsmanNested со следующими опциями:

• внешний etcd - при активации дает воможность более тонко настроить etcd для Nested-кластера.

• реплики - при активации параметра внешний etcd дает возможность указать, сколько подов etcd будет создано для подчиненного Nested-кластера. Большее количество подов приводит к увеличению отказоустойчивости etcd.

• Persistence - при активации параметра внешний etcd дает возможность указать, нужно ли создавать персистентное хранилище для пода(-ов) etcd. По умолчанию отключено.

• Имя StorageClass - при активации параметра Persistence дает возможность указать имя storageClass в управляющем кластере для создания PVC. Пустое поле приведет к использованию storageClass по умолчанию.

• Размер хранилища - при активации параметра Persistence дает возможность указать размер PVC для каждого пода etcd.

При создании кластера через yaml-манифесты, в манифесте Cluster.yaml нужно заменить блок
spec.capiConfig.controlPlane.kubeadmControlPlane
на
spec.capiConfig.controlPlane.bootsmanNestedControlPlane с необходимым содержимым, например:

Пример

bootsmanNestedControlPlane:
etcd:
  replicas: 3
  persistence:
    storageClassName: longhorn
    storageSize: 2Gi

Внимание

В манифесте Workerpool.yaml ничего править не нужно.

Пример полной конфигурации baremetal

apiVersion: provisioning.bootsman.tech/v1alpha1
kind: Cluster
metadata:
  name: {++SUBCLUSTER_NAME++} (1)
  namespace: {++SUBCLUSTER_NAMESPACE++} (2)
spec:
  capiConfig:
    controlPlane:
      endpoint:
        host: {++KCP_IP++} (3)
        port: {++KUBE_API_PORT++} (4)
      machineHealthCheck:
        maxUnhealthy: {++MHC_MAX_UNHEALTHY++} (5)
        timeoutDuration: {++MHC_TIMEOUT++} (6)
      bootsmanNestedControlPlane:
        etcd:
          replicas: {++ETCD_REPLICAS++} (7)
          persistence:
            storageSize: {++ETCD_STORAGE_SIZE++} (8)
      replicas: {++KCP_REPLICAS++} (9)
    infrastructure:
      bareMetalProviderConfig:
        resources: {}
        selector:
          matchLabels: {}
      provider: baremetal
      sshAuthorizedKeys:
        - {++SSH_PUBLIC_KEY++} (10)
    kubernetesVersion: {++SUBCLUSTER_KUBERNETES_VERSION++} (11)
    network:
      podsCidrBlocks:
        - {++SUBCLUSTER_POD_CIDR++} (12)
      servicesCidrBlocks:
        - {++SUBCLUSTER_SERVICE_CIDR++} (13)
    registry:
      credentialsSecret:
        hostKey: host
        name: {++REGISTRY_CREDS_SECRET_NAME++} (14)
        namespace: {++REGISTRY_CREDS_SECRET_NAMESPACE++} (15)
        passwordKey: password
        usernameKey: username
      url: {++REGISTRY_URL++} (16)
  targetCluster: Workload

1. Имя подчиненного Nested-кластера.
   Должно быть уникальным в пределах namespace.
2. Namespace, в который будут помещены все объекты, связанные с кластером.
3. IP-адрес kube-vip endpoint control-plane подчиненного кластера.
   Адрес должен быть свободен и не состоять в dhcp-пулах.
4. Порт Kubernetes API.
   По умолчанию 6443.
5. Максимальный процент нездоровых control-plane нод, при превышении которого MachineHealthCheck инициирует восстановление.
6. Период времени, в течение которого нода может оставаться нездоровой, до запуска восстановления.
7. Количество реплик etcd для Nested control-plane.
   Большее количество повышает отказоустойчивость etcd.
8. Размер персистентного хранилища для каждого пода etcd.
9. Количество реплик control-plane подчиненного кластера.
10. Публичный SSH-ключ, который будет добавлен на узлы подчиненного кластера.
11. Версия Kubernetes.
    Поддерживаемые версии
12. Блок адресов для Pods.
    Не должен пересекаться с CIDR управляющего кластера и физической сети.
13. Блок адресов для Services.
    Не должен пересекаться с CIDR управляющего кластера и физической сети.
14. Имя секрета с учетными данными для доступа к registry.
15. Namespace, в котором находится секрет с учетными данными для доступа к registry.
16. URL репозитория образов.

apiVersion: provisioning.bootsman.tech/v1alpha1
kind: WorkerPool
metadata:
  name: {++WORKERPOOL_NAME++} (1)
  namespace: {++SUBCLUSTER_NAMESPACE++} (2)
spec:
  bootstrapConfig:
    kubeadm: {}
  clusterName: {++SUBCLUSTER_NAME++} (3)
  infrastructure:
    bareMetalProviderConfig:
      resources: {}
      selector:
        matchLabels:
          role: {++MATCH_LABEL_VALUE++} (4)
    provider: baremetal
  kubernetesVersion: {++SUBCLUSTER_KUBERNETES_VERSION++} (5)
  machineHealthCheck:
    maxUnhealthy: {++MHC_MAX_UNHEALTHY++} (6)
    timeoutDuration: {++MHC_TIMEOUT++} (7)
  replicas: {++WORKER_REPLICAS++} (8)
  roles:
    - name: bootsman-worker

1. Имя WorkerPool.
   Должно быть уникальным в пределах namespace.
2. Namespace, должен соответствовать namespace, указанному в Cluster.yaml.
3. Имя подчиненного кластера, к которому будет подключен WorkerPool.
4. Значение лейбла, по которому будут выбираться byohost-узлы в качестве worker-узлов.
5. Версия Kubernetes.
   Должна совпадать с версией, указанной в Cluster.yaml. Поддерживаемые версии
6. Максимальный процент нездоровых worker-узлов, при превышении которого MachineHealthCheck инициирует восстановление.
7. Период времени, в течение которого узел может оставаться нездоровым, до запуска восстановления.
8. Число worker-узлов в пуле.

После сохранения заполненной формы в WEB-интерфейсе или применения объектов Cluster.yaml и Workerpool.yaml запустится процесс создания подчиненного Nested-кластера.

Что происходит дальше:

1. В управляющем-кластере создается пространство имен с указанным именем. В нем создаются поды: kube-apiserver, etcd, konnectivity-server, cloud-controller-manager, kube-controller-manager, kube-scheduler.
2. Создаются рабочие узлы с использованием указанного провайдера, машины проходят bootstrap и присоединяются к кластеру.
3. Устанавливаются аддоны вложенного кластера (cilium, coredns, konnectivity-agent, metrics-server, ingress-nginx).

Заметка

Установка Nested-кластера может занимать от двух до десяти минут, в зависимости от инфраструктуры.