|
| 1 | + |
| 2 | +# WG Checkpoint Restore Charter |
| 3 | + |
| 4 | +This charter adheres to the conventions described in the [Kubernetes Charter README] and uses |
| 5 | +the Roles and Organization Management outlined in [sig-governance]. |
| 6 | + |
| 7 | +## Scope |
| 8 | + |
| 9 | +The Checkpoint/Restore Working Group aims to solve the problem of transparently |
| 10 | +checkpointing and restoring workloads in Kubernetes, a functionality discussed |
| 11 | +for over five years. The group will deliver the design and implementation of |
| 12 | +Checkpoint/Restore functionality in Kubernetes, serving as a central hub for |
| 13 | +community information and discussion. This initiative addresses a wide range of |
| 14 | +problems, including fault tolerance, improved resource utilization, and |
| 15 | +accelerated application startup times. |
| 16 | + |
| 17 | +### In scope |
| 18 | + |
| 19 | +- Identify core Kubernetes checkpoint/restore use cases (e.g., live migration, |
| 20 | + fault tolerance, debugging, snapshotting) and gather stakeholder requirements. |
| 21 | +- Investigate and propose Kubernetes APIs for checkpoint/restore operations. |
| 22 | +- Work with SIGs for the best integration of checkpoint/restore functionality |
| 23 | + and APIs. |
| 24 | +- Provide guidance for developers on checkpoint-friendly app design and |
| 25 | + recommendations for operators on feature management. |
| 26 | +- Work closely with relevant upstream projects (CRI-O, containerd, CRIU) |
| 27 | + for alignment and integration. |
| 28 | +- Revisit the existing implementations to find and remedy possible inefficiencies. |
| 29 | + One example is the existing checkpoint archive format which has already been |
| 30 | + identified as being a major source of slowdown. |
| 31 | + |
| 32 | +### Out of scope |
| 33 | + |
| 34 | +- Not focused on general OS-level checkpointing outside Kubernetes |
| 35 | + pods/containers. |
| 36 | +- Will not dictate internal application checkpointing logic; focuses on |
| 37 | + Kubernetes platform orchestration of *container/pod state. |
| 38 | + |
| 39 | +## Stakeholders |
| 40 | + |
| 41 | +Stakeholders in this working group span multiple SIGs that own parts of the |
| 42 | +code in core kubernetes components and addons. |
| 43 | + |
| 44 | +- SIG CLI |
| 45 | +- SIG API Machinery |
| 46 | +- SIG Node |
| 47 | +- SIG Scheduling |
| 48 | +- SIG Auth |
| 49 | + |
| 50 | +## Deliverables |
| 51 | + |
| 52 | +The list of deliverables include the following high level features: |
| 53 | + |
| 54 | +- In the early stage, we mainly want to offer a well-defined location for the |
| 55 | + community to find information, ask questions, and discuss the next steps of |
| 56 | + enabling checkpoint and restore in Kubernetes. |
| 57 | + |
| 58 | +Later: |
| 59 | + |
| 60 | +- Ability to checkpoint and restore a container using kubectl |
| 61 | +- Ability to checkpoint and restore a pod using kubectl |
| 62 | +- Integration of container/pod checkpointing in scheduling decisions |
| 63 | + |
| 64 | +## Roles and Organization Management |
| 65 | + |
| 66 | +This WG adheres to the Roles and Organization Management outlined in [wg-governance] |
| 67 | +and opts-in to updates and modifications to [wg-governance]. |
| 68 | + |
| 69 | +[wg-governance]: /committee-steering/governance/wg-governance.md |
| 70 | + |
| 71 | +Additionally, the WG commits to: |
| 72 | + |
| 73 | +- maintain a solid communication line between the Kubernetes groups and the |
| 74 | + wider CNCF community |
| 75 | +- submit a proposal to the KubeCon/CloudNativeCon maintainers track |
| 76 | + |
| 77 | +## Timelines and Disbanding |
| 78 | + |
| 79 | +As a first mandate, the WG will define a roadmap and tasks in the first quarter |
| 80 | +of operation. |
| 81 | + |
| 82 | +After that the WG will distribute the different tasks to different community |
| 83 | +members to define possible APIs and how it can be integrated in Kubernetes. |
| 84 | + |
| 85 | +Achieving the aforementioned deliverables, also mentioned in the `In Scope` |
| 86 | +section, will allow us to decide when to disband this WG. There is no |
| 87 | +expectations that the Working Group will be converted into a SIG long term. |
| 88 | + |
| 89 | +[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md |
| 90 | +[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md |
0 commit comments