LXC/LXD-контейнеры в продакшене: кластеры, сети, снапшоты и миграция для серьёзных инсталляций

Мы прошли путь от ранних OpenVZ и чистого LXC до промышленных LXD-кластеров на Ubuntu Server LTS. В дата-центре МТС у нас работают два узла Dell Xeon Platinum 8280 с 40G Mellanox, объединённые в единый LXD-кластер, который держит нагрузку от сотни с лишним клиентских сервисов — и порой эта система стабильнее многих K8s-инсталляций того же масштаба.

LXC, LXD, Incus — что именно ставить сейчас

В мире LXD произошли кое-какие пертурбации, после того как проект перешёл под крыло Canonical. Сообщество не стало мириться с этим, и в 2023 году ребята сделали форк – так родился Incus, теперь им рулит организация Linux Containers. Что в итоге? Оба проекта живут и здравствуют, развиваются параллельно. По части CLI они вполне совместимы, но, конечно, в деталях есть свои нюансы и отличия. Стоит их знать!

• LXC — низкоуровневые утилиты (lxc-start, lxc-ls). Подходит, если нужна максимальная гибкость и вы готовы писать конфиги руками.
• LXD (Canonical) — стабильный выбор на Ubuntu 22.04/24.04 LTS, тесная интеграция с MAAS и Juju.
• Incus — форк сообщества, быстрее добавляют фичи, работает без snap.

На наших новых проектах мы всегда ставим LXD из snap. Только Ubuntu Server 22.04 LTS! Это уже проверенный стандарт, обкатанный на миллионах инсталляций по всему миру.

Установка и первичная инициализация

# Ubuntu 22.04 LTS
sudo apt update
sudo snap install lxd --channel=5.21/stable
sudo usermod -aG lxd $USER
newgrp lxd

# Инициализация
lxd init

# Ключевые вопросы lxd init:
# - Configure the storage pool: zfs
# - Pool device: /dev/sdb (отдельный диск под данные)
# - Configure a new local network bridge: yes, lxdbr0
# - Subnet: 10.100.0.0/24
# - IPv6: none

Завершили init – и что дальше? Получаете готовую инсталляцию: тут вам и storage pool на ZFS, и дефолтный профиль, и сетевой бридж. А вот на продакшене мы всегда физически разделяем rootfs хоста и storage pool. Rootfs летит на SSD, а контейнеры — строго на отдельный пул из NVMe или SAS-дисков в raidz. Так надёжнее, и производительность выше.

Создание контейнеров и запуск

# Список доступных образов
lxc remote list
lxc image list ubuntu: | head -20

# Создать контейнер
lxc launch ubuntu:22.04 web01
lxc launch ubuntu:22.04 web02

# Запустить команду внутри
lxc exec web01 -- apt update
lxc exec web01 -- apt install -y nginx

# Получить оболочку
lxc shell web01

# Список, статус, сеть
lxc list
lxc info web01 --show-log

Профили: правильный способ управления конфигурацией

Профиль в LXD — это набор настроек (сеть, диск, лимиты, security), который можно применить к любому контейнеру. Это главный инструмент DRY в LXD. У нас на практике я создаю профили под типовые роли: web, db, mail-relay, worker — и новые контейнеры получают настройки мгновенно.

# Создать профиль
lxc profile create web

# Задать лимиты через YAML
cat <<EOF | lxc profile edit web
config:
  limits.cpu: "2"
  limits.memory: 2GB
  limits.memory.swap: "false"
  boot.autostart: "true"
  security.nesting: "false"
devices:
  eth0:
    type: nic
    network: lxdbr0
  root:
    type: disk
    pool: default
    path: /
    size: 10GB
EOF

# Применить профиль
lxc profile add web01 web
lxc launch ubuntu:22.04 web03 -p default -p web

Сети: bridge, macvlan, OVN

LXD умеет работать с тремя сетевыми моделями. Какую выбрать? Всё зависит от ваших требований, конечно.

# macvlan
lxc network create officenet --type=macvlan parent=eno1
lxc config device add web01 eth0 nic nictype=macvlan parent=eno1

# OVN (требует предустановленного OVN-кластера)
lxc network create ovn1 --type=ovn network=UPLINK
lxc network set ovn1 ipv4.address=10.200.0.1/24

Кластеризация: объединяем три узла

LXD-кластер — киллер-фича для по-настоящему серьёзных инсталляций: один набор команд управляет всеми узлами, контейнеры распределяются автоматически, а ZFS-снапшоты всегда под рукой для миграции.

# На первом узле
lxc cluster enable node01

# На втором и третьем — повторить lxd init,
# указав "Are you joining an existing cluster? yes"
# и введя trust token, полученный через
lxc cluster add node02
# Скопировать join-token и вставить при инициализации

# Посмотреть узлы
lxc cluster list

# Создать контейнер с выбором узла
lxc launch ubuntu:22.04 db01 --target node02

Вот тут будьте внимательны: в кластере storage pool типа dir или zfs обязательно должен быть локальным на каждом отдельном узле. А если вам нужно общее хранилище, тогда ваш выбор – Ceph или любой remote storage.

Снапшоты и бэкапы

ZFS-снапшоты в LXD – это просто копейки! Мы всегда настраиваем автоматическую ротацию прямо перед любыми апдейтами. Удобно, быстро и безопасно.

# Создать снапшот
lxc snapshot web01 before-upgrade-2025-04-17

# Откатиться
lxc restore web01 before-upgrade-2025-04-17

# Автоматические снапшоты через профиль
lxc config set web01 snapshots.schedule "0 3 * * *"
lxc config set web01 snapshots.expiry "14d"

# Экспорт контейнера в tar.gz
lxc export web01 /backup/web01-$(date +%F).tar.gz

# Импорт на другой узел
lxc import /backup/web01-2025-04-17.tar.gz

Миграция между узлами

# Stopped-миграция между узлами кластера
lxc move web01 --target node03

# Cross-cluster с другим LXD
lxc remote add remote-hq 192.168.50.10 --password SECRET
lxc copy web01 remote-hq:web01-copy

# Live migration (экспериментально, нужен CRIU)
lxc move web01 --target node02 --mode=pull

Кейс: консолидация 22 сервисов на двух-узловой кластер

История из нашей практики: осенью 2025 года к нам обратилось проектное бюро. Представляете, 45 рабочих мест и 22 (!) разрозненных линукс-сервиса, всё это болталось на восьми старых HP DL360 G7. Цель была амбициозной: собрать всё на паре свежих узлов и, конечно, предусмотреть запас на будущее. Что мы сделали? Взяли два мощных Dell Xeon Platinum 8280, на каждый по 256 ГБ DDR4, плюс по 8 NVMe U.2 в raidz2. Связали их 40G Mellanox в кросс-соединении, накатили Ubuntu 22.04 LTS и LXD 5.21. Решение было элегантным.

Архитектура:

• ZFS storage pool 24 ТБ под контейнеры.
• OVN overlay-сеть? Идеально для изоляции: production и staging живут в своих мирах, не мешая друг другу.
• Мы используем 8 стандартных профилей, чтобы не изобретать велосипед: web, db, worker, ci, monitoring, mail, dev и даже для наших 'динозавров' – legacy.
• Для максимальной надёжности — автоматические ежедневные снапшоты. Плюс, не забываем про репликацию: всё улетает через zfs send на отдельный, третий узел-бэкап. Спите спокойно!

Что в итоге? Все 22 сервиса мы перенесли всего за 6 рабочих дней, при этом uptime во время миграций ни разу не опускался ниже 99,8%! Клиент получил колоссальную экономию: 140 000 рублей в год только на электричестве, плюс освободили 8 юнитов стойки. А цикл развёртывания нового сервиса? Вместо двух дней — теперь 20 минут! Весь проект обошёлся в 320 000 рублей. Неплохо, правда?

Мониторинг и типовые грабли

• Хотите мониторить всё как следует? Ставьте Prometheus node_exporter прямо в каждый контейнер, а на хосте не забудьте про кастомный lxd-exporter. Это мастхэв!
• Следите за inotify watches: sysctl fs.inotify.max_user_watches=524288.
• Если nginx в контейнере жрёт CPU — проверьте worker_rlimit_nofile, контейнеры получают свой ulimit.
• При апдейте LXD через snap убедитесь, что snap refresh не идёт в кластере одновременно на всех узлах.
• ZFS ARC ест память — ограничьте zfs_arc_max в /etc/modprobe.d/zfs.conf, иначе отожмёт у контейнеров.

Безопасность и защита от ошибок: ключи, которые я проверяю

По умолчанию LXD запускает контейнеры непривилегированными: они работают в user namespace, и root внутри контейнера отображается на обычного непривилегированного пользователя хоста. Документация LXD называет такие контейнеры безопасными по построению — уязвимость, позволяющая выбраться наружу, будет ошибкой ядра, а не LXD. Поэтому первое, что я смотрю на чужой инсталляции, — нет ли там security.privileged=true, выставленного «чтобы заработало».

• security.privileged — по умолчанию false. Включаю только для единичных legacy-сервисов, и такие контейнеры держу на отдельном узле;
• security.idmap.isolated — по умолчанию false. Если контейнерам не нужно делить данные, включаю: каждый получает свой непересекающийся диапазон UID/GID;
• security.nesting — по умолчанию false, нужен, только если внутри контейнера запускается LXD или Docker;
• security.protection.delete — по умолчанию false. На базах и почте ставлю true: lxc delete по ошибке в соседнем окне терминала такой контейнер не удалит;
• limits.memory.enforce — по умолчанию hard, контейнер не выйдет за лимит. Значение soft разрешает брать свободную память хоста, но на плотно заполненном узле я его не использую;
• boot.autostart и boot.autostart.priority — порядок запуска после перезагрузки узла: первым стартует контейнер с наибольшим приоритетом (по умолчанию 0). Базу данных ставлю выше приложений.

lxc config set db01 security.protection.delete=true
lxc config set db01 boot.autostart=true boot.autostart.priority=100
lxc config set app01 boot.autostart=true boot.autostart.priority=10

Экспорт контейнеров: что попадает в архив

У lxc export есть детали, которые влияют на размер и переносимость копии. По умолчанию в архив попадают все снапшоты контейнера — при ежедневных снапшотах с хранением две недели архив раздувается. Флаг --instance-only выгружает контейнер без снапшотов. Флаг --optimized-storage на пулах ZFS и Btrfs сохраняет данные бинарным блоком драйвера вместо архива файлов: это быстрее, но восстановить такой экспорт можно только в пул с тем же драйвером.

# Ночной экспорт без снапшотов, в формате ZFS
lxc export web01 /backup/web01-$(date +%F).tar.gz --instance-only --optimized-storage

# Восстановление под другим именем для проверки
lxc import /backup/web01-2026-09-20.tar.gz web01-restore-test

Ещё одна ловушка: если файл с таким именем уже существует, lxc export молча его перезапишет, поэтому дату в имени файла я пишу всегда. Восстановленную копию под другим именем (lxc import принимает имя вторым аргументом) запускаю раз в месяц, проверяю сервис и удаляю.

FAQ — LXC/LXD в продакшене

Нужно ли делать контейнеры привилегированными?

Почти никогда. По умолчанию security.privileged=false, и root контейнера отображается на непривилегированного пользователя хоста. Привилегированный режим оставляю только для legacy-сервисов, которые иначе не работают.

Почему экспорт контейнера такой большой?

Потому что lxc export по умолчанию включает все снапшоты. Добавьте --instance-only, чтобы выгрузить только текущее состояние.

Чем LXD отличается от LXC?

LXC — низкоуровневая библиотека. LXD — демон поверх LXC с REST API, кластеризацией, профилями и удобной CLI.

Какой storage pool выбрать?

Для продакшена ZFS — снапшоты, сжатие, репликация.

Сколько контейнеров помещается на узел?

На Dell Xeon Platinum 8280 с 256 ГБ RAM — до 180 рабочих контейнеров. Узкое место — лимиты ядра.

Работает ли live migration?

Да, через CRIU, но с ограничениями. Для stateful-сервисов надёжнее stopped-миграция с репликацией ZFS.

Можно ли Windows внутри LXD?

Нет, только Linux. Для Windows используйте LXD Virtual Machines (KVM под управлением LXD).