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

Docs: Установка Talos Linux

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

1. Установка Talos Linux

Перед началом

Убедитесь, что у вас есть узлы (bare-metal серверы или виртуальные машины), соответствующие требованиям к оборудованию.

Цели

На этом шаге вы установите Talos Linux на bare-metal серверы или виртуальные машины, на которых сейчас работает другой дистрибутив Linux.

В этом руководстве используется boot-to-talos — простой CLI-инструмент, созданный командой Cozystack для пользователей и команд, внедряющих Cozystack. Существуют и другие способы установки Talos Linux для Cozystack, но они здесь не рассматриваются и описаны в отдельных руководствах.

Установка

1. Установите boot-to-talos

Установите boot-to-talos с помощью установочного скрипта:

curl -sSL https://github.com/cozystack/boot-to-talos/raw/refs/heads/main/hack/install.sh | sh -s

2. Запустите установку Talos

Запустите boot-to-talos и укажите значения конфигурации. Убедитесь, что используете сборку Talos от Cozystack, опубликованную в ghcr.io/cozystack/cozystack/talos. Для Cozystack v1.5.0 закрепленная версия Talos — v1.13.0. Переопределите значение по умолчанию в installer prompt:

$ boot-to-talos
Target disk [/dev/sda]:
Talos installer image [ghcr.io/cozystack/cozystack/talos:v1.11.6]: ghcr.io/cozystack/cozystack/talos:v1.13.0
Add networking configuration? [yes]:
Interface [eth0]:
IP address [10.0.2.15]:
Netmask [255.255.255.0]:
Gateway (or 'none') [10.0.2.2]:
Configure serial console? (or 'no') [ttyS0]:

Summary:
 Image: ghcr.io/cozystack/cozystack/talos:v1.13.0
 Disk: /dev/sda
 Extra kernel args: ip=10.0.2.15::10.0.2.2:255.255.255.0::eth0::::: console=ttyS0

WARNING: ALL DATA ON /dev/sda WILL BE ERASED!

Continue? [yes]:

2025/08/03 00:11:03 created temporary directory /tmp/installer-3221603450
2025/08/03 00:11:03 pulling image ghcr.io/cozystack/cozystack/talos:v1.13.0
2025/08/03 00:11:03 extracting image layers
2025/08/03 00:11:07 creating raw disk /tmp/installer-3221603450/image.raw (2 GiB)
2025/08/03 00:11:07 attached /tmp/installer-3221603450/image.raw to /dev/loop0
2025/08/03 00:11:07 starting Talos installer
2025/08/03 00:11:07 running Talos installer v1.13.0
2025/08/03 00:11:07 WARNING: config validation:
2025/08/03 00:11:07 use "worker" instead of "" for machine type
2025/08/03 00:11:07 created EFI (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) size 104857600 bytes
2025/08/03 00:11:07 created BIOS (21686148-6449-6E6F-744E-656564454649) size 1048576 bytes
2025/08/03 00:11:07 created BOOT (0FC63DAF-8483-4772-8E79-3D69D8477DE4) size 1048576000 bytes
2025/08/03 00:11:07 created META (0FC63DAF-8483-4772-8E79-3D69D8477DE4) size 1048576 bytes
2025/08/03 00:11:07 formatting the partition "/dev/loop0p1" as "vfat" with label "EFI"
2025/08/03 00:11:07 formatting the partition "/dev/loop0p2" as "zeroes" with label "BIOS"
2025/08/03 00:11:07 formatting the partition "/dev/loop0p3" as "xfs" with label "BOOT"
2025/08/03 00:11:07 formatting the partition "/dev/loop0p4" as "zeroes" with label "META"
2025/08/03 00:11:07 copying from io reader to /boot/A/vmlinuz
2025/08/03 00:11:07 copying from io reader to /boot/A/initramfs.xz
2025/08/03 00:11:08 writing /boot/grub/grub.cfg to disk
2025/08/03 00:11:08 executing: grub-install --boot-directory=/boot --removable --efi-directory=/boot/efi
2025/08/03 00:11:08 installation of v1.13.0 complete
2025/08/03 00:11:08 Talos installer finished successfully
2025/08/03 00:11:08 remounting all filesystems read-only
2025/08/03 00:11:08 copy /tmp/installer-3221603450/image.raw -> /dev/sda
2025/08/03 00:11:19 installation image copied to /dev/sda
2025/08/03 00:11:19 rebooting system

Следующий шаг

Продолжите руководство по Cozystack и установите Kubernetes-кластер с помощью Talm.

Дополнительно:

Прочитайте обзор Talos Linux, чтобы понять, почему Talos Linux — оптимальный выбор ОС для Cozystack и что он даёт платформе.
Узнайте больше о boot-to-talos.
Загляните в github.com/cozystack/boot-to-talos и поставьте проекту звезду.

Docs: Установка и bootstrap кластера Kubernetes

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

2. Установка и bootstrap кластера Kubernetes

Цели

К началу этого шага у нас уже есть три узла с установленным Talos Linux.

В результате этого шага у вас будет установленный и настроенный Kubernetes-кластер, готовый к установке Cozystack. Также вы получите kubeconfig для этого кластера и выполните базовые проверки его состояния.

Установка Kubernetes

Установите и выполните bootstrap кластера Kubernetes с помощью Talm — декларативного CLI-инструмента управления конфигурацией с готовыми пресетами для Cozystack.

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

Следующий шаг

Продолжите руководство по Cozystack и установите Cozystack.

Дополнительно:

Загляните в github.com/cozystack/talm и поставьте проекту звезду.

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

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

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

Цели

Это руководство описывает установку Cozystack как готовой к использованию платформы. Если вы хотите собрать собственную платформу, устанавливая только нужные компоненты, см. руководство BYOP (Build Your Own Platform).

На этом шаге мы установим Cozystack поверх Kubernetes-кластера, подготовленного на предыдущем шаге.

Руководство проведёт вас через следующие этапы:

Установка оператора Cozystack
Подготовка файла конфигурации Cozystack и его применение
Настройка хранилища
Настройка сети
Развёртывание etcd, ingress и стека мониторинга в корневом tenant’е
Завершение развёртывания и вход в дашборд Cozystack

1. Установка оператора Cozystack

Установите оператор Cozystack с помощью Helm chart из OCI-реестра. Оператор управляет всеми компонентами платформы.

helm upgrade --install cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer \
 --version X.Y.Z \
 --namespace cozy-system

Замените X.Y.Z на нужную версию Cozystack. Доступные версии перечислены на странице релизов Cozystack.

Если установка прерывается из-за того, что cozy-system уже существует: Helm отказывается забирать себе namespace, который создал не он, и выводит ошибку invalid ownership metadata (или namespaces в зависимости от версии Helm), если cozy-system остался после ранее прерванной установки или был создан вручную для этой цели.

Если namespace не управляется другим инструментом (Terraform, Argo CD, другим Helm release и т. д.), повторите команду с флагом --take-ownership (требуется Helm 3.17+), чтобы Helm смог принять его под управление:

helm upgrade --install cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer \
 --version X.Y.Z \
 --namespace cozy-system \
 --create-namespace \
 --take-ownership

[!CAUTION] Не используйте --take-ownership, если cozy-system уже принадлежит другой системе — Helm незаметно станет новым владельцем, а последующие обновления или удаление релиза Cozystack могут изменить или удалить namespace (и всё, что было принято под управление этим флагом) вопреки ожиданиям этой системы.

2. Подготовка и применение Platform Package

2.1. Подготовьте файл конфигурации

Теперь, когда оператор запущен, подготовим для него файл конфигурации. Возьмите пример ниже и сохраните его в файл cozystack-platform.yaml:

apiVersion: cozystack.io/v1alpha1
kind: Package
metadata:
 name: cozystack.cozystack-platform
spec:
 variant: isp-full
 components:
 platform:
 values:
 publishing:
 host: example.org
 apiServerEndpoint: api.example.org
 exposedServices:
 - dashboard
 - api
 networking:
 podCIDR: 10.244.0.0/16
 podGateway: 10.244.0.1
 serviceCIDR: 10.96.0.0/12
 joinCIDR: 100.64.0.0/16

Что нужно сделать:

Замените example.org в publishing.host и publishing.apiServerEndpoint на маршрутизируемое полное доменное имя (FQDN), которым вы управляете. Если у вас есть только публичные IP-адреса, вы можете использовать сервис nip.io с dash-нотацией.
Используйте для networking.* те же значения, что и на предыдущем шаге, где вы выполняли bootstrap Kubernetes-кластера через Talos. Чтобы узнать эти значения, вы можете проверить конфигурационные файлы Talos или выполнить команды talosctl. Значения из примера — это разумные значения по умолчанию, которые подходят для большинства случаев.

В этой конфигурации есть и другие значения, которые в рамках руководства менять не требуется. Тем не менее, вот что они означают:

metadata.name должен быть равен cozystack.cozystack-platform, чтобы совпасть с PackageSource, созданным установщиком.
publishing.host используется как основной домен для всех сервисов, создаваемых в Cozystack, например дашборда, Grafana и т. д.
publishing.apiServerEndpoint — это endpoint Cluster API. Он используется для генерации kubeconfig-файлов для пользователей. Рекомендуется использовать поддомен от publishing.host.
spec.variant: isp-full означает, что используется наиболее полный набор компонентов Cozystack. Подробнее о вариантах см. в справочнике по вариантам Cozystack.
publishing.exposedServices перечисляет сервисы, которые должны быть доступны пользователям — здесь это дашборд (UI) и API.
networking.* — это внутренняя сетевая конфигурация базового Kubernetes-кластера:
- networking.podCIDR — диапазон CIDR, из которого Kube-OVN выделяет IP-адреса pod’ам. Он не должен пересекаться ни с одной физической сетью.
- networking.podGateway — адрес шлюза, который Kube-OVN назначает подсети pod’ов по умолчанию. Используйте адрес .1 сети podCIDR (например, 10.244.0.1 для 10.244.0.0/16).
- networking.serviceCIDR — диапазон CIDR для сервисов ClusterIP. Он обязательно должен совпадать со значением cluster.network.serviceSubnets, которое вы использовали при bootstrap Kubernetes-кластера: это значение вшивается в kube-apiserver и не может быть легко изменено позже.
- networking.joinCIDR — диапазон CIDR для join подсети Kube-OVN, внутренней сети, которая переносит трафик между узлами кластера и pod’ами. Значение по умолчанию 100.64.0.0/16 входит в общее адресное пространство RFC 6598 (100.64.0.0/10), зарезервированное для такого внутреннего использования. Меняйте его только если оно пересекается с вашей физической сетью. Подробнее см. в справочнике по Kube-OVN join subnet.

Подробнее об этом файле конфигурации см. в справочнике Platform Package.

По умолчанию Cozystack собирает анонимную статистику использования. Подробнее о том, какие данные собираются и как это отключить, см. в документации по телеметрии.

2.2. Примените Platform Package

Примените файл конфигурации:

kubectl apply -f cozystack-platform.yaml

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

kubectl logs -n cozy-system -l app.kubernetes.io/name=cozy-installer -f

2.3. Проверьте статус установки

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

kubectl get packages.cozystack.io cozystack.cozystack-platform

Повторяйте проверку, пока во всех строках не появится True, как в этом примере:

kubectl get cozystack -A

Пример вывода:

cozy-cert-manager cert-manager 4m1s True Release reconciliation succeeded
cozy-cert-manager cert-manager-issuers 4m1s True Release reconciliation succeeded
cozy-cilium cilium 4m1s True Release reconciliation succeeded
cozy-cluster-api capi-operator 4m1s True Release reconciliation succeeded
cozy-cluster-api capi-providers 4m1s True Release reconciliation succeeded
cozy-dashboard dashboard 4m1s True Release reconciliation succeeded
cozy-grafana-operator grafana-operator 4m1s True Release reconciliation succeeded
cozy-kamaji kamaji 4m1s True Release reconciliation succeeded
cozy-kubeovn kubeovn 4m1s True Release reconciliation succeeded
cozy-kubevirt-cdi kubevirt-cdi 4m1s True Release reconciliation succeeded
cozy-kubevirt-cdi kubevirt-cdi-operator 4m1s True Release reconciliation succeeded
cozy-kubevirt kubevirt 4m1s True Release reconciliation succeeded
cozy-kubevirt kubevirt-operator 4m1s True Release reconciliation succeeded
cozy-linstor linstor 4m1s True Release reconciliation succeeded
cozy-linstor piraeus-operator 4m1s True Release reconciliation succeeded
cozy-mariadb-operator mariadb-operator 4m1s True Release reconciliation succeeded
cozy-metallb metallb 4m1s True Release reconciliation succeeded
cozy-monitoring monitoring 4m1s True Release reconciliation succeeded
cozy-postgres-operator postgres-operator 4m1s True Release reconciliation succeeded
cozy-rabbitmq-operator rabbitmq-operator 4m1s True Release reconciliation succeeded
cozy-redis-operator redis-operator 4m1s True Release reconciliation succeeded
cozy-telepresence telepresence 4m1s True Release reconciliation succeeded
cozy-victoria-metrics-operator victoria-metrics-operator 4m1s True Release reconciliation succeeded
tenant-root tenant-root 4m1s True Release reconciliation succeeded

Список компонентов в вашей установке может отличаться от приведённого выше, так как он зависит от выбранного варианта и версии Cozystack. Когда у всех компонентов появится READY: True, можно переходить к настройке подсистем.

3. Настройка хранилища

Kubernetes нужен слой хранилища для предоставления persistent volumes приложениям, но собственного такого механизма у него нет. В качестве подсистемы хранения Cozystack использует LINSTOR. Далее мы получим доступ к интерфейсу LINSTOR, создадим storage pool’ы и определим storage class’ы.

3.1. Проверьте устройства хранения

Настройте alias для доступа к LINSTOR:

alias linstor='kubectl exec -n cozy-linstor deploy/linstor-controller -- linstor'

Выведите список узлов и проверьте их готовность:

linstor node list

Выведите список доступных пустых устройств:

linstor physical-disk list

3.2. Создайте storage pool’ы

Создайте storage pool’ы на основе ZFS:

linstor storage-pool create zfs srv1 data data
linstor storage-pool create zfs srv2 data data
linstor storage-pool create zfs srv3 data data

Рекомендуется установить для ZFS storage pool’ов failmode=continue, чтобы обработкой отказов диска занимался DRBD, а не ZFS.

kubectl exec -ti -n cozy-linstor ds/linstor-satellite.srv1 -- zpool set failmode=continue data
kubectl exec -ti -n cozy-linstor ds/linstor-satellite.srv2 -- zpool set failmode=continue data
kubectl exec -ti -n cozy-linstor ds/linstor-satellite.srv3 -- zpool set failmode=continue data

Проверьте результат, выведя список storage pool’ов:

linstor storage-pool list

Пример вывода:

StoragePool	Node	Driver	PoolName	FreeCapacity	TotalCapacity	CanSnapshots
DfltDisklessStorPool	srv1	DISKLESS				False
DfltDisklessStorPool	srv2	DISKLESS				False
DfltDisklessStorPool	srv3	DISKLESS				False
data	srv1	ZFS	data	96.41 GiB	99.50 GiB	True
data	srv2	ZFS	data	96.41 GiB	99.50 GiB	True
data	srv3	ZFS	data	96.41 GiB	99.50 GiB	True

3.3. Создайте storage class’ы

Наконец, можно создать несколько storage class’ов, один из которых будет классом по умолчанию. Создайте файл с описанием storage class’ов. Ниже приведён разумный пример по умолчанию с двумя классами: local (по умолчанию) и replicated.

storageclasses.yaml:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: local
 annotations:
 storageclass.kubernetes.io/is-default-class: "true"
provisioner: linstor.csi.linbit.com
parameters:
 linstor.csi.linbit.com/storagePool: data
 linstor.csi.linbit.com/layerList: storage
 linstor.csi.linbit.com/allowRemoteVolumeAccess: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: replicated
provisioner: linstor.csi.linbit.com
parameters:
 linstor.csi.linbit.com/storagePool: data
 linstor.csi.linbit.com/autoPlace: "3"
 linstor.csi.linbit.com/layerList: drbd storage
 linstor.csi.linbit.com/allowRemoteVolumeAccess: "true"
 property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: suspend-io
 property.linstor.csi.linbit.com/DrbdOptions/Resource/on-no-data-accessible: suspend-io
 property.linstor.csi.linbit.com/DrbdOptions/Resource/on-suspended-primary-outdated: force-secondary
 property.linstor.csi.linbit.com/DrbdOptions/Net/rr-conflict: retry-connect
volumeBindingMode: Immediate
allowVolumeExpansion: true

Примените конфигурацию storage class’ов:

kubectl apply -f storageclasses.yaml

Убедитесь, что storage class’ы были успешно созданы:

kubectl get storageclasses

Пример вывода:

NAME	PROVISIONER	RECLAIMPOLICY	VOLUMEBINDINGMODE	ALLOWVOLUMEEXPANSION
local (default)	linstor.csi.linbit.com	Delete	WaitForFirstConsumer	true
replicated	linstor.csi.linbit.com	Delete	Immediate	true

4. Настройка сети

Далее мы настроим способ доступа к кластеру Cozystack. На этом шаге есть два варианта в зависимости от доступной инфраструктуры:

Для собственного bare metal или self-hosted ВМ выбирайте вариант с MetalLB. MetalLB — это балансировщик нагрузки по умолчанию в Cozystack.
Для ВМ и выделенных серверов у облачных провайдеров выбирайте настройку через публичные IP. Большинство облачных провайдеров не поддерживают MetalLB.

Загляните в раздел provider-specific installation. Возможно, там уже есть инструкции для вашего провайдера, подходящие для развёртывания production-ready кластера.

4.a Настройка MetalLB

В Cozystack используются три типа IP-адресов:

IP-адреса узлов: постоянные и действуют только внутри кластера.
Виртуальный floating IP: используется для доступа к одному из узлов кластера и также действует только внутри кластера.
IP-адреса внешнего доступа: используются LoadBalancer’ами для публикации сервисов за пределами кластера.

Сервисы с внешними IP могут публиковаться в двух режимах: L2 и BGP. Режим L2 проще, но требует, чтобы все узлы находились в одном L2-сегменте. Режим BGP более надёжен и масштабируем, но требует поддержки BGP со стороны сетевого оборудования.

Выберите диапазон неиспользуемых IP-адресов для сервисов; в примере используется диапазон 192.168.100.200-192.168.100.250. Если вы используете режим L2, эти IP должны либо принадлежать той же сети, что и узлы, либо до них должен быть настроен проброс трафика (маршрутизация).

