-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Metrics-server : bind: permission denied #7988
Comments
Update : I tried installing a brand new kubespray with the same configuration (but on VM instead of baremetal and debian 11 instead of centOS 7 for controlplanes) and everything works fine on it.
Works on :
|
Update : I tested running |
Hi, Same issue here, changing port 443 -> 4443 fixes also (CentOS 7) I think using port 443 seems to be the target. If you check metric-server port has changed between release-0.5 and release-0.4. |
Thanks for this issue report. |
I created a pull request(#8014) to fix this issue. |
@oomichi Could this issue be re-opened, please? I think that there are actually two overlapping issues: Port 443 being bound already and PSPs prohibiting the use of privileged ports. We use PSPs and this will not suffice. There actually is an issue open upstream, too: kubernetes-sigs/metrics-server#782 |
@manzsolutions-lpreis Could you open different issue to make it easy if we still have another issue? |
@oomichi I have to admit that while preparing the new issue I was unable to recreate this specific error we were seeing during the initial upgrade and the pod is apparently running with the proper PSP attached via a group for the kube-system namespace. |
Hi !
We just upgraded to Kubespray
v2.17.0
and since then, metrics-server fails to start with the following error :I saw that there were some issues, PR and discussions linked to this matter recently on Kubespray (see #7886 and related) but apparently this issue is not solved even though the pod has the correct capability to bind to the privileged
443
port.Note that PodSecurityPolicies are enabled on this cluster, could it be related to the
seccomp.security.alpha.kubernetes.io/pod: runtime/default
annotation that is applied by theprivileged
PSP ? I'm sadly not used enough to those concepts to say.Below is the pod configuration :
The text was updated successfully, but these errors were encountered: