anchor.diff:  
   When the above is set the node continues to report node status updates at the
   frequency specified by the `node-status-update-frequency` argument, which
  -defaults to *10s*.
  +defaults to `10s`.
   
   [[out-of-resource-reclaiming-node-level-resources]]
   === Reclaiming Node-level Resources
  
positive.code: <1> This threshold can either be `eviction-hard` or `eviction-soft`.
  ====
  
  Implicit in this configuration is the understanding that *system-reserved*
  should include the amount of memory covered by the eviction threshold.
  
  To reach that capacity, either some pod is using more than its request, or the
  system is using more than *1Gi*.
  
  This configuration ensures that the scheduler does not place pods on a node that
  immediately induce memory pressure and trigger eviction assuming those pods use
  less than their configured request.
  
  
  [[out-of-resource-node-out-of-resource-and-out-of-memory]]
  == Out of Resource and Out of Memory
  
negative.code: 
  Consider the following scenario:
  
  * Node memory capacity of `10Gi`.
  * The operator wants to reserve 10% of memory capacity for system daemons
  (kernel, node, etc.).
  * The operator wants to evict pods at 95% memory utilization to reduce
  thrashing and incidence of system OOM.
  
  A node reports two values:
  
  * `Capacity`: How much resource is on the machine
  * `Allocatable`: How much resource is made available for scheduling.
  
  The goal is to allow the scheduler to fully allocate a node and to not have
  evictions occur.
  
  Evictions should only occur if pods use more than their requested amount of
  resource.
  
  To facilitate this scenario, the
  xref:../install_config/master_node_configuration.adoc#install-config-master-node-configuration[node
  