Примеры домашнего использования

Кластер работает — что в нём запустить? Вот четыре классических домашних сервиса, ради которых обычно всё это и затевается. Для каждого: зачем он нужен, почему ему хорошо в Kubernetes, ключевые моменты установки и типовые грабли.

Медиасервер Jellyfin

Идея. Свой Netflix: фильмы, сериалы и музыка лежат на дисках сервера, а смотреть их можно с телевизора, телефона, планшета и браузера. Jellyfin — свободная альтернатива Plex без аккаунтов и подписок.

Зачем в k8s. Jellyfin любит постоянную работу и периодические обновления. В кластере он переживёт перезагрузку сервера, обновляется одной командой (kubectl set image или helm upgrade), а медиатека спокойно лежит на NFS-томе, не привязанная к конкретному поду.

Ключевые моменты установки. Jellyfin разумно ставить обычным манифестом (официального helm-чарта нет, есть проверенные community-варианты). Скелет:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jellyfin
  namespace: media
spec:
  replicas: 1   # всегда 1: Jellyfin держит состояние в своём каталоге config
  selector:
    matchLabels: { app: jellyfin }
  template:
    metadata:
      labels: { app: jellyfin }
    spec:
      containers:
        - name: jellyfin
          image: jellyfin/jellyfin:latest
          ports:
            - { containerPort: 8096 }
          volumeMounts:
            - { name: config, mountPath: /config }
            - { name: media,  mountPath: /media, readOnly: true }
          resources:
            requests: { memory: "512Mi" }
            limits:   { memory: "3Gi" }   # запас под транскодинг
      volumes:
        - name: config
          persistentVolumeClaim: { claimName: jellyfin-config }
        - name: media
          persistentVolumeClaim: { claimName: media-library }   # NFS с фильмами

На что обратить внимание:

• Транскодинг — единственный прожорливый режим Jellyfin. Программный транскодинг грузит все ядра; если видеокарта поддерживает аппаратное ускорение (Intel QSV, VA-API), пробрасывайте устройство /dev/dri в под. Новичку проще: храните видео в форматах, которые ваши устройства играют напрямую (H.264/H.265), — тогда транскодинг вообще не нужен.
• Медиатека только для чтения — монтируйте том с фильмами как readOnly: true, чтобы случайное удаление в веб-интерфейсе не стёрло файлы.
• Права на файлы — контейнер работает от UID 1000; убедитесь, что файлы на NFS доступны этому пользователю (см. «Хранение»).
• Доступ из дома — Ingress с хостом media.home.lan или просто NodePort 8096.

Файловое хранилище Nextcloud

Идея. Собственное облако: файлы, фото с телефона (автозагрузка), календари, контакты, заметки — всё под вашим контролем вместо чужих сервисов.

Зачем в k8s. Nextcloud — это не один контейнер, а связка: сам Nextcloud (PHP), база данных (PostgreSQL или MariaDB), кэш (Redis), фоновые задачи (cron). Kubernetes — идеальная сцена для таких многокомпонентных приложений: всё описано декларативно и поднимается одной командой.

Ключевые моменты установки. Тут helm-чарт оправдан — компонентов много. Официальный community-чарт:

helm repo add nextcloud https://nextcloud.github.io/helm/
helm repo update

# минимальная установка со встроенной MariaDB и томами по умолчанию
helm install cloud nextcloud/nextcloud \
  --namespace nextcloud --create-namespace \
  --set nextcloud.host=cloud.home.lan \
  --set nextcloud.username=admin \
  --set nextcloud.password="СложныйПароль123" \
  --set persistence.enabled=true \
  --set persistence.size=50Gi \
  --set mariadb.enabled=true

На что обратить внимание:

• Базу — на SSD, файлы — можно на NFS. MariaDB на NFS будет мучительно медленной; каталог данных Nextcloud на NFS — вполне нормально. См. правила выбора хранилища на странице «Хранение».
• HTTPS обязателен, если облако видно из интернета: cert-manager + Let's Encrypt поверх Ingress.
• trusted_domains — Nextcloud принимает запросы только с указанных имён; добавьте свой домен через values чарта (nextcloud.host и nextcloud.trustedDomains).
• Бэкапы двойные: отдельно дамп базы, отдельно файлы. Потеряете одно из двух — второе бесполезно.
• Память: связка Nextcloud+MariaDB+Redis съедает 1–1.5 ГБ — учитывайте при планировании ресурсов узла.

Умный дом Home Assistant

Идея. Центр умного дома: лампочки, датчики, розетки, камеры, автоматизации («включи свет в коридоре, когда открывается дверь») — в одном интерфейсе, локально, без китайских облаков.

Зачем в k8s. Home Assistant должен работать 24/7 и переживать любые сбои — автоматизации не прощают простоя. Кластер перезапустит его при падении и при перезагрузке узла. Плюс вся экосистема аддонов (MQTT-брокер Mosquitto, Zigbee2MQTT, Node-RED) раскладывается по подам аккуратно и наглядно.

Ключевые моменты установки. Есть удобный community helm-чарт (pajikos/home-assistant-helm-chart или из k8s-at-home-последователей). Минимальный пример values:

helm repo add pajikos https://pajikos.github.io/home-assistant-helm-chart/

helm install homeassistant pajikos/home-assistant \
  --namespace smart-home --create-namespace \
  --set persistence.enabled=true \
  --set persistence.size=2Gi \
  --set service.type=NodePort \
  --set service.nodePort=30123

На что обратить внимание:

• hostNetwork или mDNS. Home Assistant любит видеть устройства в той же L2-сети (автообнаружение через mDNS/SSDP). В кластере это ломается: под живёт в оверлейной сети. Решения: hostNetwork: true (просто, но под делит сеть с узлом) или отказ от автообнаружения в пользу явной интеграции по IP.
• USB-стики (Zigbee/Z-Wave) — пробрасываются в под как устройства /dev/ttyUSB0, и под привязывается к конкретному узлу через nodeSelector: стик физически воткнут в одну машину.
• MQTT-брокер ставьте отдельным чартом (Mosquitto) — его будут использовать и другие сервисы.
• Права доступа — у Home Assistant будет доступ ко всему умному дому. Ingress с авторизацией или VPN для доступа снаружи — обязательны.

Собственный git-сервер Gitea

Идея. Свой GitHub: репозитории, issues, pull requests, веб-интерфейс — для домашних проектов, манифестов кластера и всего, что не хочется держать в публичных сервисах.

Зачем в k8s. Gitea лёгкая (150–300 МБ ОЗУ) и идеально ложится в кластер. А главное — логично хранить манифесты самого кластера в git-сервере, который живёт в этом же кластере (с бэкапами, разумеется). Это первый шаг к GitOps: позже можно поставить Flux или ArgoCD, и кластер будет сам себя синхронизировать с репозиторием.

Ключевые моменты установки. У Gitea официальный helm-чарт:

helm repo add gitea https://dl.gitea.com/charts/
helm repo update

helm install git gitea/gitea \
  --namespace gitea --create-namespace \
  --set gitea.admin.username=admin \
  --set gitea.admin.password="СложныйПароль123" \
  --set persistence.enabled=true \
  --set persistence.size=10Gi \
  --set service.http.type=NodePort \
  --set service.http.nodePort=30300

На что обратить внимание:

• SSH-доступ к git — отдельный сервис в чарте (порт 22). Дома удобнее включить NodePort 30022 и прописать в своём ~/.ssh/config алиас, либо работать по HTTPS.
• База данных — для домашнего использования достаточно встроенного SQLite (по умолчанию), но при росте лучше PostgreSQL (postgresql.enabled=true в чарте, том — local-path на SSD).
• Бэкап — команда gitea dump внутри пода пакует репозитории, базу и конфиг в один архив. Настройте её по cron и складывайте на NFS.
• Храните здесь манифесты кластера — привычка, которая однажды спасёт вам неделю работы.

Вывод сервисов в интернет: общая схема

Для Nextcloud и Gitea часто хочется доступ не только из дома. Правильная последовательность одинакова для любого сервиса:

1. Сервис работает и стабилен внутри домашней сети (Ingress на локальном имени);
2. Зарегистрировано доменное имя (или настроен DDNS, если провайдер даёт динамический, но белый IP);
3. На роутере проброшены только порты 80 и 443 на Ingress (см. «Сеть»);
4. Установлен cert-manager, который автоматически выпускает и продлевает сертификаты Let's Encrypt для ваших Ingress;
5. Добавлен Ingress-ресурс с внешним именем и секцией tls:, указывающей на Secret с сертификатом;
6. Проверено: сервис открывается по https:// без предупреждений, HTTP редиректит на HTTPS.

Если белого IP нет — альтернативы: Cloudflare Tunnel (бесплатный, не требует открытых портов) или WireGuard на дешёвой VPS с пробросом трафика домой. Оба варианта оставляют домашний кластер невидимым для сканеров.

Почему эти сервисы именно в Kubernetes

Честный вопрос: всё перечисленное можно запустить и через docker-compose на одной машине. Что реально даёт k8s в домашних условиях:

• Самовосстановление. Под упал ночью — к утру уже перезапущен, а не лежит до вашего прихода. Узел перезагрузился после обновления — все сервисы поднялись сами, в правильном порядке, без systemd-юнитов ручной работы.
• Единообразие. Установка любого сервиса сводится к одному и тому же действию: написал манифест (или values.yaml) → kubectl apply / helm install. Не нужно помнить, «как именно я два года назад ставил Nextcloud».
• Декларативность как документация. Манифесты в git — это и есть точное описание вашей инфраструктуры. Переезд на новый сервер = применить репозиторий к новому кластеру и развернуть бэкапы данных.
• Изоляция ресурсов. Requests и limits гарантируют, что разбушевавшийся транскодинг Jellyfin не уронит Home Assistant и не положит сам кластер.

Цена вопроса — примерно 1–1.5 ГБ ОЗУ на сам кластер и время на обучение. На железе из рекомендаций это окупается с лихвой.

Типовые грабли при установке сервисов

Проблемы повторяются от сервиса к сервису — вот короткий список того, что проверять в первую очередь, если очередное приложение не поднялось:

• PVC не привязался (Pending). Команда kubectl describe pvc имя -n namespace покажет причину: не установлен provisioner, нет класса по умолчанию, кончилось место. Разбор — на странице «Хранение».
• Permission denied на томе. Контейнер не может писать в смонтированный каталог — настройте fsGroup или права на стороне хранилища (раздел про права на странице «Хранение»).
• Приложение не видно из браузера. Проверьте цепочку: под Running → endpoints сервиса не пустые → сервис отвечает по ClusterIP из тестового пода → Ingress/NodePort настроен. Пошаговая диагностика — на странице «Сеть».
• Чарт установился, но работает не так. Вы не задали свои values, и чарт встал с умолчаниями. Посмотрите их: helm show values репозиторий/чарт > values-default.yaml — и переустановите со своим файлом.
• После перезагрузки сервера сервис мёртв. Проверьте, что кластер сам поднялся (kubectl get nodes) — если k3s не в автозагрузке, включите: sudo systemctl enable k3s (обычно включён скриптом установки).

Детальная диагностика с командами — на странице «Советы».

Helm или ручные манифесты?

На этой странице встречаются оба подхода, и полезно понимать разницу:

• Helm-чарт — «пакет» приложения: шаблоны манифестов плюс файл values.yaml с параметрами. Удобен для сложных многокомпонентных сервисов (Nextcloud, мониторинг): одна команда helm install разворачивает всё. Минус — внутри чарта «чёрный ящик»: стоит посмотреть, что он ставит (helm template имя-чарта покажет сгенерированные манифесты без установки).
• Ручные YAML-манифесты — полный контроль и прозрачность: каждый объект написан вами и понятен. Лучший способ учиться. Минус — для Nextcloud таких файлов понадобится десяток.

Рабочее правило: учебные и простые сервисы — руками в YAML; сложные «взрослые» связки — helm-чартом, но с прочитанным values.yaml. Свои values храните в git рядом с манифестами — это ваша документация о том, как именно развёрнут каждый сервис.

Команды helm, которые пригодятся каждый день:

