K3s HA для homelab: архитектура без боли

Kubernetes слишком тяжёлый, Docker Swarm мёртв, а хочется нормальный кластер для экспериментов. Знакомо? K3s решает эту проблему - полноценный Kubernetes в бинарнике на 50MB вместо 1.5GB зависимостей. Но без правильного планирования вы получите нестабильную конструкцию, которая падает в самый неподходящий момент.

В этой статье разберём архитектуру K3s HA кластера: почему именно 3 master ноды, зачем embedded etcd и сколько ресурсов закладывать. В конце - готовый план для установки.

Результат: понимание архитектуры + таблица ресурсов + сетевая схема. Всё, что нужно перед тем, как создавать VM.

Для кого это

#

Подходит:

• Знаком с базовыми концепциями Kubernetes (pod, service, deployment)
• Есть Proxmox с 14+ vCPU и 56GB+ RAM
• Хочешь понять что устанавливать, прежде чем устанавливать

Не подходит:

• Нужна одна нода для экспериментов - достаточно docker-compose или K3s single-node
• Ищешь managed Kubernetes для бизнеса - смотри в сторону Yandex Cloud или VK Cloud
• Хочешь сразу команды без теории - переходи к статье 2

K3s vs Kubernetes: в чём разница

#

Kubernetes (K8s) - оркестратор контейнеров, стандарт индустрии. Добро пожаловать в enterprise, где для запуска трёх контейнеров нужно поддерживать шесть виртуальных машин.

K3s - тот же Kubernetes, но кто-то в Rancher (теперь SUSE) задумался: “А что если выкинуть всё, что нужно только Сберу и Yandex Cloud?”

Что выкинули:

• Интеграции с облачными провайдерами (вы же не в VK Cloud)
• Legacy API (вы же не мигрируете кластер 2016 года)
• Встроенные драйверы хранилищ на все случаи жизни (вы же не используете 47 типов СХД)
• Альфа/бета-функции (нестабильные эксперименты)

Что осталось: полноценный Kubernetes, сертифицированный CNCF (Cloud Native Computing Foundation - организация, которая решает, что считать “настоящим” Kubernetes). Все манифесты работают. Helm работает. kubectl работает. Ответы со StackOverflow работают.

Сравнение в цифрах

#

“Но я потеряю гибкость!” - скажете вы. Да, вы не сможете заменить сетевой плагин Flannel без пересборки. Это критично примерно для одного проекта из тысячи, и ваш homelab в их число не входит.

Вердикт: для homelab K3s - очевидный выбор. Теряем 5% гибкости, получаем 90% простоты.

Что такое High Availability и зачем оно вам

#

HA (High Availability) - способность системы продолжать работу при отказе компонентов. Звучит как enterprise-термин для больших компаний? На практике это разница между “кластер упал в субботу, но я починил в понедельник” и “кластер сам пережил падение ноды, пока я спал”.

Без HA (single node)

#

┌─────────────────┐
│   K3s Master    │  ← Единственная точка отказа
│   + Worker      │
└─────────────────┘

Нода упала → кластер мёртв → ваши сервисы недоступны

С HA (3+ master nodes)

#

┌──────────┐  ┌──────────┐  ┌──────────┐
│ Master 1 │  │ Master 2 │  │ Master 3 │
│  + etcd  │  │  + etcd  │  │  + etcd  │
└──────────┘  └──────────┘  └──────────┘
     ↓              ↓              ↓
┌──────────┐  ┌──────────┐
│ Worker 1 │  │ Worker 2 │
└──────────┘  └──────────┘

Одна master упала → кластер работает
Один worker упал → поды переехали на другой

Сколько master нод нужно

#

Вот тут начинается интересное. Интуиция подсказывает: одна нода - плохо, две - уже лучше. Логично? Логично. И неправильно.

Почему 2 master ноды хуже, чем 1

#

etcd (база данных кластера, где хранится вообще всё) работает по принципу голосования. Чтобы записать данные, нужно согласие большинства нод. Не “хотя бы одной” - именно большинства.

Считаем:

• 1 нода: большинство = 1. Упала - кластер мёртв. Честная игра, вы знали на что шли.
• 2 ноды: большинство = 2. Упала одна - кворума нет, кластер мёртв. Сюрприз!
• 3 ноды: большинство = 2. Одна упала - две оставшиеся продолжают работать.

Это как договор, требующий подписи обоих директоров - заболел один, и компания парализована.

С двумя нодами вы не получили отказоустойчивость. Вы удвоили количество точек отказа и назвали это “высокой доступностью”.

Правило: или 1 нода (и честное понимание рисков), или 3+ (и настоящий HA). Двойка - ловушка для тех, кто не дочитал документацию.

Embedded etcd vs External etcd

#

etcd - распределённое key-value хранилище. Единственный источник истины для всего состояния Kubernetes: все объекты (поды, сервисы, секреты), конфигурации, сетевые политики. Без etcd кластер не работает. Точка.

Есть два варианта архитектуры:

External etcd (классический Kubernetes)

#

Control Plane (3 VM)              etcd кластер (3 VM)
┌────────────────┐                ┌──────────────┐
│ API Server     │                │ etcd-1       │
│ Scheduler      │ ──────────────>│ (только etcd)│
│ Controller     │                └──────────────┘
└────────────────┘                ┌──────────────┐
┌────────────────┐                │ etcd-2       │
│ API Server     │ ──────────────>│ (только etcd)│
│ Scheduler      │                └──────────────┘
│ Controller     │                ┌──────────────┐
└────────────────┘                │ etcd-3       │
┌────────────────┐                │ (только etcd)│
│ API Server     │ ──────────────>└──────────────┘
│ Scheduler      │
│ Controller     │
└────────────────┘

Итого: 6 виртуальных машин

Embedded etcd (K3s)

#

┌─────────────────────────┐
│ K3s Master 1            │
│  ┌───────────────────┐  │
│  │ API + Scheduler   │  │
│  │ + Controller      │  │
│  └───────────────────┘  │
│  ┌───────────────────┐  │
│  │ etcd (встроенный) │◄─┼──┐
│  └───────────────────┘  │  │
└─────────────────────────┘  │ Raft protocol
┌─────────────────────────┐  │ (синхронизация)
│ K3s Master 2            │  │
│  etcd ◄────────────────────┤
└─────────────────────────┘  │
┌─────────────────────────┐  │
│ K3s Master 3            │  │
│  etcd ◄────────────────────┘
└─────────────────────────┘

Итого: 3 виртуальные машины

Сравнение подходов

#

Для homelab embedded etcd - очевидный выбор. Теряем 5-10% производительности etcd, экономим 3 VM и часы настройки.

“А если мне понадобится масштаб?” - официально embedded etcd поддерживает до 100 нод и 5000 подов. Для homelab это как ограничение скорости 300 км/ч на велосипеде.

Зачем отдельные worker ноды

#

Worker ноды - машины для запуска ваших приложений (подов). На них не запускаются компоненты control plane.

“А можно запускать приложения прямо на master нодах?”

Технически - да. K3s не ставит ограничений на master ноды (в отличие от обычного Kubernetes). Но это плохая идея:

• Control plane должен быть стабильным. Ваше приложение съело всю память → API server упал → кластер недоступен.
• etcd чувствителен к диску. База данных на той же ноде создаёт I/O нагрузку → etcd тормозит → весь кластер тормозит.
• Изоляция отказов. Проблема с приложением не должна убивать control plane.

2 worker ноды - минимум для HA приложений:

• Можно запускать 2 реплики (на разных нодах)
• При падении одного worker’а второй держит нагрузку
• Легко добавить третью, четвёртую ноду потом

Архитектура нашего кластера

#

Вот что мы будем строить:

Ключевые моменты:

1. Все master ноды равны - нет “главной”, kubectl подключается к любой.
2. etcd синхронизируется через Raft - алгоритм консенсуса, гарантирует согласованность данных.
3. Workers знают только про API - они не подключаются к etcd напрямую.
4. Flannel создаёт overlay-сеть - все поды получают IP из 10.42.0.0/16, видят друг друга.

Планирование ресурсов

#

Таблица VM

#

Почему именно такие ресурсы

#

Master ноды (2 vCPU / 8GB RAM / 32GB Disk):

Реальное потребление в idle:

• API server: ~200-300MB RAM
• etcd: ~100-200MB RAM (растёт со временем)
• Scheduler + Controller: ~150MB RAM
• Системные поды: ~100-200MB RAM
• Итого: ~600-900MB используется

“Зачем тогда 8GB?” - запас для burst-нагрузки. Когда вы деплоите 50 подов одновременно, API server временно съедает больше. etcd при большом кластере может вырасти до 1-2GB. Golang GC работает лучше с запасом памяти.

Worker ноды (4 vCPU / 16GB RAM / 50GB Disk):

Здесь будут ваши приложения. При 16GB можно запустить:

• 5-10 средних приложений (256MB-2GB каждое)
• Или 2-3 базы данных (PostgreSQL любит память)
• Или комбинацию

50GB диска - под образы контейнеров (10-20GB), логи (5-10GB), временные данные.

Можно ли меньше?

#

Минимальная конфигурация (для экспериментов):

• Master: 1 vCPU / 4GB RAM / 20GB Disk
• Worker: 2 vCPU / 8GB RAM / 30GB Disk
• Итого: 9 vCPU / 36GB RAM

Риски:

• Медленная работа API server
• OOM killer при нагрузке
• Нет запаса для burst

Для production-like homelab рекомендую таблицу выше. Комфортный запас стоит дешевле, чем отладка странных падений.

Сетевая схема

#

IP-адреса (адаптируй под свою сеть)

#

192.168.11.0/24       - Локальная сеть
  192.168.11.1        - Gateway (роутер)
  192.168.11.201-203  - Master ноды
  192.168.11.210-211  - Worker ноды
  192.168.11.220-230  - Резерв для MetalLB (статья 2)

Kubernetes внутренние сети (создаются автоматически)

#

10.42.0.0/16  - Pod network (Flannel VXLAN overlay)
10.43.0.0/16  - Service network (ClusterIP)
10.43.0.10    - CoreDNS

Порты между нодами

#

Требования к железу и софту

#

Железо (Proxmox хост)

#

Минимум:

• CPU: 14 vCPU свободных
• RAM: 56GB свободных
• Disk: 200GB на SSD
• Network: 1 Gbit

Рекомендуется:

• CPU: 18+ vCPU (запас для приложений)
• RAM: 64GB+ (базы данных прожорливые)
• Disk: NVMe для etcd
• Network: 2.5 Gbit (для NFS, если будете использовать)

Софт

#

Итог

#

Что мы спроектировали:

• 5 VM: 3 master + 2 worker
• K3s с embedded etcd (HA без лишних VM)
• Отказоустойчивость: выдерживает падение 1 master и любого worker
• Ресурсы: 14 vCPU / 56GB RAM / 196GB Disk

Что НЕ входит в эту серию (отдельные статьи):

• LoadBalancer (MetalLB)
• Ingress (Traefik)
• SSL (cert-manager)
• Мониторинг (Prometheus/Grafana)

Что дальше

#

👉 “Подготовить инфраструктуру для K3s в Proxmox”

Там мы:

• Создадим template VM с Debian 12
• Склонируем 5 VM с правильными ресурсами
• Настроим статические IP
• Подготовим ОС (swap, cgroup v2, firewall)