Kubernetes на домашнем сервере: есть ли смысл

Признаюсь честно: я поддался хайпу. Год назад сидел я, смотрел на свой Proxmox с десятком LXC-контейнеров и думал — всё несерьёзно. Настоящие админы используют Kubernetes. У меня же — просто Docker на одной VM, пара компоузов, и всё это какое-то… игрушечное.

Ну и понеслось.

Я развернул K3s на трёх VPS в DigitalOcean. Потом ещё один кластер — на Raspberry Pi. Потом ещё — на старом ноутбуке. Три кластера, Карл! Потому что «надо уметь», «это стандарт индустрии», «без K8s ты не сисадмин».

Спойлер: я их все снёс через месяц. А дома оставил… обычный Docker.

Но давай по порядку.

Я начал с того, что установил K3s на два узла — мастер и воркер. Мастер на VM с 2GB RAM, воркер на отдельной VM с 4GB. По документации — легковесный Kubernetes, оптимизированный для edge, IoT, всего такого. Установка — одна команда:

curl -sfL https://get.k3s.io | sh —

Вжух — и у тебя кластер. Прям магия. Я чувствовал себя богом автоматизации. Серьёзно, первые полчаса я просто смотрел на `kubectl get nodes` и улыбался как идиот.

А потом началось.

Во-первых, память. K3s жрёт около 500MB на мастере и 300MB на воркере. Это в простое. На голой VM без полезной нагрузки. Для сравнения — Docker Compose на той же VM жрёт… практически ничего, потому что контейнеры запускаются только когда нужны. Тут же у тебя постоянно висит kubelet, containerd, kube-proxy, coredns, traefik — и это только системные поды.

Я запустил свой первый полезный под — Nextcloud. Хотел посмотреть, как оно в оркестрации. Развернул через Helm-чарт. Получил 8 подов вместо одного контейнера. База отдельно, редис отдельно, cronjob отдельно, веб-отдельно… Каждый под жрёт по 100-200MB. Nextcloud, который в Docker Compose укладывался в 1GB памяти, в K8s занял 3GB.

Тут я впервые задумался: а оно мне надо?

Дальше — обслуживание. Обновлять кластер — это ритуал с бубном. K3s обновляется легко, но если у тебя helm-релизы, PV-шные тома, ingress-контроллеры… Наступает момент, когда ты перестаёшь что-то обновлять, потому что «работает же». А потом «работает же» ломается, и ты вспоминаешь, что полгода назад ставил cert-manager, но уже забыл как.

У меня сломался Traefik после обновления K3s. Не стартовал — и всё. Я потратил вечер на дебаг (проблема была в CRD-версиях), починил, но осадочек остался.

А знаешь, что меня добило? Хранение данных. В Kubernetes StatefulSet-ы с PersistentVolumeClaim — это боль. У тебя всё хорошо, пока ты не решишь перенести под на другой узел. Или пока у тебя не сломается диск. Я использовал Longhorn для распределённого хранилища — ещё один слой сложности. И ещё 500MB памяти сверху.

Longhorn реплицирует данные между узлами. Круто, да? Только вот на домашнем сервере у меня нет 10Gbps-сети. Репликация жрёт CPU и диски, и в итоге твоя MariaDB тормозит так, что phpMyAdmin грузится 10 секунд.

Так для чего вообще K8s? Горизонтальное масштабирование. Если у тебя 10 миллионов пользователей — да, без него никуда. Если у тебя сайт, который читают 100 человек в день — не надо.

Да, я знаю, что кто-то скажет про reproducible deployments, про GitOps, про то, что всё описывается в YAML и воспроизводится на любом кластере. Аргумент рабочий. Но знаешь что ещё отлично воспроизводится? Docker Compose. Один файл. Пять минут. И ты уже развернул всё приложение.

Я не говорю, что Kubernetes — зло. Это потрясающая технология. Для дата-центров, для продакшна с сотнями микросервисов, для команд из 20+ человек. Но для домашнего сервера, где ты один, у тебя 4-8GB RAM и один IP — это оверкиллум.

Сейчас я держу K3s только на одном VPS, где крутятся тестовые проекты, которые удобно деплоить через ArgoCD. Просто чтобы навык не терять. А дома — Proxmox LXC с Docker, где каждый сервис живёт в своём Compose-файле. Всё просто, всё предсказуемо, и если что-то сломалось — я чининю это за 5 минут, а не за вечер.

Хочешь попробовать K8s ради обучения — попробуй. Разверни K3s на VPS с 4GB, поиграйся с Helm, с Ingress, с ConfigMap. Это полезный опыт. Но не ставь его дома, если у тебя нет отдельного сервера с 16GB RAM и запасом терпения. Серьёзно, не надо.

Я свой кластер снёс и не жалею.

Раз уж я начал эту историю — расскажу до конца, со всеми деталями и выводами, к которым пришёл уже после того, как снёс кластеры. В первой части я описал суть, но там многое осталось за кадром.

Про то, что подтолкнуло меня разбираться с K8s по-настоящему. Не только хайп. Я хотел научиться потому, что везде в вакансиях админов и девопсов был этот бренд, и я боялся отставать от рынка. Плюс мне нравилась идея: описал желаемое состояние в YAML — и система сама приводит к нему сервер. Это звучало как магия, и я хотел её освоить. Ничего плохого в этом желании нет. Вопрос только в том, где применять эти навыки.

Теперь про то, на что я потратил больше всего времени. На сеть. В K3s из коробки сеть между подами устроена через CNI-плагин, и поначалу всё вроде бы работает. Но как только начинаешь пробрасывать наружу свои сервисы через Ingress, всплывают нюансы: как попадает трафик в кластер, как работают NodePort и LoadBalancer, почему поды в разных неймспейсах друг друга не видят. У меня ушла не одна неделя, чтобы уверенно отвечать на эти вопросы. В Docker Compose такого нет вообще — ты просто пробрасываешь порт.

Про хранение и ещё раз про Longhorn. Я честно пытался сделать распределённое хранилище. Идея шикарная: данные реплицируются между узлами, и даже если один сервер умрёт — данные целы. На бумаге. На практике на домашнем железе это выглядело так: постоянная нагрузка на диски от синхронизации, задержки на каждой операции записи, и страх, что если реплика разъедется — я получу рассинхронизированные данные вместо «целых». Плюс каждый слой — это ещё один сервис, который надо обновлять, мониторить и чинить. В итоге для своих данных я вернулся к простым томам на хосте и классическим бэкапам через cron. Надёжнее и понятнее.

Про операционные расходы. Я завёл привычку записывать, сколько времени уходит на обслуживание. Сравнение вышло наглядным. Docker Compose у меня: обновил образ, перезапустил, всё. Пять минут в неделю. Kubernetes: обновить cert-manager, проверить CRD, обновить Helm-релизы, посмотреть, не сломался ли Traefik после апдейта, разобраться с версиями API. Это уже вечер в месяц, и это если всё идёт гладко. Для одного человека с десятком сервисов — ощутимая разница.

Про то, что я в итоге оставил. На VPS у меня до сих пор крутится K3s с парой тестовых проектов и ArgoCD. Я сознательно оставил его, чтобы не терять навык и держать руку на пульсе технологии. Пару раз в месяц я разворачиваю там что-нибудь новое, меняю Helm-чарты, смотрю на поды. Это мой полигон. Но именно полигон, а не боевая система, от которой зависит моя инфраструктура.

Про умный подход. Если ты хочешь изучить Kubernetes — мой совет: не ставь его на сервер, где живёт что-то важное. Подними отдельную тестовую среду — хоть на Proxmox, хоть на VPS за 300 рублей. Поиграйся: кластер, поды, деплойменты, Ingress, ConfigMap, секреты. Напиши пару манифестов руками, а не только через Helm. Попробуй обновить версию кластера и переживи, что что-то сломается. Вот это — ценный опыт. А свою «продакшен»-инфраструктуру оставь на простых, проверенных решениях.

Про сравнение с «умными» конкурентами. Есть ещё альтернативы вроде Docker Swarm или Nomad — проще Kubernetes, но и они добавляют слой поверх обычного Docker. Я их тоже пробовал, и вывод простой: пока тебе хватает Docker Compose и одного хоста — не усложняй. Начинай с простого, а усложняй только когда простого реально перестаёт хватать. У меня на домашнем сервере Compose хватает с головой, и я не вижу, когда перестанет.

Если совсем коротко, мой опыт такой: Kubernetes — отличная технология, но она решает задачи, которых у домашнего админа обычно нет. Масштабирование на миллионы запросов, отказоустойчивые кластеры, микросервисы с десятками команд — это про большие проекты. Для блога, домашней лаборатории и десятка сервисов это как накрывать шашлык на костре скатертью и фарфором. Полезно знать, как это делается, но каждый день так не готовят. Я снёс свои кластеры без сожаления и держу дома только Compose. И, если честно, это лучшее решение, которое я принял за весь этот эксперимент.

Ещё стоит сказать про документацию и сообщество. У Kubernetes отличная документация, это правда. Но она настолько огромная, что новичок тонет: concepts, tasks, reference, операторы, CNI, Ingress-классы, admission controllers… Каждый абзац тянет за собой три ссылки. Пока ты разберёшься в одном, придумали ещё три инструмента вокруг. Для человека, который хочет просто запустить свои сервисы, это лабиринт. Docker Compose же — один файл, где всё видно сразу. Мои сервисы описаны в пяти Compose-файлах, и любой из них я могу объяснить за минуту.

И про сообщество в соцсетях: там куча пафоса про «настоящих админов», которые только и делают, что настраивают K8s. Я на это в какой-то момент тоже подсел. А потом понял: настоящий админ — это тот, кто выбирает правильный инструмент под задачу, а не самый модный. И да, честно признаться в том, что для твоей задачи Kubernetes избыточен, — это тоже профессионально. Способность не усложнять — навык, который спасёт тебе кучу нервов.

В итоге у меня так: Docker Compose — для дома и рабочих сервисов, K3s — для изучения и тестов, и никакого пересечения. И когда кто-то говорит, что «без Kubernetes ты не сисадмин» — я вспоминаю свой снесённый кластер и спокойно улыбаюсь. Знание — да, держу. А вот применять его там, где не нужно, — больше не буду.