Облачный сервер для Kubernetes в Европе
Kubernetes - стандартная платформа оркестрации контейнерных нагрузок в масштабе. Чтобы он работал хорошо, недостаточно просто установить k8s: нужны достаточные ресурсы на каждом узле, надёжная сеть между узлами и понимание того, как выглядит минимально работоспособный кластер.
Размещение кластера Kubernetes в Европе - практическая необходимость, если здесь ваши пользователи или данные. Приватная сеть с низкой задержкой между узлами, соответствие GDPR по месту хранения данных и физическая близость к вашей инженерной команде - всё это склоняет к хостингу в ЕС.
Почему хостинг в ЕС важен для Kubernetes
Кластер Kubernetes - распределённая система. Компоненты управляющего слоя постоянно обмениваются данными с рабочими узлами, а поды общаются между собой по всему кластеру. Задержка между узлами - это не только вопрос производительности, она напрямую влияет на устойчивость кластера. Etcd, хранилище ключей и значений в сердце Kubernetes, требует записи с низкой задержкой для поддержания согласованности. Узлы с высокой задержкой до управляющего слоя могут выглядеть неработоспособными и быть исключены.
Размещение всех узлов в одном дата-центре ЕС или как минимум в одном регионе держит задержку между узлами ниже 1 мс. Это базовый ориентир для здорового кластера.
Соответствие GDPR не менее прямолинейно: нагрузки, обрабатывающие персональные данные из ЕС, должны выполняться на инфраструктуре, остающейся в юрисдикции ЕС.
Минимальные требования к серверу
У Kubernetes реальные требования к оборудованию. Профили узла управляющего слоя и рабочих узлов различаются.
Для узла управляющего слоя:
- RAM: минимум 4 ГБ (8 ГБ рекомендуется для кластеров с более чем 10 рабочими узлами)
- CPU: минимум 2 ядра (рекомендуются 4 ядра)
- Диск: 40 ГБ SSD (etcd интенсивно пишет, нужен быстрый диск)
Для каждого рабочего узла:
- RAM: минимум 4 ГБ на узел
- CPU: минимум 2 ядра на узел
- Диск: 40 ГБ SSD на узел
Минимальная схема, пригодная для продакшена, - 1 узел управляющего слоя плюс 2 рабочих узла. Для высокой доступности используйте 3 узла управляющего слоя и 3 или более рабочих. k3s - более лёгкая альтернатива полному Kubernetes, он работает на чуть меньшем объёме RAM, что делает его практичным для небольших кластеров.
Рекомендуемая конфигурация DCXV
Облачные инстансы DCXV на https://dcxv.com/data-center#cloud начинаются от EUR 15 в месяц. Для кластера Kubernetes из 3 узлов (1 управляющий и 2 рабочих) разумная отправная точка - три инстанса по 4 ГБ RAM и 4 vCPU.
Облачные инстансы DCXV в одном дата-центре находятся в общей приватной сети с очень низкой задержкой между ними, а это именно то, что нужно Kubernetes. Круглосуточная поддержка инженеров включена без доплат и полезна, когда в полночь вы разбираетесь, почему узел не возвращается в кластер.
Для более крупных кластеров или нагрузок, которым нужны гарантии выделенного оборудования, выделенные серверы DCXV начинаются от EUR 49 в месяц.
Руководство по настройке
Развёртывание кластера k3s (облегчённый Kubernetes) на трёх инстансах DCXV:
# На узле управляющего слоя: установка k3s
curl -sfL https://get.k3s.io | sh -
# Получить токен присоединения с узла управляющего слоя
cat /var/lib/rancher/k3s/server/node-token
# На каждом рабочем узле: присоединиться к кластеру
curl -sfL https://get.k3s.io | K3S_URL=https://<control-plane-ip>:6443 K3S_TOKEN=<token> sh -
# Проверить, что все узлы готовы (выполнить на управляющем слое)
kubectl get nodes
После подъёма кластера установите контроллер ingress и cert-manager для TLS:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
Сколько узлов в управляющем слое
Это решение стоит принять правильно до того, как на кластере что-то запущено, потому что etcd держит кворум, а кворуму нужно большинство. Неочевидная часть - вторая строка:
| Управляющий слой | Переживает потерю | Кворуму нужно | Когда выбирать |
|---|---|---|---|
| 1 узел | ничего - API пропадает | 1 из 1 | разработка, CI, стейджинг, всё что можно пересобрать |
| 2 узла | ничего, и стоит вдвое дороже | 2 из 2 | никогда - это строго хуже одного узла |
| 3 узла | один узел, без потери записей | 2 из 3 | продакшен, и это минимум, достойный такого названия |
| 5 узлов | два узла | 3 из 5 | крупные кластеры или когда может отказать целая стойка |
Два узла - это ловушка: при чётном числе большинства не получить, поэтому потеря любого из них уронит сервер API так же, как и один узел, а заплатили вы вдвое. С рабочими узлами всё наоборот: это расходный материал, добавляйте и убирайте их свободно, их количество ни на что критично не влияет.
Ожидаемая производительность
На кластере k3s из 3 узлов на инстансах 4 ГБ / 4 vCPU:
- задержка планирования подов менее 2 секунд для типичных нагрузок
- пропускная способность сети между подами 1-5 Гбит/с внутри одного дата-центра
- ingress обрабатывает 1 000-3 000 запросов HTTP в секунду в зависимости от нагрузки
- время ответа API управляющего слоя менее 50 мс для стандартных операций kubectl
- задержка записи etcd менее 5 мс на накопителях SSD
Это базовые цифры для кластера с умеренной нагрузкой. Тяжёлые пакетные задачи, большое число подов или нагрузки с интенсивным обменом между сервисами потребуют дополнительных узлов или более крупных инстансов.
Это ожидания для оборудования такого класса, а не измерения в нашей собственной лаборатории. Считайте их отправной точкой для расчёта размера и измеряйте свою нагрузку: реальные цифры зависят от ваших данных, запросов и настройки гораздо сильнее, чем от провайдера.
