Добавление кластера

Основная информация

Работа с кластерами оркестрации контейнеров включает в себя создание, изменение и удаление клиентских кластеров.

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

ознакомиться с системными требованиями и выделяемыми сетями при создании кластера;
убедиться, что в Комплексе создан экземпляр провайдера инфраструктуры, на котором планируется разместить кластер. При отсутствии доступа в "Платформа → Провайдеры" перейти в интерфейс создания кластера. Выбор провайдеров будет доступен, если созданы соответствующие экземпляры провайдеров.

Возможно создание клиентского кластера с провайдером:

VMware vSphere;
oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization);
OpenStack (VK Cloud, Selectel);
Basis Dynamix;
Shturval v2 ‒ физические узлы и предварительно развернутые ВМ;
VMware vCloud Director;
Yandex Cloud.

Возможно создание кластера управления с провайдером:

VMware vSphere;
oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization);
OpenStack (VK Cloud, Selectel);
Shturval v2 ‒ физические узлы и предварительно развернутые ВМ.

FQDN

В кластере FQDN формируются согласно одному из вариантов заданного Ingress:

Если при создании кластера указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если при создании кластера задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME - заданное имя кластера.

Перечень доменов по умолчанию в кластере, если при создании кластера был задан VIP-адрес Ingress, приведен в таблице 62.

Создание клиентских кластеров

В разделе "Кластер" на вкладке "Клиентские кластеры" нужно нажать кнопку +Добавление кластера для создания нового кластера (рисунок 124).

Рисунок 124 ‒ Вкладка "Клиентские кластеры"

Процесс создания кластера разбит на этапы (шаги), соответствующие экранам:

Выбор провайдера;
Конфигурация провайдера (только при создании кластера управления);
Основные данные;
Конфигурация Control Plane-узлов;
Конфигурация Worker-узлов;
Выбор сервисов;
Проверка данных.

Для перехода на следующий шаг или возврата на предыдущий используются кнопки Продолжить или Назад. Для перехода на следующий шаг необходимо заполнить обязательные поля. При переходе между шагами вперед и назад введенные данные сохраняются.

Выбор провайдера

На первом шаге "Выбор провайдера" (рисунок 125) нужно задать название кластера, выбрать провайдера, для чего нажать на кнопку с названием провайдера. Провайдеры доступны, если в "Платформа → Провайдеры" созданы соответствующие экземпляры провайдеров.

Рисунок 125 ‒ Выбор провайдера

Доступно создание клиентских кластеров с провайдерами:

oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization);
vSphere;
OpenStack (VK Cloud, Selectel);
Basis Dynamix;
Shturval v2;
Yandex Cloud;
vCloud Director.

Доступно создание кластера управления с провайдерами:

oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization);
vSphere;
OpenStack (VK Cloud, Selectel);
Shturval v2.

Профиль конфигурации клиентского кластера (ClusterProfile)

При создании клиентских кластеров применяются настройки конфигурации, определенные по умолчанию. В РОСА Кубис реализована возможность определить конфигурацию на этапе развертывания кластера. С помощью профиля кластера (ClusterProfile) можно задать, какие манифесты объектов необходимо применить в кластере (клиентском и/или управления) при инициализации.

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

ClusterProfile ‒ кастомный ресурс API-группы cluster.shturval.tech, управление которым осуществляется в кластере управления. По умолчанию предустановлен профиль по умолчанию с именем default-client-cluster-profile.

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

Рисунок 126 ‒ Выбор профиля

В будущих релизах планируется расширить перечень предустановленных профилей, например, специализированных для реализации ML-задач.

Создание профиля кластера

Для добавления требуемой конфигурации для применения на этапе создания кластера нужно:

подготовить манифесты объектов, которые должны быть созданы. Например, можно определить для создаваемого клиентского кластера:

настройки устанавливаемых сервисов с помощью PatchSSC;
сетевые политики Cilium и политики безопасности Kyverno;
конфигурацию узлов кластера с помощью NCI;
MachineHealthCheck.

Пример манифеста NCI:

apiVersion: node.shturval.tech/v1beta2
kind: NodeConfigItem
metadata:
  name: admin-user
spec:
  nodeconfigselector:
    kubernetes.io/os: linux
  priority: 100
  users:
    - group: someusergroup
      homedir: ""
      shell: /bin/bash
      username: someuser

Важно ‒ При необходимости подстановки имени кластера в манифест, который будет применен при инициализации кластера, используется плейсхолдер {{.ClusterName}}.

Например, это может потребоваться, когда для клиентского кластера применяются манифесты объектов, которыми управляет кластер управления.

Пример манифеста с плейсхолдером:

apiVersion: cluster.x-k8s.io/v1beta2
kind: MachineHealthCheck
metadata:
  name: {{.ClusterName}}-default-healthcheck
  namespace: {{.ClusterName}}
spec:
  checks:
    nodeStartupTimeoutSeconds: 0
    unhealthyNodeConditions:
      - status: Unknown
        timeoutSeconds: 600
        type: Ready
      - status: 'False'
        timeoutSeconds: 600
        type: Ready
  clusterName: {{.ClusterName}}
  remediation:
    triggerIf:
      unhealthyLessThanOrEqualTo: 39%
  selector:
    matchLabels:
      cluster.x-k8s.io/deployment-name: {{.ClusterName}}-default

в неймспейсе kube-system кластера управления создать Secret с типом Opaque; добавить ключи, в значении которых указать подготовленные манифесты.

Пример Secret с манифестами NCI и Namespace:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  labels:
    cluster.shturval.tech/manifest: ""
    clientcluster: clientcluster
  name: secret-for-profile
  namespace: kube-system
data:
  key: YXBpVmVyc2lvbjogbm9kZS5zaHR1cnZhbC50ZWNoL3YxYmV0YTIKa2luZDogTm9kZUNvbmZpZ0l0ZW0KbWV0YWRhdGE6CiAgbmFtZTogYWRtaW4tdXNlcgpzcGVjOgogIG5vZGVjb25maWdzZWxlY3RvcjoKICAgIGt1YmVybmV0ZXMuaW8vb3M6IGxpbnV4CiAgcHJpb3JpdHk6IDEwMAogIHVzZXJzOgogICAgLSBncm91cDogc29tZXVzZXJncm91cAogICAgICBob21lZGlyOiAiIgogICAgICBzaGVsbDogL2Jpbi9iYXNoCiAgICAgIHVzZXJuYW1lOiBzb21ldXNlcg==
  key2: 
  YXBpVmVyc2lvbjogdjEKa2luZDogTmFtZXNwYWNlCm1ldGFkYXRhOgogIG5hbWU6IG5zLWJ5LWNsdXN0ZXJwcm9maWxl

Важно ‒ Secrets должен быть обязательно присвоен лейбл по умолчанию "cluster.shturval.tech/manifest": "". Secrets без лейбла по умолчанию будут проигнорированы.

При необходимости можно добавить еще лейблы для гибкого управления секретами в разных профилях.

подготовить манифест ClusterProfile, где:

указать имя профиля и неймспейс kube-system;
в блоке "CustomManifests" задать совпадающие лейблы Secrets;
- Если указан хотя бы один лейбл в селекторе лейблов (matchLabels), можно не добавлять в matchExpression лейбл по умолчанию. Он будет присвоен автоматически.
- Если используется только лейбл по умочанию cluster.shturval.tech/manifest, его необходимо добавить в селектор лейблов.
прописать, в каком кластере (клиентском, управления) манифесты из Secret должны деплоиться: Скриншот выбора профиля или platformManifestsSelector.

Пример кастомного ClusterProfile:

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  name: cluster-profile
  namespace: kube-system
spec:
  customManifests:
    - clientManifestsSelector:  # Манифесты Secrets, соответствующие селектору, будут применены в клиентском кластере
        matchLabels:
          clientcluster: clientcluster
      platformManifestsSelector: # Манифесты Secrets, соответствующие селектору, будут применены в кластере управления
        matchLabels:
          cluster.shturval.tech/manifest:

загрузить ClusterProfile в кластер управления, например, в графическом интерфейсе с помощью импорта манифестов.

Важно:

Переопределять конфигурацию ClusterProfile по умолчанию с именем default-client-cluster-profile строго запрещено. Это может привести к ошибкам создания клиентских кластеров.
После создания кастомного профиля с настройкой применения манифестов конфигурация профиля default-client-cluster-profile будет добавлена по умолчанию.
Применение кастомного профиля с переопределенными параметрами конфигурации (за исключением настройки применения манифестов) может привести к ошибкам инициализации кластера.

Пример примененного ClusterProfile:

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  creationTimestamp: 2026-01-22T07:55:09Z
  generation: 1
  labels:
    k8slens-edit-resource-version: v1beta1
    shturval.tech/shturval-cluster-profile-config: ""
  name: cluster-profile
  namespace: kube-system
  resourceVersion: "29842860"
  uid: 44a09930-9728-418b-a8c6-51e791a2aa64
spec:
  customManifests:
    - clientManifestsSelector:
        matchExpressions:
          - key: cluster.shturval.tech/manifest
            operator: Exists
        matchLabels:
          clientcluster: clientcluster
      platformManifestsSelector:
        matchExpressions:
          - key: cluster.shturval.tech/manifest
            operator: Exists
        matchLabels: {}
# Здесь будут параметры конфигурации дефолтного профиля кластера
status:
  extraManifestsStatus:
    manifestsStatus:
      - clientManifestsStatus:
          - secretRef:
              name: secretname
              namespace: kube-system
            status: valid
        deployPhase: postsscdeploy
        platformManifestsStatus:
          - secretRef:
              name: secretname
              namespace: kube-system
            status: valid
    ready:
      status: "True"

Особенности работы профилей

Результаты валидации манифестов объектов, включенных в Secret, выводятся в статус ClusterProfile.
Обновления конфигурации ClusterProfile, указанных в нем Secrets, манифестов объектов в Secrets не приведут к изменению конфигурации ранее созданных клиентских кластеров с этим профилем.
Любые изменения (обновление, создание новых) Secrets, соответствующих селектору в профиле кластера, приведут к автоматическому обновлению в профиле.
В кластер управления могут быть созданы ресурсы из API-групп auth.shturval.tech и custer.x-k8s.io для применения в клиентском кластере.
Фазу применения манифестов нельзя переопределить (deployPhase: postsscdeploy), она устанавливается по умолчанию. Манифесты применяются после установки сервисов в кластере.
Манифесты ресурсов, которыми управляет кластер управления, создаются только в неймспейсе клиентского кластера, заданный неймспейс в манифесте игнорируется.

Выделение подсетей

В Комплексе при создании клиентского кластера по умолчанию выделяются:

подсеть подов ‒ 172.16.0.0/16;
подсеть сервисов ‒ 10.96.0.0/12.

Диапазон подсетей может быть изменен в соответствии с вашими потребностями. Рекомендуется до создания кластера проверять диапазоны на пересечения. Как определить пересечение подсетей подов и сервисов в инициализированном кластере, см. в инструкции "Диагностика пересечения подсетей в кластере".

Подсети подов и сервисов располагаются в общем overlay network кластера. Подсеть подов и сервисов разворачивается только внутри кластера и не пересекается с другими кластерами и вашей корпоративной сетью. Фактически, даже если подсеть подов/сервисов совпадает с вашей корпоративной, то доступа у подов к сервисам вне кластера не будет.

По умолчанию в кластерах разрешен весь входящий и исходящий трафик. Для управления сетевыми политиками в Комплексе используется Cilium (CNI) (п. Сетевые политики Cilium).

На каждом узле кластера из общей подсети подов выделяется отдельная подсеть. Если в кластере разрешен исходящий трафик, по умолчанию весь исходящий трафик будет выходить от IP узла. Можно настроить выделенный IP-адрес или сетевой интерфейс для отдельных неймспейсов, настроив параметры Egress на странице неймспейса (п. О неймспейсе).

Входящий трафик в кластер по умолчанию приходит на IP-адрес Ingress-кластера. Для выделения IP-адреса для неймспейса требуется настроить параметры Ingress на странице неймспейса (рисунок 127).

Рисунок 127 ‒ Используемые подсети

Пример использования подсетей показан на рисунке 128.

Рисунок 128 ‒ Пример использования подсетей

Системные требования для клиентского кластера

Клиентский кластер должен состоять как минимум из одного Control Plane- и двух Worker-узлов. Для обеспечения отказоустойчивости кластер должен состоять как минимум из трех Control Plane- и двух Worker-узлов. Для клиентского кластера предъявляются требования к количеству и вычислительным ресурсам серверов, указанные в таблицах ниже.

Минимальные требования приведены в таблице 63.

Для клиентских кластеров введено понятие инфраструктурного узла ‒ Infra Worker ‒ это такой Worker узел, на котором будут приоритетно развернуты системные сервисы кластера. Чтобы системные сервисы разместились только на Infra-узлах, рекомендуется три Infra-узла.

Следует обратить внимание:

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

Рекомендуемые требования приведены в таблице 64.

Процесс создания

С провайдером oVirt и oVirt-подобными

Конфигурация провайдера (только для кластера управления)

На странице "Создание кластера управления" можно создать конфигурацию провайдера oVirt (zVirt, HostVM, РЕД Виртуализация, ROSA Virtualization) (рисунок 129).

Рисунок 129 ‒ Создание кластера управления

Основные данные

На экране "Основные данные" доступны поля для определения основных настроек кластера (рисунок 130). Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Рисунок 130 ‒ Основные данные

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

Базовый режим

Основные данные в базовом режиме:

Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически. Если к шаблону провайдера был привязан пул IP-адресов, то для этого шаблона будет отображена подсказка с количеством свободных IP-адресов в пуле. Можно выбрать свободные IP-адреса пула для адреса API-сервера кластера и VIP-адреса для Ingress.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
Адрес API-сервера кластера. В качестве адреса API управления кластером ввести вручную IP-адрес или FQDN API, или выбрать IP-адрес из выпадающего списка. Доступно копирование введенного значения.
VIP-адрес для Ingress. Ввести свободный IPv4-адрес вручную из внутренней подсети узлов кластера или выбрать IP-адрес из выпадающего списка. Этот IP-адрес будет добавлен в сетевой интерфейс одного из Worker-узлов. По этому адресу будет доступен системный Ingress-контроллер. Доступно копирование введенного значения.
Включить интеграцию CSI. Если в шаблоне провайдера нет запрета, то кнопка доступна и по умолчанию стоит значение "Нет". Если в шаблоне провайдера есть запрет, то кнопка недоступна.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, следует ввести вручную IP-адреса.

Важно:

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

В кластере FQDN формируются согласно одному из вариантов заданного Ingress:

Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Расширенные параметры информационной безопасности не устанавливаются. Внешний балансировщик не используется. Параметры не отображаются в интерфейсе в базовом режиме. Для изменения значений параметров нужно включить расширенные настройки.

Режим расширенных настроек

Основные данные для провайдера oVirt в режиме расширенных настроек:

Адрес API-сервера кластера. В качестве адреса API управления кластером ввести IP-адрес или FQDN API.
VIP-адрес для Ingress или DNS-запись Ingress. Ввести свободный IPv4-адрес из внутренней подсети узлов кластерав поле "VIP-адрес для Ingress" или указать Wildcard FQDN в поле "DNS-запись Ingress".
Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая, совместимая с выбранным шаблоном ВМ версия Комплекса.
Включить интеграцию CSI. Если в шаблоне провайдера нет запрета, то кнопка доступна и по умолчанию установлена на Нет. Если в шаблоне провайдера есть запрет, то кнопка недоступна.
Использовать внешний балансировщик. Если выбран внешний балансировщик, будет использован haproxy, иначе балансировка внутри кластера не используется, а весь управляющий трафик будет приходить на VIP.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type: ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Профиль кластера . По умолчанию применяется дефолтный профиль.

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

Если требуется использовать внешний балансировщик для Ingress, останется доступным только поле "DNS-запись Ingress", в которое нужно ввести Wildcard FQDN.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, нужно ввести вручную IP-адреса.

Важно:

Механизм резервирования для IP-адресов отсутствует. Пул IP-адресов провайдера предоставляет перечень IP-адресов, свободных на момент запроса. Возможны ситуации, когда IP-адрес был свободен на моменте конфигурации кластера, но к моменту инициализации создания кластера IP-адрес был уже занят. В таком случае кластер не будет успешно развернут. Рекомендуется выделять различные подсети для каждого кластера управления, а также создавать пулы IP-адресов с непересекающимися подсетями под разные команды.
В кластере FQDN формируются согласно одному из вариантов заданного Ingress:
Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Конфигурация узлов

Чтобы определить системные требования для Control Plane-, Worker-узлов, следует ознакомиться с минимальными и рекомендуемыми требованиями (п. Основная информация).

Конфигурация Control Plane-узлов

Для конфигурации Control Plane-узлов нужно задать следующие параметры (рисунок 131):

Рисунок 131 ‒ Конфигурация Control Plane-узлов

Количество Control Plane-узлов (должно быть нечетное значение. Рекомендуется не больше 5);
Cores (значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Sockets (значение по умолчанию ‒ 1);
Threads (значение по умолчанию ‒ 1);
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ.

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

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 132).

Рисунок 132 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Эти группы защищены от удаления при создании кластера. Если во время создания кластера Worker-узлы в этих группах не требуются, следует проставить значение "0" в поле "Количество worker-узлов": будут созданы MachineDeployments, а в будущем при необходимости можно легко добавить узлы в группы. Помимо группы по умолчанию и инфраструктурной группы есть возможность добавить дополнительные группы Worker-узлов.

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

Также есть возможность скопировать настройки группы по умолчанию в другие группы Worker-узлов. Для этого нажать на иконку копирования в правой части строки группы узлов.

Редактировать параметры группы можно, нажав на название группы в таблице. При редактировании группы Worker-узлов можно:

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

Рисунок 133 ‒ Создание дубликата конфигурации

Для конфигурации группы доступны параметры (рисунок 134):

Рисунок 134 ‒ Конфигурация группы

Масштабирование узлов ‒ Ручное/Автоматическое;
При выбранном ручном масштабировании узлов, определить количество Worker-узлов;
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее 2-х реплик;
Cores (значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Sockets (значение по умолчанию ‒ 1);
Threads (значение по умолчанию ‒ 1);
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ;
Роли (указать роли для группы через запятую. Заданные роли будут указаны в ключах лейблов узлов группы после префикса node-role.kubernetes.io/).

Установка сертификатов

В Комплексе имеется возможность создания кластера с сертификатом (рисунок 135):

Рисунок 135 ‒ Кластер с сертификатом

Самоподписным (не требует дополнительной конфигурации) (рисунок 136).
Промежуточным. Загрузить цепочку сертификатов в формате PEM (промежуточный сертификат) и закрытый ключ промежуточного сертификата центра сертификации CA. Можно задать сертификат и ключ, загрузив файлы или указав данные в текстовом формате (рисунок 137).
ACME (Automatic Certificate Management Environment). Загрузить файл корневого сертификата CA для ACME и указать адрес ACME сервера с портом и путем к ресурсу. Можно загрузить файл сертификата или указать сертификат в текстовом формате (рисунок 138).
Корпоративным. Загрузить корпоративный сертификат в формате PEM и закрытый ключ корпоративного сертификата Ingress. Можно задать сертификат и ключ, загрузив файлы или указав данные в текстовом формате. Сертификат должен быть выпущен центром сертификации (Certificate Authority, CA) (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress (рисунок 139).
Let’s Encrypt. Указать Email, который связан с учетной записью Let’s Encrypt. Корневой сертификат СА для Let’s Encrypt загружается автоматически, адрес Let’s Encrypt сервера задан по умолчанию ‒ https://acme-v02.api.letsencrypt.org/directory (рисунок 140).

Важно ‒ Если в кластере установлен сертификат ACME, необходимо мониторить работу ACME-сервера. В случае сбоя на сервере кластеры с сертификатами ACME будут недоступны.

Рисунок 136 ‒ Создание кластера с самоподписным сертификатом

Рисунок 137 ‒ Создание кластера с промежуточным сертификатом

Рисунок 138 ‒ Создание кластера с ACME

Рисунок 139 ‒ Создание кластера с корпоративным сертификатом

Рисунок 140 ‒ Создание кластера с Let’s Encrypt

После успешной установки кластера установленные сертификаты будут доступны в разделе "Администрирование" на странице "ClusterIssuers" созданного кластера.

Выбор сервисов

Этот шаг является общим для всех провайдеров (рисунок 141).

На шаге доступен выбор сервисов для автоматического включения сервисов в кластере в базовом режиме или режиме расширенных настроек. При создании кластера автоматически устанавливаются критически важные для работы кластера сервисы, они недоступны для отключения ни в одном из режимов. При переключении между режимами установленный выбор отменяется.

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

Резервного копирования и восстановления;
Логирования;
Доставки приложений;
Мониторинга;
Балансировки нагрузки;
Инструментов ИБ.

Рисунок 141 ‒ Выбор сервисов

При необходимости самостоятельного выбора сервисов для включения в кластере следует перейти в режим расширенных настроек, для чего перевести переключатель "Показать расширенные настройки" в активное состояние и выбрать сервисы для включения. Список сервисов выводится в алфавитном порядке (рисунок 142).

Рисунок 142 ‒ Выбор системных сервисов

Важно ‒ При выборе сервиса зависимые сервисы будут выбраны автоматически. Это необходимо для корректной работы основного сервиса.

Выбранные для включения сервисы устанавливаются с версией latest, режимом автоматического обновления и названием экземпляра сервиса идентичным названию сервиса. Для каждой версии РОСА Кубис состав сервисов и их версии будут отличаться.

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

Проверка данных

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

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

После инициализации создания клиентского кластера и установки кластера управления доступен графический дашборд статуса развертывания кластера. Этот процесс является общим для всех провайдеров. Информацию о статусной модели развертывания кластера см в п. Статус развертывания кластера.

С провайдером vSphere

Конфигурация провайдера (только для кластера управления)

На странице "Создание кластера управления" можно создать конфигурацию провайдера VMWare vSphere (рисунок 143).

Рисунок 143 ‒ Создание кластера управления

Основные данные

На экране доступны поля для определения основных настроек кластера (рисунок 144). Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Рисунок 144 ‒ Основные данные

Базовый режим

Основные данные для провайдера vSphere в базовом режиме:

Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически. Если к шаблону провайдера был привязан пул IP-адресов, то для этого шаблона будет отображена подсказка с количеством свободных IP-адресов в пуле. Можно выбрать свободные IP-адреса пула для адреса API-сервера кластера и VIP-адреса для Ingress.
Адрес API-сервера кластера. В качестве адреса API управления кластером ввести вручную IP-адрес или FQDN API или выбрать свободный IP-адрес из выпадающего списка. Доступно копирование введенного значения.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
VIP-адрес для Ingress. Ввести свободный IPv4-адрес вручную из внутренней подсети узлов кластера или выбрать IP-адрес из выпадающего списка. Этот IP-адрес будет добавлен в сетевой интерфейс одного из Worker-узлов. По этому адресу будет доступен системный Ingress-контроллер. Доступно копирование введенного значения.
Включить интеграцию CSI. Если в шаблоне провайдера нет запрета, то кнопка доступна и по умолчанию установлено Нет. Если в шаблоне провайдера есть запрет, то кнопка недоступна.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, нужно ввести вручную IP-адреса.

Важно:

Механизм резервирования для IP-адресов отсутствует. Пул IP-адресов провайдера предоставляет перечень IP-адресов, свободных на момент запроса. Возможны ситуации, когда IP-адрес был свободен на моменте конфигурации кластера, но к моменту инициализации создания кластера IP-адрес был уже занят. В таком случае кластер не будет успешно развернут. Рекомендуется выделять различные подсети для каждого кластера управления, а также создавать пулы IP-адресов с непересекающимися подсетями под разные команды.
В кластере FQDN формируются согласно одному из вариантов заданного Ingress:
Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Режим расширенных настроек

Основные данные для провайдера vSphere в режиме расширенных настроек:

Адрес API-сервера кластера. В качестве адреса API управления кластером ввести IP-адрес или FQDN API. Доступно копирование введенного значения.
VIP-адрес для Ingress. Ввести свободный IPv4-адрес из внутренней подсети узлов кластера. Этот IP-адрес будет добавлен в сетевой интерфейс одного из Worker-узлов. По этому адресу будет доступен системный Ingress-контроллер.
Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
Включить интеграцию CSI. Если в шаблоне провайдера нет запрета, то кнопка доступна и по умолчанию установлено Нет. Если в шаблоне провайдера есть запрет, то кнопка недоступна.
Использовать внешний балансировщик. Если выбран внешний балансировщик, будет использован haproxy, иначе балансировка внутри кластера не используется, а весь управляющий трафик будет приходить на VIP.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с "type: ClusterIP". Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Профиль кластера . По умолчанию применяется дефолтный профиль.

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

Если необходимо использовать внешний балансировщик для Ingress, останется доступным только поле "DNS-запись Ingress". Нужно ввести в него Wildcard FQDN.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, нужно ввести вручную IP-адреса.

Важно:

Механизм резервирования для IP-адресов отсутствует. Пул IP-адресов провайдера предоставляет перечень IP-адресов, свободных на момент запроса. Возможны ситуации, когда IP-адрес был свободен на моменте конфигурации кластера, но к моменту инициализации создания кластера IP-адрес был уже занят. В таком случае кластер не будет успешно развернут. Рекомендуется выделять различные подсети для каждого кластера управления, а также создавать пулы IP-адресов с непересекающимися подсетями под разные команды.
В кластере FQDN формируются согласно одному из вариантов заданного Ingress:
Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Конфигурация узлов

Чтобы определить системные требования для Control Plane-, Worker-узлов, следует ознакомиться с минимальными и рекомендуемыми требованиями кластера клиентского, кластера управления (п. Основная информация).

Конфигурация Control Plane-узлов

Конфигурация Control Plane-узлов определяется следующими параметрами (рисунок 145):

Рисунок 145 ‒ Конфигурация Control Plane-узлов

Количество Control Plane-узлов (должно быть нечетное значение, рекомендуется не больше 5);
Количество ядер (значение по умолчанию ‒ 4, рекомендуемое ‒ 12)
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 120). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ.

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

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 146).

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Эти группы защищены от удаления при создании кластера. Если во время создания кластера Worker-узлы в этих группах не требуются, можно проставить значение "0" в поле "Количество worker-узлов": будут созданы MachineDeployments, а в будущем при необходимости можно легко добавить узлы в группы. Помимо группы по умолчанию и инфраструктурной группы есть возможность добавить дополнительные группы Worker-узлов.

Также есть возможность скопировать настройки группы по умолчанию в другие группы Worker-узлов. Для этого нужно нажать на иконку копирования в правой части строки группы узлов.

Редактировать параметры группы можно, нажав на название группы в таблице. При редактировании есть возможность:

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

Рисунок 146 ‒ Конфигурация Worker-узлов

Для конфигурации группы доступны параметры (рисунок 147):

Рисунок 147 ‒ Конфигурация группы

Масштабирование узлов ‒ Ручное/Автоматическое;
При выбранном ручном масштабировании узлов определить количество Worker-узлов;
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее двух реплик;
Количество ядер (значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 240). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ.

Если в поле "Количество Worker-узлов" проставить значение "0", Worker-узлы не будут созданы.

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

Установка сертификатов

В Комплексе имеется возможность создания кластера с сертификатом (рисунок 148):

Рисунок 148 ‒ Кластер с сертификатом

Самоподписным (не требует дополнительной конфигурации) (рисунок 149).
Промежуточным. Загрузить цепочку сертификатов в формате PEM (промежуточный сертификат) и закрытый ключ промежуточного сертификата центра сертификации CA. Можно задать сертификат и ключ, загрузив файлы или указав данные в текстовом формате (рисунок 150).
ACME (Automatic Certificate Management Environment). Загрузить файл корневого сертификата CA для ACME и указать адрес ACME сервера с портом и путем к ресурсу. Можно загрузить файл сертификата или указать сертификат в текстовом формате (рисунок 151).
Корпоративным. Загрузить корпоративный сертификат в формате PEM и закрытый ключ корпоративного сертификата Ingress. Можно задать сертификат и ключ, загрузив файлы или указав данные в текстовом формате. Сертификат должен быть выпущен центром сертификации (Certificate Authority, CA) (в этом случае в файле будет цепочка сертификатов) или самоподписан для доменного имени Ingress (рисунок 152).
Let’s Encrypt. Указать Email, который связан с учетной записью Let’s Encrypt. Корневой сертификат СА для Let’s Encrypt загружается автоматически, адрес Let’s Encrypt сервера задан по умолчанию ‒ https://acme-v02.api.letsencrypt.org/directory (рисунок 153).

Рисунок 149 ‒ Создание кластера с самоподписным сертификатом

Рисунок 150 ‒ Создание кластера с промежуточным сертификатом

Рисунок 151 ‒ Создание кластера с ACME

Рисунок 152 ‒ Создание кластера с корпоративным сертификатом

Рисунок 153 ‒ Создание кластера с Let’s Encrypt

Выбор сервисов

Этот шаг является общим для всех провайдеров и выполняется по аналогии с выбором сервисов для oVirt (п. Выбор сервисов).

Проверка данных

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

С провайдерами OpenStack, VK Cloud, Selectel

Конфигурация провайдера (шаг только для кластера управления)

На странице "Создание кластера управления" можно создать конфигурацию провайдеров OpenStack (рисунок 154), VK Cloud (рисунок 155), Selectel (рисунок 156).

Рисунок 154 ‒ Конфигурация провайдера OpenStack

Рисунок 155 ‒ Конфигурация провайдера VK Cloud

Рисунок 156 ‒ Конфигурация провайдера Selectel

Основные данные

На экране доступны поля для определения основных настроек кластера (рисунок 157). Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Рисунок 157 ‒ Создание кластера

Базовый режим

Основные данные для провайдера в базовом режиме:

Экземпляр провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
Включить интеграцию CSI. Если в экземпляре провайдера нет запрета, то кнопка доступна и по умолчанию стоит "Нет". Если в экземпляре провайдера есть запрет, то кнопка недоступна. Следует обратить внимание, что при использовании облачного хранилища платформы виртуализации Openstack после удаления кластера с провайдером OpenStack потребуется удалить вручную PVC в платформе виртуализации.

Расширенные параметры информационной безопасности не устанавливаются.

FQDN Ingress формируется автоматически согласно *.<CLUSTER_NAME>.ip-<IP_EXTERNAL_LB>.shturval.link, где <CLUSTER_NAME> ‒ имя кластера, заданное в интерфейсе, <IP_EXTERNAL_LB> ‒ VIP-адрес внешнего балансировщика для Ingress в платформе виртуализации.