Для режима BGP также потребуются IP-адреса BGP peer’ов и локальные и удалённые номера AS. В примере ниже используется 192.168.20.254 как IP peer’а и номера AS 65000 и 65001 как локальный и удалённый соответственно.

Создайте и примените файл с описанием пула адресов metallb-ip-address-pool.yml:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
 name: cozystack
 namespace: cozy-metallb
spec:
 addresses:
 # используется для публикации сервисов за пределами кластера
 - 192.168.100.200-192.168.100.250
 autoAssign: true
 avoidBuggyIPs: false

kubectl apply -f metallb-ip-address-pool.yml

Создайте и примените ресурсы, необходимые для L2- или BGP-анонса. L2Advertisement использует имя ресурса IPAddressPool, который мы создали на предыдущем шаге.

metallb-l2-advertisement.yml:

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
 name: cozystack
 namespace: cozy-metallb
spec:
 ipAddressPools:
 - cozystack

Примените изменения:

kubectl apply -f metallb-l2-advertisement.yml

Теперь, когда MetalLB настроен, включите ingress в tenant-root:

kubectl patch -n tenant-root tenants.apps.cozystack.io root --type=merge -p '{"spec":{"components":{"ingress":{"enabled":true}}}}'

Чтобы убедиться, что всё настроено корректно, проверьте HelmRelease’ы ingress и ingress-nginx-system:

kubectl get hr -n tenant-root

Пример корректного вывода:

ingress 47m True Helm upgrade succeeded for release tenant-root/ingress.v3 with...
ingress-nginx-system 47m True Helm upgrade succeeded for release tenant-root/ingress-nginx-s...

Затем проверьте состояние сервиса root-ingress-controller:

kubectl get svc -n tenant-root root-ingress-controller

Сервис должен быть развёрнут как TYPE: LoadBalancer и иметь корректный внешний IP:

NAME	TYPE	CLUSTER-IP	EXTERNAL-IP	PORT(S)
root-ingress-controller	LoadBalancer	10.96.16.141	192.168.100.200	80:31632/TCP, 443:30113/TCP

4.b. Настройка публичных IP узлов

Если ваш облачный провайдер не поддерживает MetalLB, вы можете опубликовать ingress controller через externalIPs напрямую. Если публичные IP привязаны непосредственно к узлам, укажите их. Если публичные IP предоставляются облаком как виртуальные (Elastic IP), укажите IP-адреса внешних сетевых интерфейсов. В примере используются 192.168.100.11, 192.168.100.12 и 192.168.100.13.

Сначала добавьте внешние IP в Platform Package:

kubectl patch packages.cozystack.io cozystack.cozystack-platform --type=merge -p '{"spec":{"components":{"platform":{"values":{"publishing":{"externalIPs":["192.168.100.11","192.168.100.12","192.168.100.13"]}}}}}}'

Затем включите ingress для корневого tenant’а:

kubectl patch -n tenant-root tenants.apps.cozystack.io root --type=merge -p '{"spec":{"components":{"ingress":{"enabled":true}}}}'

Наконец, добавьте внешние IP-адреса в список externalIPs в конфигурации Ingress:

kubectl patch -n tenant-root ingresses.apps.cozystack.io ingress --type=merge -p '{"spec":{"externalIPs":["192.168.100.11","192.168.100.12","192.168.100.13"]}}'

После этого ваш Ingress будет доступен по указанным IP-адресам. Проверьте это так:

kubectl get svc -n tenant-root root-ingress-controller

Сервис должен быть развёрнут как TYPE: ClusterIP и содержать полный список внешних IP:

NAME	TYPE	CLUSTER-IP	EXTERNAL-IP	PORT(S)
root-ingress-controller	ClusterIP	10.96.91.83	192.168.100.11, 192.168.100.12, 192.168.100.13	80/TCP, 443/TCP

5. Завершение установки

5.1. Настройте сервисы корневого tenant’а

Включите etcd и monitoring для корневого tenant’а:

kubectl patch -n tenant-root tenants.apps.cozystack.io root --type=merge -p '{"spec":{"components":{"monitoring":{"enabled":true},"etcd":{"enabled":true}}}}'

5.2. Проверьте состояние и состав кластера

Проверьте созданные persistent volume’ы:

kubectl get pvc -A

Пример вывода:

