Marc Bihlmaier
b3ac0d1124
* Update guaranteed-scheduling-critical-addon-pods.md cleanup old stuff again * Update content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update guaranteed-scheduling-critical-addon-pods.md remove whitespace
33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
---
|
|
reviewers:
|
|
- davidopp
|
|
- filipg
|
|
- piosz
|
|
title: Guaranteed Scheduling For Critical Add-On Pods
|
|
content_template: templates/concept
|
|
---
|
|
|
|
{{% capture overview %}}
|
|
|
|
In addition to Kubernetes core components like api-server, scheduler, controller-manager running on a master machine
|
|
there are a number of add-ons which, for various reasons, must run on a regular cluster node (rather than the Kubernetes master).
|
|
Some of these add-ons are critical to a fully functional cluster, such as metrics-server, DNS, and UI.
|
|
A cluster may stop working properly if a critical add-on is evicted (either manually or as a side effect of another operation like upgrade)
|
|
and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space
|
|
vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).
|
|
|
|
Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable.
|
|
For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled.
|
|
|
|
{{% /capture %}}
|
|
|
|
|
|
{{% capture body %}}
|
|
|
|
|
|
### Marking pod as critical
|
|
|
|
To mark a Pod as critical, set priorityClassName for that Pod to `system-cluster-critical` or `system-node-critical`. `system-node-critical` is the highest available priority, even higher than `system-cluster-critical`.
|
|
|
|
{{% /capture %}}
|