System critical priority classes — protecting kube-system

System critical priority classes protect the cluster’s critical components from preemption. This lesson walks the system classes, the protection mechanism, the use cases, and the discipline.

The system classes

flowchart LR
    A[system-cluster-critical] --> A1["Value: 1,000,000,000"]
    A --> A2[Cluster-wide critical Pods]
    A2 --> A3["CoreDNS, kube-proxy"]
    B[system-node-critical] --> B1["Value: 1,000,000,001"]
    B --> B2[Node-critical Pods]
    B2 --> B3["CNI agents, monitoring"]

The system classes:

• system-cluster-critical. Value 1,000,000,000. For Pods that the cluster needs to function (CoreDNS, kube-proxy).
• system-node-critical. Value 1,000,000,001. Higher than system-cluster-critical. For Pods that the node needs to function (CNI agents, node monitoring).

Both are installed automatically in modern Kubernetes (kubeadm, EKS, AKS, GKE install them).

The use cases

flowchart LR
    A[System classes use cases] --> B[kube-proxy]
    B --> C[Service traffic]
    A --> D[CoreDNS]
    D --> E[Cluster DNS]
    A --> F[CNI agent]
    F --> G[Pod networking]
    A --> H[Node monitoring]
    H --> I[Node-level metrics]

The use cases:

• kube-proxy. Required for Service traffic. Without it, Services do not route.
• CoreDNS. Required for cluster DNS. Without it, Pods cannot resolve Service names.
• CNI agent. Required for pod networking. Without it, new Pods cannot get an IP.
• Node monitoring. Required for node-level metrics and alerts.

These are never preempted.

Assigning system classes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system
spec:
  template:
    spec:
      priorityClassName: system-cluster-critical
      containers:
        - name: coredns
          image: coredns

A critical component declares its PriorityClass. The scheduler gives it the highest priority.

Why preemption does not affect system classes

flowchart LR
    A["Pod: priority 1,000,000,001"] --> B[Cannot be preempted]
    A --> C["Preempts only Pods with priority < 1,000,000,001"]
    C --> D[Application Pods with priority < 1 billion]

The protection:

• System classes cannot be preempted. A Pod with priority 1,000,000,001 cannot be evicted by another Pod; the scheduler refuses to do so.
• System classes can preempt everything else. A Pod with priority 1,000,000,001 can preempt any Pod with priority < 1 billion.

The mechanism: preemption requires the preempting Pod’s priority to be higher than the preempted Pod’s priority. System classes have the highest priority; nothing can preempt them.

Verifying system classes

kubectl get priorityclass

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-cluster-critical   2000000000   false            90d
system-node-critical      3000000000   false            90d

(Note: actual values may differ by version; the principle is values above 1 billion.)

The system classes are present. Application classes should use values below 1 billion.

Quiz

The operational discipline

System critical priority classes in production rest on five non-negotiable elements:

• Verify system classes exist. They are auto-installed in modern clusters.
• Use system classes for critical components. kube-proxy, CoreDNS, CNI agents.
• Don’t use values above 1 billion for applications. Reserved for system.
• Don’t preempt system classes. The scheduler enforces this; verify in tests.
• Test preemption. Quarterly: simulate a cluster under pressure; verify system classes survive.

System classes are the foundation of cluster reliability. Without them, critical components can be preempted by application workloads, breaking cluster-wide functionality.