NAME	STATUS	VOLUME	CAPACITY	…
data-etcd-0	Bound	pvc-4cbd29cc-a29f-453d-b412-451647cd04bf	10Gi	…
data-etcd-1	Bound	pvc-1579f95a-a69d-4a26-bcc2-b15ccdbede0d	10Gi	…
data-etcd-2	Bound	pvc-907009e5-88bf-4d18-91e7-b56b0dbfb97e	10Gi	…
grafana-db-1	Bound	pvc-7b3f4e23-228a-46fd-b820-d033ef4679af	10Gi	…
grafana-db-2	Bound	pvc-ac9b72a4-f40e-47e8-ad24-f50d843b55e4	10Gi	…
vmselect-cachedir-vmselect-longterm-0	Bound	pvc-622fa398-2104-459f-8744-565eee0a13f1	2Gi	…
vmselect-cachedir-vmselect-longterm-1	Bound	pvc-fc9349f5-02b2-4e25-8bef-6cbc5cc6d690	2Gi	…
vmselect-cachedir-vmselect-shortterm-0	Bound	pvc-7acc7ff6-6b9b-4676-bd1f-6867ea7165e2	2Gi	…
vmselect-cachedir-vmselect-shortterm-1	Bound	pvc-e514f12b-f1f6-40ff-9838-a6bda3580eb7	2Gi	…
vmstorage-db-vmstorage-longterm-0	Bound	pvc-e8ac7fc3-df0d-4692-aebf-9f66f72f9fef	10Gi	…
vmstorage-db-vmstorage-longterm-1	Bound	pvc-68b5ceaf-3ed1-4e5a-9568-6b95911c7c3a	10Gi	…
vmstorage-db-vmstorage-shortterm-0	Bound	pvc-cee3a2a4-5680-4880-bc2a-85c14dba9380	10Gi	…
vmstorage-db-vmstorage-shortterm-1	Bound	pvc-d55c235d-cada-4c4a-8299-e5fc3f161789	10Gi	…

Убедитесь, что все pod’ы запущены:

kubectl get pod -n tenant-root

пример вывода:

NAME	READY	STATUS	RESTARTS	AGE
etcd-0	1/1	Running	0	2m1s
etcd-1	1/1	Running	0	106s
etcd-2	1/1	Running	0	82s
grafana-db-1	1/1	Running	0	119s
grafana-db-2	1/1	Running	0	13s
grafana-deployment-74b5656d6-5dcvn	1/1	Running	0	90s
grafana-deployment-74b5656d6-q5589	1/1	Running	1 (105s ago)	111s

Получите публичный IP ingress controller:

kubectl get svc -n tenant-root root-ingress-controller

Пример вывода:

NAME	TYPE	CLUSTER-IP	EXTERNAL-IP	PORT(S)
root-ingress-controller	LoadBalancer	10.96.16.141	192.168.100.200	80:31632/TCP, 443:30113/TCP

5.3 Доступ к дашборду Cozystack

Если вы включили dashboard в список publishing.exposedServices вашего Platform Package (как показано на шаге 2), дашборд Cozystack уже доступен. Если в исходной конфигурации его не было, обновите Platform Package:

kubectl patch packages.cozystack.io cozystack.cozystack-platform --type=json -p '[{"op":"add","path":"/spec/components/platform/values/publishing/exposedServices/-","value":"dashboard"}]'

Откройте dashboard.example.org, чтобы перейти в системный дашборд, где example.org — домен, указанный вами для tenant-root. Там вы увидите окно входа, ожидающее токен аутентификации.

Получите токен аутентификации для tenant-root:

kubectl get secret -n tenant-root tenant-root -o go-template='{{ printf "%s\n" .data.token | base64decode }}'

Войдите с этим токеном. Теперь вы можете пользоваться дашбордом как администратор. Дальше вы сможете:

Настроить OIDC и использовать его вместо токенов для аутентификации.
Создавать пользовательские tenant’ы и выдавать пользователям доступ через токены или OIDC.

5.4 Доступ к метрикам в Grafana

Используйте grafana.example.org для доступа к системному мониторингу, где example.org — домен, указанный для tenant-root. В этом примере grafana.example.org доступен по адресу 192.168.100.200.

логин: admin получите пароль:

kubectl get secret -n tenant-root grafana-admin-password -o go-template='{{ printf "%s\n" .data.password | base64decode }}'

Следующий шаг

Продолжите руководство по Cozystack и создайте пользовательский tenant.

Docs: Создание пользовательского tenant'а

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

4. Создание пользовательского tenant’а и настройка доступа

Цели

На этом шаге вы создадите пользовательский tenant — пространство, в котором пользователи смогут развёртывать приложения и виртуальные машины. Вы также получите учётные данные tenant’а и войдёте как пользователь с доступом к этому tenant’у.

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

Перед началом:

Завершите предыдущие шаги руководства, чтобы получить работающий кластер Cozystack, в котором уже настроены хранилище, сеть и управляющий дашборд.
Убедитесь, что у вас есть доступ к дашборду, как описано на предыдущем шаге руководства.
Если вы используете OIDC, пользователи и роли уже должны быть настроены. Подробности о работе со встроенным OIDC-сервером см. в руководстве по OIDC.

Во время установки Kubernetes для Cozystack вы должны были получить административный файл kubeconfig для нового кластера. Держите его под рукой — позже он может пригодиться для диагностики. Однако для повседневной работы лучше создать отдельные пользовательские учётные данные.

Введение

Tenant’ы — это механизм изоляции в Cozystack. Они используются для разделения клиентов, команд или окружений. У каждого tenant’а есть собственный набор приложений и один или несколько вложенных Kubernetes-кластеров. Пользователи tenant’а имеют полный доступ к своим кластерам. При необходимости вы можете настроить квоты для каждого tenant’а, чтобы ограничить потребление ресурсов и избежать перерасхода.

Чтобы узнать о tenant’ах больше, прочитайте руководство Core Concepts.

Создание tenant’а

Tenant’ы создаются с помощью приложения Cozystack с именем Tenant. После установки в Cozystack уже существует встроенный tenant tenant-root. Этот корневой tenant зарезервирован для администраторов платформы и должен использоваться только для создания дочерних tenant’ов. Технически установить приложения в tenant-root можно, но для production-окружений это не рекомендуется.

Через дашборд

Откройте дашборд от имени пользователя tenant-root.
Убедитесь, что текущий контекст установлен в tenant-root. При необходимости переключите контекст и перезагрузите страницу.
Перейдите на вкладку Catalog.
Найдите приложение Tenant и откройте его.
Ознакомьтесь с документацией, затем нажмите кнопку Deploy, чтобы перейти к странице параметров.
Заполните поле name tenant’а. Это единственный параметр, который нельзя изменить позже.
(Необязательно) Заполните доменное имя в host. Это доменное имя уже должно существовать. Убедитесь, что пользователь tenant’а имеет достаточный контроль над доменом для настройки DNS-записей. Если оставить поле пустым, по умолчанию будет использован домен <name>.<cozystack-domain>.
Отметьте флажки для установки системных приложений: etcd, monitoring, ingress и seaweedfs. Пользователи tenant’а не смогут устанавливать или удалять эти приложения — это могут делать только администраторы. Параметр etcd требуется для вложенного Kubernetes. Выберите его до установки приложения Kubernetes в tenant’е. Отключайте его только если уверены, что tenant не будет использовать вложенный Kubernetes.
По умолчанию ресурсные квоты не задаются. Это означает отсутствие ограничений на использование ресурсов. При необходимости можно определить квоты, чтобы избежать их перерасхода.
Нажмите Deploy, чтобы установить приложение tenant’а в корневой tenant.

Через kubectl

Создайте манифест HelmRelease для tenant’а. В качестве отправной точки можно взять манифест, созданный через дашборд:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: tenant-team1
 namespace: tenant-root
spec:
 chart:
 spec:
 chart: tenant
 reconcileStrategy: Revision
 sourceRef:
 kind: HelmRepository
 name: cozystack-apps
 namespace: cozy-public
 version: 1.9.1
 interval: 0s
 values:
 etcd: true
 host: team1.example.org
 ingress: true
 monitoring: false
 resourceQuotas: {}
 seaweedfs: false

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

# Используйте kubeconfig корневого tenant'а
export KUBECONFIG=./kubeconfig-tenant-root

# Примените манифест
kubectl -n tenant-root apply -f hr-tenant-team1.yaml

Примечание об изоляции: Сетевые политики Cilium в Cozystack v1.0+ всегда изолируют соседние tenant’ы друг от друга — поля isolated больше нет ни в форме дашборда, ни в значениях HelmRelease. Pod’ы внутри namespace tenant’а также по умолчанию не могут обращаться к kube-apiserver, а при создании tenant’а с etcd: true ещё и к собственному etcd. Чтобы разрешить pod’у один из этих путей, добавьте ему метку policy.cozystack.io/allow-to-apiserver: "true" или policy.cozystack.io/allow-to-etcd: "true" соответственно. Полную таблицу и пример см. в примечаниях к обновлению: Tenant isolated flag removed.

Вы можете помогать пользователям tenant’ов с установкой баз данных или вложенных Kubernetes-кластеров. Администратор может переключать контекст в дашборде и получать доступ к любому tenant’у. Пользователи tenant’а, в свою очередь, могут работать только со своим tenant’ом и его дочерними tenant’ами.

Получение kubeconfig tenant’а

Пользователям tenant’а нужен файл kubeconfig для доступа к своему Kubernetes-кластеру. Способ его получения зависит от того, включён ли OIDC в вашей установке Cozystack.

Если OIDC включён

Вы можете получить kubeconfig напрямую из дашборда, как описано в руководстве по OIDC.

Если OIDC выключен

В этом случае администратору нужно получить токен service account из namespace tenant’а. Секрет с токеном имеет то же имя, что и tenant.

Чтобы получить токен для tenant’а с именем team1, выполните:

kubectl -n tenant-team1 get secret tenant-team1 -o json | jq -r '.data.token | @base64d'

Затем подставьте этот токен в шаблон kubeconfig и сохраните файл под именем kubeconfig-tenant-<name>.yaml.

Обязательно задайте namespace по умолчанию равным имени tenant’а. Многие GUI-клиенты будут показывать ошибки доступа, если namespace не указан явно.

Тот же токен можно использовать и для входа пользователя tenant’а в дашборд Cozystack, если OIDC отключён.

Получение kubeconfig вложенного Kubernetes

Как правило, администраторам не нужно получать kubeconfig для вложенных Kubernetes-кластеров. Такие кластеры устанавливаются самим пользователем tenant’а внутри его namespace. Пользователи tenant’а полностью контролируют свои вложенные Kubernetes-окружения.

Чтобы получить доступ к вложенному Kubernetes-кластеру, пользователь tenant’а может скачать kubeconfig прямо со страницы соответствующего приложения в дашборде.

Docs: Требования

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

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

Набор инструментов

На вашей рабочей станции должны быть установлены следующие инструменты:

talosctl, клиент командной строки для Talos Linux (используйте серию v1.13.x, соответствующую Cozystack 1.5.0).
kubectl, клиент командной строки для Kubernetes.
Talm, собственный менеджер конфигурации Talos Linux от Cozystack:

curl -sSL https://github.com/cozystack/talm/raw/refs/heads/main/hack/install.sh | sh -s

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

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

Узлы кластера: три bare-metal сервера или виртуальные машины. Требования к оборудованию зависят от вашего сценария использования:

Минимальная

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

Компонент	Требование
Хосты	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-совместимого хранилища

Хранилище:

Основной диск: используется для Talos Linux, хранилища etcd и загруженных образов. Требуется низкая задержка.
Дополнительный диск: используется для данных пользовательских приложений (ZFS pool).

ОС:

Любой дистрибутив Linux, например Ubuntu.
Есть и другие способы установки, для которых на старте требуется либо любой Linux, либо вообще не требуется установленная ОС.

BIOS/UEFI Settings:

Secure Boot. Talos Linux ships pre-signed kernel modules and works with Secure Boot enabled. On non-Talos Ubuntu hosts, the default piraeus-operator flow compiles DRBD in-cluster; the resulting unsigned modules are rejected by kernel lockdown when Secure Boot is enforced. The simplest path is to disable Secure Boot in BIOS/UEFI; alternatively, follow Ubuntu + Secure Boot to pre-install dkms-signed DRBD on the host.

Сеть:

Маршрутизируемый домен с FQDN. Если его нет, можно использовать nip.io с dash-нотацией.
Узлы должны находиться в одном L2-сегменте сети.
Anti-spoofing должен быть отключён. Это необходимо для MetalLB — балансировщика нагрузки, используемого в Cozystack.

Виртуальные машины:

В настройках гипервизора должен быть включён CPU passthrough, а модель CPU должна быть установлена в host.
Должна быть включена nested virtualization. Это требуется для виртуальных машин и Kubernetes-кластеров tenant’ов.

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

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

Docs: Установка Talos Linux

1. Установка Talos Linux

Перед началом

Цели

Установка

1. Установите boot-to-talos

2. Запустите установку Talos

Следующий шаг

Docs: Установка и bootstrap кластера Kubernetes

2. Установка и bootstrap кластера Kubernetes

Цели

Установка Kubernetes

Следующий шаг

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

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

Цели

1. Установка оператора Cozystack

2. Подготовка и применение Platform Package

2.1. Подготовьте файл конфигурации

2.2. Примените Platform Package

2.3. Проверьте статус установки

3. Настройка хранилища

3.1. Проверьте устройства хранения

3.2. Создайте storage pool’ы

3.3. Создайте storage class’ы

4. Настройка сети

4.a Настройка MetalLB

4.b. Настройка публичных IP узлов

5. Завершение установки

5.1. Настройте сервисы корневого tenant’а

5.2. Проверьте состояние и состав кластера

5.3 Доступ к дашборду Cozystack

5.4 Доступ к метрикам в Grafana

Следующий шаг

Docs: Создание пользовательского tenant'а

4. Создание пользовательского tenant’а и настройка доступа

Цели

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

Введение

Создание tenant’а

Через дашборд

Через kubectl

Получение kubeconfig tenant’а

Если OIDC включён

Если OIDC выключен

Получение kubeconfig вложенного Kubernetes

Docs: Требования

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

Набор инструментов

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

Минимальная

Рекомендуемая

Оптимальная