Explain that static Pods never get evicted under node pressure #50569
Conversation
Static Pods never get evicted when under Node Pressure Issue #126542
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/M
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
| `priorityClassName` field for that Pod directly. | ||
|
|
||
| **Note:** | ||
| >The kubelet considers all static pods as critical regardless of their `.spec.priorityClassName`. |
There was a problem hiding this comment.
Are you sure about this?
My take is that static Pods can be evicted as just other Pods. They will never get admitted unless the kubelet is restarted.
There was a problem hiding this comment.
Historical conversation and explanation here.
https://github.com/kubernetes/website/pull/47055/files#diff-56de0c49fa24aa21138c65e0b8a9d71ab70f48159fc8184d9fee6e82793418a2R360
| apiVersion: v1 | ||
| kind: Pod | ||
| metadata: | ||
| name: static-web |
There was a problem hiding this comment.
This is an interesting usage scenario ...
you are running a static Pod as web server?
Static pods are created by the kubelet, even when the kubelet doesn't know a thing about the API server. In this case, how does the kubelet handle things like priority class (e.g. priorityClassName)?
There was a problem hiding this comment.
The kubelet creates mirror Pods and responds to (externally managed) static pod manifests.
But yes, I can't see how a static Pod can usefully have a priorityClassName.
|
/retitle Explain that static Pods never get evicted under node pressure |
k8s-ci-robot
changed the title
|
We avoid mentioning issues in commit messages |
| `priorityClassName` field. | ||
| `priorityClassName` field for that Pod directly. | ||
|
|
||
| **Note:** |
There was a problem hiding this comment.
We have a special short code for note callouts; please use that.
See https://kubernetes.io/docs/contribute/style/style-guide/#note
| xyz-priority 1000000 false 47s | ||
| ``` | ||
|
|
||
| This is a definition for a static Pod. You would define this directly for the kubelet on a particular nod (and not via kubectl) |
| apiVersion: v1 | ||
| kind: Pod | ||
| metadata: | ||
| name: static-web |
There was a problem hiding this comment.
The kubelet creates mirror Pods and responds to (externally managed) static pod manifests.
But yes, I can't see how a static Pod can usefully have a priorityClassName.
| **Note:** | ||
| >The kubelet considers all static pods as critical regardless of their `.spec.priorityClassName`. | ||
| >Static pods also pass kubelet admission even if a node does not have enough resources; the kubelet may | ||
| >instead evict another Pod (potentially even evicting a different Pod at a higher priority, if there is no better match). |
There was a problem hiding this comment.
Can you give an example of the kubelet evicting a higher-priority, non static Pod? It will help folks decide whether to accept the changes in this PR.
Description
Update README: Add priorityClassName usage for static Pods
This PR enhances the README with an example and explanation of how to assign priorityClassName to static Pods.
📌 Includes a note clarifying how kubelet treats static Pods with respect to priority.
✅ Adds sample output of kubectl get priorityclass.
📝 Demonstrates a complete static Pod definition using priorityClassName: xyz-priority.
This addition improves understanding of static Pod scheduling behavior and resource management.
Issue
kubernetes/kubernetes#126542
Closes: # kubernetes/kubernetes#126542