-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Select entrypoint command based on runtime platform #4420
Conversation
|
The following is the coverage report on the affected files.
|
e208b39
to
f30d280
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
aafc270
to
0959669
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test check-pr-has-kind-label |
The following is the coverage report on the affected files.
|
/easycla |
The following is the coverage report on the affected files.
|
18a2c99
to
e7d02c9
Compare
The following is the coverage report on the affected files.
|
I've managed to appease EasyCLA, just needs an approval @vdemeester @afrittoli 🙏 |
The following is the coverage report on the affected files.
|
/test check-pr-has-kind-label This also needs a kick and I'm not sure it'll listen to me, but YOLO /lgtm |
/test check-pr-has-kind-label |
1 similar comment
/test check-pr-has-kind-label |
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.
One nit comment on a comment, otherwise, looking very good 😬
/lgtm
The following is the coverage report on the affected files.
|
/lgtm |
/test check-pr-has-kind-label |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc, mattmoor 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 |
/kind bug |
@imjasonh: The following test failed, say
Full PR test history. Your PR dashboard. 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. |
1 similar comment
@imjasonh: The following test failed, say
Full PR test history. Your PR dashboard. 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. |
This fixes a long-standing bug affecting heterogenous clusters, where the controller's platform would be used to lookup the image's entrypoint, instead of the platform of the node where the workload would eventually run.
With this change, the controller looks up all the image's entrypoints and passes them to the entrypoint binary on the node, where it uses its current runtime platform to lookup the correct entrypoint to execute.
This has the added benefit that we can now pass the entire image@digest of the multi-platform image down to the Pod, instead of the (controller's) platform-specific image. This has benefits for scenarios where Pods may be blocked from running unsigned/untrusted images, since it might be the multi-platform image index that's signed/trusted, and not any particular platform-specific constituent image.
NB: There is still a small bug here with Windows images specifically. If a multi-platform image contains multiple entries for the same OS+arch+variant, but with different
osversion
, likegolang
for instance, this change may not select the right command, and may instead take the last matching platform'scommand
instead of the "correct" one for the runtime platform. When that happens, the "correct" image will be selected for the runtime node's platform (takingosversion
into account), but will use the "incorrect" image'scommand
. In practice, every image I could find that's in this state has the same command for allosversion
s, so it's moot. But it's possible a multi-platform image will tickle this bug. The "good" news is that this bug also existed in the previous incarnation of the code -- the code would select thecommand
for the first matching platform (not taking into accountvariant
orosversion
), then would pass it to the runtime node which may expect a possibly-differentcommand
. To fix this bug, you'd need to include theosversion
in the command map key, and (somehow) detect the node'sosversion
from the entrypoint binary at runtime, to select the correct platform (includingosversion
). In practice AFAIK this never happened, but just in case, it's worth calling out while I'm still thinking about it, in case something fishy happens on Windows clusters in the future, this comment might be useful to someone. If you're reading this and nodding in excitement that I might be describing your bug, may god have mercy on your soul.Fixes #4299
/kind bug
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes
cc @mattmoor