Change:
PriorityClassName: "system-cluster-critical", }, }, <ins> // pod[5]: mirror Pod with a system priority class name { ObjectMeta: metav1.ObjectMeta{ Name:        "mirror-pod-w-system-priority", Namespace:   "namespace", Annotations: map[string]string{api.MirrorPodAnnotationKey: ""}, }, Spec: api.PodSpec{ Containers: []api.Container{ { Name: containerName, }, }, PriorityClassName: "system-cluster-critical", }, }, // pod[6]: mirror Pod with integer value of priority { ObjectMeta: metav1.ObjectMeta{ Name:        "mirror-pod-w-integer-priority", Namespace:   "namespace", Annotations: map[string]string{api.MirrorPodAnnotationKey: ""}, }, Spec: api.PodSpec{ Containers: []api.Container{ { Name: containerName, }, }, PriorityClassName: "default1", Priority:          &intPriority, }, }, </ins> } // Enable PodPriority feature gate. utilfeature.DefaultFeatureGate.Set(fmt.Sprintf("%s=true", features.PodPriority))

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Priority admission controller of mirror pods. This is an error and should be removed. What you expected to happen: Integer value of Priority should be populated by the admission controller. How to reproduce it (as minimally and precisely as possible): Create a static pod with PriorityClassName set. The created mirror pod will not get the integer value of priority. /sig scheduling xref
what is the kubelet expected to do with a low priority static pod if it gets evicted?
also doesn't this mean a user can claim their pod is a mirror pod via an annotation and get it admitted with any priority they want?
knows better about kubelet evictions, but in my opinion a static low priority pod should be evicted similar to other pods. Whether it makes sense for static pods to be low priority or not is a relevant question. I would say it doesn't make sense, but one might find a reason to have static low priority pod. Not really. This check effectively bypasses integer resolution of priority causing the priority of all those mirror pods to be considered zero. This if statement is wrong and should be removed.
It also bypasses the check that prevents the pod creator from setting an integer priority themselves. In any case, agree removing the bypass is good
Static pods that fail for any reason (eviction is just one) are not re-run. To avoid evictions entirely as a static pod, users can use the critical pod annotation.
, it seems we just log error if creating mirror pod failed; refer to . Does it make sense?
I am not sure I understand the question entirely. The mirror pod exists only to show the status of the static pod. If the mirror pod doesn't exist, the static pod should still function correctly. Since that is in , it will be retried periodically.
The scheduler dependent on mirror pods for resource usage :). If creating mirror pod failed (e.g. wrong priority class name), there'll be ping-pong between scheduler and kubelet: scheduler send pod to node, kubelet reject it. But we can-t just return error, kubelet can start in standalone mode.
However critical pod annotation is ignored if pod priorities are in use.

This is not the case. See in your issue.
However critical pod annotation is ignored if pod priorities are in use. the intent of pod priorities was to replace the critical pod annotation with something more principled. is that not how it was implemented?
Priority replaces most of the functionality that the critical pod annotation provides. However, the critical pod annotation is still useful for static pods, as it can prevent kubelet evictions. But for all other use-cases, I agree that priority is a much better way to manage which workloads are run, and which remain pending. I am not sure if the scheduler translates a "critical" pod to a "system-priority" pod for scheduling purposes, but the kubelet still prevents the eviction of static critical pods as an escape hatch for important static pods which cannot tolerate kubelet evictions.
Why would that not be modeled as a system priority? I expected critical pod annotations to not be present once the priority feature was completed.
I agree with this. do you think we should not evict static pods which are system priority, so that even users of static pods can move from using the critical pod annotation to use pod priority?
I think Kubelet should not evict static system pods, but even with the current logic of eviction, if these Pods do not use more resources than requested, kubelet never evicts them as their priority is higher than other pods.
I think as a best practice users that write static pod manifests should apply a system priority to prevent eviction, but I do not think the kubelet should do anything magical about that source.