K3s в офисе на 40 человек: когда маленький Kubernetes лучше Docker Compose

Меня зовут Семёнов Евгений Сергеевич, я 15 лет веду IT-аутсорсинг для юрлиц в Москве. В статье расскажу, как мы в АйТи Фреш внедряли K3s у клиента — маркетингового агентства с 40 сотрудниками — и почему в другом похожем проекте отказались от идеи наотрез. Kubernetes в малом бизнесе — как дорогой костюм: в одном случае обязательный, в другом — стыдный оверкилл.

Откуда вообще взялась задача

Клиент — агентство интернет-маркетинга с собственной разработкой (4 разработчика, 1 техлид, команда ведёт 3 внутренних продукта: CRM-лайт, таск-трекер и дашборд для клиентов). До нашего прихода всё крутилось на трёх VPS с Docker Compose: один сервер под прод, один под стейдж, один под CI. Каждый релиз — это был квест «разработчик пишет в Telegram админу: перекати компоуз». По пятницам, конечно, всё падало.

Мы зашли с аудитом и увидели набор проблем, который в 2025 году выглядит уже архаично:

• Нет изоляции. Один падающий контейнер вешал весь хост — ядро Linux кряхтело, остальные сервисы отваливались.
• Релизы в ручном режиме. Разработчик собирал образ, пушил в приватный Docker Registry, ехал к админу с просьбой обновить Compose — 40 минут на релиз.
• Откатов нет. Если обновление сломало прод, возврат — это перекомпиляция предыдущей версии, потому что образы в Registry не теговались нормально.
• Секретов нет. Пароли к базе лежали в открытом виде в compose-файлах в git.
• Мониторинг — по глазам. Если сайт лёг, узнавали от клиентов.

Классический выход — брать Kubernetes. Но у нас 40 сотрудников, 3 разраба, и тащить полный управляющий кластер на 3 master-нодах было бы смешно. Тут на сцене появляется K3s.

Что такое K3s и почему он хорошо ложится на SMB

K3s — это дистрибутив Kubernetes от Rancher (теперь SUSE). Главная идея: весь управляющий стек упакован в один бинарник размером около 70 мегабайт. Вырезаны куски, которые нужны только облачным провайдерам (AWS/GCP/Azure cloud-controller), etcd заменён на SQLite по умолчанию (можно вернуть etcd для HA), встроены Traefik, local-path storage и helm-controller.

По API он на 100% совместим со «взрослым» Kubernetes. То есть любой манифест deployment/service/ingress из обычного куба работает без единой правки. Это важно — если завтра вы вырастете и захотите переезжать в «большой» кластер, манифесты не придётся переписывать.

Что получает SMB от K3s в сравнении с голым Docker Compose:

• Декларативные манифесты в git — вся инфраструктура читается как код, и любой член команды видит, что где крутится.
• Автоперезапуск упавших подов — если сервис вылетел, K3s поднимает его без вмешательства админа.
• Плавные деплои (rolling update) — новый релиз катится по одному поду, старые умирают только когда новые проходят health-check.
• Откат командой kubectl rollout undo — возврат на предыдущую версию за 30 секунд.
• Секреты в Kubernetes Secrets — пароли не в git, а в зашифрованном хранилище кластера.
• Ingress с автоматическим Let's Encrypt через cert-manager — сертификаты продлеваются сами.

Архитектура, которую мы собрали клиенту

Финальная схема получилась компактной — три VPS на обычном российском хостере, плюс одна резервная нода для бэкапа состояния:

• Node-1 (master + worker). 4 vCPU / 8 ГБ RAM / 160 ГБ NVMe. Здесь живёт K3s control-plane, CoreDNS, Traefik, cert-manager.
• Node-2 (worker). 4 vCPU / 8 ГБ RAM / 160 ГБ NVMe. Запускает приложения: CRM, таск-трекер, дашборд, PostgreSQL в StatefulSet.
• Node-3 (worker). 4 vCPU / 8 ГБ RAM / 160 ГБ NVMe. Запускает стейдж-окружение и вспомогательные сервисы: Redis, ClickHouse для аналитики, Grafana.
• Longhorn для распределённого блочного хранилища на трёх нодах — если нода упадёт, том переключается на другую за 15 секунд.
• Прод-база PostgreSQL вынесена отдельно: не в кластере, а на выделенном VPS с managed backup — потому что базы данных в Kubernetes — это отдельная религия, и SMB её не тянет без ущерба для здравого смысла.

Общая стоимость инфраструктуры — 14 600 рублей в месяц за четыре VPS и около 4 000 рублей за статические IP и S3-хранилище под бэкапы.

Что установили в кластер сверху

Как выглядит деплой после перехода на K3s

Процесс, который раньше занимал 40 минут и требовал админа, теперь выглядит так:

1. Разработчик мёрджит ветку в main в Gitea.
2. Gitea Act Runner собирает Docker-образ, прогоняет тесты, пушит в Harbor с тегом sha-abc123.
3. В репозитории инфраструктуры (отдельный git-репо с манифестами) меняется один файл deployment.yaml: новая версия образа.
4. ArgoCD видит изменение в git, применяет манифест в кластер. Rolling update поднимает новый под, дожидается health-check, выключает старый.
5. Сообщение в Telegram-канал: «Deploy CRM v1.42 — success, rollout time 45s».

Админ не участвует в релизе. Если что-то сломалось, разработчик пишет kubectl rollout undo deployment/crm и через 30 секунд прод откатывается. Пятничные инциденты как класс исчезли.

Когда K3s — не ваш случай

Теперь честная часть, после которой клиенты меня уважают больше. Если у вас в офисе стоят 1С, файловый сервер, почта на Postfix и десяток внутренних веб-сервисов — K3s вам не нужен. Держите Docker Compose или даже просто systemd-юниты, и будет счастье.

K3s имеет смысл только если:

• Есть собственная разработка ≥3 человек с регулярными релизами (минимум раз в неделю).
• У вас ≥8 микросервисов, которые завязаны друг на друга.
• Нужна зона стейджинга, отдельная от прода, с быстрым воспроизведением.
• Сотрудники разработки понимают, что такое манифест и kubectl. Нельзя внедрить куб в команду, которая не хочет учиться.

В прошлом году мы отказались от аналогичного проекта у клиента-стоматологической сети: у них стоял CRM Dental4Windows и десяток коробочных программ для рентген-снимков. Тащить туда куб — это как ставить Formula-1 на грунтовую дорогу. Оставили обычный Hyper-V и Docker там, где он нужен для одного сервиса.

Стоимость внедрения и сопровождения

Инфраструктура в месяц: 14 600 ₽ VPS + 4 000 ₽ прочее = 18 600 ₽. Экономия от пропавших пятничных инцидентов и от скорости релизов — около 80 часов работы админа в год, то есть 560 000 ₽. Проект окупается за 3 месяца.

Типичные грабли K3s, которые я собираю у клиентов

• SQLite в одном мастере. При росте кластера до 6–7 нод SQLite становится узким местом. Решение — переход на etcd при установке: curl -sfL https://get.k3s.io | sh -s - --cluster-init. После старта — три master-ноды и отказоустойчивость.
• Traefik по умолчанию. Встроенный Traefik иногда не хватает контроля над middleware. Мы обычно оставляем его для внутренних сервисов, а для production ingress ставим отдельный nginx-ingress-controller.
• Longhorn и диски. Longhorn требует быстрых дисков — с HDD он захлёбывается. Минимум — NVMe или хороший SATA SSD, иначе поды ждут IO до минуты.
• Тег latest. Если в манифесте указано image: app:latest, ArgoCD не перекатит деплой при появлении нового образа — нужны явные теги по коммит-хешу.
• Секреты в git. Кубовые Secrets всё ещё лежат в base64, что не шифрование. Ставим Sealed Secrets или внешний Vault для боевых паролей.

FAQ — частые вопросы

Нужен ли Kubernetes офису на 40 человек?

В 7 из 10 случаев — нет. Если у вас 5–10 сервисов в Docker Compose и они живут спокойно — K3s не даст выигрыша. Но если есть команда разработки, которая катит обновления по несколько раз в неделю, или если количество сервисов уже перевалило за 15 — K3s экономит много нервов.

Чем K3s отличается от полного Kubernetes?

K3s — это дистрибутив от Rancher, где всё собрано в один бинарник 70 МБ. Убраны облачные провайдеры, etcd заменён на SQLite по умолчанию, kube-proxy упрощён. API совместим на 100% — манифесты работают без изменений.

Сколько ресурсов ест K3s?

Один master-нода комфортно живёт на 2 vCPU / 2 ГБ RAM. На Raspberry Pi 4 с 4 ГБ RAM успешно крутим внутренние сервисы малого офиса. Для продакшена берём 4 vCPU / 8 ГБ RAM с NVMe под данные.

Сколько стоит внедрение K3s в АйТи Фреш?

Базовый кластер из 3 нод с Traefik, cert-manager, Longhorn, мониторингом и CI-конвейером — 130 000 руб. Сроки: 7 рабочих дней. Далее — ведение на абонентке без доплаты.