Требования

Что подготовить на узлах workload-кластера перед и во время создания в интерфейсе платформы.

Здесь собраны требования к клиентским (workload) кластерам — Kubernetes-кластерам, которые создаются в уже установленной платформе. Требования к установке кластера управления (инсталляция платформы) описаны отдельно: открытый контур и закрытый контур.

Модель узлов и провайдеры #

От того, откуда берутся узлы (готовые хосты или ВМ/инстансы из образа или шаблона, подготовленного для платформы), зависит, что вы настраиваете вручную до создания кластера. Общая схема — на странице Создание узлов при развертывании клиентского кластера.

В мастере создания кластера поддерживаются провайдеры: Shturval v2, oVirt и аналоги виртуализации, VMware vSphere, OpenStack (в том числе VK Cloud, Selectel), Basis Dynamix, VMware vCloud Director, Yandex Cloud. Для всех, кроме Shturval v2, узлы создаёт платформа из образа или шаблона, прошедшего единую подготовку утилитой stc по инструкции Подготовка шаблона провайдера; особенности среды и сети — в колонке ниже и на вкладках Как развернуть кластер.

Ниже требования сформулированы ко всем узлам клиентского кластера. Если пункт относится только к хостам Shturval v2 или только к пути образ/шаблон после stc — это явно помечено.

Для гибридных кластеров (основной провайдер — ВМ из шаблона, узлы с GPU — хосты Shturval v2) требования к ВМ и к хостам применяются раздельно к соответствующим группам; порядок подключения Shturval v2 — в Гибридные кластеры.

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

Минимум: 1 Control Plane + 1 Worker. Для отказоустойчивости: 3 Control Plane + 2 Worker.

* WL — ресурсы для workload-приложений. При отсутствии Infra Worker: 16 + WL vCPU для Worker.

** Логи и метрики клиентского кластера пересылаются в кластер управления и не хранятся на infra-узле локально, поэтому диск infra-узла занят наблюдаемо немного (порядка 20 GiB). 100 GiB — минимум с запасом на образы контейнеров, буферы логов и локальные тома инфра-сервисов. Локальное хранилище под пользовательские нагрузки планируйте дополнительно.

Проверка: в гипервизоре, облачной консоли или на хосте сверьте выделенные vCPU/RAM/диск с таблицей; если узлы создаются из образа/шаблона (все провайдеры, кроме Shturval v2), в мастере создания кластера ресурсы часто можно переопределить — см. вкладку вашего провайдера в Как развернуть кластер и таблицу провайдеров; они не должны быть ниже указанных минимумов. IOPS оцените по возможностям СХД или политики хранилища ВМ / дисков инстанса.

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

Минимальная (тестовая) конфигурация #

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

При такой конфигурации ограничивающий ресурс — память: на тестовых стендах Control Plane и Infra-узлы достигают 68–75% RAM даже без пользовательской нагрузки. Для любого реального workload используйте основную таблицу выше.

Поддерживаемые операционные системы #

На всех узлах кластера должна использоваться одна и та же версия ядра ОС.

Инфраструктура (где могут выполняться узлы): физические серверы архитектуры x86 и/или виртуальные машины / облачные инстансы. Для oVirt и VMware vSphere в документации обычно указываются версии среды не ниже 4.4 (oVirt) и 6.7 update 3 (ESXi); для остальных провайдеров требования к инфраструктуре — на вкладках провайдера в Как развернуть кластер и в таблице выше.

Локальное хранилище #

В качестве локального хранилища используется RawFile Provisioner; ZFS не поддерживается. Допустимые файловые системы: ext4, btrfs, xfs.

Внешний балансировщик нагрузки #

При использовании внешнего балансировщика:

1. Балансировка — на уровне L4.

2. Балансировщик должен поддерживать сохранение привязки сессии к конечному узлу по IP-адресу источника.

3. Внешний балансировщик для API-сервера при развёртывании кластера с провайдером Shturval v2 должен быть настроен до начала создания кластера (в том числе клиентского). Подробнее о модели узлов — Как развернуть кластер — Shturval v2.

Подробности и пример настройки — в требованиях к открытому контуру и закрытому контуру.

Квалификация администратора #

Администратор должен обладать:

• базовыми навыками администрирования Linux;

• навыками работы с Kubernetes и процессами автоматизации управления контейнерными приложениями в кластерах.

Схемы и матрицы сетевого трафика #

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

• Открытый контур — якоря вида #capsm-v2-…, #capov-capvs-…, #capos-external-kubeapi-external-ingress-public-cloud и др.

• Закрытый контур — те же идентификаторы сценариев; сценарии публичных облаков (#capos-external-kubeapi-external-ingress-public-cloud) применимы только к открытому контуру.

Общие порты и правила для настройки межсетевых экранов по контурам — в разделах «Сетевые требования» на страницах открытого и закрытого контура.

Требования к DNS и сетевым именам #

• Узел кластера — уникальное сетевое имя; валидное DNS-имя не длиннее 63 символов (при создании узлов из образа или шаблона платформой имя может назначаться автоматически — нюансы у конкретного провайдера, см. таблицу провайдеров).

• Имя каждого кластера — уникальное в сочетании с доменной зоной организации.

• В DNS: одна зона; для каждого узла — запись типа A в этой зоне; для Ingress — wildcard *.<cluster_name>.<base_domain>.

• Имена узлов, VIP и FQDN API/Ingress клиентского кластера должны разрешаться в IP-адреса на узлах. В закрытом контуре также должны резолвиться FQDN зеркала (для загрузки образов).

Требования к IP-адресам и VIP #

• IP-адреса узлов не меняются при эксплуатации; замена узла — вывод из кластера и добавление с новым адресом.

• Все узлы Control Plane клиентского кластера — одна подсеть и один широковещательный сегмент.

• Без внешних балансировщиков для KubeAPI и Ingress нужны два свободных VIP, не назначенных на интерфейсы узлов до установки.

• При одном Control Plane: адрес узла, затем VIP API, затем VIP Ingress — по возрастанию адресов.

См. также пулы IP-адресов и FQDN и VIP.