Spec URL: https://buckaroogeek.fedorapeople.org/reviews/kubernetes-user-namespace.spec SRPM URL: https://buckaroogeek.fedorapeople.org/reviews/kubernetes-user-namespace-1.0.0-1.fc44.src.rpm Description: Installs kubelet sysuser and draft subordinate user ids for this user in /etc/subuid and /etc/subgid. This meets requirements for Kubernetes User Namespace feature which is available in Kubernetes 1.33 and newer. Enhances security for kubernetes node. Fedora Account System Username: buckaroogeek
Copr build: https://copr.fedorainfracloud.org/coprs/build/9942016 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2424524-kubernetes-user-namespace/fedora-rawhide-x86_64/09942016-kubernetes-user-namespace/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
This package doesn't make sense. Why isn't this part of some kind of kubernetes-common thing that exists for all kubernetes packages to depend on?
This feature has some specific requirements including either containerd or crio and crun or runc. There are a few other technical requirements (idmap support in the filesystem) that are not too constraining. But the restriction to crio or containerd and crun or runc could potentially be blocking for some users and, in my perspective, make this capability optional and not (yet at least) a standard component. During some testing and debugging I found that if the `kubelet` user existing on the machine but subuids were not assigned, then the kubelet service will fail to start with an error message about the misconfiguration. So I suspect that if this were part of a kubernetes-common package that was a required dependency for the kubernetes packages (e.g. kubernetes1.34) then the out-of-the-box experience would be a failure to start unless the subuids are configured even when not used.
> So I suspect that if this were part of a kubernetes-common package that was a required dependency for the kubernetes packages (e.g. kubernetes1.34) then the out-of-the-box experience would be a failure to start unless the subuids are configured even when not used. So this sounds like we need this to be fixed so that we always have this configured so it can be opportunistically used.