Nested Containersとコンテナランタイム ～なぜyoukiはruncと異なる設計を選んだか

デファクトスタンダードの実装がいつも最善の設計とは限りません。
時に後発のOSSが異なる設計を選び、品質と信頼性を高めることで、採用を検討できるOSSの選択肢を増やすことも、エコシステム全体を『共にスケール』させる一歩です。

Dockerのrunc代替としてyoukiを継続利用していたところ、KinDなどのNested Containersで`exec`が`Device or resource busy`エラーで失敗しました。
未実装だった対処を自ら実装する中で、runcが失敗後にinit processのcgroupへフォールバックする実装で対処していた一方、youkiでは所属すべきcgroupを先に推定する実装を選びました。
この設計はruncとの互換性を一部失いますが、維持する互換性と許容する差分を、実装・テストと双方のメンテナーとの議論で決めました。

本セッションでは、runcを踏襲した初期案から、実装と議論を経て独自案へ至った経緯と設計判断をお伝えします。
どの互換性を維持し、何を捨てたのかを知ることで、新たな選択肢を生む設計視点を持ち帰っていただければ幸いです。