Примеры подготовки кластера Kubernetes

Содержание

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

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

Подготовка кластера в Yandex Cloud Managed Service for Kubernetes#

Yandex Cloud предоставляет услуги по созданию кластеров Kubernetes в облаке, которые обеспечены всеми необходимыми сервисами, включая управление узлами master и группами рабочих узлов, автоматическое масштабирование, автоматические обновления, резервное копирование. Также предоставлены услуги по сбору метрик, служба DNS, постоянные тома.

Предварительная подготовка#

Необходимо предварительно подготовить следующие ресурсы:

Создание кластера необходимо привязать к каталогу, на который имеются привилегии по созданию и управлению ресурсами.
Поскольку запросы будут направляться через Yandex Cloud API, необходима сервисная учетная запись (SA, Service Account), которой назначены роли, достаточные для создания ресурсов в каталоге и управления ими. Для создания ресурсов в каталоге и управления ими достаточно назначить роль editor. Однако можно использовать более гранулярный подход согласно документации Yandex Cloud. Сервисной учетной записи, назначенной ресурсам кластера, дополнительно необходима роль k8s.tunnelClusters.agent, поскольку кластер создается с туннельным режимом сети. Эту роль, как и остальные, назначают сервисной учетной записи на каталог (см. назначение ролей). Перечень ролей приведен в документации Yandex Cloud.
Если по каким-либо причинам необходимо использовать сеть, привязанную к другому каталогу, необходимо назначить роли для SA на этот каталог:
- vpc.privateAdmin;
- vpc.user;
- vpc.bridgeAdmin (если надо создавать публичные IP-адреса);
- vpc.publicAdmin (если надо создавать публичные IP-адреса).
Для хранения контента приватного реестра потребуется объектное хранилище в виде S3 bucket, объемом минимум 3 ГБ. Его можно также создать в Yandex Cloud. Назначьте роль editor для SA на S3 bucket.
Для управления кластером со своей локальной рабочей станции используйте утилиту командного интерфейса Yandex Cloud CLI (Command Line Interface).

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

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

В группе ресурсов Yandex Cloud Managed Service for Kubernetes создайте кластер:
- Назначьте созданную ранее учетную запись SA для ресурсов и узлов кластера.
- Выберите автоматическое или статическое назначение публичного IP-адреса, если необходим доступ через интернет.
- Выберите тип мастера Базовый (Base) для базовой топологии или Высокодоступный (Highly available) для топологии уровня предприятия.
- Выберите сеть, обеспечивающую требуемые коммуникации, например сеть, связанную с управляемым сегментом по VPN.
- В группе параметров Сетевые настройки кластера (Cluster network settings) установите флажок Cilium CNI. Этот флажок включает туннельный режим для сети кластера, при котором задействуется сетевой контроллер Cilium.
Добавьте группу рабочих узлов для кластера:
- Задайте необходимые ресурсы согласно рекомендациям:
  - для базовой топологии достаточно одного рабочего узла Kubernetes;
  - для топологии уровня предприятия необходимо не менее трех узлов с автоматическим масштабированием.
- Выберите тип диска SSD.
- Если необходимо назначить публичные IP-адреса, выберите автоматическое или статическое назначение публичного IP-адреса.

Управление кластером Kubernetes#

Убедитесь, что кластером можно управлять со своей рабочей станции. Следуйте инструкциям в документации провайдера для настройки. Например, для Yandex Cloud Managed Service for Kubernetes настройте это через Yandex Cloud CLI (Command Line Interface), как описано в инструкции:

Убедитесь, что установлена утилита kubectl, и установите соединение с кластером, следуя указаниям в описании свойств кластера. Например:
```
yc managed-kubernetes cluster get-credentials --id cat8...i7d --external
```
Проверьте доступность кластера:
```
kubectl get pods -A
```
Команда выводит список служебных подов.

Класс хранилища по умолчанию#

В кластере Yandex Cloud Managed Service for Kubernetes классы хранилища создает драйвер CSI провайдера, и по умолчанию используется класс на дисках HDD. Для повышения производительности переключите класс по умолчанию на диски SSD:

Проверьте список классов:
```
kubectl get storageclass
```

Если настроено на использование по умолчанию yc-network-hdd, измените это следующими командами:

kubectl patch storageclass yc-network-hdd \
-p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

kubectl patch storageclass yc-network-ssd \
-p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Подготовка кластера с помощью Боцман (Bootsman)#

Боцман – инструмент для развертывания кластеров Kubernetes и управления ими, в том числе в облаке Yandex Cloud.

Подготовка платформы Боцман состоит из следующих этапов:

Подготовка окружения на установочном узле.
Развертывание управляющего кластера Боцман с помощью утилиты bootsmanctl.
Развертывание подчиненного кластера Kubernetes, предназначенного для платформы Astra Automation.

Требования к установочному узлу#

Команды развертывания управляющего кластера выполняются на установочном узле. Для остальных блоков команд ниже указано, с какого узла они выполняются и к какому кластеру обращаются: часть шагов работает с управляющим кластером, часть – с подчиненным.

Для установочного узла, с которого выполняется развертывание управляющего кластера Боцман с помощью bootsmanctl, действуют следующие минимальные требования:

Параметр	Минимальное значение
CPU	4 vCPU
RAM	8 ГБ
Дисковое пространство	40 ГБ

Требования приведены согласно официальной документации Боцман.

Для подготовки необходимо заранее иметь:

архив дистрибутива Боцман;
файл лицензии;
установленный интерфейс командной строки Yandex Cloud (yc) с настроенным профилем – облако и каталог, в которых создается кластер. Порядок установки и настройки приведен в документации Yandex Cloud;
сервисную учетную запись Yandex Cloud и JSON-ключ к ней;
сеть и подсеть в Yandex Cloud;
образ операционной системы для виртуальных машин кластера, загруженный в Yandex Cloud.

Боцман создает виртуальные машины, диски и сетевые балансировщики от имени сервисной учетной записи, поэтому ей необходима роль editor или admin в каталоге, где создается кластер. JSON-ключ создается командой:

yc iam key create --service-account-name <service_account> --output <key_file>.json

Сеть и подсеть в этом примере готовят заранее, а в конфигурационном файле указывают их идентификаторы с признаком useExisting: true. Боцман умеет создавать сеть и сам, для этого в конфигурационном файле задают useExisting: false. Подсеть должна находиться в той же зоне доступности, которая указана в параметре zone. ID существующих сетей и подсетей выводятся командами:

yc vpc network list

yc vpc subnet list

Образ операционной системы необходимо подготовить самостоятельно согласно инструкции Создание образа операционной системы в официальной документации Боцман. Подготовленный образ необходимо загрузить в Yandex Cloud согласно инструкции Yandex Cloud. Если базовый образ Astra Linux Special Edition уже загружен в Yandex Cloud, образ можно подготовить непосредственно в облаке: создать виртуальную машину из базового образа, выполнить на ней шаги инструкции, выключить виртуальную машину и создать из ее загрузочного диска новый образ. В этом случае отдельная загрузка образа не требуется. ID полученного образа указывается далее в конфигурационном файле развертывания (параметр imageId).

Примечание

Инструкция Боцман рассчитана на cloud-init версии ниже 24. В Astra Linux Special Edition версии 1.8 служба cloud-init.service отсутствует (переименована в cloud-init-network.service), а все службы cloud-init уже включены, поэтому включать их не требуется.

Рекомендуется разместить архив дистрибутива, файл лицензии, JSON-ключ Yandex Cloud и создаваемые далее файлы конфигурации в отдельном рабочем каталоге, например ~/bootsman-install:

mkdir -p ~/bootsman-install && cd ~/bootsman-install

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

Требования к ресурсам#

Развертывание платформы Боцман включает создание двух кластеров Kubernetes – управляющий и подчиненный, поэтому итоговый объем виртуальных машин и облачных квот складывается из требований обоих кластеров.

Минимальные требования к виртуальным машинам каждой роли:

Роль	CPU	RAM	Дисковое пространство
Мастер-узел (Control Plane)	4 vCPU	8 ГБ	65 ГБ
Рабочий узел (Worker)	4 vCPU	12 ГБ	60 ГБ

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

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

Ресурс	Значение
Виртуальные машины	7 (шесть узлов кластера и установочный узел)
CPU	28 vCPU
RAM	72 ГБ
Диски SSD	7 (440 ГБ)
Публичные IP-адреса	2

Поскольку развертывание включает управляющий и подчиненный кластеры, при планировании квот Yandex Cloud необходимо увеличить приведенные значения минимум в два раза. Также необходимо учитывать квоту на сетевые балансировщики (ylb.networkLoadBalancers.count): каждому кластеру требуются два балансировщика – для Kubernetes API и для ingress-контроллера, через который у управляющего кластера публикуется веб-консоль. Если квота исчерпана, балансировщик не создается (ошибка ResourceExhausted), а развертывание управляющего кластера завершается ошибкой этапа waitProvisioningStage по таймауту.

Примечание

Отдельный установочный узел для подчиненного кластера не требуется. Его развертывание выполняется через графическую консоль в браузере, поэтому один установочный узел, использованный для управляющего кластера, покрывает потребности обоих кластеров.

Требования приведены согласно официальной документации Боцман.

Примечание

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

Развертывание управляющего кластера#

Для развертывания управляющего кластера Боцман выполните следующие действия:

Распакуйте архив дистрибутива и назначьте права на исполнение:
```
unzip <bootsman_archive>.zip
chmod +x bootsmanctl
```
В зависимости от настроек распаковщика содержимое архива попадает в текущий каталог или в подкаталог с названием архива. Во втором случае перейдите в этот подкаталог перед следующими шагами.
Добавьте лицензию в переменную окружения:
```
export LICENSE="$(cat '<license_file>.lic')"
```
Проверьте, что переменная заполнена:
```
echo "$LICENSE"
```
Если переменная заполнена, в консоли выводится содержимое лицензии.
Заранее подготовьте доменное имя для доступа к графической консоли Боцман. Это доменное имя необходимо указать в конфигурационном файле, а после развертывания – привязать к внешнему IP-адресу балансировщика.
Создайте конфигурационный файл bootsman.config.yaml в каталоге с инсталлятором bootsmanctl:
```
touch bootsman.config.yaml
```
Заполните файл по следующему шаблону:
```
---
kubernetesVersion: "<kubernetes_version>"
sshAuthorizedKeys:
  - <public_ssh_key>
wait:
  AddonHelmTimeout: 10m
  clusterCtlTimeout: 30m0s
  operationTimeout: 40m0s
  operationRetryInterval: 15s
  objCreateTimeout: 4m0s
  objCreateInterval: 5s
infrastructure:
  clusterNetwork:
    podCidrBlocks: ["<pod_cidr>"]
    servicesCidrBlocks: ["<services_cidr>"]
  yandex:
    auth:
      keyFileLocation: "<yandex_key_file>.json"
    folderId: "<folder_id>"
    zone: "<zone>"
    network:
      id: "<network_id>"
      useExisting: true
    subNetworks:
      - availabilityZone: <zone>
        id: "<subnet_id>"
        useExisting: true
    privacy: Public
controlPlane:
  endpoint:
    host:
    port: 6443
  replicas: 3
  label: master
  kubeletExtraArgs:
    kube-reserved: ""
    system-reserved: ""
    eviction-hard: ""
    eviction-minimum-reclaim: ""
    eviction-max-pod-grace-period: ""
    max-pods: ""
    seccomp-default: ""
  yandexMachine:
    availabilityZones:
      - <zone>
    platformId: standard-v2
    cores: 4
    memory: 8
    diskType: network-ssd
    diskSize: 65
    imageId: <image_id>
  machineHealthCheck:
    timeoutDuration: 10m0s
    maxUnhealthy: 100%
workerPool:
  replicas: 3
  label: worker
  kubeletExtraArgs:
    kube-reserved: ""
    system-reserved: ""
    eviction-hard: ""
    eviction-minimum-reclaim: ""
    eviction-max-pod-grace-period: ""
    max-pods: ""
    seccomp-default: ""
  yandexMachine:
    platformId: standard-v2
    cores: 4
    memory: 12
    diskType: network-ssd
    diskSize: 65
    imageId: <image_id>
    availabilityZones:
      - <zone>
  machineHealthCheck:
    timeoutDuration: 10m0s
    maxUnhealthy: 40%
web:
  bootstrapPassword: "<bootstrap_password>"
  hostname: <your_hostname>
```
Здесь:
- kubernetesVersion – версия Kubernetes, устанавливаемая на узлы кластера. Она должна совпадать с версией, предустановленной в используемом образе операционной системы, и присутствовать в матрице совместимости.
  
  Важно
  
  Часть версий Kubernetes в матрице совместимости помечена как доступные только для подчиненных кластеров. Для управляющего кластера они не подходят: развертывание завершается ошибкой kubernetes version <version> is not supported на этапе предварительных проверок, до создания каких-либо ресурсов.
  
  Убедитесь, что выбранная версия допустима именно для управляющего кластера и что образ операционной системы подготовлен с этой же версией.
- sshAuthorizedKeys – список публичных ключей SSH для доступа к создаваемым виртуальным машинам. На стенде подключение к таким машинам выполнялось под учетной записью bootsman, однако вендор название учетной записи не публикует, поэтому в других версиях оно может отличаться;
- podCidrBlocks – внутренняя сеть для подов (CIDR);
- servicesCidrBlocks – внутренняя сеть для сервисов Kubernetes (CIDR);
- keyFileLocation – файл в формате JSON с ключом сервисной учетной записи Yandex Cloud (см. следующий шаг);
- folderId – ID каталога Yandex Cloud, в котором создается кластер;
- zone – зона размещения ресурсов;
- network.id – ID существующей сети Yandex Cloud;
- subNetworks[].id – ID существующей подсети;
- privacy – режим взаимодействия с кластером, от которого зависит, какие ресурсы получают публичные IP-адреса. В шаблоне задан режим Public, при котором публичные адреса получают и виртуальные машины, и балансировщики, а режимы PrivateMachines и Private оставляют виртуальные машины без публичных адресов. У развернутого кластера режим сменить нельзя, поэтому его выбирают заранее (см. концепцию приватности Боцман);
- imageId (в блоках controlPlane и workerPool) – ID самостоятельно подготовленного образа операционной системы, загруженного заранее в Yandex Cloud (см. требования к установочному узлу);
- bootstrapPassword (в блоке web) – первичный пароль учетной записи admin графической консоли Боцман, который задается при развертывании. Задайте собственное значение, так как при режиме Public и привязанном доменном имени консоль доступна из интернета сразу после развертывания;
- hostname – доменное имя для графической консоли Боцман. Указывать IP-адрес нельзя, и запись в файле /etc/hosts вместо записи в DNS не подходит.
Поместите файл с ключом Yandex Cloud в каталог, где его ожидает Боцман:
```
mkdir -p .bootsmanctl
cp <yandex_key_file>.json .bootsmanctl/
```
Проверьте конфигурационный файл:
```
./bootsmanctl management config test -c bootsman.config.yaml -i yandex
```
Ожидаемый результат: Config is valid.

Если проверка завершается ошибкой need to migrate (шаблон конфигурации создан для более ранней версии Боцман), выполните миграцию конфигурационного файла и повторите проверку:
```
./bootsmanctl management config migrate -c bootsman.config.yaml
```
Запустите развертывание управляющего кластера:
```
./bootsmanctl mgmt create <cluster_name> -i yandex -c bootsman.config.yaml
```
Здесь <cluster_name> – короткое название кластера, которое будет отображаться в графической консоли Боцман.

Если развертывание завершилось успешно, в конце вывода приводится внешний IP-адрес, например:
```
2026-04-07T13:35:46Z | INFO | finished
Current cluster: 'bootsman-mgmt'
Add one of the addresses to the DNS server for the domain name <domain_name>
<external_ip>
```
Этот IP-адрес необходимо привязать к доменному имени на следующем шаге.

Если вывод установщика не сохранился, тот же адрес дают два других способа:
- Объект Ingress графической консоли в управляющем кластере. Файл kubeconfig этого кластера утилита bootsmanctl сохраняет в каталоге .bootsmanctl/management рабочего каталога:
```
export KUBECONFIG=~/bootsman-install/.bootsmanctl/management/<cluster_name>-kubeconfig
kubectl get ingress -n cattle-system
```
  Адрес приведен в столбце ADDRESS строки rancher.
- Балансировщик нагрузки в консоли Yandex Cloud. В каталоге, где создан кластер, установщик создает балансировщик с названием вида yandex-ccm-*, и его внешний адрес совпадает с адресом графической консоли Боцман.
Примечание

Если развертывание прервалось, повторной попытке предшествует полная зачистка. Сначала удалите вручную все ресурсы, которые установщик успел создать в каталоге Yandex Cloud:
- виртуальные машины;
- балансировщики нагрузки и целевые группы;
- сеть, подсеть, шлюз и таблицу маршрутизации, если их создавал установщик.
Сети и подсети, существовавшие до развертывания, удалять не нужно. Перечень ресурсов и порядок их удаления приведены в инструкции по удалению кластера Боцман.

Затем удалите локальные файлы развертывания, так как команда mgmt delete работает только с ними:
```
./bootsmanctl mgmt delete <cluster_name> -c bootsman.config.yaml
```
Если переменная LICENSE была задана в предыдущем сеансе, проверьте ее наличие (env | grep LICENSE) и при необходимости задайте заново, после чего повторите команду bootsmanctl mgmt create.
Проверьте, что кластер появился в списке:
```
./bootsmanctl mgmt list -c bootsman.config.yaml
```
Ожидаемый результат: в выводе присутствует строка вида <cluster_name> CURRENT.
Привяжите доменное имя к внешнему IP-адресу Боцман: настройте DNS-запись доменного имени так, чтобы она указывала на IP-адрес, полученный на шаге развертывания.

После выполнения перечисленных шагов управляющий кластер поднят, а графическая консоль Боцман доступна в браузере по адресу https://<domain_name>.

Примечание

Если сайт не доступен сразу, подождите несколько минут и повторите попытку.

Развертывание подчиненного кластера#

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

Примечание

Шаги в графической консоли выполняются в браузере, поэтому для них достаточно любого узла с сетевым доступом до консоли Боцман. Отдельные шаги этого раздела обращаются к управляющему кластеру командой kubectl. Их выполняют на установочном узле, с которого утилита bootsmanctl развертывала управляющий кластер.

Утилита bootsmanctl хранит свое состояние в каталоге .bootsmanctl рабочего каталога, то есть там же, куда на шаге подготовки помещен ключ Yandex Cloud. Файл kubeconfig управляющего кластера она сохраняет в подкаталоге management этого каталога под названием <cluster_name>-kubeconfig, где <cluster_name> – название управляющего кластера. В общий файл ~/.kube/config она его не добавляет, поэтому перед командами к управляющему кластеру необходимо указать этот файл:

export KUBECONFIG=~/bootsman-install/.bootsmanctl/management/<cluster_name>-kubeconfig

Без этого команда обратится к кластеру, заданному текущим контекстом kubectl, где объектов управляющего кластера нет.

Важно

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

Примечание

