09.Proxmox 컨테이너 배포하기
Proxmox VE LXC 컨테이너란 무엇인가
Proxmox VE는 KVM 기반 가상 머신(VM)뿐 아니라 LXC(Linux Containers) 기반 시스템 컨테이너를 함께 관리할 수 있습니다.
LXC 컨테이너는 독립된 Linux 사용자 공간, 프로세스, 네트워크, 파일시스템 환경을 제공하지만, 자체 커널을 실행하지 않고 Proxmox VE 호스트의 Linux 커널을 공유합니다.
KVM Virtual Machine
└── Proxmox VE Host
└── KVM / QEMU
└── VM
├── Guest Kernel
├── Guest OS
└── Application
LXC Container
└── Proxmox VE Host
└── Host Linux Kernel
└── LXC Container
├── Linux User Space
├── Process / Network Namespace
└── Application
LXC는 게스트 커널을 별도로 실행하지 않으므로 VM보다 CPU·메모리 오버헤드가 낮고, 빠르게 생성·기동할 수 있습니다. 다만 실제 성능과 보안 수준은 호스트 커널, cgroup 제한, 스토리지·네트워크 구성, 애플리케이션 특성에 따라 달라집니다.
Proxmox VE에서는 pct 명령으로 LXC 컨테이너를 관리합니다.
pct list
pct status 1001
pct start 1001
pct shutdown 1001
pct enter 1001
LXC와 VM의 차이
| 항목 | KVM 기반 VM | LXC 기반 컨테이너 |
|---|---|---|
| 가상화 방식 | 하드웨어 수준 가상화 | OS 수준 가상화 |
| 커널 | VM마다 독립 Guest Kernel | Proxmox 호스트 Linux Kernel 공유 |
| 지원 OS | Linux, Windows, BSD 등 | Linux 사용자 공간 중심 |
| 격리 | 상대적으로 강함 | VM보다 낮은 커널 격리 |
| 자원 사용량 | Guest OS 전체가 필요 | Kernel 공유로 상대적으로 적음 |
| 부팅·생성 속도 | 일반 OS 부팅 시간 필요 | 일반적으로 빠름 |
| 커널·드라이버 제어 | VM 내부에서 가능 | 호스트 커널 제약을 받음 |
| GPU·PCI Passthrough | 가능 | 일반적인 사용 사례 아님 |
| 관리 명령 | qm |
pct |
다음과 같은 워크로드는 VM을 우선 검토합니다.
- Windows Server 또는 Windows Desktop
- Kubernetes Control Plane·Worker Node
- 데이터베이스, 메시지 브로커, 검색 플랫폼 같은 상태 기반 핵심 서비스
- 커널 모듈, 특수 드라이버, GPU·PCI Passthrough가 필요한 서비스
- 보안 정책상 VM 수준의 강한 격리가 필요한 업무 시스템
- 컨테이너 환경을 지원하지 않는 EDR·백신·보안 Agent가 필요한 서비스
다음과 같은 Linux 서비스는 LXC를 검토할 수 있습니다.
- 내부 DNS, NTP, Bastion
- Reverse Proxy, 경량 웹 서버, 간단한 API
- Package·Artifact·Registry Mirror
- 관리용 Utility, 로그 전달 중계
- 개발·테스트·교육용 Linux 환경
- 빠르게 만들고 삭제하는 단기 실습 환경
Proxmox VE
├── VM: PostgreSQL
├── VM: GitLab
├── VM: Harbor
├── VM: Kubernetes Node
├── CT: DNS
├── CT: NTP
├── CT: Bastion
└── CT: Utility
LXC와 Docker·Kubernetes
LXC는 Docker나 Kubernetes와 같은 의미가 아닙니다.
| 구분 | Proxmox VE LXC | Docker / containerd | Kubernetes |
|---|---|---|---|
| 주 목적 | Linux 시스템 컨테이너 | 애플리케이션 컨테이너 실행 | 컨테이너 오케스트레이션 |
| 운영 단위 | 작은 Linux 서버와 유사 | 단일 또는 소수 프로세스 | Pod, Deployment, StatefulSet |
| systemd | 일반적으로 사용 가능 | 일반적으로 사용하지 않음 | Node OS에서 사용 |
| 일반 용도 | DNS, NTP, Bastion, Utility | 애플리케이션 배포 | 분산 애플리케이션 운영 |
LXC 내부에서 Docker·Podman·Kubernetes를 구성할 수 있는 경우도 있습니다. 하지만 Nesting, Keyctl, cgroup, AppArmor, user namespace, 스토리지 드라이버, CNI 호환성을 추가로 검토해야 합니다.
따라서 운영 Kubernetes Node, 일반적인 Docker Host, CI Runner는 KVM VM을 우선 검토하는 편이 단순합니다.
Proxmox VE
└── KVM VM
└── Linux
└── containerd / CRI-O / Docker
└── Application Container
Privileged와 Unprivileged Container
LXC 생성 시 가장 중요한 선택 중 하나는 Unprivileged Container입니다.
| 항목 | Privileged Container | Unprivileged Container |
|---|---|---|
| 컨테이너 root UID | 호스트에서도 root UID 0으로 매핑될 수 있음 | 호스트의 비권한 UID 범위로 매핑 |
| 보안 경계 | 상대적으로 약함 | User Namespace 기반으로 강화 |
| 호스트 영향 | Escape·Bind Mount·장치 설정 문제 시 영향이 더 클 수 있음 | 호스트 root로 직접 이어질 위험을 줄임 |
| 호환성 | 일부 특수 기능에 유리 | 일부 마운트·장치·권한 작업에 제약 가능 |
| 기본 권장 | 특별한 요구사항이 있을 때만 검토 | 일반적인 신규 컨테이너에 권장 |
Unprivileged Container는 컨테이너 내부에서는 root UID 0으로 보이지만, 호스트에서는 일반적으로 100000 이상의 비권한 UID 범위로 매핑됩니다.
Container View
└── root UID 0
│
▼
Host View
└── Unprivileged UID Range
└── Example: 100000+
일반적인 DNS, NTP, Bastion, Reverse Proxy, Utility, 테스트 컨테이너는 Unprivileged Container를 우선 사용합니다.
Privileged Container는 특수 장치 접근, 파일시스템 마운트, VPN TUN/TAP, 호환성 문제 등 명확한 이유가 있을 때만 검토합니다. 그 경우에도 먼저 “이 워크로드를 VM으로 분리하는 편이 더 안전한가”를 판단하는 것이 좋습니다.
고급 기능 주의사항
Proxmox VE LXC에는 Nesting, Keyctl, FUSE, mknod, mount 같은 고급 기능이 있습니다.
Container Features
├── nesting
├── keyctl
├── fuse
├── mknod
├── mount
└── force_rw_sys
기본 원칙은 필요한 기능만 최소한으로 활성화하는 것입니다.
| 기능 | 용도 | 주의사항 |
|---|---|---|
| Nesting | 내부 컨테이너 런타임·일부 systemd 격리 | 호스트 /proc, /sys 정보 노출 범위 증가 |
| Keyctl | 일부 Docker-in-LXC 구성 | Unprivileged LXC의 Docker 실행에 필요할 수 있음 |
| FUSE | 사용자 공간 파일시스템 | backup freeze와 상호작용해 I/O deadlock 위험 가능 |
mknod |
특정 장치 노드 생성 | Unprivileged LXC에서는 실험적 기능 |
mount |
특정 파일시스템 마운트 | 격리와 보안 경계에 영향 |
일반 Linux 서비스
└── 고급 기능 비활성화
특수 호환성 요구
└── 필요한 기능만 별도 검증 후 활성화
중첩 Docker·Kubernetes·장치 접근
└── VM 전환 가능성을 먼저 검토
LXC 템플릿 준비
컨테이너를 만들려면 LXC 템플릿이 필요합니다. 사용 가능한 배포판과 버전은 Proxmox VE 버전·저장소에 따라 달라질 수 있으므로 Web UI 또는 pveam available로 확인합니다.
# 온라인 템플릿 목록 갱신
pveam update
# 템플릿 검색
pveam available | grep -i debian
pveam available | grep -i ubuntu
pveam available | grep -i alpine
# 템플릿 다운로드
pveam download local debian-12-standard_<version>_amd64.tar.zst
# 다운로드한 템플릿 확인
pveam list local
Web UI에서는 다음 경로에서 템플릿을 받을 수 있습니다.
Node
└── local Storage
└── CT Templates
└── Templates
└── Download
폐쇄망에서는 외부 스테이징 환경에서 템플릿을 내려받고, 무결성 검증과 승인 절차를 거쳐 내부 Proxmox Storage에 반입합니다.
Internet-connected Staging Zone
├── Template Download
├── SHA256 Verification
├── Security Review
└── Approval
│
▼
Air-gapped Proxmox VE
└── local:vztmpl
Web UI와 CLI 생성
Web UI에서는 다음 메뉴에서 컨테이너를 생성합니다.
Node
└── Create CT
├── General
├── Template
├── Disks
├── CPU
├── Memory
├── Network
├── DNS
└── Confirm
일반적인 LXC 생성 기준은 아래와 같습니다.
| 항목 | 권장 기준 |
|---|---|
| CTID·Hostname | 서비스·환경·순번 기반 정책 |
| Template | 조직 표준 또는 검증된 Linux 템플릿 |
| Unprivileged | 기본 활성화 |
| RootFS | OS와 로그·데이터 증가량 기준 산정 |
| CPU·Memory·Swap | 실제 서비스 요구사항 기준 |
| Bridge·VLAN | 네트워크 정책에 맞게 선택 |
| IP·Gateway·DNS | 고정 IP 또는 DHCP 정책에 맞게 설정 |
| Firewall | 컨테이너 수준 정책 사용 시 활성화 |
| Start at boot | 서비스 중요도와 의존성 기준으로 선택 |
CLI 생성 예시입니다.
pct create 1001 \
local:vztmpl/debian-12-standard_<version>_amd64.tar.zst \
--hostname dns-prod-01 \
--cores 1 \
--memory 1024 \
--swap 512 \
--rootfs local-lvm:8 \
--net0 name=eth0,bridge=vmbr1,tag=20,ip=10.10.20.11/24,gw=10.10.20.1,type=veth,firewall=1 \
--nameserver 10.10.10.53 \
--searchdomain example.internal \
--unprivileged 1 \
--onboot 1 \
--start 1
컨테이너 생성 후 상태와 설정을 확인합니다.
pct list
pct status 1001
pct config 1001
pct enter 1001
다중 NIC 구성에서는 기본 게이트웨이를 일반적으로 하나만 설정합니다.
net0: Service Network
└── Default Gateway 설정
net1: Storage / Backup Network
└── Default Gateway 미설정
기본 운영과 보안
자주 사용하는 기본 명령은 아래와 같습니다.
pct start 1001
pct shutdown 1001
pct stop 1001
pct reboot 1001
pct exec 1001 -- hostnamectl
pct exec 1001 -- ip -br addr
pct exec 1001 -- systemctl --failed
pct stop은 컨테이너 프로세스를 강제 종료할 수 있으므로, 데이터가 기록 중인 서비스에는 신중하게 사용합니다.
LXC 컨테이너도 다음 보안 기준을 적용합니다.
- Unprivileged Container 우선 사용
- 불필요한 Nesting·Keyctl·FUSE·Mount 기능 비활성화
- Host 경로 Bind Mount 최소화
- SSH Key, Bastion, 사용자별 계정, 로그·감사 정책 적용
- 컨테이너·호스트 OS의 정기 업데이트
- 컨테이너 방화벽과 네트워크 분리
- 정기 백업과 실제 복구 테스트
- 중요 서비스는 VM 격리 우선 검토
Bind Mount는 편리하지만 특히 Privileged Container에서 호스트 파일 권한에 영향을 줄 수 있습니다. 가능하면 별도 Mount Point, NFS·SMB·Object Storage 같은 네트워크 스토리지, 또는 VM 분리를 먼저 검토합니다.
생성 후 체크리스트
- CTID와 Hostname이 네이밍 정책에 맞는가
- 신뢰할 수 있는 템플릿을 사용했는가
- Unprivileged Container로 생성했는가
- CPU, 메모리, Swap, RootFS가 워크로드에 맞는가
- Bridge, VLAN, IP, Gateway, DNS가 올바른가
- 기본 게이트웨이가 하나만 설정되었는가
- 불필요한 Nesting·Keyctl·FUSE가 비활성화되었는가
- SSH Key, Bastion, 방화벽, 접근 정책이 적용됐는가
- 데이터 증가 서비스는 별도 Mount Point 또는 스토리지를 검토했는가
- 백업 대상에 포함됐고, 새 CTID·격리 VLAN으로 복구 테스트를 했는가
핵심 정리
- Proxmox VE LXC는 Linux Kernel의 Namespace와 cgroup을 활용하는 시스템 컨테이너입니다.
- LXC는 독립 Linux 사용자 공간을 제공하지만 호스트 Linux Kernel을 공유하므로 VM과 같은 격리 수준은 아닙니다.
- VM은 Windows, Kubernetes Node, DB, 특수 장치, 강한 보안 경계가 필요한 서비스에 적합합니다.
- LXC는 DNS, NTP, Bastion, Reverse Proxy, Utility, 개발·테스트 같은 경량 Linux 서비스에 적합합니다.
- 일반적인 신규 컨테이너는 Unprivileged Container를 우선 사용합니다.
- Nesting, Keyctl, FUSE,
mknod, Mount 기능은 호환성을 높일 수 있지만 보안·운영 복잡도를 높일 수 있으므로 최소한으로 사용합니다. - 컨테이너 생성 시 CTID, Hostname, 템플릿, RootFS, CPU·메모리·Swap, Bridge·VLAN·IP·DNS, 방화벽, 백업을 함께 설계해야 합니다.
- LXC도 VM과 마찬가지로 패치, 모니터링, 백업, 복구, 변경 관리가 필요합니다.
참고 자료
- Proxmox VE Linux Container
- Proxmox VE pct Manual
- Proxmox VE pct.conf Manual
- Proxmox VE Unprivileged LXC Containers
- Proxmox VE FAQ