Linux Namespace & cgroup

같은 호스트에서 여러 프로세스를 돌릴 때, 서로의 프로세스 목록과 포트, 마운트 지점을 모두 보게 두면 충돌과 보안 문제가 생깁니다. 한 서비스가 메모리를 과하게 쓰면 다른 서비스까지 함께 느려지는 문제도 피할 수 없습니다. 컨테이너가 안전하게 공존하려면 관찰 범위와 자원 사용량을 동시에 제어해야 합니다.

컨테이너가 갑자기 생겨난 새 발명이라기보다, 오래전부터 리눅스 커널에 있던 기능들을 조합해 개발자가 쓰기 쉬운 형태로 감싼 결과에 가깝습니다. 초기에는 LXC 같은 도구가 직접 namespace를 묶어 노출했고, 이후 Docker가 이미지와 빌드, 배포 경험까지 한 번에 묶으면서 대중화했습니다. 컨테이너 붐의 밑바탕에는 커널의 격리 기능 축적이 있었습니다.

PID namespace는 컨테이너 안의 프로세스 번호를 분리해 각 컨테이너가 자신만의 PID 1을 갖게 만듭니다. NET namespace는 별도 네트워크 스택과 인터페이스를 제공하고, MNT namespace는 마운트 지점과 파일시스템 보기를 나눕니다. cgroup은 이와 별도로 CPU 시간, 메모리, I/O 사용량을 추적하고 제한해 한 컨테이너의 폭주가 전체 호스트로 번지는 것을 막습니다.

Namespace·cgroup은 컨테이너와 같은 수준의 배포 단위가 아닙니다. 컨테이너는 이미지, 네트워크, 볼륨, 실행 명령까지 포함한 운영 개념이고, namespace·cgroup은 그 운영 개념 밑에서 격리와 제어를 제공하는 커널 부품입니다. 따라서 컨테이너를 직접 다루는 CLI와 커널 메커니즘을 같은 층위로 비교하면 역할이 흐려집니다.

장애 분석에서는 컨테이너 안에서 보이는 PID와 호스트에서 보이는 PID가 왜 다른지, 메모리 제한을 넘겼을 때 왜 OOM이 나는지를 이 개념으로 설명하게 됩니다. 런타임 설정에서 `--cpus`, `--memory` 같은 옵션이 실제로 무엇을 건드리는지 이해하면, 단순한 옵션 암기가 아니라 격리 정책으로 읽히기 시작합니다.