Współdzielony kernel zamiast pełnej wirtualizacji
Kontener LXC nie uruchamia własnego jądra ani BIOS-u — współdzieli kernel hosta Proxmox, izolując procesy przez namespaces i cgroups. W efekcie start trwa ułamek sekundy, narzut pamięci jest minimalny, a na jednym hoście zmieścisz znacznie więcej kontenerów niż pełnych VM.
| Cecha | Kontener LXC | Maszyna QEMU/KVM |
|---|---|---|
| Kernel | Współdzielony z hostem | Własny, dowolny |
| Narzut zasobów | Bardzo niski | Wyższy (pełna VM) |
| Czas startu | < 1 s | Sekundy–minuty |
| System gościa | Tylko Linux | Linux, Windows, BSD… |
| Izolacja | Na poziomie kernela | Pełna (sprzętowa) |
| Snapshoty / backup | Tak (ZFS, PBS) | Tak (ZFS, PBS) |
Bezpieczeństwo: unprivileged domyślnie
Proxmox tworzy kontenery jako nieuprzywilejowane (unprivileged) i tak powinno pozostać. UID/GID kontenera są mapowane na nieuprzywilejowany zakres hosta (root w kontenerze = zwykły użytkownik na hoście), co znacząco ogranicza skutki ewentualnej ucieczki z kontenera.
- Nieuprzywilejowane: domyślny i rekomendowany wybór dla niemal wszystkich usług — web, API, aplikacje, bazy danych.
- Uprzywilejowane: tylko gdy naprawdę musisz (np. specyficzny dostęp do urządzeń) — root w kontenerze = root na hoście, większe ryzyko.
- Nesting / FUSE / keyctl: dodatkowe funkcje (np. Docker w LXC) włączasz świadomie przez „Features”, nie globalnie.
Uwaga: obciążenia wymagające własnych modułów jądra, własnego kernela lub systemu innego niż Linux (Windows) nie nadają się do LXC — tam użyj pełnej maszyny QEMU.
Bind mounts i trwałe dane
Kontenery używają wolumenów na storage Proxmox (ZFS, LVM-thin, katalog). Duże, współdzielone zbiory danych podłączamy przez bind mount (pct set <id> -mp0 /tank/dane,mp=/data), zamiast trzymać je w rootfs kontenera — ułatwia to backup, migrację i współdzielenie między kontenerami.
- Rootfs kontenera trzymaj mały — system i aplikacja, nie dane.
- Dane użytkowe na osobnym wolumenie ZFS z własnym snapshotem.
- Przy nieuprzywilejowanych kontenerach pamiętaj o mapowaniu UID/GID dla bind mounts.
LXC w realnej infrastrukturze
Kontenery LXC backupujemy tak samo jak VM — przez Proxmox Backup Server (PBS) z deduplikacją i kopiami przyrostowymi, albo przez vzdump. Wspierane są tryby snapshot (na ZFS/LVM-thin) oraz suspend/stop. HA klastra Proxmox obejmuje kontenery tak samo jak maszyny wirtualne.
Typowe, dobre zastosowania LXC: serwery WWW i reverse-proxy, API i mikrousługi, runnery CI, instancje baz danych dev/test, serwery DNS/monitoring. Dla maksymalnej izolacji najemców lub obciążeń niezaufanych — zostań przy pełnych VM.
W praktyce: w migracjach łączymy oba światy — krytyczne i niezaufane obciążenia jako VM, a gęste, jednorodne usługi linuksowe jako LXC. Efekt: większa gęstość i niższy koszt bez utraty bezpieczeństwa tam, gdzie ma ono znaczenie.
Zaplanujemy podział VM / LXC
Pomożemy zdecydować, które obciążenia przenieść do lekkich kontenerów, a które zostawić jako pełne maszyny — z backupem PBS i HA.
⚡ Bezpłatna konsultacja → Wybór typu CPU w Proxmox