-
Notifications
You must be signed in to change notification settings - Fork 38.6k
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.
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
KEP 4216: Add changes for alpha version under RuntimeClassInImageCriApi feature gate #121456
KEP 4216: Add changes for alpha version under RuntimeClassInImageCriApi feature gate #121456
Conversation
/priority important-soon |
3539df2
to
81ddedd
Compare
81ddedd
to
6cd700a
Compare
/retest |
// Therefore, validate that image returned from ListImages() call above has a valid | ||
// runtimehandler field set; that is, it should not be "" | ||
if utilfeature.DefaultFeatureGate.Enabled(features.RuntimeClassInImageCriAPI) { | ||
if img.Spec != nil && img.Spec.RuntimeHandler == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would the CRI say the image was pulled in the default handler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand the question -
If no runtimeHandler was specified for the pod in deployment yaml, then kubelet sets the pod's runtimehandler as "" and container runtime recognizes it and uses the default runtime handler. When the feature flag is set, we expect runtime handler to set the newly added runtime handler field of ImageSpec in CRI to fill in the runtime handler that was used - this field will be filled always (for default runtime used or non-default runtime handler used)
RuntimeHandler field added to CRI in #121121
This check here is making sure that the field is set by container runtimes when the feature gate is enabled and fails if it doesn't (this will indicate a bug on the container runtime side).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should be able to show that in the mock test linked above ^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikebrow added test. Please let me know if this looks good. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am concerned about version skew policy if you require this field always be supported. Is there a reason kubelet can't consider default runtime handler the empty string ""
and not have these error conditions if the CRI doesn't return a runtime handler? For instance, CRI-O may not want to support this feature and it'd be easier to leave it empty (though trivially easy to add support if there's a design reason to not allow the CRI to leave it empty that I've missed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The admin decides if runtime class definition was changed and flushes/remove images from containerd and restarts. For kubelet a simple service restart should suffice right as it doesn't see to persist the tables that GC looks at. Not sure if node should be cordoned. Should they?
It was not immediately obvious to me that admin intervention was required. Not sure if this is a great UX but I will defer to SIG-node here.
Not sure that there is a better way to do this. If not, the existing images can be allowed to be loaded and used by containerd and eventually starting containers could fail and then user would have to flush containerd of the older images. The latter might be a painful debugging experience. There it might be better to flush containerd and restart just like in toggling the feature gate for this KEP would need manual intervention.
Alternatively, we could add an option/annotation/config on containerd side which when set in the toml causes containerd to purge and delete the images using the edited runtime class rather than loading them. Any thoughts on this last option @mikebrow @dmcgowan?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we had to make a similar concession in the cgroup driver reported by runtime KEP. Basically, it's up to the container runtime/admin to verify this information isn't changing while there are containers/images that already exist. Kubelet has no way to verify it mid run (or it would be inefficent to do so). Explicitly declaring this is a requirement of the CRI is good here, and having a mechanism in the CRI to report errors to the admin would be good to (but out of scope here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this invariant https://github.com/kubernetes/kubernetes/pull/118770/files#diff-7a3c2723dedc6b44cf183fc52f84cc4015ffbd65a998a65c3959a953cb63c945R139-R141 it's declared in the CRI definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this invariant https://github.com/kubernetes/kubernetes/pull/118770/files#diff-7a3c2723dedc6b44cf183fc52f84cc4015ffbd65a998a65c3959a953cb63c945R139-R141 it's declared in the CRI definition
This is great!
"The Kubelet will not re-request the RuntimeConfiguration after startup, and CRI implementations should avoid updating them without a full node reboot."
-- Node reboot might still not fix containerd loading previous images in containerd's store. I discussed this in the containerd community meeting this morning and we are fine with the existing invariant which is to ask admins to purge if runtimeclass name is the same but some of its fields like platform versioning and snapshotters have changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@haircommander @jsturtevant @aravindhp @mikebrow pushed new changes based on the discussion. Updated the tests as necessary.
Please let me know if it looks ok :) Thanks a lot!
personally, I am more of a fan of writing the base struct and overriding with an if statement, rather than defining the struct in two places:
and so fourth. It's a stylistic thing, and if you prefer the way it is, keep it. but if it's no different to you, I'd prefer the other way :) |
I'll make this change where applicable and push new changes. |
@kiashok Oh wait, this is with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
LGTM label has been added. Git tree hash: e0580f737b6574fa8c202a32f6967b9c9abb41d1
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: derekwaynecarr, kiashok, mikebrow The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@dims This seems like a new linter check and not sure what its complaining about: Any combination that I try is failing this linter. Other PRs that went in few hours back are starting their comments with // Owners just like the rest of this file. Do you happen to know what this linter check is about? |
@kiashok if it doesn't make sense, you can use |
This commit does the following: 1. Add RuntimeClassInImageCriApi feature gate 2. Extend pkg/kubelet/container Image struct 3. Adds runtimeHandler string in the following CRI calls i. ImageStatus ii. PullImageRequest iii. RemoveImage Signed-off-by: kiashok <[email protected]>
481a472
to
252e1d2
Compare
/lgtm |
LGTM label has been added. Git tree hash: ede380cc2bb7f41c78f93324e4fb5688e8911a10
|
@kiashok: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Trying this in my PR. I don't love this change as it goes against all the other kubelet features. But it makes sense for exported functions. |
yeah! The other PRs that went in for kubelet features, seem to have ignored this and kept to the format of the rest of the file which is // Owner followed by the rest |
I am in favor of matching the rest of the feature gates comments as it is now and letting the PR merge as is (since this isn't blocking). We should create a follow up issue to sort his out. I don't think adding the |
Opened a new github issue to fix this #121660 |
Changelog suggestion Added new feature gate `RuntimeClassInImageCriApi` to support per-RuntimeClass container image pulls
Notable changes:
1. Populate new `RuntimeHandler` field in CRI's `ImageSpec` struct during image pulls from container runtimes.
2. Pass `runtimeHandler` field in CRI `RemoveImage()` call to container runtime in kubelet's image garbage collection. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Add changes for alpha release of Image pull per runtime class feature described in KEP 4216: kubernetes/enhancements#4216
Which issue(s) this PR fixes:
Add changes for alpha release of Image pull per runtime class feature described in KEP 4216: kubernetes/enhancements#4216
Special notes for your reviewer:
Does this PR introduce a user-facing change?
NONE
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: