Pod-level Checkpoint/Restore

This proposal defines CRI APIs, kubelet support, and controllers together with Kubernetes objects for managing the lifecycle and artifacts of these operations to enable native support for Pod-level checkpoint and restore. The scope of the proposal is limited to warm start and fault-tolerance use cases, with outline of the API design to accommodate other use cases such as suspend/resume (with IP preservation) and live migration (streaming checkpoint data between nodes). These use cases will be addressed in future KEPs. The core idea is to outline the minimal set of Container Runtime Interface (CRI) and kubelet extensions required for Pod-level checkpoint and restore, and to provide a clear path for iteratively building on top of these APIs to address the broader set of use cases and requirements. In this KEP, checkpoints represent the runtime state of a Pod, where the checkpoint format and low-level implementation details are left to the container runtime (e.g., containerd, CRI-O), the OCI runtime (runc, crun), and the underlying checkpoint/restore mechanism (e.g., CRIU, gVisor). While Pod-level checkpointing is inspired by the existing [kubelet checkpoint] API and extends that container checkpointing mechanism to Pods, the restore functionality is a larger addition as Kubernetes currently supports container restore only via [OCI image annotations]. This proposal defines Pod-level checkpoint and restore as a single, cohesive feature as checkpointing without restore would be incomplete and impractical for the use cases motivating this work.