-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Leverage docker labels to construct container statuses without consulting pod spec #15089
Comments
/cc @kubernetes/rh-cluster-infra |
cc/ @taotaotheripper Lantao, I am assigning this to you. |
cc/ @yifan-gu on RKT support side. |
sgtm. FWIW, appc has similar concept called annotations Once we have apis to read them from rkt, we don't have to store everything in service files. |
I just put restart count into docker label last week in #15965. |
@Random-Liu: Thanks for working on this! Looking forward to those patches. |
@vishh Thank you, I'll keep working! :) |
I put pod full name into docker label and add label filter in GetPodStatus() in #16414. |
Progress Update At least till now, the best solution is to add labels on running containers, but docker doesn't support that yet. I submitted an issue in docker community moby/moby#17457. And there is also related discussion moby/moby#15496. Hope that docker will add this feature soon. Anyhow, for the next step, I'll keep on moving all the other related things into docker label. :) |
To figure out whether docker list with label filter could improve the efficiency, I did a simple experiment. Benchmark
Result
Related Code in Docker Conclusion
|
I guess this was what we were assuming is true with labels. Is there an issue filed against docker to improve label based queries? |
@vishh In the original proposal of docker label, they proposed indexing and performance. I just check the code to figure out whether they have done that, :) |
As originally proposed, I think we should write TerminationMessagePath as a docker label, so that we don't need to rely on the pod spec to examine a terminated container. |
OK. I'll do it. :) |
Progress Update |
Progress Update |
I believe we can close this one too. @Random-Liu, thanks for working on it! |
@yujuhong Yeah. Maybe after moby/moby#18958 is landed, we can do something more. For now, I think we have done most of the things. :) |
Kubelet reconciles the difference between the pod status and the desired pod specs. When generating status for a pod (
GetPodStatus
), kubelet relies on several pieces of information from the apiserver:(edit: this list may be incomplete)
We can eliminate this dependency by writing the information as docker labels onto the container. The benefits of doing so include 1) kubelet can populate and maintain a container/pod status cache, representing what's running on the node, regardless of whether it has access to the pod spec yet or not; 2) this should simplify a lot of logic in pod spec.
(Note that
rkt
doesn't have this dependency as it writes relevant bits in the systemd unit file)Alternatively, kubelet can store a checkpoint of pods assigned to itself, and load the checkpoint when kubelet restarts. We may need to do this eventually, but in the meantime, docker labels seem like a good idea.
The original docker label issue: #3764
@kubernetes/goog-node, WDYT?
The text was updated successfully, but these errors were encountered: