Change:
// or equal to SystemCriticalPriority. Both the rescheduler(deprecated in 1.10) and the kubelet use this function // to make admission and scheduling decisions. func IsCriticalPod(pod *v1.Pod) bool { <del> return IsCritical(pod.Namespace, pod.Annotations) || (pod.Spec.Priority != nil && IsCriticalPodBasedOnPriority(pod.Namespace, *pod.Spec.Priority)) </del> <ins> return IsCritical(pod.Namespace, pod.Annotations) || (pod.Spec.Priority != nil && IsCriticalPodBasedOnPriority(*pod.Spec.Priority)) </ins> } // IsCritical returns true if parameters bear the critical pod annotation

Discussion:
When we used annotations to mark critical pods, we considered pods with such an annotation critical only when they were created in "kube-system" namespace. Going to the new era of using priority to indicate critical pods, we would like to remove the restriction of "kube-system" namespace and consider pods with critical priority as critical no matter what namespace they are in. ref/ /kind bug /sig scheduling /assign cc/
While I am fine with the approach, it seems the only way to ensure that those critical pods are not coming from some random namespace is whitelisting them using priority admission controller or using quota. Atleast previously we have one more level of security that critical pod has to be created in kube-system namespace.
The requirement to limit the critical pod annotation meaning to the kube-system namespace was a workaround for the lack of access control and quota around the annotation. We actively work to prevent special handling of the kube-system namespace wherever possible.
Yes, which is why those aspects are essential to a functional priority system that works for a variety of cluster configurations
Agree with Ravi and Jordan on what is needed for final solution.
There is no doubt that we need to have quota for priority. It is needed not only for critical priorities, but also for any other high priority classes that users may define. That effort is going forward and we will have it soon.
, I think we also need to update Priority admission controller for that.
see later PR re-restricting this until the quota controls graduate to at least beta state:
Got that, thanks :) That makes sense to me.
If this is closed and there even was a for this type of functionality, what is the current status? And is in sync with current status?
It seems that namespace is still , so I guess the current status is that system critical pods are still limited to namespace. Based on that I think this issue should not be closed.
can we reopen this issue please because as pointed out by the issue still exists. Thanks.
Waiting for this to be available myself. No reason my Node Exporter dataset has to run in the namespace instead of my Grafana namespace.
Confirmed code + behavior. /open
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
I too am confused based on that documentation. Can we get an update here with an answer and fix the documentation if it's wrong?
This is resolved in 1.17 See