anchor.diff:  
   You can assign pods a priority class, which is a non-namespaced object that defines a mapping from a name to the integer value of the priority. The higher the value, the higher the priority.
   
  -A priority class object can take any 32-bit integer value smaller than or equal to 1000000000 (one billion). Reserve numbers larger than one billion for critical pods that should not be preempted or evicted. By default, {product-title} has two reserved priority classes for critical system pods to have guaranteed scheduling.
  +A priority class object can take any 32-bit integer value smaller than or equal to 1000000000 (one billion). Reserve numbers larger than or equal to one billion for critical pods that must not be preempted or evicted. By default, {product-title} has two reserved priority classes for critical system pods to have guaranteed scheduling.
   
   [source,terminal]
   ----
  
positive.code: [source,terminal]
  ----
  NAME                      VALUE        GLOBAL-DEFAULT   AGE
  cluster-logging           1000000      false            29s
  system-cluster-critical   2000000000   false            72m
  system-node-critical      2000001000   false            72m
  ----
  
  * *system-node-critical* - This priority class has a value of 2000001000 and is used for all pods that should never be evicted from a node. Examples of pods that have this priority class are `sdn-ovs`, `sdn`, and so forth. A number of critical components include the `system-node-critical` priority class by default, for example:
  
negative.code: ** metrics-server
  ** descheduler
  
  * *openshift-user-critical* - You can use the `priorityClassName` field with important pods that cannot bind their resource consumption and do not have predictable resource consumption behavior. Prometheus pods under the `openshift-monitoring` and `openshift-user-workload-monitoring` namespaces use the `openshift-user-critical` `priorityClassName`. Monitoring workloads use `system-critical` as their first `priorityClass`, but this causes problems when monitoring uses excessive memory and the nodes cannot evict them. As a result, monitoring drops priority to give the scheduler flexibility, moving heavy workloads around to keep critical nodes operating.
  
  * *cluster-logging* - This priority is used by Fluentd to make sure Fluentd pods are scheduled to nodes over other apps.
  
  [NOTE]
  