Katamarina - PaaS-платформа для построения облачных инфраструктур. – Руководство по развертыванию Cozystack

Docs: Автоматизированная установка с Ansible

Mon, 01 Jan 0001 00:00:00 +0000

Автоматизированная установка с Ansible

Ansible collection cozystack.installer автоматизирует весь pipeline развертывания: подготовку ОС, bootstrap кластера k3s и установку Cozystack. Она подходит для развертывания Cozystack на bare-metal серверах или ВМ со стандартным дистрибутивом Linux.

Когда использовать Ansible

Рассмотрите этот подход, если:

Вам нужно полностью автоматизированное, повторяемое развертывание от чистой ОС до работающего Cozystack
Вы развертываете платформу на generic Linux (Ubuntu, Debian, RHEL, Rocky, openSUSE), а не на Talos Linux
Вы хотите управлять несколькими узлами через один inventory-файл

Шаги ручной установки без Ansible см. в руководстве Generic Kubernetes.

Предварительные требования

Управляющая машина

Python >= 3.9
Ansible >= 2.15

Целевые узлы

Операционная система: Ubuntu/Debian, RHEL 8+/CentOS Stream 8+/Rocky/Alma или openSUSE/SLE
Архитектура: amd64 или arm64
SSH-доступ с passwordless sudo
Требования к CPU, RAM и дискам см. в требованиях к оборудованию

Установка

1. Установка Ansible collection

ansible-galaxy collection install git+https://github.com/cozystack/ansible-cozystack.git

Установите необходимые dependency collections. Файл requirements.yml не включен в packaged collection, поэтому скачайте его из репозитория:

curl --silent --location --output /tmp/requirements.yml \
 https://raw.githubusercontent.com/cozystack/ansible-cozystack/main/requirements.yml
ansible-galaxy collection install --requirements-file /tmp/requirements.yml

Это установит следующие зависимости:

ansible.posix, community.general, kubernetes.core — из Ansible Galaxy
k3s.orchestration — collection для развертывания k3s, устанавливается из Git

2. Создание inventory

Создайте файл inventory.yml. Внутренний (private) IP каждого узла должен использоваться как host key, потому что KubeOVN проверяет IP хостов через NODE_IPS. Public IP, если он отличается, указывается в ansible_host.

cluster:
 children:
 server:
 hosts:
 10.0.0.10:
 ansible_host: 203.0.113.10
 agent:
 hosts:
 10.0.0.11:
 ansible_host: 203.0.113.11
 10.0.0.12:
 ansible_host: 203.0.113.12
 vars:
 ansible_port: 22
 ansible_user: ubuntu

 # настройки k3s — доступные версии см. на https://github.com/k3s-io/k3s/releases
 k3s_version: v1.35.0+k3s3
 token: # ЗАМЕНИТЕ на надежный случайный secret
 api_endpoint:
 cluster_context: my-cluster

 # настройки Cozystack
 cozystack_api_server_host:
 cozystack_root_host:
 cozystack_platform_variant:
 # cozystack_k3s_extra_args:

Замените token на надежный случайный secret. Этот token используется для подключения узлов k3s и дает полный доступ к кластеру. Сгенерируйте его командой openssl rand -hex 32.

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

cozystack_chart_version: "1.5.0"

Доступные версии см. в релизах Cozystack.

3. Создание playbook

Создайте файл site.yml, который последовательно запускает подготовку ОС, развертывание k3s и установку Cozystack.

Репозиторий collection содержит примеры prepare playbooks для каждого поддерживаемого семейства ОС в каталоге examples/. Скопируйте подходящий для вашей целевой ОС файл в каталог проекта, затем подключите его как локальный playbook.

Скопируйте prepare-ubuntu.yml из examples/ubuntu/, затем создайте site.yml:

- name: Prepare nodes
 ansible.builtin.import_playbook: prepare-ubuntu.yml

- name: Deploy k3s cluster
 ansible.builtin.import_playbook: k3s.orchestration.site

- name: Install Cozystack
 ansible.builtin.import_playbook: cozystack.installer.site

4. Запуск playbook

ansible-playbook --inventory inventory.yml site.yml

Playbook автоматически выполняет следующие шаги:

Prepare nodes — устанавливает необходимые пакеты (nfs-common, open-iscsi, multipath-tools), настраивает sysctl, включает storage services
Deploy k3s — выполняет bootstrap кластера k3s с настройками, совместимыми с Cozystack (отключает встроенные Traefik, ServiceLB, kube-proxy, Flannel; задает cluster-domain=cozy.local)
Install Cozystack — устанавливает Helm и plugin helm-diff (используется для идемпотентных обновлений), развертывает chart cozy-installer, ожидает operator и CRD, затем создает Platform Package

Справочник конфигурации

Основные переменные

Переменная	По умолчанию	Описание
cozystack_api_server_host	(обязательно)	Внутренний IP узла control plane.
cozystack_chart_version	1.5.0	Версия Helm chart Cozystack. Закрепляйте явно.
cozystack_platform_variant	isp-full-generic	Platform variant: `default`, `isp-full`, `isp-hosted`, `isp-full-generic`.
cozystack_root_host	""	Домен для сервисов Cozystack. Оставьте пустым, чтобы пропустить publishing configuration.

Сеть

Переменная	По умолчанию	Описание
cozystack_pod_cidr	10.42.0.0/16	Диапазон Pod CIDR.
cozystack_pod_gateway	10.42.0.1	Gateway pod-сети.
cozystack_svc_cidr	10.43.0.0/16	Диапазон Service CIDR.
cozystack_join_cidr	100.64.0.0/16	Join CIDR для межузлового взаимодействия.
cozystack_api_server_port	6443	Порт Kubernetes API server.

Расширенные настройки

Переменная	По умолчанию	Описание
cozystack_chart_ref	oci://ghcr.io/cozystack/cozystack/cozy-installer	OCI reference для Helm chart.
cozystack_operator_variant	generic	Operator variant: `generic`, `talos`, `hosted`.
cozystack_namespace	cozy-system	Namespace для Cozystack
cozystack_release_name	cozy-installer
cozystack_release_namespace	kube-system
cozystack_kubeconfig	/etc/rancher/k3s/k3s.yaml
cozystack_create_platform_package	true
cozystack_helm_version	3.17.3
cozystack_helm_binary	/usr/local/bin/helm
cozystack_helm_diff_version	3.12.5
cozystack_operator_wait_timeout	300

Переменные prepare playbook

Примерные prepare playbooks (скопированные из каталога examples/) поддерживают дополнительные переменные:

Переменная	По умолчанию	Описание
cozystack_flush_iptables	false
cozystack_k3s_extra_args		Дополнительные аргументы для k3s server (например, `--tls-san=<PUBLIC_IP>` для узлов за NAT).

Проверка

После завершения playbook проверьте развертывание с первого server-узла:

# Проверить operator
kubectl get deployment cozystack-operator --namespace cozy-system

# Проверить Platform Package
kubectl get packages.cozystack.io cozystack.cozystack-platform

# Проверить все pods
kubectl get pods --all-namespaces

Идемпотентность

Playbook идемпотентен: повторный запуск не будет повторно применять ресурсы, которые не изменились. Cozystack operator использует Helm для управления ресурсами, и Ansible collection использует helm-diff, чтобы видеть изменения перед их применением, аналогично kubectl diff.

Docs: Рекомендации по планированию системных ресурсов

Mon, 01 Jan 0001 00:00:00 +0000

Размер кластера	Узлы	До 5 tenants	6-14 tenants	15-30 tenants	31+ tenants
Малый	3-5	CPU: 2 ядра RAM: 6 ГБ	CPU: 2 ядра RAM: 6 ГБ	CPU: 3 ядра RAM: 10 ГБ	CPU: 3 ядра RAM: 15 ГБ
Средний	6-10	CPU: 3 ядра RAM: 7 ГБ	CPU: 3 ядра RAM: 7 ГБ	CPU: 3 ядра RAM: 12 ГБ	CPU: 4 ядра RAM: 18 ГБ
Крупный	11+	CPU: 3 ядра RAM: 9 ГБ	CPU: 3 ядра RAM: 10 ГБ	CPU: 4 ядра RAM: 15 ГБ	CPU: 4 ядра RAM: 22 ГБ

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Варианты развертывания

Минимальная конфигурация

Ниже приведены базовые требования для запуска небольшой инсталляции. Минимальная рекомендуемая конфигурация для каждого узла:

Компонент	Требование
Хосты	3x физических хоста (или ВМ с host CPU passthrough)
Architecture	x86_64
CPU	8 ядер
RAM	24 ГБ
Основной диск	50 ГБ SSD (или RAW для ВМ)
Дополнительный диск	256 ГБ SSD (raw)

Подходит для:

Dev/Test-сред
Небольших демонстрационных конфигураций
1-2 tenants
До 3 кластеров Kubernetes
Небольшого числа ВМ или баз данных

Компонент	Требование
Хосты	3x физических хоста
Architecture	x86_64
CPU	16-32 ядра
RAM	64 ГБ
Основной диск	100 ГБ SSD или NVMe
Дополнительный диск	1-2 ТБ SSD или NVMe

Оптимальная конфигурация

Для средних и крупных production-сред оптимальная конфигурация каждого узла выглядит так:

Компонент	Требование
Хосты	6x+ физических хостов
Architecture	x86_64
CPU	32-64 ядра
RAM	128-256 ГБ
Основной диск	200 ГБ SSD или NVMe
Дополнительный диск	4-10 ТБ NVMe

Подходит для:

Крупных production-сред
20+ tenants
Десятков кластеров Kubernetes
Сотен виртуальных машин и баз данных
S3-совместимого хранилища

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

Три или более физических либо виртуальных сервера с архитектурой 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 см. в разделе Рекомендации по планированию системных ресурсов.

Docs: Установка и настройка Cozystack

Mon, 01 Jan 0001 00:00:00 +0000

Установка и настройка Cozystack

Третий шаг развертывания кластера Cozystack — установка Cozystack в ранее установленный и настроенный кластер Kubernetes. Предварительное условие для этого шага — установленный кластер Kubernetes.

Cozystack можно установить в двух режимах, в зависимости от того, насколько детально вы хотите управлять устанавливаемыми компонентами:

Как платформа

Установите Cozystack как готовую к использованию платформу, где все компоненты управляются автоматически. Вы выбираете variant (например, isp-full), а Cozystack устанавливает и настраивает все необходимые компоненты — сеть, хранилище, мониторинг, dashboard, operators и managed applications.

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

Установить Cozystack как платформу

Build Your Own Platform (BYOP)

Используйте Cozystack, чтобы собрать собственную платформу, устанавливая только нужные компоненты. Вы устанавливаете operator с variant default, который предоставляет только package registry (PackageSources). Затем с помощью CLI-инструмента cozypkg выборочно устанавливаете отдельные packages — networking, storage, ingress, operators и любые другие компоненты, доступные в репозитории Cozystack.

Этот подход подходит, если у вас уже есть существующий кластер Kubernetes с частью инфраструктуры или если вам нужны только отдельные компоненты из экосистемы Cozystack.

Собрать собственную платформу с Cozystack

Установка Cozystack как платформы

Установите Cozystack как готовую к использованию платформу, где все компоненты управляются автоматически.

Собственная платформа (BYOP)

Соберите собственную платформу с Cozystack, устанавливая только нужные компоненты с помощью CLI-инструмента cozypkg.

Katamarina - PaaS-платформа для построения облачных инфраструктур. – Руководство по развертыванию Cozystack

Docs: Автоматизированная установка с Ansible

Автоматизированная установка с Ansible

Когда использовать Ansible

Предварительные требования

Управляющая машина

Целевые узлы

Установка

1. Установка Ansible collection

2. Создание inventory

3. Создание playbook

4. Запуск playbook

Справочник конфигурации

Основные переменные

Сеть

Расширенные настройки

Переменные prepare playbook

Проверка

Идемпотентность

Docs: Рекомендации по планированию системных ресурсов

Рекомендации по планированию системных ресурсов

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

Рассчитайте свои требования

Почему требования к ресурсам масштабируются

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

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

Варианты развертывания

Минимальная конфигурация

Рекомендуемая конфигурация

Оптимальная конфигурация

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

Хранилище:

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

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

Сеть:

Production-кластер

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

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

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

Docs: Установка и настройка Cozystack

Установка и настройка Cozystack

Как платформа

Build Your Own Platform (BYOP)

Установка Cozystack как платформы

Собственная платформа (BYOP)