Подсети подов и сервисов принимают значения по умолчанию.

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

Режим расширенных настроек

Основные данные для провайдера OpenStack в режиме расширенных настроек:

Использовать внешний балансировщик для Ingress. Значение по умолчанию ‒ Да. После завершения создания кластера необходимо перейти в платформу виртуализации и настроить внешний балансировщик в разделе "Виртуальные сети → Балансировщики нагрузки".
DNS-запись Ingress. Следует прописать Wildcard FQDN для Ingress. FQDN будут сформированы согласно: *.<DNS-запись-Ingress>. Если поле пустое, то FQDN Ingress будет сформирован автоматически согласно: *.<CLUSTER_NAME>.ip-<IP_EXTERNAL_LB>.shturval.link, где <CLUSTER_NAME> ‒ имя кластера, заданное в интерфейсе, <IP_EXTERNAL_LB> ‒ VIP-адрес внешнего балансировщика для Ingress в платформе виртуализации.
Экземпляр провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
Включить интеграцию CSI. Если в экземпляре провайдера нет запрета, то кнопка доступна и по умолчанию стоит "Нет". Если в экземпляре провайдера есть запрет, то кнопка недоступна. Следует обратить внимание, что при использовании облачного хранилища платформы виртуализации Openstack после удаления кластера с провайдером OpenStack потребуется удалить вручную PVC в платформе виртуализации.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type ‒ ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Подсеть узлов. Подсеть узлов не должна пересекаться с подсетью подов и подсетью сервисов. Если не задана, будет использована подсеть из конфигурации провайдера OpenStack/VK Cloud/Selectel.
Профиль кластера. По умолчанию применяется дефолтный профиль.

Конфигурация узлов

Конфигурация Control Plane-узлов

Конфигурация Control Plane-узлов определяется следующими параметрами (рисунок 158):

Рисунок 158 ‒ Конфигурация Control Plane-узлов

Количество Control Plane-узлов (должно быть нечетное значение не больше 5);
Тип ВМ;
Тип диска;
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 120). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ;
Зона доступности.

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 159).

Рисунок 159 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Эти группы защищены от удаления при создании кластера. Если во время создания кластера Worker-узлы в этих группах не требуются, нужно проставить значение "0" в поле "Количество worker-узлов": будут созданы MachineDeployments, а в будущем при необходимости можно легко добавить узлы в группы. Помимо группы по умолчанию и инфраструктурной группы есть возможность добавить дополнительные группы Worker-узлов.

Есть возможность скопировать настройки группы по умолчанию в другие группы Worker-узлов, для чего следует нажать на иконку копирования в правой части строки группы узлов.

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

Для конфигурации группы доступны параметры:

Масштабирование узлов ‒ Ручное/Автоматическое;
При выбранном ручном масштабировании узлов, определить количество Worker-узлов;
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее двух реплик;
Тип ВМ;
Тип диска;
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 240). При использовании локального хранилища в кластере объем диска не должен быть менее 60 ГБ;
Зона доступности.

Если в поле "Количество Worker-узлов" проставить значение "0", Worker-узлы не будут созданы.

Рисунок 160 ‒ Дублирование конфигурации

Установка сертификатов

Этот шаг является общим для всех провайдеров и выполняется по аналогии с установкой сертификатов для oVirt (п. Установка сертификатов).

Выбор сервисов

Проверка данных

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

С провайдером BasisDynamix

Основные данные

На экране доступны поля для определения основных настроек кластера (рисунок 161). Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Рисунок 161 ‒ Основные данные

Базовый режим

Основные данные для провайдера Basis Dynamix в базовом режиме:

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

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

Для настройки IP-адреса кластера необходимо после создания кластера зайти на платформу виртуализации Basis Dynamix в раздел "Сеть". На странице "Балансировщики нагрузки" для используемого балансировщика на вкладке "Schema" добавить frontend для созданного CLUSTERNAME-ingress-backend и сделать binding сервера frontend, порт 30443. Указанный для frontend IP-адрес будет присвоен как IP-адрес для Ingress-кластера.

Режим расширенных настроек

Основные данные для провайдера Basis Dynamix в режиме расширенных настроек:

Использовать внешний балансировщик для Ingress. Для настройки IP-адреса кластера необходимо после создания кластера зайти на платформу виртуализации Basis Dynamix в раздел "Network (Сеть)". На странице "Load Balancers" для используемого балансировщика на вкладке "Schema" добавить frontend для созданного CLUSTERNAME-ingress-backend и сделать binding сервера frontend, порт 30443. Указанный для frontend IP-адрес будет присвоен как IP-адрес для Ingress-кластера.
DNS-запись Ingress. Следует прописать Wildcard FQDN для Ingress. FQDN будут сформированы согласно: *.<DNS-запись-Ingress>.
Экземпляр провайдера. Выпадающий список. Если доступен только один экземпляр, он будет выбран автоматически.
Версия Комплекса. После выбора экземпляра провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type ‒ ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Профиль кластера. По умолчанию применяется дефолтный профиль.

Конфигурация узлов

Конфигурация Control Plane-узлов

Конфигурация Control Plane-узлов определяется следующими параметрами (рисунок 162).

Рисунок 162 ‒ Конфигурация Control Plane-узлов

Количество Control Plane-узлов (должно быть нечетное значение. Рекомендуется не больше 5);
Количество ядер (значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 120).

Значения по умолчанию соответствуют минимальным требованиям к ресурсам (CPU, Memory, Disk). В интерфейсе заблокирована возможность создания клиентского кластера с конфигурацией ресурсов (количество ядер, объем оперативной памяти) меньше минимально требуемых

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 163).

Рисунок 163 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

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

Для конфигурации группы доступны параметры:

