chore: rewrite, add longhorn

This commit is contained in:
2026-08-04 22:34:32 +03:00
parent 04fe026b82
commit 4d783b2305
20 changed files with 258 additions and 61 deletions
+137
View File
@@ -0,0 +1,137 @@
# Оглавление
- [Установка 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` - в нём видно узлы, диски, тома и статус реплик.