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: 
  Consider the following scenario:
  
  * Node memory capacity of *10Gi*.
  * Operator wants to reserve 10 percent of memory capacity for system daemons
  (kernel, node, etc.).
  * Operator wants to evict pods at 95 percent memory utilization to reduce
  thrashing and incidence of system OOM.
  
  To facilitate this scenario, the
  xref:../install_config/master_node_configuration.adoc#install-config-master-node-configuration[node
  
negative.code: <1> This threshold can either be `eviction-hard` or `eviction-soft`.
  ====
  
  [NOTE]
  ====
  Soft eviction usage is more common when you are targeting a certain level of
  utilization, but can tolerate temporary spikes. It is recommended
  that the soft eviction threshold is always less than the hard eviction
  threshold, but the time period is operator specific. The system reservation
  should also cover the soft eviction threshold.
  ====
  
  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`.
  
  If a node has 10 Gi of capacity, and you want to reserve 10% of that capacity for
  the system daemons, do the following:
  
  ----
  capacity = 10 Gi
  system-reserved = 10 Gi * .01 = 1 Gi
  ----
  
  The node allocatable value in this setting becomes:
  
  ----
  allocatable = capacity - system-reserved = 9 Gi
  ----
  
  This means by default, the scheduler will schedule pods that request 9 Gi of
  memory to that node.
  
  If you want to turn on eviction so that eviction is triggered when the node
  observes that available memory falls below 10% of capacity for 30 seconds, or
  immediately when it falls below 5% of capacity, you need the scheduler to see
  allocatable as 8Gi. Therefore, ensure your system reservation covers the greater
  of your eviction thresholds.
  
  ----
  capacity = 10 Gi
  eviction-threshold = 10 Gi * .05 = .5 Gi
  system-reserved = (10Gi * .01) + eviction-threshold = 1.5 Gi
  allocatable = capacity - system-reserved = 8.5 Gi
  ----
  
  You must set `system-reserved` equal to the amount of resource you want to
  reserve for system-daemons, plus the amount of resource you want to reserve
  before triggering evictions.
  
  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
  