Масштабирование узлов ‒ Ручное/Автоматическое;
При выбранном ручном масштабировании узлов определить количество Worker-узлов;
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее 2-х реплик;
Количество ядер (значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Объем оперативной памяти (МБ) (значение по умолчанию ‒ 8192);
Объем диска (ГБ) (значение по умолчанию ‒ 60, рекомендуемое ‒ 240);

Если в поле "Количество Worker-узлов" проставить значение "0", Worker-узлы не будут созданы.

Рисунок 164 ‒ Дублирование конфигурации группы

Установка сертификатов

Выбор сервисов

Проверка данных

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

С провайдером Shturval V2

Конфигурация провайдера (только для кластера управления)

На экране можно создать конфигурацию провайдера Shturval v2 (рисунок 165).

Рисунок 165 ‒ Конфигурация провайдера Shturval v2

Основные данные

На экране доступны поля для определения основных настроек кластера (рисунок 166). Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Рисунок 166 ‒ Основные данные

Базовый режим

Основные данные для провайдера Shturval V2 в базовом режиме:

Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически. Если к шаблону провайдера был привязан пул IP-адресов, то для этого шаблона будет отображена подсказка с количеством свободных IP-адресов в пуле. Можно выбрать свободные IP-адреса пула для адреса API-сервера кластера и VIP-адреса для Ingress.
Адрес API-сервера кластера. В качестве адреса API управления кластером ввести вручную IP-адрес или FQDN API или выбрать свободный IP-адрес из выпадающего списка.
VIP-адрес для Ingress. Ввести свободный IPv4-адрес вручную из внутренней подсети узлов кластера или выбрать IP-адрес из выпадающего списка. Этот IP-адрес будет добавлен в сетевой интерфейс одного из Worker-узлов. По этому адресу будет доступен системный Ingress-контроллер.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, нужно ввести вручную IP-адреса.

Важно:

Механизм резервирования для IP-адресов отсутствует. Пул IP-адресов провайдера предоставляет перечень IP-адресов, свободных на момент запроса. Возможны ситуации, когда IP-адрес был свободен на моменте конфигурации кластера, но к моменту инициализации создания кластера IP-адрес был уже занят. В таком случае кластер не будет успешно развернут. Рекомендуется выделять различные подсети для каждого кластера управления, а также создавать пулы IP-адресов с непересекающимися подсетями под разные команды.
В кластере FQDN формируются согласно одному из вариантов заданного Ingress:
Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Расширенные параметры информационной безопасности не устанавливаются. Внешний балансировщик не используется. Внешний механизм управления виртуальным IP кластера не используется. Параметры не отображаются в интерфейсе в базовом режиме. Для изменения значений параметров нужно включить расширенные настройки.

Режим расширенных настроек

Основные данные для провайдера Shturval V2 в режиме расширенных настроек:

Адрес API-сервера кластера. В качестве адреса API управления кластером ввести IP-адрес или FQDN API.
VIP-адрес для Ingress. Ввести свободный IPv4-адрес из внутренней подсети узлов кластера в поле "VIP-адрес для Ingress" или указать Wildcard FQDN в поле "DNS-запись Ingress".
Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Использовать внешний балансировщик. Если выбран внешний балансировщик, будет использован haproxy, иначе балансировка внутри кластера не используется, весь управляющий трафик будет приходить на VIP.
Использовать внешний балансировщик для API-сервера (по умолчанию не используется). Когда включен внешний балансировщик для API-сервера, указать FQND для API-сервера в поле "Адрес API-сервера кластера".

Следует обратить внимание, что внешний балансировщик для API-сервера должен быть корректно настроен обязательно до начала установки кластера (рисунок 167).

Рисунок 167 ‒ Использование внешнего балансировщика API-сервера

Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type ‒ ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Профиль кластера. По умолчанию применяется дефолтный профиль.

Если необходимо использовать внешний балансировщик, поле "VIP-адрес для Ingress" заменится на "DNS-запись Ingress". Следует ввести в него Wildcard FQDN.

Для адреса API-сервера и VIP-адреса для Ingress список IP-адресов содержит только свободные IP-адреса пула выбранного шаблона провайдера. Если в пуле шаблона провайдера только один свободный IP-адрес, можно указать его либо в качестве адреса API-сервера, либо в качестве VIP-адреса Ingress-контроллера. Если выбранный шаблон провайдера не имеет привязанного пула или привязанный пул IP-адресов не содержит свободных IP-адресов, нужно ввести вручную IP-адреса.

Важно:

Механизм резервирования для IP-адресов отсутствует. Пул IP-адресов провайдера предоставляет перечень IP-адресов, свободных на момент запроса. Возможны ситуации, когда IP-адрес был свободен на моменте конфигурации кластера, но к моменту инициализации создания кластера IP-адрес был уже занят. В таком случае кластер не будет успешно развернут. Рекомендуется выделять различные подсети для каждого кластера управления, а также создавать пулы IP-адресов с непересекающимися подсетями под разные команды.
В кластере FQDN формируются согласно одному из вариантов заданного Ingress:
Если указана DNS-запись Ingress: *.<DNS-запись-Ingress>.
Если задан VIP-адрес для Ingress: *.<CLUSTER_NAME>.ip-<VIP-адрес-Ingress>.shturval.link, где CLUSTER_NAME ‒ заданное имя кластера.

Конфигурация узлов

Конфигурация Control Plane-узлов

Конфигурация Control Plane-узлов определяется следующими параметрами:

Количество Control Plane-узлов (должно быть нечетное значение не больше 5).
Конфигурация Control Plane-узлов доступна в базовом режиме и режиме расширенных настроек.

По умолчанию включен базовый режим. В блоке "Потенциально доступные хосты" отображены свободные для присоединения к кластеру хосты с ролью controlplane. Если в перечне нет доступных хостов, нужно добавить хосты с ролью controlplane в выбранном провайдере (рисунок 168).

Рисунок 168 ‒ Конфигурация Control Plane-узлов

Для включения режима расширенных настроек нужно перевести переключатель "Показать расширенные настройки" в активное состояние. В "Селекторе хостов" по умолчанию добавлен лейбл с ролью хостов controlplane (рисунок 169). При необходимости можно добавить дополнительные лейблы, переопределить или удалить роль по умолчанию, задать совпадающие выражения.

Рисунок 169 ‒ Селектор хостов

Важно ‒ Лейблы, указанные в селекторе в качестве совпадающих в одной группе, должны быть указаны в совпадающих выражениях в качестве исключения в другие группы узлов по принципу:

ключ = выбранный в другой группе ключ лейбла;
оператор = NotIn;
значение = выбранное в другой группе значение лейбла.

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 170).

Рисунок 170 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Параметры групп Worker-узлов

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

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

Для конфигурации группы доступны параметры (рисунок 171):

Масштабирование узлов ‒ Ручное/Автоматическое;
При выбранном ручном масштабировании узлов, определить количество Worker-узлов;
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее 2-х реплик;
В базовом режиме настроек ‒ "Роль хостов".
По умолчанию группам Worker-узлов default и infra установлены соответствующие роли workers и infra. При необходимости можно изменить роли. Роль controlplane недоступна для выбора в группах Worker-узлов во избежание захвата хостов, предназначенных для группы Control Plane-узлов.
В "Потенциально доступные хосты" будут отображены доступные для присоединения к кластеру хосты провайдера с заданной ролью.

Следует обратить внимание:

Роль обязательно должна быть заполнена. Для кастомной настройки выбора потенциальных хостов можно перейти в режим расширенных настроек.
Информационные подсказки помогут убедиться, что в выбранном провайдере достаточно хостов с заданной ролью в каждой группе Worker-узлов:
Если хостов в провайдере меньше, чем общее количество запрошенных узлов во всех группам Worker-узлов.
Если потенциально доступных хостов меньше, чем запланировано к добавлению узлов в группе. Нужно добавить хосты с соответствующими параметрами в провайдер.
Если на момент инициализации кластера не будет достаточно хостов, то кластер будет создан без них. Нужно добавить хосты в провайдер, чтобы они могли быть присоединены к кластеру.
Если выбраны одинаковые роли для нескольких групп, нужно убедиться в достаточности доступных хостов в провайдере с выбранной ролью.
В режиме расширенных настроек ‒ "Селектор хостов". Чтобы включить расширенные настройки, нужно перевести переключатель "Показать расширенные настройки" в активное состояние. В режиме расширенных настроек в "Селекторе хостов" по умолчанию добавлен лейбл с ролью хостов по умолчанию (default или infra). При необходимости можно добавить дополнительные лейблы, переопределить или удалить роль по умолчанию, задать совпадающие выражения. Если селектор не будет заполнен, хосты будут выбраны автоматически (рисунок 172).

ключ = выбранный в другой группе ключ лейбла;
оператор = NotIn;
значение = выбранное в другой группе значение лейбла.

Если в поле "Количество Worker-узлов" проставить значение "0", Worker-узлы не будут созданы.

Важно ‒ Если по каким-либо причинам хост не смог присоединиться к кластеру (не хватило хостов в принципе; не хватило хостов с выбранными лейблами; другие ошибки), то следует:

Рисунок 171 ‒ Конфигурация групп в базовом режиме

Рисунок 172 ‒ Конфигурация групп в расширенном режиме

перейти на страницу провайдера;
добавить новые хосты или изменить существующие;
уточнить, какие лейблы были назначены хостам (если были назначены лейблы хостов для узлов при создании кластера) можно на странице "Управление узлами → Узел → Лейблы" и "Аннотации → Cluster API".

Новые хосты будут применены в создаваемом кластере.

Установка сертификатов

Выбор сервисов

Проверка данных

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

С провайдером Yandex Cloud

Основные данные

На экране доступны поля для определения основных настроек кластера. Заполнение данных доступно в базовом режиме и режиме расширенных настроек.

Базовый режим

