-
Notifications
You must be signed in to change notification settings - Fork 355
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
CoreDNS PreemptionPolicy conflicts with host cluster global default Priority Class #1718
Comments
Hello Thank you for the information regarding the issue you are facing. This conflict arises because the default PriorityClass of your host cluster has a preemption policy of 'Never' which does not align with the 'PreemptLowerPriority' policy specified in the coredns pod. At my investigation it may be either a miss-configuration or a real problem close to https://github.com/loft-sh/vcluster/blob/v0.20.0-beta.1/pkg/controllers/resources/priorityclasses/translate.go#L26. I would recommend to provide any additional logs or configurations that might help our team replicate and address this issue. |
What kind of additional logs and/or configurations would be helpful here? The default preemption policy on my host cluster is indeed intended to never preempt other pods. As previously stated, I'm using a default configuration of vcluster as deployed via CLI, so I'm not entirely sure how this can be a misconfiguration if the default configuration is producing pod specs that is conflicting with a host cluster default priorityClass preemption policy. |
What happened?
When trying to deploy a vcluster to my homelab cluster,
I found out that the coredns pod fails to sync because it has a preemptionPolicy set that is different from the default PriorityClass on my cluster.
The syncer fails to sync the coredns pod with the following error
What did you expect to happen?
For it to successfully sync the pod.
Ideally by omitting the preemptionPolicy here. Or mapping it properly to the host's system-cluster-critical PriorityClass.
How can we reproduce it (as minimally and precisely as possible)?
Anything else we need to know?
After temporarily removing the globalDefault PriorityClass on the host cluster, the pod successfully syncs, and I've observed that the resulting pod has an empty priorityClassName, which causes the host cluster to apply the default priorityClass which conflicts with the pod that has the values of system-cluster-critical inside the vcluster, but not actually having that priorityClassName.
Host cluster Kubernetes version
Host cluster Kubernetes distribution
vlcuster version
Vcluster Kubernetes distribution(k3s(default)), k8s, k0s)
OS and Arch
The text was updated successfully, but these errors were encountered: