Change:
Name: "foo", }, }, <ins> Priority:          &priority, </ins> PriorityClassName: "system-node-critical", HostNetwork:       true, Volumes:           []v1.Volume{},

Discussion:
etcd / kube-apiserver stops before most containers, despite using . On a single node server, with multus (and likely other CNI talking to the API), this spam the logs and make the shutdown slower should stop one group at a time On a single node cluster, have a slow to shutdown pod (sleep inf), look at the logs to see in which order they are killed Reading the kep , the summary says so I would expect all pods with priority between 0 and to be stopped first, then coredns (), then the rest. This is definitely not what's happening: <details</detailsN/A <details</detailskubeadm containerd multus
/cc /sig node
Each will match all Pods whose is less than or equal to it. This may suit your want
/kind support
sorry for the delay I missed the notification ... this is the opposite of what the documentation says :( Maybe i'm misunderstanding the feature, I want shutdown ordering, and it's not working for me. All my pods have priority set to either 0, or . I want all the pods with priority 0 to shutdown first, once they are all shutdown or grace period is elapsed, shutdown the ones with priority , wait for them to shutdown or grace period, and finally take care of the ones with priority . Here some failing tests: test1: First killed pod was etcd (verified priority is ) ... test2: first pod killed was kube-scheduler test3 (same as test2): first pod killed was kube-controller-manager test4: first pod killed was etcd test5 (config in reverse order as test1): etcd was killed 3rd but still before pods with priority 0
I see what you mean, but this shouldn't be happening. It should only shutdown based on the priority of the group from lowest to highest. I would like to know the priority of all Pods on the node you shut down, and the configuration of , to try to reproduce it on my side
I'm reproducing it on an empty cluster, but just noticed coredns is killed correctly, it's just all containers from last group end up in first group
For some reasons the system-node-critical / pods go with the priority 0 pods
I think the pods quit too quickly so it looks like they were deleted together, maybe you should block them until the last moment.

I think I found a lead, it's all the static pods that are killed too soon, not kubeproxy () they have priorityClassName set, but not priority, so maybe priority is nil when getting of a static pod
I see that in numeric priorities to manifests in cluster/gce/manifests/ with the comment in the PR , are priority mandatory for static pods ? should we make kubeadm add them, or fix that in kube somewhere ?
This is the result from the API, I bet kubelet has different path to get pod manifests for cluster pods and static pods, as kubelet can work without the API
If I manually add to etcd manifest it's killed in the last group with kubeproxy
/remove-kind support
/triage accepted
[For a single-node cluster], I wonder if we should actually set a higher priority than for all or a subset of control plane Pods, because even with this change we could still shut down the API server quickly and before a node-critical component has completed its own shutdown.
I agree with this idea, because of the dependencies between the components of node-critical.