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

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

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

Наш клиент — это такое типичное агентство интернет-маркетинга, у которого есть и своя разработка. В штате — 4 разработчика и 1 техлид. Ребята поддерживают три внутренних продукта: свой 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 (хотя для 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 рабочих дней. Далее — ведение на абонентке без доплаты.