Названия блоков и полей консоли, а также приведенные далее снимки экрана соответствуют Боцман версии v3.4.0. В других версиях консоли названия могут отличаться.

Для развертывания подчиненного кластера через графическую консоль Боцман выполните следующие действия:

Откройте в браузере графическую консоль Боцман по адресу https://<domain_name> и войдите под учетной записью admin с паролем, заданным в параметре bootstrapPassword. После первого входа пароль рекомендуется сменить средствами управления пользователями консоли.
На главной странице со списком кластеров нажмите кнопку Create.
Заполните поле Cluster name – короткое название подчиненного кластера.
Заполните блок Kubernetes Options:
- Kubernetes version – версия Kubernetes, соответствующая используемому образу (в разных образах предустановлена разная версия).
- Namespace – пространство имен управляющего кластера, в котором будут храниться объекты подчиненного кластера. Если нужное пространство имен еще не создано, нажмите значок + рядом с полем, создайте его и выберите в списке.
- Pod CIDR – внутренняя сеть для подов (CIDR).
- Service CIDR – внутренняя сеть для сервисов Kubernetes (CIDR).
Заполните блок Infrastructure Provider Configuration:
- Infrastructure Provider – Yandex.
- AirGap – выключено, если у кластера есть доступ в интернет.
- Privacy – требуемый режим доступа к кластеру.
- Folder ID – каталог в Yandex Cloud, где создается кластер.
- Public SSH keys – содержимое публичного ключа SSH, который будет добавлен на создаваемые виртуальные машины. Подключение по этому ключу выполняется под той же учетной записью, что и на машинах управляющего кластера (см. описание sshAuthorizedKeys).
Заполните блок Private Registry.

Переключатель Use private registry определяет, откуда подчиненный кластер загружает компоненты Боцман. В этом примере он включен, так как управляющий кластер развернут из собственного реестра, и подчиненный кластер использует тот же реестр. Значения полей URL и Credential settings совпадают со значениями управляющего кластера – их можно посмотреть в его манифесте:
```
kubectl get cluster.provisioning.bootsman.tech <mgmt_cluster> -n default \
  -o jsonpath='{.spec.capiConfig.registry}'
```
Здесь <mgmt_cluster> – название управляющего кластера. Его объекты утилита bootsmanctl создает в пространстве имен default.
Заполните блок Control Plane – параметры мастер-узлов подчиненного кластера:
- Replicas – 3.
- Kubernetes API port – 6443.
- External etcd – выключено.
- Maximum unhealthy – 100%.
- Timeout duration – 10m.
Для авторизации в Yandex Cloud включите Use existing и укажите secret с ключом доступа. Готовить его не требуется: утилита bootsmanctl создает такой secret при развертывании управляющего кластера.
- Namespace – default.
- Name – название управляющего кластера.
- Field – key.json.
Для мастер-виртуальных машин заполните Platform ID, Image ID, CPU, RAM, Disk type, Disk size и Availability zones – эти параметры аналогичны соответствующим полям блока controlPlane в файле bootsman.config.yaml управляющего кластера.

Для сети мастер-узлов включите Use existing и укажите Network ID существующей сети, а также включите Use existing subnetwork и укажите Subnetwork ID существующей подсети.
Заполните блок WorkerPool (#1), задав значения параметров рабочих узлов, на которых выполняется нагрузка:
- Name – название пула рабочих узлов.
- Replicas – требуемое количество рабочих узлов (суммарно во всех пулах не менее 3).
- Role – bootsman-worker.
- Enable taints – выключено.
- Maximum unhealthy – 40%.
- Timeout duration – 10m.
- Platform ID, Image ID, CPU, RAM, Disk type, Disk size, Availability zones – параметры виртуальных машин рабочих узлов.
Перед нажатием кнопки Create убедитесь, что заполнены название кластера, пространство имен, оба CIDR, каталог, публичный SSH-ключ, secret и параметры виртуальных машин в блоке Control Plane, а также название пула, число узлов и параметры виртуальных машин в блоке WorkerPool. При корректном заполнении формы кнопка Create становится активной.
Нажмите кнопку Create и в открывшемся окне подтверждения проверьте основные параметры (версия Kubernetes, пространство имен, число мастер- и рабочих узлов), после чего нажмите кнопку Start.
Дождитесь появления окна Cluster Creation с шагами и прогрессом развертывания.
Проверьте, что кластер появился в общем списке. На первом этапе состояние Unavailable со строкой initializing Cluster stage означает не ошибку, а то, что кластер только начинает развертываться.

Когда развертывание полностью завершится, состояние кластера меняется на Active, а в строке кластера появляется кнопка Manage.

Развертывание подчиненного кластера из манифеста#

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

Кластер описывается двумя объектами:

Cluster – параметры кластера и его мастер-узлов;
WorkerPool – параметры пула рабочих узлов.

Манифест применяют одним из двух способов:

выполнить kubectl apply для управляющего кластера;
в окне создания кластера переключиться на вкладку YAML и нажать кнопку Read from File:

Важно

Параметры kubernetesVersion, network и registry находятся внутри spec.capiConfig, а не в spec. При размещении их на верхнем уровне применение манифеста завершается ошибкой:

ValidationError(Cluster.spec): unknown field "kubernetesVersion"
ValidationError(Cluster.spec.capiConfig): missing required field "kubernetesVersion"

Готовым образцом служат объекты управляющего кластера, созданные утилитой bootsmanctl:

kubectl get cluster.provisioning.bootsman.tech <mgmt_cluster> -n default -o yaml

kubectl get workerpool <mgmt_cluster> -n default -o yaml

В полученных манифестах для подчиненного кластера необходимо изменить следующее:

metadata.name и spec.clusterName – название подчиненного кластера;
metadata.namespace – пространство имен управляющего кластера, в котором хранятся объекты подчиненного кластера;
spec.capiConfig.network – сети подов и сервисов, не пересекающиеся с сетями управляющего кластера;
версия Kubernetes и образ операционной системы – наборы допустимых версий у управляющего и подчиненного кластеров различаются, а версия должна соответствовать версии компонентов в образе. Значения управляющего кластера подчиненному могут не подойти, поэтому сверьте их с матрицей совместимости и при необходимости замените;
spec.targetCluster необходимо удалить, так как значение этого параметра по умолчанию Workload и так соответствует подчиненному кластеру;
spec.addons необходимо удалить, если он есть, так как этот блок описывает графическую консоль управляющего кластера.

Кроме того, из образца необходимо удалить поля, которые проставляет сервер: metadata.resourceVersion, metadata.uid, metadata.creationTimestamp, metadata.managedFields и весь блок status. Команда kubectl get -o yaml выводит их вместе с описанием объекта, а при создании нового объекта они не принимаются. Если оставить хотя бы metadata.resourceVersion, создание объекта отклоняется с сообщением resourceVersion should not be set on objects to be created.

Блоки registry и authConfig переносятся без изменений, так как подчиненный кластер использует тот же реестр и тот же secret с ключом Yandex Cloud.

После применения манифеста отслеживайте состояние кластера командой:

kubectl get cluster.provisioning.bootsman.tech -n <namespace>

Здесь <namespace> – пространство имен, заданное в параметре metadata.namespace манифеста.

Готовность обозначается значением True в столбце READY.

Настройка системы хранения#

Компонентам платформы требуются постоянные тома (PersistentVolumeClaim, PVC), поэтому в подчиненном кластере необходимо настроить класс хранилища по умолчанию. В созданном подчиненном кластере Боцман класс хранилища изначально не задан.

Боцман предоставляет несколько модулей хранения, их перечень приведен в разделе о модулях официальной документации Боцман, где описан и модуль Longhorn. Для промышленной эксплуатации рекомендуется Longhorn: он обеспечивает и монопольный доступ (ReadWriteOnce), и совместный (ReadWriteMany), необходимый для Private Automation Hub.

Модули хранения подключаются как дополнения (addons) кластера. В чистом подчиненном кластере уже подключены дополнения ingress-nginx, metrics-server и rancher-monitoring-crd.

Для подключения Longhorn выполните следующие действия:

В графической консоли Боцман откройте Cluster Management.
В строке подчиненного кластера нажмите значок с тремя точками и выберите Edit config.
Внизу страницы в блоке Addons нажмите кнопку + Add addon и в поле Kind выберите longhorn-crd.
Повторите добавление и выберите longhorn.

Дополнения хранилища отмечены в списке суффиксом (@storage). Уже добавленные дополнения из списка исчезают. Дополнение longhorn-crd после добавления longhorn автоматически отмечается как зависимость (dependant), поэтому следить за порядком не требуется.
В конфигурации дополнения longhorn задайте значение true параметру defaultClass в блоке persistence:
```
persistence:
  defaultClass: true
```
Значение по умолчанию – false. Без этого изменения класс хранилища будет создан, но не станет классом по умолчанию.
Нажмите кнопку Apply, проверьте в открывшемся окне список Addons to enable и нажмите кнопку Start.

Дополнения представлены объектами configs.addon.bootsman.tech, поэтому Longhorn можно подключить и без графической консоли. Обе следующие команды обращаются к управляющему кластеру, так как объекты дополнений лежат в нем рядом с объектами cluster.provisioning.bootsman.tech. Выполняют их на том же установочном узле, с которого развертывался управляющий кластер.

kubectl patch configs.addon.bootsman.tech <cluster>-longhorn-crd -n <namespace> \
  --type=merge -p '{"spec":{"enabled":true}}'

kubectl patch configs.addon.bootsman.tech <cluster>-longhorn -n <namespace> \
  --type=merge -p '{"spec":{"enabled":true,"values":{"persistence":{"defaultClass":true}}}}'

Здесь:

<cluster> – название подчиненного кластера;
<namespace> – пространство имен, заданное в поле Namespace при создании кластера: объекты дополнений создаются рядом с объектами кластера.

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

Для получения файла выполните следующие действия:

В графической консоли Боцман откройте Cluster Management.
В строке подчиненного кластера нажмите кнопку Manage.
В блоке вспомогательных функций в верхней части рабочей области нажмите кнопку Download KubeConfig. Рядом расположена кнопка Copy KubeConfig to Clipboard, которая помещает то же содержимое в буфер обмена.

Описание этих кнопок приведено в документации Боцман.

Полученный файл подключают к kubectl привычным способом, то есть переменной окружения KUBECONFIG или слиянием с файлом ~/.kube/config.

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

kubectl get nodes

Все узлы должны находиться в состоянии Ready, а их роли и версия Kubernetes – соответствовать заданным при создании кластера.

Важно

Команды к управляющему и подчиненному кластерам обращаются к разным файлам kubeconfig. Для управляющего кластера это файл, который создала утилита bootsmanctl в каталоге .bootsmanctl/management/ рабочего каталога, для подчиненного – файл, полученный из графической консоли. Перед выполнением команд убедитесь, что выбран нужный кластер:

kubectl config current-context

После переключения контекста на подчиненный кластер проверьте, что классы хранилища созданы:

kubectl get storageclass

Longhorn создает два класса – longhorn и longhorn-static. Первый из них должен быть отмечен как (default):

NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE
longhorn (default)   driver.longhorn.io   Delete          Immediate
longhorn-static      driver.longhorn.io   Delete          Immediate

Примечание

Для тестовых сред вместо Longhorn допустимо использовать local-path. Он не обеспечивает совместный доступ (ReadWriteMany), поэтому Private Automation Hub в этом случае потребуется объектное хранилище S3.

Longhorn отмечает класс longhorn как используемый по умолчанию, однако в манифесте платформы класс хранилища указывают явно – см. переход на файловое хранилище.