Основные данные для провайдера Yandex Cloud в базовом режиме (рисунок 173):

Рисунок 173 ‒ Основные данные в базовом режиме

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

Расширенные настройки параметров информационной безопасности не устанавливаются. DNS-запись Ingress принимает значение cluster.shturval.link. Подсети подов и сервисов принимают значения по умолчанию. Параметры не отображаются в интерфейсе в базовом режиме. Для изменения значений параметров нужно включить расширенные настройки.

Режим расширенных настроек

Основные данные для провайдера Yandex Cloud в базовом режиме (рисунок 173):

Рисунок 174 ‒ Основные данные в расширенном режиме

DNS-запись Ingress. Значению по умолчанию ‒ cluster.shturval.link. Следует прописать Wildcard FQDN для Ingress. FQDN будут сформированы согласно: *.<DNS-запись-Ingress>.
Экземпляр провайдера. Выпадающий список. Если доступен только один экземпляр, он будет выбран автоматически.
Версия Комплекса. После выбора экземпляра провайдера, можно выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. Версия Комплекса будет заполнена автоматически, если выбранный "Экземпляр провайдера" содержит версию Kubernetes, совпадающую с текущей версией Комплекса.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон ‒ 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type ‒ ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон ‒ 10.96.0.0/12 (по-другому kubeadm не распознает).
Профиль кластера. По умолчанию применяется дефолтный профиль.

Конфигурация узлов

Конфигурация Control Plane-узлов

Конфигурация Control Plane-узлов определяется следующими параметрами (рисунок 175):

Рисунок 175 ‒ Конфигурация Control Plane-узлов

Количество Control Plane-узлов (должно быть нечетное значение).
Тип Комплекса. Выбрать один из доступных типов в экземпляре провайдера.
Тип диска. Выбрать один из доступных типов в экземпляре провайдера.
Количество ядер (количество ядер, значение по умолчанию ‒ 4, рекомендуемое ‒ 12).
Объем оперативной памяти. Выбрать единицу измерения и задать необходимое значение. Можно задать объем оперативной памяти в Gi или Mi (значение по умолчанию: 8 Gi или 8 192 Mi).
Объем диска. Выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi или Mi (значение по умолчанию: 60 Gi или 61 440 Mi).

Значения по умолчанию соответствуют минимальным требованиям к ресурсам (CPU, Memory, Disk). В интерфейсе заблокирована возможность создания кластера с конфигурацией ресурсов (количество ядер, объем оперативной памяти) меньше минимально требуемых.

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 176).

Рисунок 176 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Эти группы защищены от удаления при создании кластера. Если во время создания кластера Worker-узлы в этих группах не требуются, нужно проставить значение "0" в поле "Количество worker-узлов": будут созданы MachineDeployments. В будущем при необходимости можно добавить узлы в группы. Помимо группы по умолчанию и инфраструктурной группы есть возможность добавить дополнительные группы Worker-узлов. Для этого нужно нажать Добавить группу узлов и задать необходимую конфигурацию.

Есть возможность скопировать настройки группы по умолчанию в другие группы Worker-узлов. Для этого нужно нажать на иконку копирования в правой части строки группы узлов.

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

Для конфигурации группы доступны параметры (рисунок 177):

Рисунок 177 ‒ Конфигурация группы

Масштабирование узлов ‒ Ручное/Автоматическое.
При выбранном ручном масштабировании узлов, определить количество Worker-узлов.
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов. Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать менее 2-х реплик.
Тип Комплекса. Выбрать один из доступных типов в экземпляре провайдера.
Тип диска. Выбрать один из доступных типов в экземпляре провайдера.
Количество ядер (количество ядер, значение по умолчанию ‒ 4, рекомендуемое ‒ 12);
Объем оперативной памяти. Выбрать единицу измерения и задать необходимое значение. Можно задать объем оперативной памяти в Gi или Mi (значение по умолчанию: 8 Gi или 8 192 Mi).
Объем диска. Выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi или Mi (значение по умолчанию: 60 Gi или 61 440 Mi).
Роли. Указать роли для группы через запятую. Заданные роли будут указаны в ключах лейблов узлов группы после префикса node-role.kubernetes.io/.

Установка сертификатов

Выбор сервисов

Проверка данных

Для создания кластера нужно нажать на кнопку Создать кластер.

Статус создания

С провайдером vCloud Director

Основные данные

Базовый режим

Основные данные для провайдера vCloud Director в базовом режиме (рисунок 173):

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

Расширенные настройки параметров информационной безопасности не устанавливаются.

FQDN Ingress формируется автоматически согласно:

*.<CLUSTER_NAME>.ip-<IP_EXTERNAL_LB>.shturval.link

где <CLUSTER_NAME> ‒ имя кластера, заданное в интерфейсе, <IP_EXTERNAL_LB> ‒ VIP-адрес внешнего балансировщика для Ingress в платформе виртуализации.

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

Режим расширенных настроек

Основные данные для провайдера Yandex Cloud в базовом режиме (рисунок 178):

Рисунок 178 ‒ Основные данные в расширенном режиме

DNS-запись Ingress. Прописать Wildcard FQDN для Ingress. FQDN будут сформированы согласно: *.<DNS-запись-Ingress>. Если поле пустое, то FQDN Ingress будет сформирован автоматически согласно: *.<CLUSTER_NAME>.ip-<IP_EXTERNAL_LB>.shturval.link, где <CLUSTER_NAME> ‒ имя кластера, заданное в интерфейсе, <IP_EXTERNAL_LB> ‒ VIP-адрес внешнего балансировщика для Ingress в платформе виртуализации.
Шаблон провайдера. Выпадающий список. Если доступен только один шаблон, он будет выбран автоматически.
Версия Комплекса. После выбора шаблона провайдера есть возможность выбрать версию Комплекса. В выпадающем списке доступны версии Комплекса, которые совместимы с версией Kubernetes, указанной в шаблонах ВМ этого экземпляра провайдера, а также с текущей версией Комплекса. По умолчанию выбрана самая старшая совместимая с выбранным шаблоном ВМ версия Комплекса.
Установить расширенные параметры информационной безопасности. Устанавливает Secret Encryption для ETCD и преднастроенную политику аудита (Audit Policy).
Подсеть подов. Подсеть, из которой будут назначаться IPv4-адреса для Pods. Подсеть не должна пересекаться с сетью узлов и сервисов. Рекомендуемый диапазон: 172.16.0.1-172.16.255.254.
Подсеть сервисов. Подсеть, из которой будут назначаться IPv4-адреса для сервисов с type: ClusterIP. Подсеть не маршрутизируется с сетью узлов и Pod и не должна с ней пересекаться. Рекомендуемый диапазон: 10.96.0.0/12 (по-другому kubeadm не распознает).
Включить интеграцию CSI. Если в шаблоне провайдера нет запрета, то кнопка доступна и по умолчанию стоит нет. Если в шаблоне провайдера есть запрет, то кнопка недоступна. Информация о настройке прав доступа сервисной учетной записи vCenter находится на странице провайдера vSphere.
kubeAPIVIPSubnet ‒ определить, из какой подсети выбирать IP-адрес для KubeAPI.
serviceVIPSubnet ‒ определить, из какой подсети выбирать IP-адрес для сервисов с типом LoadBalancer.
Профиль кластера. По умолчанию применяется дефолтный профиль.

Конфигурация узлов

Конфигурация Control Plane узлов

Конфигурация Control Plane-узлов определяется следующими параметрами (рисунок 179):

Рисунок 179 ‒ Конфигурация Control Plane-узлов

Количество Control Plane узлов (должно быть нечетное значение).
DiskSize. Выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi (выбрано по умолчанию) или M. Значение по умолчанию 60 Gi (61 440 Mi) соответствует минимальным требованиям к ресурсам. В интерфейсе заблокирована возможность создания кластера с конфигурацией меньше минимально требуемого объема диска.
SizingPolicy. Выбрать политику управления ресурсами (CPU, RAM) из доступных в выпадающем списке.

