-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: add slim image #84
Conversation
Yes, I think reducing kubelet image size is a great step forward. With Kubernetes removing in-tree CSI drivers, I'm not sure if e.g. But your PR might be a good way forward to first introduce |
Dockerfile
Outdated
ca-certificates \ | ||
libcap2 \ | ||
ethtool \ | ||
iproute2 \ |
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.
socat should be small and seems to be listed as a dependency in upstream kubelet package
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.
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 remember the time when socat was required for kubectl port-forward, i've tested it recently it works without socat.
But we can keep it as well.
I believe, that most of the tools are legacy. And kubernetes community do not want to spent time to removal process yet.
Also my research kubernetes/mount-utils#17
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 remember the time when socat was required for kubectl port-forward, i've tested it recently it works without socat.
should we keep it them @smira ?
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've added socat
to slim version...
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.
What I'm thinking is what if for K8s 1.31+ we offer slim version by default and do a 😱 test?
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.
yeh, and still keep the old one around, so if something breaks it's a machine config patch to fix
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.
so it should be something like:
< 1.31
- build "1.x" + "1.x-silim">= 1.31
- build "1.x" (actually slim) and "1.x-fat" ?
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 previous comment was more of a question actually
dea388d
to
62e3708
Compare
I will refactor this a bit to support what we've discussed so far |
@frezbo @sergelogvinov please let me know what do you think about the changes I made (in a separate commit) |
/lgtm Thanks ) |
Build two kubelet images full size (fat) and slim. For Kubernetes < 1.31.0, there will be two images built: * `v1.x.y` (default, fat) * `v1.x.y-slim` (slim) For Kubernetes >= 1.31.0, there will be same two images built, but the default tag would point to slim image: * `v1.x.y` (default, slim) * `v1.x.y-fat` (fat) Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev> Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
/m |
See siderolabs/kubelet#84 Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
See siderolabs/kubelet#84 Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
#78
Build two images full size and slim.
What do you think to build two images?