저자는 Docker 시험에 합격했음에도 불구하고, 실제 컨테이너 지식이 이론적 이해와 다르다는 것을 깨달았습니다. unshare 명령어로 초기 시도를 했을 때 PID 네임스페이스에 대한 오해가 드러났고, 새로운 네임스페이스 내에서 PID 1을 올바르게 설정하기 위해 --fork 플래그가 필요했습니다. 이후, 네임스페이스 내에서 /proc 파일 시스템을 다시 마운트하는 것이 ps와 같은 도구가 격리된 프로세스 계층 구조를 정확하게 반영하는 데 중요했습니다. UTS 네임스페이스 시연은 호스트 이름을 어떻게 격리할 수 있는지 보여주었고, 명확한 제어 및 처리 시나리오를 통해 개념을 증명했습니다.여정은 pivot_root로 이어졌는데, 저자는 프로세스에 자체 파일 시스템을 부여하는 것을 목표로 했습니다. 초기 장애물은 동적 연결된 BusyBox 실행 파일이 새로운 루트 파일 시스템에서 필요한 인터프리터를 사용할 수 없어 실패한 것이었습니다. 해결책은 파일 시스템 전환 중에 정적 연결된 BusyBox를 브릿지로 사용하고, 이전 명령 경로를 기억하는 Bash의 해시 캐시를 해결하는 것이었습니다. virtiofs와 심볼릭 링크 실행에 대한 Mac 특정 문제는 루트 파일 시스템을 네이티브 컨테이너 경로로 이동하여 해결되었습니다.pivot_root 작업 자체는 특정 설정이 필요했습니다. 새로운 루트는 마운트 지점이어야 했고, 실제 변경 전에 이전 루트를 별도로 준비해야 했습니다. Alpine Linux의 /etc/os-release를 표시하는 것과 같이 새로 조립된 파일 시스템 내에서 명령을 성공적으로 실행하는 것은 실질적인 보상을 제공했습니다. 마지막으로, cgroups를 파일 시스템 API로 탐색하면서 리소스 제한을 시연했고, cgroup v2에서 컨트롤러를 활성화하기 위한 "내부 프로세스 없음" 규칙을 발견했습니다.프로세스를 신중하게 대피시킨 후 부모 cgroup에서 컨트롤러를 활성화함으로써, 저자는 자식 cgroup에 대한 메모리 및 PID 제한을 성공적으로 설정했습니다. 특히 dmesg를 통해 메모리 부족(OOM) 종료 이벤트를 관찰하며 이러한 제한을 강제하는 것은 cgroups를 추상적인 설정이 아닌 직접적인 커널 파일 시스템 상호 작용으로 이해하는 것을 공고히 했습니다. 이러한 실습 경험은 Kubernetes Pod를 명확하게 보여주었고, 네임스페이스, 파일 시스템 격리, cgroups와 같은 기본 Linux 기본 요소의 구성된 구현으로 드러냈습니다. 결과적으로 Docker, containerd, Kubernetes와 같은 컨테이너화 도구는 브랜드 제품에서 이러한 핵심 스크립트의 구조화된 배열로 변모했습니다.