컨테이너의 환상 제거, OS 커널 수준의 정체 파헤치기

Context

컨테이너를 독립된 OS나 가상 머신으로 오해하는 기술적 혼동 존재. 마케팅 용어로 인해 실제 커널 동작 원리에 대한 엔지니어의 이해도 부족. 프로세스 격리와 자원 제한의 실제 구현 메커니즘 파악 필요.

Technical Solution

• 컨테이너를 Namespace를 통한 시야 제한과 cgroup을 통한 자원 상한선이 적용된 일반 프로세스로 정의
• Podman과 같은 도구가 OCI Runtime(crun, runc)을 통해 clone() 및 execve() 시스템 콜을 호출하는 실행 흐름 설계
• Image를 읽기 전용 파일 시스템 레이어와 JSON 설정 파일의 조합인 불변의 청사진으로 분리
• PID 1을 독립된 OS의 init 시스템이 아닌 PID Namespace 내의 상대적 식별자로 처리
• /sys/fs/cgroup 경로를 통해 커널이 메모리와 PID 수를 직접 제어하는 자원 강제 방식 적용
• conmon 프로세스를 배치하여 컨테이너의 stdio 유지 및 종료 코드를 보고하는 모니터링 구조 구축

Impact

• Memory 512 MiB 제한 및 PIDs Limit 100개 설정의 커널 수준 강제 적용 확인

Key Takeaway

컨테이너는 가상화 기술이 아닌 커널의 격리 기능과 자원 제한을 조합한 프로세스 제어 전략임. 런타임은 설정 단계의 도구일 뿐 실제 제어권은 호스트 커널에 있음.