Mac mini M4 で Kind／minikube を回すと壁は多くの場合 入れ子 containerd の pull と RTT。CPU／mem クォートが Pod バースト上限。表で並列・containerd・上限・タイムアウト層を整理し批処理／対話型を分岐。Docker／Podman 稿、本番稿 と併読。料金・購入・ヘルプはログイン不要。
シナリオ
典型：Linux 横の macOS、Apple Silicon 検証、購入前ステージング。痛み：入れ子 pull 嵐（ノード毎 containerd、扇 apply で APFS 飽和）、クォート死角（LimitRange 欠で allocatable 枯渇）、タイムアウト一本化（pull／Ready／期限が混ざる）。
批処理＝事前 pull・digest・少数 Pod に CPU 集中。対話型＝短い startupProbe と低並列 pull。遅延は TCO 稿。
ノード選定
Kind＝多ノード演習、containerd と統合メモリ圧がノード数に近い。minikube＝単一 API で Helm 反復。16GB は Kind ワーカ1＋控えめクォート、24GB はワーカ2まで検討しホスト用に約4GB余白。
5 手順：（1）内蔵 SSD にルート （2）レジストリ共置は TCO 稿 と整合 （3）共有タグを脚本で先 pull （4）Helm 前に ResourceQuota／LimitRange （5）kubectl describe pod で pull／サンドボックスを先に見る。
パラメータマトリクス
入れ子 containerd（Docker Desktop／Colima 背後）向けの出発帯。実測で再調整。
| ワークロードプロファイル | イメージ並列取得（層） | containerd 設定の要点 | メモリ／CPU 上限（目安） | タイムアウト |
|---|---|---|---|---|
| 対話型開発 | ノードあたり層 2〜3 並列；冷起動でレプリカ扇を避ける | hosts.toml ミラー；snapshotter 上限はディスク温まってから |
16GB：mem req 合計〜12GB、CPU req 〜10 相当＋kube-system | pull〜600s；startupProbe 合計〜30s |
| CI シャード | 重タグ直列→小層 4〜6 並列 | 層破棄可なら有効化；config_path で近傍レジストリ固定 |
24GB：NS あたり CPU req 合計 8、mem req 合計〜14GB 上限帯 | pull／liveness 分離；Ready〜180s；deadline＝実測＋40% |
| 夜間バッチ | 大層は 1〜2 ストリーム；チャート間に間隔 | 一時イメージ preload；IO 待ちのみなら並列 unpack を弱める | 重いドライバ：CPU≥4・mem≥10GB 要求、kubelet 用に 2CPU 未要求で残す | deadline は時間単位；pull 猶予長 RTT で〜1200s＋アラート |
アンカー：APFS 空き 15%、長 RTT は pull>15 分を疑う、安定まで Pod 作成 〜20/分。
トラブルシュート FAQ
緑でも進まない→層展開、describe 先。Desktop↔Colima→メンテでルート移し再計測。cgroup→limits.cpu は硬い、バッチは大きめ 1 Pod。SSH／VNC。