27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
---
|
|
reviewers:
|
|
- davidopp
|
|
- filipg
|
|
- piosz
|
|
title: Guaranteed Scheduling For Critical Add-On Pods
|
|
content_type: concept
|
|
weight: 220
|
|
---
|
|
|
|
<!-- overview -->
|
|
|
|
Kubernetes core components such as the API server, scheduler, and controller-manager run on a control plane node. However, add-ons must run on a regular cluster node.
|
|
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.
|
|
A static pod marked as critical, can't be evicted. However, a non-static pods marked as critical are always rescheduled.
|
|
|
|
<!-- 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`.
|