Однонодовый Kubernetes
как центр умного дома.

Один сервер, несколько полезных ролей

Домашний сервер становится интересным, когда помогает в повседневных делах. Файл можно открыть с ноутбука и телефона. Запись встречи — превратить в текст. Фильм — посмотреть на телевизоре. Следующий шаг — дать этой же системе доступ к событиям физического дома: движению, температуре, открытой двери.

Мой сервер уже обслуживает несколько таких задач. На нём работает однонодовый Kubernetes: один физический компьютер одновременно выполняет роль управляющего узла и запускает приложения. Это общая площадка, на которой можно размещать независимые сервисы и управлять их конфигурацией.

Не всё обязано жить внутри Kubernetes. Например, Samba работает как служба хоста. В этой архитектуре сервер — физическая основа, Kubernetes — среда для приложений, а Home Assistant станет прикладным центром управления домом. У каждого слоя своя задача.

Зачем Kubernetes дома, если нода всего одна

Практическая причина — единообразное обслуживание нескольких приложений. Можно описать, какой контейнер запускать, где хранить его данные и как проверить готовность. Конфигурация сохраняет замысел системы: после обновления не приходится вспоминать, с какими параметрами когда-то стартовал процесс.

В домашней инфраструктуре особенно полезно видеть соседство нагрузок. Расшифровка длинной записи, сканирование медиатеки и база данных способны одновременно потребовать ресурсы. Для приложений стоит задать обоснованные requests и limits, а затем сопоставить их с реальным потреблением. Они помогают управлять распределением ресурсов, но не создают дополнительную память или процессорное время. Как Kubernetes учитывает ресурсы.

Цена такого подхода — обслуживание самого кластера: обновления, сеть, хранилище и восстановление. Если задача ограничивается Home Assistant и парой сервисов, Docker Compose или Home Assistant OS могут потребовать меньше усилий. Kubernetes становится осмысленным выбором, когда он уже используется или его эксплуатация — часть интереса владельца.

Одна нода даёт общий способ управления сервисами. Отказоустойчивость самого компьютера она не обеспечивает.

Как связаны Home Assistant, MQTT и Zigbee

Для предлагаемого контура я выбираю Home Assistant как интерфейс и движок автоматизаций, Mosquitto как MQTT-брокер и Zigbee2MQTT как связующее звено между брокером и радиосетью Zigbee. SONOFF выступает координатором этой радиосети.

Например, датчик передаёт температуру по Zigbee. Координатор принимает сообщение, Zigbee2MQTT публикует показание в MQTT, а Home Assistant использует его на панели и в автоматизации. Команда на совместимое реле проходит цепочку в обратном направлении. Для появления устройств в Home Assistant настраиваются MQTT-интеграция и discovery в Zigbee2MQTT. Документация интеграции.

Альтернативный путь — интеграция ZHA, при которой координатор подключается непосредственно к Home Assistant. Для этого Zigbee-контура отдельный MQTT-брокер не нужен. Один координатор должен обслуживаться выбранной системой: одновременно подключать его к ZHA и Zigbee2MQTT нельзя. Возможности ZHA.

В Kubernetes я рассматриваю Home Assistant Container. В нём нет механизма установки дополнительных приложений Home Assistant OS: Mosquitto и Zigbee2MQTT нужно развернуть самостоятельно. Это архитектура для владельца, который готов обслуживать каждый компонент. Сравнение способов установки.

SONOFF: USB рядом с сервером или Ethernet ближе к датчикам

Название SONOFF объединяет разные устройства. Перед настройкой важно узнать точную модель, радиочип и установленную прошивку. Потребительский Zigbee Bridge нельзя автоматически считать эквивалентом USB-координатора.

Вариант 1. USB-координатор

ZBDongle-P основан на CC2652P и использует в Zigbee2MQTT адаптер zstack. ZBDongle-E основан на EFR32MG21 и использует ember с совместимой прошивкой. Внешне похожие донглы требуют разных настроек. ZBDongle-P · ZBDongle-E.

USB подходит, если сервер расположен в удобной для радиосвязи точке. В проекте нужно предусмотреть доступ контейнера к устройству, стабильную идентификацию адаптера и размещение Zigbee2MQTT именно на узле с этим USB-портом. При переподключении донгла важно проверить восстановление доступа, а не только наличие процесса.

Вариант 2. Сетевой координатор

