[enterprise-4.16] OSDOCS 16930 CQA2.0 of NODES-2: Node Management and Maintenance Part II

Author: Michael Burke

modules/mco-update-boot-images-configuring.adoc

@@ -7,11 +7,16 @@
 [id="mco-update-boot-images-configuring_{context}"]
 = Configuring updated boot images
 
-By default, {product-title} does not manage the boot image. You can configure your cluster to update the boot image whenever you update your cluster by modifying the `MachineConfiguration` object.
+[role="_abstract"]
+include::snippets/mco-update-boot-images-abstract.adoc[]
+
+Enabling the feature updates the boot image to the {op-system-first} boot image version appropriate for your cluster. If the cluster is again updated to a new {product-title} version in the future, the boot image is updated again. New nodes created after enabling the feature use the updated boot image. This feature has no effect on existing nodes.
+
+To enable the boot image management feature for control plane machine sets or to re-enable the boot image management feature for worker machine sets where it was disabled, edit the `MachineConfiguration` object. You can enable the feature for all of the machine sets in the cluster or specific machine sets.
 
 .Prerequisites
 
-* You have enabled the `TechPreviewNoUpgrade` feature set by using the feature gates. For more information, see "Enabling features using feature gates" in the _Additional resources_  section.
+* If you are enabling boot image management for control plane machine sets, you enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`.
 
 .Procedure
 
@@ -87,7 +92,6 @@ $ oc get machineconfiguration cluster -n openshift-machine-api -o yaml
 ----
 +
 .Example machine set with the boot image reference
-+
 [source,yaml]
 ----
 kind: MachineConfiguration

modules/mco-update-boot-images-disable.adoc

@@ -7,7 +7,8 @@
 [id="mco-update-boot-images-disable_{context}"]
 = Disabling updated boot images
 
-To disable the updated boot image feature, edit the `MachineConfiguration` object so that the `machineManagers` field is an empty array.
+[role="_abstract"]
+You can disable the boot image management feature so that the Machine Config Operator (MCO) no longer manages or updates the boot image in the affected machine sets. For example, you could disable this feature for the worker nodes in order to use a custom boot image that you do not want changed.
 
 If you disable this feature after some nodes have been created with the new boot image version, any existing nodes retain their current boot image. Turning off this feature does not rollback the nodes or machine sets to the originally-installed boot image. The machine sets retain the boot image version that was present when the feature was enabled and is not updated again when the cluster is upgraded to a new {product-title} version in the future.
 

modules/nodes-nodes-viewing-listing-pods.adoc

@@ -6,7 +6,8 @@
 [id="nodes-nodes-viewing-listing-pods_{context}"]
 = Listing pods on a node in your cluster
 
-You can list all the pods on a specific node.
+[role="_abstract"]
+You can list all of the pods on a node by using the `oc get pods` command along with specific flags. This command shows the number of pods on that node, the state of the pods, number of pod restarts, and the age of the pods.
 
 .Procedure
 

modules/nodes-nodes-viewing-listing.adoc

@@ -6,7 +6,8 @@
 [id="nodes-nodes-viewing-listing_{context}"]
 = About listing all the nodes in a cluster
 
-You can get detailed information on the nodes in the cluster.
+[role="_abstract"]
+You can get detailed information about the nodes in the cluster, which can help you understand the state of the nodes in your cluster.
 
 * The following command lists all nodes:
 +
@@ -108,39 +109,39 @@ include::snippets/osd-aws-example-only.adoc[]
 .Example output
 [source,text]
 ----
-Name:               node1.example.com <1>
-Roles:              worker <2>
+Name:               node1.example.com
+Roles:              worker
 Labels:             kubernetes.io/os=linux
                     kubernetes.io/hostname=ip-10-0-131-14
-                    kubernetes.io/arch=amd64 <3>
+                    kubernetes.io/arch=amd64
                     node-role.kubernetes.io/worker=
                     node.kubernetes.io/instance-type=m4.large
                     node.openshift.io/os_id=rhcos
                     node.openshift.io/os_version=4.5
                     region=east
                     topology.kubernetes.io/region=us-east-1
                     topology.kubernetes.io/zone=us-east-1a
-Annotations:        cluster.k8s.io/machine: openshift-machine-api/ahardin-worker-us-east-2a-q5dzc  <4>
+Annotations:        cluster.k8s.io/machine: openshift-machine-api/ahardin-worker-us-east-2a-q5dzc
                     machineconfiguration.openshift.io/currentConfig: worker-309c228e8b3a92e2235edd544c62fea8
                     machineconfiguration.openshift.io/desiredConfig: worker-309c228e8b3a92e2235edd544c62fea8
                     machineconfiguration.openshift.io/state: Done
                     volumes.kubernetes.io/controller-managed-attach-detach: true
 CreationTimestamp:  Wed, 13 Feb 2019 11:05:57 -0500
-Taints:             <none>  <5>
+Taints:             <none>
 Unschedulable:      false
-Conditions:                 <6>
+Conditions:
   Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
   ----             ------  -----------------                 ------------------                ------                       -------
   OutOfDisk        False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientDisk     kubelet has sufficient disk space available
   MemoryPressure   False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientMemory   kubelet has sufficient memory available
   DiskPressure     False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasNoDiskPressure     kubelet has no disk pressure
   PIDPressure      False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientPID      kubelet has sufficient PID available
   Ready            True    Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:07:09 -0500   KubeletReady                 kubelet is posting ready status
-Addresses:   <7>
+Addresses:
   InternalIP:   10.0.140.16
   InternalDNS:  ip-10-0-140-16.us-east-2.compute.internal
   Hostname:     ip-10-0-140-16.us-east-2.compute.internal
-Capacity:    <8>
+Capacity:
  attachable-volumes-aws-ebs:  39
  cpu:                         2
  hugepages-1Gi:               0
@@ -154,7 +155,7 @@ Allocatable:
  hugepages-2Mi:               0
  memory:                      7558116Ki
  pods:                        250
-System Info:    <9>
+System Info:
  Machine ID:                              63787c9534c24fde9a0cde35c13f1f66
  System UUID:                             EC22BF97-A006-4A58-6AF8-0A38DEEA122A
  Boot ID:                                 f24ad37d-2594-46b4-8830-7f7555918325
@@ -167,7 +168,7 @@ System Info:    <9>
  Kube-Proxy Version:                      v1.29.4
 PodCIDR:                                  10.128.4.0/24
 ProviderID:                               aws:///us-east-2a/i-04e87b31dc6b3e171
-Non-terminated Pods:                      (12 in total)  <10>
+Non-terminated Pods:                      (12 in total)
   Namespace                               Name                                   CPU Requests  CPU Limits  Memory Requests  Memory Limits
   ---------                               ----                                   ------------  ----------  ---------------  -------------
   openshift-cluster-node-tuning-operator  tuned-hdl5q                            0 (0%)        0 (0%)      0 (0%)           0 (0%)
@@ -189,7 +190,7 @@ Allocated resources:
   cpu                         380m (25%)   270m (18%)
   memory                      880Mi (11%)  250Mi (3%)
   attachable-volumes-aws-ebs  0            0
-Events:     <11>
+Events:
   Type     Reason                   Age                From                      Message
   ----     ------                   ----               ----                      -------
   Normal   NodeHasSufficientPID     6d (x5 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientPID
@@ -201,25 +202,27 @@ Events:     <11>
   Normal   Starting                 6d                 kubelet, m01.example.com  Starting kubelet.
 #...
 ----
-<1> The name of the node.
-<2> The role of the node, either `master` or `worker`.
-<3> The labels applied to the node.
-<4> The annotations applied to the node.
-<5> The taints applied to the node.
-<6> The node conditions and status. The `conditions` stanza lists the `Ready`, `PIDPressure`, `MemoryPressure`, `DiskPressure` and `OutOfDisk` status. These condition are described later in this section.
-<7> The IP address and hostname of the node.
-<8> The pod resources and allocatable resources.
-<9> Information about the node host.
-<10> The pods on the node.
-<11> The events reported by the node.
-
-ifndef::openshift-rosa,openshift-dedicated[]
-
+where:
++
+--
+`Names`:: Specifies the name of the node.
+`Roles`:: Specifies the role of the node, either `master` or `worker`.
+`Labels`:: Specifies the labels applied to the node.
+`Annotations`:: Specifies the annotations applied to the node.
+`Taints`:: Specifies the taints applied to the node.
+`Conditions`:: Specifies the node conditions and status. The `conditions` stanza lists the `Ready`, `PIDPressure`, `MemoryPressure`, `DiskPressure` and `OutOfDisk` status. These condition are described later in this section.
+`Addresses`:: Specifies the IP address and hostname of the node.
+`Capacity`:: Specifies the pod resources and allocatable resources.
+`Information`:: Specifies information about the node host.
+`Non-terminated Pods`:: Specifies the pods on the node.
+`Events`:: Specifies the events reported by the node.
+--
++
+ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [NOTE]
 ====
 The control plane label is not automatically added to newly created or updated master nodes. If you want to use the control plane label for your nodes, you can manually configure the label. For more information, see _Understanding how to update labels on nodes_ in the _Additional resources_ section.
 ====
-
 endif::openshift-rosa,openshift-dedicated[]
 
 Among the information shown for nodes, the following node conditions appear in the output of the commands shown in this section:

modules/nodes-nodes-viewing-memory.adoc

@@ -6,9 +6,8 @@
 [id="nodes-nodes-viewing-memory_{context}"]
 = Viewing memory and CPU usage statistics on your nodes
 
-You can display usage statistics about nodes, which provide the runtime
-environments for containers. These usage statistics include CPU, memory, and
-storage consumption.
+[role="_abstract"]
+You can display usage statistics about nodes, including CPU, memory, and storage consumption. These statistics can help you ensure your cluster is running efficiently.
 
 .Prerequisites
 

modules/nodes-nodes-working-deleting-bare-metal.adoc

@@ -7,16 +7,18 @@
 [id="nodes-nodes-working-deleting-bare-metal_{context}"]
 = Deleting nodes from a bare metal cluster
 
+[role="_abstract"]
+You can delete a node from a {product-title} cluster that does not use machine sets by using the `oc delete node` command and decommissioning the node.
+
 When you delete a node using the CLI, the node object is deleted in Kubernetes,
 but the pods that exist on the node are not deleted. Any bare pods not backed by
 a replication controller become inaccessible to {product-title}. Pods backed by
 replication controllers are rescheduled to other available nodes. You must
 delete local manifest pods.
 
-.Procedure
+The following procedure deletes a node from an {product-title} cluster running on bare metal.
 
-Delete a node from an {product-title} cluster running on bare metal by completing
-the following steps:
+.Procedure
 
 . Mark the node as unschedulable:
 +
@@ -32,7 +34,7 @@ $ oc adm cordon <node_name>
 $ oc adm drain <node_name> --force=true
 ----
 +
-This step might fail if the node is offline or unresponsive. Even if the node does not respond, it might still be running a workload that writes to shared storage. To avoid data corruption, power down the physical hardware before you proceed.
+This step might fail if the node is offline or unresponsive. Even if the node does not respond, the node might still be running a workload that writes to shared storage. To avoid data corruption, power down the physical hardware before you proceed.
 
 . Delete the node from the cluster:
 +

modules/nodes-nodes-working-deleting.adoc

@@ -6,7 +6,8 @@
 [id="nodes-nodes-working-deleting_{context}"]
 = Deleting nodes from a cluster
 
-To delete a node from the {product-title} cluster, scale down the appropriate `MachineSet` object.
+[role="_abstract"]
+You can delete a node from a {product-title} cluster by scaling down the appropriate `MachineSet` object.
 
 [IMPORTANT]
 ====
@@ -58,7 +59,9 @@ metadata:
   namespace: openshift-machine-api
   # ...
 spec:
-  replicas: 2 # <1>
+  replicas: 2
   # ...
 ----
-<1> Specify the number of replicas to scale down to.
+where:
+
+`spec.replicas`:: Specifies the number of replicas to scale down to.

modules/nodes-nodes-working-evacuating.adoc

@@ -4,23 +4,23 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="nodes-nodes-working-evacuating_{context}"]
-= Understanding how to evacuate pods on nodes
+= Evacuating pods on nodes
 
-Evacuating pods allows you to migrate all or selected pods from a given node or
-nodes.
+[role="_abstract"]
+You can remove, or evacuate, pods from a given node or nodes. Evacuating pods allows you to migrate all or selected pods to other nodes.
 
-You can only evacuate pods backed by a replication controller. The replication controller creates new pods on
+You can evacuate only pods that are backed by a replication controller. The replication controller creates new pods on
 other nodes and removes the existing pods from the specified node(s).
 
 Bare pods, meaning those not backed by a replication controller, are unaffected by default.
-You can evacuate a subset of pods by specifying a pod-selector. Pod selectors are
-based on labels, so all the pods with the specified label will be evacuated.
+You can evacuate a subset of pods by specifying a pod selector. Because pod selectors are
+based on labels, all of the pods with the specified label are evacuated.
 
 .Procedure
 
-. Mark the nodes unschedulable before performing the pod evacuation.
+. Mark the nodes as unschedulable before performing the pod evacuation.
 
-.. Mark the node as unschedulable:
+.. Mark the node as unschedulable by running the following command:
 +
 [source,terminal]
 ----
@@ -33,7 +33,7 @@ $ oc adm cordon <node1>
 node/<node1> cordoned
 ----
 
-.. Check that the node status is `Ready,SchedulingDisabled`:
+.. Check that the node status is `Ready,SchedulingDisabled` by running the following command:
 +
 [source,terminal]
 ----
@@ -47,69 +47,69 @@ NAME        STATUS                     ROLES     AGE       VERSION
 <node1>     Ready,SchedulingDisabled   worker    1d        v1.29.4
 ----
 
-. Evacuate the pods using one of the following methods:
+. Evacuate the pods by using one of the following methods:
 
-** Evacuate all or selected pods on one or more nodes:
+** Evacuate all or selected pods on one or more nodes by running the `oc adm drain` command:
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
 ----
 
-** Force the deletion of bare pods using the `--force` option. When set to
+** Force the deletion of bare pods by using the `--force` option with the `oc adm drain` command. When set to
 `true`, deletion continues even if there are pods not managed by a replication
-controller, replica set, job, daemon set, or stateful set:
+controller, replica set, job, daemon set, or stateful set.
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> --force=true
 ----
 
-** Set a period  of time in seconds for each pod to
-terminate gracefully, use `--grace-period`. If negative, the default value specified in the pod will
+** Set a period of time in seconds for each pod to
+terminate gracefully by using the `--grace-period` option with the `oc adm drain` command. If negative, the default value specified in the pod will
 be used:
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> --grace-period=-1
 ----
 
-** Ignore pods managed by daemon sets using the `--ignore-daemonsets` flag set to `true`:
+** Ignore pods managed by daemon sets by using the `--ignore-daemonsets=true` option with the `oc adm drain` command:
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> --ignore-daemonsets=true
 ----
 
-** Set the length of time to wait before giving up using the `--timeout` flag. A
-value of `0` sets an infinite length of time:
+** Set the length of time to wait before giving up using the `--timeout`  option with the `oc adm drain` command. A
+value of `0` sets an infinite length of time.
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> --timeout=5s
 ----
 
-** Delete pods even if there are pods using `emptyDir` volumes by setting the `--delete-emptydir-data` flag to `true`. Local data is deleted when the node
-is drained:
+** Delete pods even if there are pods using `emptyDir` volumes by setting the `--delete-emptydir-data=true` option with the `oc adm drain` command. Local data is deleted when the node
+is drained.
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2> --delete-emptydir-data=true
 ----
 
-** List objects that will be migrated without actually performing the evacuation,
-using the `--dry-run` option set to `true`:
+** List objects that would be migrated without actually performing the evacuation,
+by using the `--dry-run=true` option with the `oc adm drain` command:
 +
 [source,terminal]
 ----
 $ oc adm drain <node1> <node2>  --dry-run=true
 ----
 +
 Instead of specifying specific node names (for example, `<node1> <node2>`), you
-can use the `--selector=<node_selector>` option to evacuate pods on selected
+can use the `--selector=<node_selector>` option with the `oc adm drain` command to evacuate pods on selected
 nodes.
 
-. Mark the node as schedulable when done.
+. Mark the node as schedulable when done by using the following command.
 +
 [source,terminal]
 ----

modules/nodes-nodes-working-marking.adoc

@@ -6,10 +6,14 @@
 [id="nodes-nodes-working-marking_{context}"]
 = Understanding how to mark nodes as unschedulable or schedulable
 
+[role="_abstract"]
+You can mark a node as unschedulable in order to block any new pods from being scheduled on the node. 
+
+When you mark a node as unschedulable, existing pods on the node are not affected.
+
 By default, healthy nodes with a `Ready` status are
 marked as schedulable, which means that you can place new pods on the
-node. Manually marking a node as unschedulable blocks any new pods from being
-scheduled on the node. Existing pods on the node are not affected.
+node.
 
 * The following command marks a node or nodes as unschedulable:
 +
@@ -42,5 +46,5 @@ node1.example.com    kubernetes.io/hostname=node1.example.com      Ready,Schedul
 $ oc adm uncordon <node1>
 ----
 +
-Alternatively, instead of specifying specific node names (for example, `<node>`), you can use the `--selector=<node_selector>` option to mark selected
+Instead of specifying specific node names (for example, `<node>`), you can use the `--selector=<node_selector>` option to mark selected
 nodes as schedulable or unschedulable.