-
Notifications
You must be signed in to change notification settings - Fork 39.4k
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
v1.8 hyperkube images don't allow the kubelet to mount #52789
Comments
/sig storage |
Seems the base hyperkube image was changed: https://github.com/kubernetes/kubernetes/blob/v1.8.0-beta.1/cluster/images/hyperkube/Makefile#L24 done in 66b9ae7. /cc @ixdy |
The pkg/util/mount/mount_linux source defaults to ext4 if a fstype is not selected. It makes sense to restore the e2fsprogs package within the hyperkube image. |
cc @kubernetes/sig-node-bugs This seems like something that should be in the 1.8 milestone. Can someone who owns the hyperkube image comment on that? |
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings:
|
Containerization of mount is not going to happen until 1.9 at the earliest. So if hyperkube is broken, it should be fixed before ship. |
…rkube Automatic merge from submit-queue (batch tested with PRs 52477, 52790, 52798). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.. restore e2fsprogs in hyperkube image **What this PR does / why we need it**: Kubernetes defaults to the ext4 filesystem if no filesystem is specified. Unformatted filesystems are not able to be mounted without these tools. The default ext{2,3,4} tools and mkfs.* utilities should be included in the hyperkube image. **Which issue this PR fixes**: Fixes #52789 #50802 **Special notes for your reviewer**: **Release note**: ```release-note NONE ```
"modprobe" also went missing in 1.8 hyperkube images... Both kubelet and kube-proxy need it. |
@edevil Are you noticing any buggy behaviour on those components without it? Would you mind creating an issue and/or PR to restore that dep |
/kind bug
What happened:
When a cluster is provisioned using a containerised kubelet using the following images:
gcr.io/google-containers/hyperkube-amd64:v1.8.0-beta.0
gcr.io/google-containers/hyperkube-amd64:v1.8.1-beta.0
Pods with PVCs are not created because kubelet cannot mount the disks. If you look at events, you can see that it's missing some binaries:
This executable is
mkfs.ext4
. This problem can be resolved by mounting paths from the host into the rkt container, specifically/usr/sbin
and/usr/lib
.Is this expected? @saad-ali mentioned in #50802, that mounting operations are moving out from the main process into containers. Is this part of that effort? This caught me quite unexpected, and I didn't find any docs or changelog entries which indicated additional host mounts were necessary.
If it's deliberate, I can close this until we perhaps document the breaking change. Is there a good place where we can document this?
If it's not, I'll leave this open as a tracking issue.
What you expected to happen:
The hyperkube image to work without lots of host mounts.
How to reproduce it (as minimally and precisely as possible):
Run kubelet with rkt in one of the above listed images (see CoreOS' kubelet-wrapper).
Environment:
kubectl version
): v1.8.0.beta-1uname -a
):The text was updated successfully, but these errors were encountered: