Требования к оборудованию

Cozystack использует Talos Linux — минималистичный дистрибутив Linux, предназначенный исключительно для запуска Kubernetes. Обычно это означает, что сервер нельзя совместно использовать с сервисами, которые не запущены Cozystack. Хорошая новость в том, что какой бы сервис вам ни понадобился, Cozystack сможет запустить его корректно: безопасно, эффективно и в полностью контейнеризованной или виртуализованной среде.

Требования к оборудованию зависят от вашего сценария использования. Ниже приведены несколько распространенных вариантов развертывания; изучите их, чтобы определить, какая конфигурация лучше всего подходит под ваши задачи.

• Минимальная
• Рекомендуемая
• Оптимальная

Вычислительные ресурсы:

• Три или более физических либо виртуальных сервера с архитектурой amd64/x86_64 и характеристиками, указанными в таблице выше.
• Для виртуализированных серверов должна быть включена вложенная виртуализация, а модель CPU должна быть установлена в host (без эмуляции).
• Для установки через PXE требуется дополнительный управляющий инстанс, подключенный к той же сети, с любой Linux-системой, способной запускать Docker-контейнер. Он также должен иметь архитектуру x86-64-v2; в случае виртуальной машины этого, скорее всего, можно добиться, установив модель CPU в host.

Хранилище:

Хранилище в кластере Cozystack используется как системой, так и пользовательскими workload’ами. Есть два варианта: выделить отдельный диск для каждой роли или выделить место под пользовательское хранилище на системном диске. Для хранилища узлов control plane критически важна низкая задержка, поэтому рекомендуются локальные SSD.

Использование двух дисков

Разделение дисков по ролям — основной и более надежный вариант.

• Основной диск: на этом диске находятся операционная система Talos Linux, необходимые системные модули ядра, базовые системные поды Cozystack, логи и базовые контейнерные образы. Также поверх него будет работать кластер etcd, поэтому следует использовать том с низкой задержкой, предпочтительно локальный SSD.

  Минимальные размеры зависят от конфигурации (см. таблицу выше). Установка Talos ожидает /dev/sda в качестве системного диска (диски virtio обычно отображаются как /dev/vda).

• Дополнительный диск: предназначен для данных workload’ов, его размер можно увеличивать в зависимости от требований workload’ов. Используется для выделения томов через PersistentVolumeClaims (PVC).

  Минимальные размеры зависят от конфигурации (см. таблицу выше). Путь к диску (обычно /dev/sdb) будет указан в конфигурации хранилища. Он не влияет на установку Talos.

  Подробнее о настройке Linstor StorageClass см. в руководстве по развертыванию Cozystack

Использование одного диска

Можно использовать один диск с выделенным пространством для пользовательского хранилища. См. Как установить Talos на машину с одним диском Рекомендуется использовать локальный SSD-диск.

Сеть:

• Машинам должно быть разрешено использовать дополнительные IP-адреса, либо должен быть доступен внешний балансировщик нагрузки. Использование дополнительных IP-адресов по умолчанию отключено и в большинстве публичных облаков должно включаться явно.
• Могут потребоваться дополнительные публичные IP-адреса для ingress и виртуальных машин. Проверьте, поддерживает ли ваш облачный провайдер floating IP.
• Маршрутизируемый FQDN-домен (или используйте nip.io с записью через дефис)
• Размещение в одном L2-сегменте сети
• Отключенный anti-spoofing (требуется для MetalLB)
• Минимум 1 Гбит/с (для production рекомендуется 10 Гбит/с)
• Низкая задержка между узлами кластера

Production-кластер

Для production-среды учитывайте следующее:

Вычислительные ресурсы:

• Для запуска высокодоступных приложений обязательно иметь как минимум три worker-узла. Если один из трех узлов станет недоступен из-за аппаратного сбоя или обслуживания, кластер будет работать в деградированном состоянии. Кластеры баз данных и реплицированное хранилище продолжат работать, но запуск новых экземпляров баз данных или создание реплицированных томов будет невозможным.
• Настоятельно рекомендуется, хотя и не обязательно, использовать отдельные серверы для master-узлов Kubernetes. Чистый worker-узел гораздо проще выводить из эксплуатации для обслуживания или обновления, чем узел, который одновременно является управляющим.

Сеть:

• В конфигурации с несколькими дата-центрами оптимально иметь прямые выделенные оптические каналы между ними.
• Серверы должны поддерживать out-of-band management (IPMI, iLO, iDRAC и т. д.) для удаленного мониторинга, восстановления и управления.

Распределенный кластер

С помощью Cozystack можно построить распределенный кластер.

Сеть:

• Для распределенного кластера требуется быстрая и надежная сеть, и у нее обязательно должен быть низкий RTT (Round Trip Time), так как Kubernetes не рассчитан на эффективную работу в сетях с высокой задержкой.

  Дата-центры в пределах одного города обычно имеют задержку менее 1 мс, что является идеальным вариантом. Максимально допустимый RTT — 10 мс. Запуск Kubernetes или реплицированного хранилища в сети с RTT выше 20 мс настоятельно не рекомендуется. Для измерения фактического RTT можно использовать команду ping.

• Также рекомендуется иметь как минимум 2–3 узла на дата-центр в распределенном кластере. Это гарантирует, что кластер сможет пережить потерю одного дата-центра без серьезных нарушений работы.

• Если сложно поддерживать единое адресное пространство между дата-центрами, вместо внешнего VPN можно включить KubeSpan — функцию Talos Linux, которая создает full-mesh VPN между узлами на базе WireGuard.

Высокодоступные приложения

Обеспечение высокой доступности добавляет требования к базовой production-среде.

Сеть:

• Рекомендуется иметь несколько сетевых карт 10 Гбит/с или быстрее. Трафик хранилища и приложений можно разделить, назначив их разным сетевым интерфейсам.

• Ожидайте значительный объем горизонтального межузлового трафика внутри кластеров. Обычно он возникает из-за обмена данными между несколькими репликами сервисов и баз данных, развернутыми на разных узлах. Кроме того, виртуальные машины с live migration требуют реплицированных томов, что дополнительно увеличивает объем трафика.

Планирование системных ресурсов

Подробные рекомендации по выделению системных ресурсов (CPU и памяти) на узел с учетом масштаба кластера и количества tenants см. в разделе Рекомендации по планированию системных ресурсов.