著者はDocker試験に合格したにもかかわらず、実践的なコンテナ知識は理論的な理解とは異なると認識しました。unshareコマンドでの最初の試みは、PID名前空間の誤解を明らかにし、新しい名前空間内にPID 1を正しく確立するために--forkフラグが必要でした。その後、名前空間内で/procファイルシステムを再マウントすることが、psのようなツールが分離されたプロセス階層を正確に反映するために不可欠でした。UTS名前空間のデモンストレーションは、ホスト名をどのように分離できるかを示し、明確な制御と処置のシナリオで概念を証明しました。旅はpivot_rootで続きました。著者はプロセスに独自のファイルシステムを与えることを目指しました。最初の障害は、動的にリンクされたBusyBox実行可能ファイルが、新しいルートファイルシステムにその必要なインタープリタが利用できなかったために失敗したことでした。解決策は、ファイルシステム遷移中に静的にリンクされたBusyBoxをブリッジとして使用し、古いコマンドパスを記憶していたBashのハッシュキャッシュに対処することでした。virtiofsとシンボリックリンクの実行に関するMac固有の問題は、ルートファイルシステムをネイティブコンテナパスに移動することで解決されました。pivot_root操作自体には特定のセットアップが必要でした。新しいルートはマウントポイントである必要があり、実際の変更の前に古いルートは別途準備する必要がありました。Alpine Linuxの/etc/os-releaseを表示するなど、新しく組み立てられたファイルシステム内でコマンドを正常に実行することは、具体的な成果をもたらしました。最後に、ファイルシステムAPIとしてのcgroupsを探索することでリソース制限が実証され、cgroup v2でコントローラーを有効にするための「内部プロセスなし」のルールが明らかになりました。プロセスを慎重に退避させてから、親cgroupでコントローラーを有効にすることで、著者は子cgroupのメモリとPID制限を正常に設定しました。これらの制限を強制すること、特にdmesgを介してメモリ不足（OOM）キルイベントを観察することは、cgroupsを抽象的な設定ではなく、直接的なカーネルファイルシステムインタラクションとして理解することを固めました。この実践的な経験は、Kubernetes Podの謎を解き明かし、それらがこれらの基本的なLinuxプリミティブ（名前空間、ファイルシステム分離、cgroups）の整理された実装であることを明らかにしました。その結果、Docker、containerd、Kubernetesのようなコンテナ化ツールは、ブランド製品からこれらのコアスクリプトの構造化された配置へと変貌しました。