SONOFF Dongle Max, модель Dongle-M, поддерживает Ethernet и питание PoE. Его можно поставить ближе к жилым помещениям, даже если сервер находится в технической комнате. Здесь появляется зависимость от коммутатора и локальной сети. Для удалённого координатора Zigbee2MQTT рекомендует проводное соединение: задержки и потери пакетов Wi-Fi могут мешать последовательному протоколу адаптера. Подключение Dongle Max · Рекомендации по адаптерам.

В обоих случаях покрытие нужно проверять в доме. Совместимые устройства с постоянным питанием могут расширять Zigbee mesh; рассчитывать на батарейный датчик как на ретранслятор не стоит. Совместимость проверяется по точной модели устройства и доступным функциям, а не только по логотипу Zigbee.

Пять сценариев, с которых есть смысл начать

Первая автоматизация должна приносить небольшую, понятную пользу и легко проверяться. Следующие сценарии — проектные примеры; их работа на моём сервере пока не проверена.

1. Ночная подсветка. Движение в коридоре включает совместимую лампу на низкой яркости. Через заданное время после последнего движения свет выключается. Начинать удобно с одной зоны, сохранив обычное управление светом.
2. Влажность в ванной. Датчик сообщает показания, Home Assistant сравнивает их с порогом и управляет вентиляцией через подходящее реле. Разные пороги включения и выключения помогают избежать постоянных переключений.
3. Открытое окно. После нескольких минут проветривания система меняет режим совместимого терморегулятора. При закрытии возвращает прежнюю уставку. Нужно проверить поведение при потере связи с датчиком.
4. Обнаружение воды. Датчик протечки включает местное оповещение. Перекрытие воды — отдельный проект с подходящим приводом, ручным управлением и испытаниями. Критическую защиту дома разумно сохранять независимой от этого сервера.
5. Кнопка у выхода. Одно нажатие выключает выбранный свет. Состав группы задаётся явно: холодильник, сетевое оборудование и другие необходимые нагрузки в неё не попадают.

Для каждого сценария полезно записать четыре вещи: событие, условие, действие и способ отмены. Например: «движение → после 23:00 → подсветка 15% → выключение после двух минут без движения». Это уже проверяемое требование, которое легко объяснить другим жильцам.

Что произойдёт без интернета и при отказе сервера

Локальный Zigbee-сценарий можно построить без обращения в облако производителя. Но независимость от интернета ещё не означает независимость от питания, радиосети или домашнего компьютера. Разберём предполагаемую архитектуру по зависимостям.

У совместимых Zigbee-устройств возможна прямая привязка, например пульта к лампе. Она позволяет передавать команды без Home Assistant, но поддержку и поведение конкретной пары нужно проверять отдельно. Как работает Zigbee binding.

Что предусмотреть до первого датчика

Постоянные данные и резервные копии

Конфигурация Home Assistant, данные Zigbee2MQTT и необходимые данные брокера должны сохраняться вне файловой системы контейнера. PersistentVolume решает задачу жизненного цикла хранения, но не заменяет резервную копию. Копия на том же диске не защищает от его отказа. Хранилище Kubernetes.

Я бы сохранял конфигурацию приложений и поддерживаемую резервную копию координатора на отдельном носителе, защищал её как чувствительные данные и проверял восстановление. Возможность переноса Zigbee-сети зависит от адаптера и выбранного ПО.

Единственный владелец координатора

Для Zigbee2MQTT с одним координатором нужен один активный экземпляр. Обновление не должно запускать второго конкурирующего владельца устройства. При использовании Helm отдельно включается постоянное хранилище и, для USB, задаётся привязка к узлу. Установка Zigbee2MQTT в Kubernetes.

Сеть и доступ

Панели управления и MQTT не стоит открывать всему интернету ради удобства. Для удалённого управления можно использовать существующий защищённый доступ домой. Обнаружение устройств через multicast нужно проектировать отдельно: обычный Ingress не решает эту задачу. Для MQTT следует задать учётные записи и разрешения на темы.

Последовательность проверки

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

Когда такая архитектура оправдана

Для меня домашний сервер уже объединяет документы, почту, медиатеку и обработку записей. Умный дом логично добавляет ещё одну группу событий и действий на ту же вычислительную основу. При этом полезно сохранять границы: Kubernetes обслуживает приложения, Home Assistant задаёт бытовую логику, а SONOFF связывает программную часть с Zigbee-устройствами.

Начать можно с маленького контура: координатор, датчик, лампа и одна понятная автоматизация. Когда известны её зависимости и проверено восстановление, систему легче развивать. Именно возможность объяснить и обслужить каждый шаг делает домашнюю инфраструктуру удобной в долгой эксплуатации.

Частые вопросы