# Оглавление
- [Установка Longhorn](#установка-longhorn)
  - [Предварительные требования](#предварительные-требования)
  - [Создание namespace и настройка Pod Security](#создание-namespace-и-настройка-pod-security)
  - [Разметка узлов хранения](#разметка-узлов-хранения)
  - [Конфигурация longhorn-values.yaml](#конфигурация-longhorn-valuesyaml)
  - [Установка через helm](#установка-через-helm)
  - [Проверка установки](#проверка-установки)
  - [Доступ к UI](#доступ-к-ui)

# Установка Longhorn

Longhorn - распределённое блочное хранилище для Kubernetes: тома реплицируются между узлами кластера, подключаются к подам по iSCSI и переживают отказ отдельного узла (при количестве реплик > 1).

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

Всё необходимое на уровне ОС уже подготовлено на этапе разворота кластера (см. основной [README](README.md)):

- В образ Talos встроены расширения `siderolabs/iscsi-tools` и `siderolabs/util-linux-tools`
- На воркерах с дополнительным диском (`patch-worker-with-disk.yaml`):
  - загружен модуль ядра `iscsi_tcp`
  - дополнительный диск `/dev/sdb` смонтирован в `/var/lib/longhorn`
  - точка монтирования проброшена в контейнер kubelet (bind mount с `rshared`)

##### Про пути в командах:
Как и в основном README, команды выполняются из директории `examples/` - там лежит `longhorn-values.yaml`.

## Создание namespace и настройка Pod Security

Talos по умолчанию включает Pod Security Admission с профилем `baseline` для всех namespace. Компонентам Longhorn нужны привилегированные поды (доступ к хост-устройствам, монтирование, iSCSI), поэтому namespace нужно создать заранее и явно перевести на профиль `privileged` - иначе admission-контроллер заблокирует запуск подов.

#### Создание namespace:
```sh
kubectl create namespace longhorn-system
```

#### Привязка привилегированного профиля Pod Security:
```sh
kubectl label namespace longhorn-system \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/audit=privileged \
  pod-security.kubernetes.io/warn=privileged
```

- `enforce=privileged` - разрешает запуск привилегированных подов в namespace (без этого поды будут отклонены)
- `enforce-version=latest` - использовать актуальную версию политики
- `audit=privileged` и `warn=privileged` - отключают предупреждения и записи аудита для привилегированных подов в этом namespace

## Разметка узлов хранения

В `longhorn-values.yaml` все компоненты Longhorn привязаны к узлам с label `role: storage`, а настройка `createDefaultDiskLabeledNodes: true` дополнительно требует label `node.longhorn.io/create-default-disk=true` - диск под данные будет создан только на узлах с этим label.

#### Посмотреть список узлов:
```sh
kubectl get nodes
```

#### Навесить label на воркеры с дополнительным диском (в тестовом кластере это `10.255.200.204`-`10.255.200.206`):
```sh
kubectl label node <имя-узла> role=storage
kubectl label node <имя-узла> node.longhorn.io/create-default-disk=true
```
Команды нужно выполнить для каждого из трёх воркеров с дополнительным диском.

Такая разметка гарантирует, что данные Longhorn окажутся только на узлах с подготовленным диском `/var/lib/longhorn`, а не на всех воркерах подряд.

## Конфигурация longhorn-values.yaml
```yaml
defaultSettings:
  defaultReplicaCount: 2
  createDefaultDiskLabeledNodes: true
  defaultDataPath: /var/lib/longhorn

csi:
  attacherReplicaCount: 2
  nodeSelector:
    role: storage

persistence:
  defaultClass: true
  defaultClassReplicaCount: 2

global:
  nodeSelector:
    role: storage

longhornUI:
  nodeSelector:
    role: storage
```

##### Ключевые моменты конфигурации:
- `defaultReplicaCount: 2` - каждый том хранится в двух репликах на разных узлах; при трёх узлах хранения кластер переживает отказ одного из них
- `createDefaultDiskLabeledNodes: true` - диск под данные создаётся только на узлах с label `node.longhorn.io/create-default-disk=true` (см. раздел выше)
- `defaultDataPath: /var/lib/longhorn` - путь к данным, совпадает с точкой монтирования дополнительного диска из `patch-worker-with-disk.yaml`
- `persistence.defaultClass: true` - StorageClass `longhorn` становится классом по умолчанию: PVC без явного указания `storageClassName` будут создаваться в Longhorn
- `nodeSelector: role: storage` (в `global`, `csi`, `longhornUI`) - компоненты Longhorn запускаются только на размеченных узлах хранения

## Установка через helm

#### Подключение репозитория helm и установка:
```sh
helm repo add longhorn https://charts.longhorn.io
helm repo update longhorn
helm install longhorn longhorn/longhorn --namespace longhorn-system -f longhorn-values.yaml
```

При необходимости зафиксировать версию чарта можно флагом `--version` (список версий: `helm search repo longhorn/longhorn --versions`).

## Проверка установки

#### Дождаться запуска всех подов:
```sh
kubectl -n longhorn-system get pods
```
Все поды должны перейти в статус `Running` (менеджеры, CSI-компоненты и engine-образы запускаются только на узлах с label `role: storage`).

#### Проверить, что StorageClass создан и назначен по умолчанию:
```sh
kubectl get storageclass
```
В выводе должен появиться `longhorn (default)`.

#### Проверить, что диски узлов подхвачены:
```sh
kubectl -n longhorn-system get nodes.longhorn.io
```
В выводе должны быть три узла хранения со статусом `Ready`.

## Доступ к UI

UI не опубликован наружу; для быстрого доступа можно пробросить порт:
```sh
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
```
После этого UI доступен на `http://localhost:8080` - в нём видно узлы, диски, тома и статус реплик.