Перейти к содержанию

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

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

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

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

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

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

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

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

nested_cp
nested_cp

Выбор данного значения также добавляет ниже блок Настройки для 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-кластера может занимать от двух до десяти минут, в зависимости от инфраструктуры.