Большинство кластеров Kubernetes разворачивают в средах с запасом ресурсов.
Много памяти. Много процессорной мощности. Эластичная инфраструктура за кулисами.
Здесь всё иначе.
Этот кластер работает на Raspberry Pi 3, в обычной домашней сети, за роутером провайдера, который нельзя заменить. Он делит ту же сеть с личными устройствами, гостевыми девайсами и обычным набором потребительского оборудования.
Цель состояла не в том, чтобы построить «домашнюю лабораторию» (homelab).
Цель — создать компактную, переносимую, ориентированную на безопасность платформу, применяя те же принципы, что и в профессиональной среде.
Ограничения были реальными. И именно они определили каждое принятое решение.
Ограничения, сформировавшие архитектуру
Прежде чем выбирать инструменты, я обозначил границы:
-
Роутер потребительского класса с минимальными настройками
-
Отдельная гостевая сеть, которая должна оставаться работоспособной
-
Ограниченный объём оперативной памяти и процессорных ресурсов
-
Недопустимость нарушения домашнего интернет-соединения
-
Возможный переезд в другое место в будущем
Raspberry Pi 3 предоставляет 1 ГБ оперативной памяти. Kubernetes не считает это щедрым объёмом.
Роутер нельзя заменить, а поведение гостевой сети во многом непрозрачно.
Это были не мелкие неудобства, которые можно было обойти позднее. Это были исходные условия проектирования.
Если решение требовало идеального сетевого оборудования или предполагало открытый доступ к сервисам из интернета — оно отвергалось сразу.
Среда должна была быть:
-
Самодостаточной
-
Переносимой
-
Восстанавливаемой с нуля
Почему Kubernetes, несмотря на накладные расходы
Запуск Kubernetes на Raspberry Pi нередко называют избыточным решением.
Во многих случаях эта критика обоснована.
Данный кластер — не про масштаб. Не про обработку всплесков трафика. Не про демонстрацию высокой доступности.
Он про дисциплину.
Использование k3s обеспечивает:
-
Декларативную конфигурацию
-
Явное управление ресурсами
-
Контейнеризованные рабочие нагрузки
-
Воспроизводимые развёртывания
-
Чёткое разделение между сервисами
На ограниченном железе накладные расходы ощутимы. Только стандартные компоненты способны перегрузить Pi 3.
Но выигрыш носит структурный характер.
Если железо сменится, добавится новый узел или кластер придётся пересобрать после переезда — модель развёртывания останется неизменной.
Компромисс: сложность в обмен на долгосрочную гибкость.
В данном контексте этот компромисс — осознанный выбор.
Обзор архитектуры
Текущий кластер — одноузловой (single-node).
Raspberry Pi 3 одновременно выполняет роль компонентов плоскости управления (control plane) и несёт рабочие нагрузки. Высокой доступности и резервирования нет. Это известное и принятое ограничение.
Основные сервисы:
-
Pi-hole — для DNS-контроля в масштабах всей сети
-
Tailscale — для безопасного удалённого доступа
-
Linkding — как состоятельная (stateful) пользовательская нагрузка
Все сервисы развёрнуты с помощью «сырых» манифестов Kubernetes. Никаких Helm-чартов и никаких слоёв абстракции, кроме самого Kubernetes.
Состоятельные нагрузки используют PersistentVolumeClaim, подкреплённые локальным хранилищем. Это вынужденный компромисс, продиктованный аппаратными ограничениями.
Маршрут трафика прост:
Внутренние устройства -> DHCP роутера -> DNS-запросы к Pi-hole -> Вышестоящий резолвер Удалённый доступ -> Зашифрованный оверлей через Tailscale -> Внутренние сервисы
Ничто не открыто публично.
Архитектура ставит ясность выше изощрённости.
Сеть и DNS: где теория столкнулась с реальностью
Сеть оказалась первым реальным препятствием.
Домашняя сеть включает:
-
Доверенные устройства
-
IoT-устройства
-
Отдельную гостевую сеть
Первоначальный план состоял в том, чтобы передать DHCP Pi-hole и централизовать управление как DNS, так и адресным пространством.
Это сломало гостевую сеть.
Роутер провайдера не позволял настроить всё необходимое для поддержки такой схемы. Гостевая сеть опиралась на поведение DHCP, управляемое роутером, которое нельзя было воспроизвести снаружи.
Решение оказалось несложным.
Роутер сохранил за собой функции DHCP. Pi-hole стал единственным DNS-сервером, прописанным на роутере.
Это позволило сохранить:
-
Работоспособность гостевой сети
-
Видимость трафика и фильтрацию на уровне DNS
-
Простоту схемы
Компромисс оказался правильным, потому что он уважал окружающую среду.
Хорошая инфраструктура адаптируется к ограничениям, а не борется с ними.
Модель безопасности и поверхность атаки
Безопасность в этом кластере строится на сокращении поверхности атаки, а не на её расширении.
Ни один сервис не доступен публично.
Нет проброса портов. Нет открытых правил входящего трафика в файрволе. Нет публичного ingress-контроллера.
Удалённый доступ осуществляется исключительно через Tailscale, что обеспечивает:
-
Зашифрованное соединение
-
Контроль доступа на основе идентификации
-
Отсутствие зависимости от доверия к IP-адресам
Модель угроз (threat model) прагматична.
Она предполагает:
-
Локальная сеть может содержать недоверенные устройства
-
Публичный интернет не должен иметь видимости внутренних сервисов
Она не претендует на защиту от атак государственного уровня.
Уровень защиты соразмерен контексту.
Что ломалось и что изменилось в результате
Некоторые допущения не выдержали проверки с самого начала.
Первая ошибка — устаревший образ Raspberry Pi OS. Обновление пакетов было ненадёжным, и систему пришлось полностью переустановить с актуальным релизом.
Затем выяснилось, что стандартные компоненты k3s слишком тяжелы для данного железа.
Изначально были включены Traefik, ServiceLB, metrics-server и локальное хранилище. Производительность была нестабильной, давление на память — значительным.
Отключение несущественных компонентов стабилизировало узел.
Позднее развёртывание Linkding создало новые ограничения. Миграции Django работали медленно, а настройки uWSGI по умолчанию провоцировали исчерпание памяти (out-of-memory).
Меры по исправлению включали:
-
Сокращение числа воркеров и потоков
-
Установку явных лимитов ресурсов
-
Осторожное повторное включение локального хранилища
Каждая корректировка следовала одному и тому же шаблону:
Допущение → сбой → упрощение.
Система улучшалась не через наращивание, а через сдержанность.
Дальнейшее развитие без переработки архитектуры
Проект изначально рассчитан на постепенную эволюцию.
Планируемые изменения:
-
Добавление Raspberry Pi 5 в качестве второго узла
-
Перенос состоятельных нагрузок на хранилище на базе SSD
-
Разметка узлов для более чёткого разделения нагрузок
Существующие манифесты не потребуют структурной переработки.
Модель развёртывания остаётся неизменной вне зависимости от того, один узел или два.
Высокая доступность сейчас не реализована. Возможно, она будет рассмотрена позднее — но только если её потребуют реальные нужды, а не стремление к теоретической полноте.
Кластеру позволено расти, но не в ущерб ясности.
Что на самом деле демонстрирует этот проект
Этот кластер невелик.
Он не enterprise-масштаба. Он не обладает высокой доступностью. Он не сложен ради сложности.
Он демонстрирует:
-
Принятие решений в условиях ограничений
-
Проектирование с приоритетом безопасности в потребительской среде
-
Умение работать с компромиссами
-
Операционную настройку на ограниченном железе
-
Дисциплину в документировании и воспроизводимости
Самые ценные уроки дало не добавление компонентов.
Их дало удаление.
Полные манифесты, диаграммы и документация доступны в репозитории: