Skip to content

KEP-2008: changed to target 1.25 #3264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 31, 2022
Merged

KEP-2008: changed to target 1.25 #3264

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 21 additions & 7 deletions keps/sig-node/2008-forensic-container-checkpointing/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
- [Non-Goals](#non-goals)
- [Proposal](#proposal)
- [Implementation](#implementation)
- [CRI Updates](#cri-updates)
- [User Stories](#user-stories)
- [Risks and Mitigations](#risks-and-mitigations)
- [Design Details](#design-details)
Expand Down Expand Up @@ -65,7 +66,7 @@ will not be aware of any sandboxed analysis.

### Goals

The goal of this KEP is to introduce *checkpoint* and *restore* to the CRI API.
The goal of this KEP is to introduce *checkpoint* to the CRI API.
This includes extending the *kubelet* API to support checkpointing single
containers with the forensic use case in mind.

Expand Down Expand Up @@ -106,13 +107,24 @@ For the first implementation we do not want to support restore in the
outside of Kubernetes. The restore is a container engine only operation
in this first step.

The forensic use case is targeted to be part of the next (1.24) release.
#### CRI Updates

Although this KEP only adds checkpointing support to the kubelet the CRI API in
the corresponding code pull request is extended to support *checkpoint* and
*restore* in the CRI API. The reason to add *restore* to the CRI API without
implementing it in the kubelet is to make development and especially testing
easier on the container engine level.
The CRI API will be extended to introduce one new RPC:
```
// CheckpointContainer checkpoints a container
rpc CheckpointContainer(CheckpointContainerRequest) returns (CheckpointContainerResponse) {}
```
with the following parameters:
```
message CheckpointContainerRequest {
Copy link
Member

@mikebrow mikebrow May 24, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs a security statement / set of requirements for this service, validating the request and destination are authorized. see https://github.com/kubernetes/enhancements/pull/1990/files#r798031530

Copy link
Member Author

@adrianreber adrianreber May 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikebrow Thanks for helping with this KEP. Can you be more specific what you would expect here. Looking at @derekwaynecarr comment on the original KEP it says:

please add detail on checkpoint authorization, we will need to restrict access to the kubelet api resource.

on the container runtime, the actual checkpoint is stored in a location is restricted, but prior to beta, we need clear security practices documented.

Are there already other kubelet API resources which have this kind of authorization? Accessing the kubelet API is not possible without access to the certificates as far as I understand it. Do we need additional authorization? If there is an existing mechanism I am happy to include this. If there is any authorization available on the kubelet API I am not sure I have the necessary understanding of the kubelet to introduce something like that.

// ID of the container to be checkpointed.
string container_id = 1;
// Location of the checkpoint archive used for export/import
string location = 2;
}

message CheckpointContainerResponse {}
```

### User Stories

Expand Down Expand Up @@ -268,6 +280,8 @@ does not compress the checkpoint archive on disk.
* 2021-09-22: Removed everything which is not directly related to the forensic use case
* 2022-01-06: Reworked based on review
* 2022-01-20: Reworked based on review and renamed feature gate to `ContainerCheckpoint`
* 2022-04-05: Added CRI API section and targeted 1.25
* 2022-05-17: Remove *restore* RPC from the CRI API

## Drawbacks

Expand Down
10 changes: 5 additions & 5 deletions keps/sig-node/2008-forensic-container-checkpointing/kep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ participating-sigs:
- TBD
status: implementable
creation-date: 2020-09-16
last-updated: 2022-01-20
last-updated: 2022-05-17
reviewers:
- "@mrunalp"
- "@elfinhe"
Expand All @@ -22,13 +22,13 @@ stage: alpha
# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.24"
latest-milestone: "v1.25"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
alpha: "v1.24"
beta: "v1.25"
stable: "v1.27"
alpha: "v1.25"
beta: "v1.26"
stable: "v1.28"

# The following PRR answers are required at alpha release
# List the feature gate name and the components for which it must be enabled
Expand Down