Настроил. Добавил серию статей о K3S Cluster

content/posts/k3s-architecture/index.md

@@ -0,0 +1,374 @@
+---
+title: "K3s HA для homelab: архитектура без боли"
+date: 2025-10-14
+draft: false
+description: "Полноценный Kubernetes в бинарнике на 50MB вместо 1.5GB зависимостей. Разбираем архитектуру K3s HA кластера: почему именно 3 master ноды, зачем embedded etcd и сколько ресурсов закладывать."
+summary: "Kubernetes слишком тяжёлый, Docker Swarm мёртв, а хочется нормальный кластер для экспериментов. K3s решает эту проблему - полноценный Kubernetes в 50MB. Разберём архитектуру HA кластера без боли."
+tags: ["kubernetes", "k3s", "homelab", "proxmox", "architecture", "ha", "devops"]
+series: ["K3s HA кластер для homelab"]
+series_order: 1
+# seriesOpened: false
+# showTableOfContents: true
+showAuthor: true
+---
+
+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)