Merge pull request #62485 from mburke5678/nodes-jobs-fix-errors

Nodes Jobs docs fixes during ROSA review

Author: mburke5678

modules/nodes-nodes-jobs-about.adoc

@@ -15,39 +15,39 @@ There are two possible resource types that allow creating run-once objects in {p
 
 Job::
 A regular job is a run-once object that creates a task and ensures the job finishes.
-
++
 There are three main types of task suitable to run as a job:
-
++
 * Non-parallel jobs:
 ** A job that starts only one pod, unless the pod fails.
 ** The job is complete as soon as its pod terminates successfully.
-
++
 * Parallel jobs with a fixed completion count:
 ** a job that starts multiple pods.
 ** The job represents the overall task and is complete when there is one successful pod for each value in the range `1` to the `completions` value.
-
++
 * Parallel jobs with a work queue:
 ** A job with multiple parallel worker processes in a given pod.
 ** {product-title} coordinates pods to determine what each should work on or use an external queue service.
 ** Each pod is independently capable of determining whether or not all peer pods are complete and that the entire job is done.
 ** When any pod from the job terminates with success, no new pods are created.
 ** When at least one pod has terminated with success and all pods are terminated, the job is successfully completed.
 ** When any pod has exited with success, no other pod should be doing any work for this task or writing any output. Pods should all be in the process of exiting.
-
++
 For more information about how to make use of the different types of job, see link:https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-patterns[Job Patterns] in the Kubernetes documentation.
 
 Cron job::
 
 A job can be scheduled to run multiple times, using a cron job.
-
++
 A _cron job_ builds on a regular job by allowing you to specify
 how the job should be run. Cron jobs are part of the
 link:http://kubernetes.io/docs/user-guide/cron-jobs[Kubernetes] API, which
 can be managed with `oc` commands like other object types.
-
++
 Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails.
 Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period. A cron job creates a `Job` object based on the timezone configured on the control plane node that runs the cronjob controller.
-
++
 [WARNING]
 ====
 A cron job creates a `Job` object approximately once per execution time of its

modules/nodes-nodes-jobs-creating-cron.adoc

@@ -40,6 +40,7 @@ spec:
             image: perl
             command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
           restartPolicy: OnFailure <10>
+#...
 ----
 +
 <1> Schedule for the job specified in link:https://en.wikipedia.org/wiki/Cron[cron format]. In this example, the job will run every minute.

modules/nodes-nodes-jobs-creating.adoc

@@ -34,6 +34,7 @@ spec:
         image: perl
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: OnFailure    <6>
+#...
 ----
 <1> Optional: Specify how many pod replicas a job should run in parallel; defaults to `1`.
 * For non-parallel jobs, leave unset. When unset, defaults to `1`.

modules/nodes-pods-daemonsets-creating.adoc

@@ -32,6 +32,7 @@ metadata:
   name: <namespace>
   annotations:
     openshift.io/node-selector: ''
+#...
 ----
 ====
 
@@ -76,6 +77,7 @@ spec:
         terminationMessagePath: /dev/termination-log
       serviceAccount: default
       terminationGracePeriodSeconds: 10
+#...
 ----
 <1> The label selector that determines which pods belong to the daemon set.
 <2> The pod template's label selector. Must match the label selector above.

nodes/jobs/nodes-nodes-jobs.adoc

@@ -36,6 +36,7 @@ spec:
         image: perl
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: OnFailure    <6>
+#...
 ----
 <1> The pod replicas a job should run in parallel.
 <2> Successful pod completions are needed to mark a job completed.

nodes/jobs/nodes-pods-daemonsets.adoc

@@ -29,23 +29,30 @@ the cluster.
 
 == Scheduled by default scheduler
 
-A daemon set ensures that all eligible nodes run a copy of a pod. Normally, the node that a pod runs on is selected by the Kubernetes scheduler. However, previously daemon set pods are created and scheduled by the daemon set controller. That introduces the following issues:
+A daemon set ensures that all eligible nodes run a copy of a pod. Normally, the node that a pod runs on is selected by the Kubernetes scheduler. However, daemon set pods are created and scheduled by the daemon set controller. That introduces the following issues:
 
 * Inconsistent pod behavior: Normal pods waiting to be scheduled are created and in Pending state, but daemon set pods are not created in `Pending` state. This is confusing to the user.
 * Pod preemption is handled by default scheduler. When preemption is enabled, the daemon set controller will make scheduling decisions without considering pod priority and preemption.
 
-The *ScheduleDaemonSetPods* feature, enabled by default in {product-title}, lets you to schedule daemon sets using the default scheduler instead of the daemon set controller, by adding the `NodeAffinity` term to the daemon set pods, instead of the `spec.nodeName` term. The default scheduler is then used to bind the pod to the target host. If node affinity of the daemon set pod already exists, it is replaced. The daemon set controller only performs these operations when creating or modifying daemon set pods, and no changes are made to the `spec.template` of the daemon set.
+The *ScheduleDaemonSetPods* feature, enabled by default in {product-title}, lets you schedule daemon sets using the default scheduler instead of the daemon set controller, by adding the `NodeAffinity` term to the daemon set pods, instead of the `spec.nodeName` term. The default scheduler is then used to bind the pod to the target host. If node affinity of the daemon set pod already exists, it is replaced. The daemon set controller only performs these operations when creating or modifying daemon set pods, and no changes are made to the `spec.template` of the daemon set.
 
 [source,yaml]
 ----
-nodeAffinity:
-  requiredDuringSchedulingIgnoredDuringExecution:
-    nodeSelectorTerms:
-    - matchFields:
-      - key: metadata.name
-        operator: In
-        values:
-        - target-host-name
+kind: Pod
+apiVersion: v1
+metadata:
+  name: hello-node-6fbccf8d9-9tmzr
+#...
+spec:
+  nodeAffinity:
+    requiredDuringSchedulingIgnoredDuringExecution:
+      nodeSelectorTerms:
+      - matchFields:
+        - key: metadata.name
+          operator: In
+          values:
+          - target-host-name
+#...
 ----
 
 In addition, a `node.kubernetes.io/unschedulable:NoSchedule` toleration is added automatically to daemon set pods. The default scheduler ignores unschedulable Nodes when scheduling daemon set pods.