Конфигурация Worker-узлов

Для конфигурации Worker-узлов нужно задать параметры на соответствующем шаге (рисунок 180).

Рисунок 180 ‒ Конфигурация Worker-узлов

По умолчанию создается две группы Worker-узлов с тремя узлами в каждой группе:

default;
infra.

Эти группы защищены от удаления при создании кластера. Если во время создания кластера Worker-узлы в этих группах не требуются, нужно проставить значение "0" в поле "Количество worker-узлов". Будут созданы MachineDeployments. В будущем при необходимости можно добавить узлы в группы. Помимо группы по умолчанию и инфраструктурной группы есть возможность добавить дополнительные группы Worker-узлов. Для этого следует нажать Добавить группу узлов и задать необходимую конфигурацию.

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

Есть возможность скопировать настройки дефолтной группы в другие группы Worker-узлов. Для этого нужно нажать на иконку копирования в правой части строки группы узлов.

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

Для конфигурации группы доступны параметры:

Масштабирование узлов: Ручное/Автоматическое.
При выбранном ручном масштабировании узлов определить количество Worker-узлов.
При выбранном автоматическом масштабировании узлов определить диапазон для автоматического масштабирования Worker-узлов (по умолчанию минимальное и максимальное количество не установлено). Минимально количество узлов может быть 2. В графическом интерфейсе ограничена возможность задать минимально реплик менее 2-х.
DiskSize. Выбрать единицу измерения и задать необходимое значение. Можно задать объем диска в Gi (выбрано по умолчанию) или Mi. Значение по умолчанию 60 Gi (61 440 Mi) соответствует минимальным требованиям к ресурсам. В интерфейсе заблокирована возможность создания кластера с конфигурацией меньше минимально требуемого объема диска.
SizingPolicy. Выбрать политику управления ресурсами (CPU, RAM) из доступных в выпадающем списке.
Роли. Указать роли для группы через запятую. Заданные роли будут указаны в ключах лейблов узлов группы после префикса node-role.kubernetes.io/.

Установка сертификатов

Выбор сервисов

Проверка данных

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

Для создания кластера необходимо нажать на кнопку Создать кластер.

Статус создания

Статус развертывания кластера

В РОСА Кубис после инициализации создания клиентского кластера или запуска установки кластера управления можно отследить процесс создания кластера по статусу развертывания.

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

Этапы статуса развертывания

По нажатию на этап статуса развертывания отображается дополнительная информация:

Создание ресурсов ‒ начальный этап подготовки ресурсов (рисунок 181);
Подготовка инфраструктуры кластера ‒ выводит информацию о состоянии готовности инфраструктуры (рисунок 182);
Инициализация Control Plane-узлов ‒ на этапе отображается перечень инициализированных Control Plane-узлов. Нажатие на condition открывает боковое окно просмотра детализированной информации по состоянию (рисунок 183);
Создание Worker-узлов в группах ‒ на этапе отображается перечень инициализированных Worker-узлов по группам. Нажатие на condition открывает боковое окно просмотра детализированной информации по состоянию (рисунок 184);
Установка Node configurations ‒ автоматическое применение конфигураций по умолчанию узла (Node Config Item, NCI). На этапе отображается перечень NCI с информацией отношения количества узлов, на которых конфигурация применена, к количеству запланированных узлов для применения в колонке "Применено на узлах" (рисунок 185);

В графическом интерфейсе развернутого кластера перечень примененных NCI к узлу доступен на вкладке "Конфигурация узла".

Установка сервисов репозитория Shturval в кластер ‒ нажатие на condition открывает боковое окно просмотра детализированной информации по состоянию сервиса (рисунок 186);
Репликация (только для кластера управления) ‒ на этапе отображается список conditions репликации (рисунок 187);
Готовность кластера ‒ итоговый статус развертывания кластера.

Цветовая индикация определяет состояние каждого этапа:

зеленый цвет ‒ при успешном завершении этапа;
желтый ‒ этап в процессе выполнения;
серый ‒ процесс выполнения этапа не запущен.

Рисунок 181 ‒ Этап "Создание ресурсов"

Рисунок 182 ‒ Этап "Подготовка инфраструктуры кластера"

Рисунок 183 ‒ Этап "Инициализация Control Plane-узлов"

Рисунок 184 ‒ Этап "Создание Worker-узлов в группах"

Рисунок 185 ‒ Этап "Установка Node configurations"

Рисунок 186 ‒ Этап "Установка сервисов репозитория в кластер"

Рисунок 187 ‒ Этап "Репликация"

Статус клиентского кластера

После инициализации создания клиентского кластера статус создания кластера можно отследить в разделе "Кластер  Клиентские кластеры", нажав на имя создаваемого кластера. До завершения развертывания кластера в разделе "Администрирование" доступна страница "Дашборд", на которой выводится информация по статусу развертывания.

Когда все Control Plane и Worker узлы будут подняты, а инфраструктура готова, отобразится дашборд развернутого кластера.

Этапы установки сервисов репозитория Shturval в кластере и Node configurations (применение NCI на узлы) клиентского кластера приведены для дополнительного отслеживания и не влияют на итоговый статус развертывания кластера. Поэтому, если кластер поднят ранее, чем установлены все сервисы и/или применены все NCI на узлы кластера, на страницах графического интерфейса можно убедиться в завершении применения NCI и установки сервисов.

Статус кластера управления

Когда запущен процесс установки кластера управления, на экране отобразится статус развертывания кластера с его этапами. Не следует закрывать вкладку до завершения установки. По завершении будет автоматическое перенаправление на этап "Кластер готов", в котором будут доступны (рисунок 188):

статический kubeconfig постоянного кластера управления для скачивания ‒ необходимо сохранить;
ссылка для перехода в постоянный кластер управления ‒ lля входа использовать логин и пароль администратора Комплекса, полученные в консоли.

Завершение установки кластера управления определяется по минимальным требованиям:

готовность инфраструктуры;
готовность минимум одного Control Plane-узла;
успешно установлены сервисы:

Рисунок 188 ‒ Этап "Кластер готов"

Модуль программного управления (shturval-backend);
Модуль управления аутентификацией (shturval-auth);
Модуль графического управления (shturval-frontend);
Модуль управления внешними подключениями (shturval-ingress-controller).

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

Установка сервисов репозитория Shturval происходит в два этапа: сначала поднимаются критически важные сервисы, далее ‒ все выбранные на шаге "Выбор сервисов". Поэтому после завершения первого этапа индикация установки сервисов снова меняется на цвет, соответствующий состоянию процесса выполнения.

Возможные проблемы с кластером

При установке клиентского кластера может возникнуть ошибка доступности указанных IP-адресов для API-сервера и/или Ingress.

Чтобы провести диагностику сетевой доступности IP-адресов, нужно подключиться по SSH к узлу кластера управления, на котором запущен под shturval-backend и выполнить команды:

Проверка для KubeAPI-сервера:

nc <ВВЕДИТЕ-IP-АДРЕС-KUBEAPI> 6443 -v -w 5

или

curl -k https://<ВВЕДИТЕ-IP-АДРЕС-KUBEAPI>:6443

Проверка для Ingress:

nc <ВВЕДИТЕ-VIP-АДРЕС-INGRESS> 443 -v -w 5

или

curl -k https://<ВВЕДИТЕ-VIP-АДРЕС-INGRESS>:443

В ответах команд не должно быть "Connection refused|Forbidden". Ошибки говорят о том, что "Соединение отклонено", а значит IP-адрес уже используется.

Подробнее о конфигурации адресов API-сервера и Ingress на страницах создания кластера с провайдерами (п. Процесс создания).