helm list -A                          # все установленные релизы
helm status cloud -n nextcloud        # состояние релиза
helm upgrade cloud nextcloud/nextcloud -n nextcloud -f my-values.yaml
helm rollback cloud 1 -n nextcloud    # откат к ревизии 1
helm uninstall cloud -n nextcloud     # удаление (PVC по умолчанию остаются!)

В каком порядке ставить

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

1. AdGuard Home — простейший деплой, мгновенная видимая польза (реклама исчезает везде), плюс сразу решается задача локальных DNS-имён для остальных сервисов.
2. Gitea — лёгкий, неприхотливый, и сразу появляется где хранить манифесты кластера в git.
3. Jellyfin — средней сложности: учит работать с большими NFS-томами и правами доступа, награда — работающий медиасервер.
4. Home Assistant — если есть умные устройства: нюансы с hostNetwork и USB-пробросом осваиваются на уже живом кластере.
5. Nextcloud — самое тяжёлое из набора: связка из четырёх компонентов, HTTPS, бэкапы двух слоёв данных. Браться после того, как освоены тома и Ingress.
6. Prometheus + Grafana — когда всё работает, добавьте наблюдаемость: с этого момента вы увидите проблемы раньше, чем они случатся.

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

После каждой установки делайте паузу и проверяйте три вещи: сервис открывается из домашней сети, переживает перезагрузку сервера и его данные попадают в бэкап. Только потом переходите к следующему.

Бонус: AdGuard Home и мониторинг

Два сервиса, которые почти всегда появляются в домашнем кластере следом за первой четвёркой.

AdGuard Home — DNS с блокировкой рекламы

Идея. Свой DNS-сервер для всей домашней сети: режет рекламу и трекеры на всех устройствах сразу (включая телевизоры и телефоны, где блокировщик не поставить) и заодно решает задачу локальных имён для сервисов (media.home.lan → адрес Ingress, см. «Сеть»).

Ключевые моменты. Ставится простым манифестом: образ adguard/adguardhome, PVC на 1 ГБ под конфиги, и вот важный нюанс — DNS слушает порт 53, который Ingress не проксирует (Ingress — только HTTP). Поэтому сервис делают типа LoadBalancer (через MetalLB выделите ему постоянный IP, например 192.168.1.210) с портами 53/tcp и 53/udp, а затем прописывают этот IP как DNS в настройках роутера (DHCP).

На что обратить внимание: кластер и AdGuard Home образуют круговую зависимость — если DNS в роутере указывает на AdGuard, а AdGuard живёт в кластере, который сам резолвит имена через этот DNS... На узлах оставьте upstream-DNS провайдера или 1.1.1.1 (настраивалось в «Подготовке»), а AdGuard используйте для клиентских устройств.

Prometheus + Grafana — мониторинг кластера

Идея. Графики по всему кластеру: загрузка узлов, память подов, место на дисках — и алерты, когда что-то выходит за рамки. Для домашнего кластера это и полезно (увидеть утечку памяти до того, как узел умрёт), и поучительно — это стек, который вы встретите в любом продакшене.

Ключевые моменты. Ставится одним helm-чартом kube-prometheus-stack (Prometheus + Grafana + alertmanager + экспортеры):

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword="СложныйПароль123" \
  --set prometheus.prometheusSpec.retention=7d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=5Gi

На что обратить внимание: стек заметно тяжелее остальных (1–2 ГБ ОЗУ) — на слабом узле может не взлететь. Параметр retention ограничивает, сколько дней хранить метрики: без него база Prometheus будет расти без остановки и съест диск. Grafana доступна через сервис в том же namespace — откройте её через NodePort или Ingress.

Сколько ресурсов съедает весь набор

Прикинем, потянет ли ваш сервер все шесть сервисов разом (ориентировочные значения в обычной работе):

Вывод подтверждает рекомендации со страницы «Требования»: сервер с 4 ядрами и 16 ГБ ОЗУ несёт весь набор с комфортным запасом, а 8 ГБ — уже впритык, если добавить мониторинг.

Общие принципы для любых сервисов

Что бы вы ни ставили, правила одни и те же: