--- title: "K3s HA для homelab: архитектура без боли" date: 2025-10-14 draft: false description: "Полноценный Kubernetes в бинарнике на 50MB вместо 1.5GB зависимостей. Разбираем архитектуру K3s HA кластера: почему именно 3 master ноды, зачем embedded etcd и сколько ресурсов закладывать." tags: ["kubernetes", "k3s", "homelab", "proxmox", "architecture", "ha", "devops"] categories: ["Kubernetes", "Homelab"] series: ["K3s HA кластер для homelab"] series_order: 1 --- 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?" ![Kubernetes](k8s-architecture.svg "**Kubernetes**") ![K3s](k3s-architecture.svg "**K3s**") **Что выкинули:** - Интеграции с облачными провайдерами (вы же не в VK Cloud) - Legacy API (вы же не мигрируете кластер 2016 года) - Встроенные драйверы хранилищ на все случаи жизни (вы же не используете 47 типов СХД) - Альфа/бета-функции (нестабильные эксперименты) **Что осталось:** полноценный Kubernetes, сертифицированный CNCF (Cloud Native Computing Foundation - организация, которая решает, что считать "настоящим" Kubernetes). Все манифесты работают. Helm работает. kubectl работает. Ответы со StackOverflow работают. ### Сравнение в цифрах | Характеристика | Kubernetes | K3s | |----------------|------------|-----| | Размер | ~1.5GB образы | 50MB бинарник | | RAM на control plane | ~2GB на ноду | ~500MB на ноду | | Установка | kubeadm, 10+ шагов | один curl-скрипт | | etcd | Отдельный кластер (3+ VM) | Встроенный | | CNI | Нужно устанавливать | Flannel из коробки | | Совместимость | 100% | 100% | *"Но я потеряю гибкость!"* - скажете вы. Да, вы не сможете заменить сетевой плагин 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 нод нужно Вот тут начинается интересное. Интуиция подсказывает: одна нода - плохо, две - уже лучше. Логично? Логично. И неправильно. | Master нод | Выдержит отказов | Кворум | Вердикт | |------------|------------------|--------|---------| | 1 | 0 | 1/1 | Нет HA, но честно | | 2 | 0 | **Ловушка!** | ⛔ Хуже, чем 1 | | 3 | 1 | 2/3 | ✅ Минимум для HA | | 5 | 2 | 3/5 | Для критичных систем | ### Почему 2 master ноды хуже, чем 1 etcd (база данных кластера, где хранится вообще всё) работает по принципу голосования. Чтобы записать данные, нужно согласие большинства нод. Не "хотя бы одной" - именно большинства. Считаем: - **1 нода:** большинство = 1. Упала - кластер мёртв. Честная игра, вы знали на что шли. - **2 ноды:** большинство = 2. Упала одна - кворума нет, кластер мёртв. Сюрприз! - **3 ноды:** большинство = 2. Одна упала - две оставшиеся продолжают работать. Это как договор, требующий подписи обоих директоров - заболел один, и компания парализована. С двумя нодами вы не получили отказоустойчивость. Вы удвоили количество точек отказа и назвали это "высокой доступностью". ![High Availability](k3s-ha.svg) **Правило:** или 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 виртуальные машины ``` ![etcd](etcd.svg) ### Сравнение подходов | Критерий | External etcd | Embedded etcd | |----------|---------------|---------------| | Количество VM | 6 (3 master + 3 etcd) | 3 (всё вместе) | | Сложность настройки | Высокая | Один флаг `--cluster-init` | | Сложность обновления | Отдельно etcd и K8s | Одна команда | | Производительность | Чуть лучше | Достаточно для homelab | | Масштаб | >500 нод | До 100-200 нод | **Для 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'а второй держит нагрузку - Легко добавить третью, четвёртую ноду потом --- ## Архитектура нашего кластера Вот что мы будем строить: ![Архитектура нашего кластера](final_arch.svg) **Ключевые моменты:** 1. **Все master ноды равны** - нет "главной", kubectl подключается к любой. 2. **etcd синхронизируется через Raft** - алгоритм консенсуса, гарантирует согласованность данных. 3. **Workers знают только про API** - они не подключаются к etcd напрямую. 4. **Flannel создаёт overlay-сеть** - все поды получают IP из 10.42.0.0/16, видят друг друга. --- ## Планирование ресурсов ### Таблица VM | Hostname | VM ID | IP | vCPU | RAM | Disk | Роль | |----------|-------|------------|------|-----|------|------| | k3s-master-1 | 201 | 192.168.11.201 | 2 | 8GB | 32GB | Control Plane + etcd | | k3s-master-2 | 202 | 192.168.11.202 | 2 | 8GB | 32GB | Control Plane + etcd | | k3s-master-3 | 203 | 192.168.11.203 | 2 | 8GB | 32GB | Control Plane + etcd | | k3s-worker-1 | 210 | 192.168.11.210 | 4 | 16GB | 50GB | Workloads | | k3s-worker-2 | 211 | 192.168.11.211 | 4 | 16GB | 50GB | Workloads | | **Итого** | - | - | **14** | **56GB** | **196GB** | - | ### Почему именно такие ресурсы **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 ``` ![Сети](k3s_network.svg) ### Порты между нодами | Порт | Протокол | Направление | Назначение | |------|----------|-------------|------------| | 6443 | TCP | Master ← Worker | Kubernetes API | | 2379-2380 | TCP | Master ↔ Master | etcd (client + peer) | | 10250 | TCP | Master ↔ All | Kubelet API | | 8472 | UDP | All ↔ All | Flannel VXLAN | --- ## Требования к железу и софту ### Железо (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, если будете использовать) ### Софт | Компонент | Версия | |-----------|--------| | Proxmox VE | 7.x или 8.x | | K3s | v1.31+ (stable) | | ОС на нодах | Debian 12 или Ubuntu 22.04+ | | Kernel | 5.15+ (для cgroup v2) | ## Итог **Что мы спроектировали:** - 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)