コンテナは嘘である — cgroupsとネームスペースで見るカーネルの真実

        「コンテナ」という幻想
  +--------------------------------------+
  |  実はただのLinuxプロセス              |
  |                                      |
  |  + ネームスペース (隔離: 何が見えるか) |
  |    pid, net, mnt, uts, ipc,          |
  |    user, cgroup, (time)              |
  |                                      |
  |  + cgroups (制限: どれだけ使えるか)    |
  |    cpu, memory, io, pids ...         |
  |                                      |
  |  + セキュリティ層 (権限: 何ができるか) |
  |    capabilities, seccomp,            |
  |    LSM (SELinux/AppArmor)            |
  |                                      |
  |  + ルートファイルシステム              |
  |    (overlayfsイメージ)               |
  +--------------------------------------+
            |
            v
     全員が1つのホストカーネルを共有
     (VMとの根本的な違い)

# 1) uts: 最も簡単なネームスペース。ホスト名の隔離
sudo unshare --uts bash
hostname container-test   # ホストのhostnameは変わらない
hostname                  # container-test
exit

# 2) pid: PID空間の隔離。--forkと--mount-procが鍵
sudo unshare --pid --fork --mount-proc bash
echo $$                   # 1  <- このシェルがPID 1
ps aux                    # プロセスが2〜3個しか見えない
exit

# 3) net: 空のネットワークスタックができる
sudo unshare --net bash
ip link                   # loが1つだけ、しかもDOWN状態
exit

# 4) mnt: マウントツリーの隔離
sudo unshare --mount bash
mount -t tmpfs tmpfs /mnt # ホストには見えないマウント
findmnt /mnt
exit

# 5) ipc: 共有メモリの隔離
ipcmk -M 1024             # ホストで共有メモリ作成
sudo unshare --ipc bash
ipcs -m                   # 見えない (隔離済み)
exit

# 6) user: 非rootユーザーが「ネームスペース内でだけroot」
unshare --user --map-root-user bash   # sudo不要!
id                        # uid=0(root) ... しかし
cat /proc/self/uid_map    # 0 <自分のUID> 1 形式のマッピングを確認
exit

# 7) cgroup: cgroupパスの視界の隔離
sudo unshare --cgroup bash
cat /proc/self/cgroup     # ルート(/)のように見える
exit

unshare --user --map-root-user --pid --fork --mount-proc \
        --net --uts --ipc --cgroup bash

   コンテナ内の視界              ホストの真実
  +----------------+          +---------------------+
  | uid 0 (root)   |  ----->  | uid 100000 (無権限) |
  | uid 1 (daemon) |  ----->  | uid 100001          |
  | ...            |          | ...                 |
  | uid 65535      |  ----->  | uid 165535          |
  +----------------+          +---------------------+

  /etc/subuid、/etc/subgid がマッピング可能な範囲を定義
  newuidmap/newgidmap ヘルパーがマッピングを記録

# ホストでマッピング範囲を確認
cat /etc/subuid    # 例: youngju:100000:65536
cat /etc/subgid

# 実行中のプロセスのマッピング確認 (実際のPIDに置き換えて)
cat /proc/12345/uid_map

   /sys/fs/cgroup            (ルート、cgroup2マウント)
   |-- cgroup.controllers     使用可能なコントローラの一覧
   |-- cgroup.subtree_control 子に委譲するコントローラ
   |-- system.slice/          systemdサービス
   |-- user.slice/            ログインセッション
   +-- kubepods.slice/        KubernetesのPod
       +-- kubepods-burstable.slice/
           +-- kubepods-burstable-pod<hash>.slice/
               +-- cri-containerd-<hash>.scope/
                   |-- cpu.max
                   |-- memory.max
                   |-- io.max
                   +-- pids.max

# 新しいcgroupの作成とコントローラの有効化
sudo mkdir /sys/fs/cgroup/lab
echo "+cpu +memory +io +pids" | sudo tee /sys/fs/cgroup/cgroup.subtree_control

# cpu: 100ms周期あたり20ms = 0.2 CPU
echo "20000 100000" | sudo tee /sys/fs/cgroup/lab/cpu.max

# memory: ソフト圧迫ライン192MiB、ハード上限256MiB
echo "201326592" | sudo tee /sys/fs/cgroup/lab/memory.high
echo "268435456" | sudo tee /sys/fs/cgroup/lab/memory.max

# pids: フォークボム防止
echo 128 | sudo tee /sys/fs/cgroup/lab/pids.max

# 現在のシェルを入れて確認
echo $$ | sudo tee /sys/fs/cgroup/lab/cgroup.procs
cat /sys/fs/cgroup/lab/memory.current   # 現在の使用量
cat /sys/fs/cgroup/lab/cpu.stat         # usage、nr_throttled
cat /sys/fs/cgroup/lab/memory.events    # low/high/max/oom/oom_kill回数

# メモリ圧迫の正直な指標: PSI
cat /sys/fs/cgroup/lab/memory.pressure
# some avg10=12.34 ... 一部のタスクがメモリ待ちに時間を使った
# full avg10=3.21  ... すべてのタスクが同時に停止 (深刻)

#!/bin/bash
# mini-container.sh — unshare + pivot_root + cgroup の結合
# 事前準備: ルートFS (例: alpineミニルートFSを展開したディレクトリ)
set -euo pipefail

ROOTFS=/opt/rootfs-alpine
CG=/sys/fs/cgroup/minic

# 1) cgroupの準備: 0.5 CPU、256MiB、プロセス64個
mkdir -p "$CG"
echo "50000 100000" > "$CG/cpu.max"
echo "268435456"    > "$CG/memory.max"
echo 64             > "$CG/pids.max"

# 2) ネームスペースを作り、その中でセットアップスクリプトを実行
exec unshare --pid --fork --mount --uts --ipc --net bash -c '
  set -euo pipefail
  ROOTFS=/opt/rootfs-alpine

  # 2-1) 自分をcgroupに登録
  echo $$ > /sys/fs/cgroup/minic/cgroup.procs

  # 2-2) ホスト名
  hostname minic

  # 2-3) マウント伝播の遮断 (ホスト汚染の防止)
  mount --make-rprivate /

  # 2-4) pivot_rootの準備: new_rootはマウントポイントである必要がある
  mount --bind "$ROOTFS" "$ROOTFS"
  cd "$ROOTFS"
  mkdir -p old_root

  # 2-5) ルートの交換。chrootと違い脱出が難しい
  pivot_root . old_root

  # 2-6) 新ルート基準の必須仮想ファイルシステム
  mount -t proc  proc  /proc
  mount -t tmpfs tmpfs /tmp

  # 2-7) 旧ルートへのアクセス遮断
  umount -l /old_root
  rmdir /old_root

  # 2-8) コンテナのinitを実行
  exec /bin/sh
'

// minic.go — Goで作るミニコンテナ (概念検証用)
package main

import (
	"fmt"
	"os"
	"os/exec"
	"path/filepath"
	"syscall"
)

func main() {
	switch os.Args[1] {
	case "run": // 親: ネームスペースを持って自分自身を再実行
		parent()
	case "child": // 子: 新しいネームスペース内でセットアップ
		child()
	default:
		panic("usage: minic run <cmd>")
	}
}

func parent() {
	cmd := exec.Command("/proc/self/exe",
		append([]string{"child"}, os.Args[2:]...)...)
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWPID | syscall.CLONE_NEWNS |
			syscall.CLONE_NEWUTS | syscall.CLONE_NEWIPC |
			syscall.CLONE_NEWNET,
	}
	cmd.Stdin, cmd.Stdout, cmd.Stderr = os.Stdin, os.Stdout, os.Stderr
	if err := cmd.Run(); err != nil {
		fmt.Println("error:", err)
		os.Exit(1)
	}
}

func child() {
	rootfs := "/opt/rootfs-alpine"

	// cgroup登録 (v2ファイルインターフェースそのまま)
	cg := "/sys/fs/cgroup/minic"
	os.MkdirAll(cg, 0755)
	os.WriteFile(filepath.Join(cg, "memory.max"),
		[]byte("268435456"), 0644)
	os.WriteFile(filepath.Join(cg, "pids.max"), []byte("64"), 0644)
	os.WriteFile(filepath.Join(cg, "cgroup.procs"),
		[]byte(fmt.Sprint(os.Getpid())), 0644)

	syscall.Sethostname([]byte("minic"))

	// マウント伝播の遮断 + pivot_root
	syscall.Mount("", "/", "", syscall.MS_REC|syscall.MS_PRIVATE, "")
	syscall.Mount(rootfs, rootfs, "", syscall.MS_BIND, "")
	os.MkdirAll(rootfs+"/old_root", 0700)
	syscall.PivotRoot(rootfs, rootfs+"/old_root")
	os.Chdir("/")
	syscall.Mount("proc", "/proc", "proc", 0, "")
	syscall.Unmount("/old_root", syscall.MNT_DETACH)
	os.Remove("/old_root")

	// ユーザーが与えたコマンドを実行
	cmd := exec.Command(os.Args[2], os.Args[3:]...)
	cmd.Stdin, cmd.Stdout, cmd.Stderr = os.Stdin, os.Stdout, os.Stderr
	cmd.Run()
}

go build -o minic minic.go
sudo ./minic run /bin/sh
# 中で: hostname -> minic、ps aux -> PID 1から、ip link -> loのみ

   コンテナが見るファイルシステム (merged)
  +------------------------------------+
  |  /bin/sh   /etc/app.conf   /tmp/x  |
  +------------------------------------+
      ^ 合成された単一ビュー
      |
  upperdir (書き込み可能、コンテナレイヤー)   <- 変更分だけ記録
  +------------------------------------+
  |  /etc/app.conf (修正版)  /tmp/x    |
  +------------------------------------+
  lowerdir (読み取り専用、イメージレイヤー群)  <- 複数重ねられる
  +------------------------------------+
  |  layer3: アプリのバイナリ           |
  |  layer2: ランタイム/ライブラリ      |
  |  layer1: ベースOS                  |
  +------------------------------------+

  - 読み取り: 上から探索、最上位のファイルが勝つ
  - 書き込み: lowerdirのファイル修正時はupperdirへコピーしてから修正
              (copy-up)
  - 削除:     upperdirにwhiteoutマーカーを作成 (実際には消えない)

# overlayfsの直接実習
mkdir -p /tmp/ov/lower /tmp/ov/upper /tmp/ov/work /tmp/ov/merged
echo "from-image" > /tmp/ov/lower/base.txt
sudo mount -t overlay overlay \
  -o lowerdir=/tmp/ov/lower,upperdir=/tmp/ov/upper,workdir=/tmp/ov/work \
  /tmp/ov/merged

echo "modified" > /tmp/ov/merged/base.txt   # copy-up発生
cat /tmp/ov/lower/base.txt                  # from-image (原本保存)
cat /tmp/ov/upper/base.txt                  # modified (変更分)

# 現在のプロセスのケーパビリティ確認
capsh --print
grep Cap /proc/self/status   # CapEffが有効ケーパビリティのビットマスク
capsh --decode=00000000a80425fb   # ビットマスクの解読

# ファイルへのケーパビリティ付与 (setuid rootの代替)
sudo setcap cap_net_bind_service=+ep ./myserver  # 80番ポートのバインドだけ許可

# Kubernetes: すべて捨てて必要なものだけ追加するのが模範
securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
  allowPrivilegeEscalation: false

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "openat", "close", "fstat",
                 "mmap", "brk", "exit_group", "futex", "epoll_wait"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

# プロセスのseccomp状態: 0 なし、1 strict、2 filter
grep Seccomp /proc/self/status

# Kubernetesでランタイム既定プロファイルを適用
# securityContext.seccompProfile.type: RuntimeDefault

  kubelet
    | CRI (gRPC)
    v
  containerd          イメージのpull/保存、スナップショット(overlayfs)、
    |                  コンテナのライフサイクル
    | OCIスペック (config.json)
    v
  runc                この記事で扱ったすべての実行者:
                      ネームスペース作成、cgroup設定、pivot_root、
                      capabilities適用、seccompロード、プロセスexec
                      -- 実行後は消える (デーモンではない)

# 実行中のコンテナのOCI設定を覗く
sudo cat /run/containerd/io.containerd.runtime.v2.task/k8s.io/*/config.json \
  | jq '.linux.namespaces, .process.capabilities.effective' | head -30

stat -fc %T /sys/fs/cgroup    # cgroup2fs ならv2

# 1) lsns: ホストの全ネームスペースを列挙
lsns                       # タイプ別ネームスペースと代表PID
lsns -t net                # netネームスペースのみ

# 2) nsenter: 特定プロセスのネームスペースへ進入
PID=$(pgrep -f my-app | head -1)
nsenter -t "$PID" -n ss -tlnp      # そのコンテナのnet nsでソケットを見る
nsenter -t "$PID" -m -p ps aux     # mnt+pid nsでプロセスを見る
nsenter -t "$PID" -a bash          # すべて進入 (事実上のexec)
# デバッグツールのないdistrolessコンテナもnsenterで調査可能
# (バイナリはホストのものを使い、視界だけコンテナへ)

# 3) /procでネームスペースIDを直接比較
ls -l /proc/$$/ns/         # 各nsのinode番号
ls -l /proc/"$PID"/ns/     # 同じinode = 同じネームスペース

# 4) cgroupパスの追跡: プロセス -> cgroup -> 上限/使用量
cat /proc/"$PID"/cgroup    # cgroupパスの確認
CG=/sys/fs/cgroup$(cut -d: -f3 /proc/"$PID"/cgroup)
cat "$CG/memory.current" "$CG/memory.max" "$CG/memory.events"
cat "$CG/cpu.stat" | grep -E "usage|throttled"
cat "$CG/memory.pressure" "$CG/cpu.pressure"   # PSI

# 5) OOM Killの事後分析
dmesg -T | grep -i -A5 "killed process"
journalctl -k | grep -i oom