Merge pull request #27899 from mburke5678/nodes-terminology

Updating terminology for nodes

Author: mburke5678

_topic_map.yml

@@ -1257,9 +1257,9 @@ Topics:
   - Name: Configuring a cluster for Pods
     File: nodes-pods-configuring
     Distros: openshift-enterprise,openshift-webscale,openshift-origin
-  - Name: Automatically scaling pods with the Horizontal Pod Autoscaler
+  - Name: Automatically scaling pods with the horizontal pod autoscaler
     File: nodes-pods-autoscaling
-  - Name: Automatically adjust pod resource levels with the Vertical Pod Autoscaler
+  - Name: Automatically adjust pod resource levels with the vertical pod autoscaler
     File: nodes-pods-vertical-autoscaler
   - Name: Providing sensitive data to Pods
     File: nodes-pods-secrets

modules/cluster-autoscaler-about.adoc

@@ -56,7 +56,7 @@ maximum node pools that you configure.
 your cloud provider.
 
 
-The Horizontal Pod Autoscaler (HPA) and the ClusterAutoscaler modify cluster
+The horizontal pod autoscaler (HPA) and the ClusterAutoscaler modify cluster
 resources in different ways. The HPA changes the deployment's or ReplicaSet's
 number of replicas based on the current CPU load.
 If the load increases, the HPA creates new replicas, regardless of the amount

modules/jaeger-config-collector.adoc

@@ -68,7 +68,7 @@ Autoscaling is only supported for Jaeger 1.20 or later.
 
 You can configure the Collector to autoscale; the Collector will scale up or down based on the CPU and/or memory consumption.  Configuring the Collector to autoscale can help you ensure your Jaeger environment scales up during times of increased load, and scales down when less resources are needed, saving on costs.  You configure autoscaling by setting the `autoscale` parameter to `true` and specifying a value for `.spec.collector.maxReplicas` along with a reasonable value for the resources that you expect the Collector’s pod to consume. If you do not set a value for `.spec.collector.maxReplicas` the Operator will set it to `100`.
 
-By default, when there is no value provided for `.spec.collector.replicas`, the Jaeger Operator creates  a Horizontal Pod Autoscaler (HPA) configuration for the Collector.  For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].
+By default, when there is no value provided for `.spec.collector.replicas`, the Jaeger Operator creates  a horizontal pod autoscaler (HPA) configuration for the Collector.  For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].
 
 The following is an example autoscaling configuration, setting the Collector’s limits as well as the maximum number of replicas:
 

modules/jaeger-config-ingester.adoc

@@ -90,7 +90,7 @@ Autoscaling is only supported for Jaeger 1.20 or later.
 
 You can configure the Ingester to autoscale; the Ingester will scale up or down based on the CPU and/or memory consumption.  Configuring the Ingester to autoscale can help you ensure your Jaeger environment scales up during times of increased load, and scales down when less resources are needed, saving on costs. You configure autoscaling by setting the `autoscale` parameter to `true` and specifying a value for `.spec.ingester.maxReplicas` along with a reasonable value for the resources that you expect the Ingester's pod to consume. If you do not set a value for `.spec.ingester.maxReplicas` the Operator will set it to `100`.
 
-By default, when there is no value provided for `.spec.ingester.replicas`, the Jaeger Operator creates  a Horizontal Pod Autoscaler (HPA) configuration for the Ingester.  For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].
+By default, when there is no value provided for `.spec.ingester.replicas`, the Jaeger Operator creates  a horizontal pod autoscaler (HPA) configuration for the Ingester.  For more information about HPA, refer to the link:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[Kubernetes documentation].
 
 The following is an example autoscaling configuration, setting the Ingester’s limits as well as the maximum number of replicas:
 

modules/nodes-cluster-enabling-features-cluster.adoc

@@ -7,7 +7,7 @@
 = Enabling Technology Preview features using feature gates
 
 You can turn on Technology Preview features on for all nodes in the cluster by
-editing the Feature Gate Custom Resource, named `cluster`, in the `openshift-config` project.
+editing the `FeatureGate` custom resource, named `cluster`, in the `openshift-config` project.
 
 The following Technology Preview features are enabled by feature gates:
 
@@ -17,7 +17,7 @@ The following Technology Preview features are enabled by feature gates:
 
 [IMPORTANT]
 ====
-Turning on Technology Preview features using the Feature Gate Custom Resource cannot be undone and prevents upgrades.
+Turning on Technology Preview features using the `FeatureGate` custom resource cannot be undone and prevents upgrades.
 ====
 
 .Procedure

modules/nodes-cluster-features-about.adoc

@@ -5,7 +5,7 @@
 [id="nodes-cluster-features-about_{context}"]
 = Understanding feature gates and Technology Preview features
 
-You can use the Feature Gate Custom Resource to enable Technology Preview
+You can use the `FeatureGate` custom resource to enable Technology Preview
 features throughout your cluster. This allows you, for example, to enable
 Technology Preview features on test clusters where you can fully test them while
 ensuring they are disabled on production clusters.

modules/nodes-cluster-limit-ranges-about.adoc

@@ -5,13 +5,13 @@
 [id="nodes-cluster-limit-ranges-about_{context}"]
 = About limit ranges
 
-A limit range, defined by a LimitRange object, restricts resource
+A limit range, defined by a `LimitRange` object, restricts resource
 consumption in a project. In the project you can set specific resource
 limits for a pod, container, image, image stream, or
 persistent volume claim (PVC).
 
 All requests to create and modify resources are evaluated against each
-LimitRange object in the project. If the resource violates any of the
+`LimitRange` object in the project. If the resource violates any of the
 enumerated constraints, the resource is rejected.
 
 ifdef::openshift-online[]

modules/nodes-cluster-limit-ranges-creating.adoc

@@ -7,7 +7,7 @@
 
 To apply a limit range to a project: 
 
-. Create a limit range object with your required specifications: 
+. Create a `LimitRange` object with your required specifications: 
 +
 [source,yaml]
 ----
@@ -52,7 +52,7 @@ spec:
       max:
         storage: "50Gi"
 ----
-<1> Specify a name for the LimitRange object.
+<1> Specify a name for the `LimitRange` object.
 <2> To set limits for a pod, specify the minimum and maximum CPU and memory requests as needed.
 <3> To set limits for a container, specify the minimum and maximum CPU and memory requests as needed.
 <4> Optional. For a container, specify the default amount of CPU or memory that a container can use, if not specified in the `Pod` spec.

modules/nodes-cluster-limit-ranges-deleting.adoc

@@ -6,7 +6,7 @@
 = Deleting a Limit Range
 
 
-To remove any active limit range to no longer enforce the limits in a project:
+To remove any active `LimitRange` object to no longer enforce the limits in a project:
 
 . Run the following command:
 +

modules/nodes-cluster-limit-ranges-limits.adoc

@@ -6,7 +6,7 @@
 = About component limits
 
 The following examples show limit range parameters for each component. The
-examples are broken out for clarity. You can create a single limit range object
+examples are broken out for clarity. You can create a single `LimitRange` object
 for any or all components as necessary.
 
 [id="nodes-cluster-limit-container-limits"]
@@ -15,23 +15,23 @@ for any or all components as necessary.
 A limit range allows you to specify the minimum and maximum CPU and memory that each container
 in a pod can request for a specific project. If a container is created in the project,
 the container CPU and memory requests in the `Pod` spec must comply with the values set in the
-limit range object. If not, the pod does not get created.
+`LimitRange` object. If not, the pod does not get created.
 
 * The container CPU or memory request and limit must be greater than or equal to the
-`min` resource constraint for containers that are specified in the limit range object.
+`min` resource constraint for containers that are specified in the `LimitRange` object.
 
 * The container CPU or memory request must be less than or equal to the
-`max` resource constraint for containers that are specified in the limit range object.
+`max` resource constraint for containers that are specified in the `LimitRange` object.
 +
-If the limit range defines a `max` CPU, you do not need to define a CPU
+If the `LimitRange` object defines a `max` CPU, you do not need to define a CPU
 `request` value in the `Pod` spec. But you must specify a CPU `limit` value that
 satisfies the maximum CPU constraint specified in the limit range.
 
 * The ratio of the container limits to requests must be
 less than or equal to the `maxLimitRequestRatio` value for containers that
-is specified in the limit range object.
+is specified in the `LimitRange` object.
 +
-If the limit range defines a `maxLimitRequestRatio` constraint, any new
+If the `LimitRange` object defines a `maxLimitRequestRatio` constraint, any new
 containers must have both a `request` and a `limit` value. {product-title}
 calculates the limit-to-request ratio by dividing the `limit` by the
 `request`. This value should be a non-negative integer greater than 1.
@@ -44,7 +44,7 @@ If the `Pod` spec does not specify a container resource memory or limit,
 the `default` or `defaultRequest` CPU and memory values for containers
 specified in the limit range object are assigned to the container.
 
-.Container LimitRange object definition
+.Container `LimitRange` object definition
 
 [source,yaml]
 ----
@@ -71,12 +71,12 @@ spec:
         cpu: "10" <10>
 ----
 <1> The name of the LimitRange object.
-<2> The maximum amount of CPU that a single container in a Pod can request.
-<3> The maximum amount of memory that a single container in a Pod can request.
-<4> The minimum amount of CPU that a single container in a Pod can request.
+<2> The maximum amount of CPU that a single container in a pod can request.
+<3> The maximum amount of memory that a single container in a pod can request.
+<4> The minimum amount of CPU that a single container in a pod can request.
 Not setting a `min` value or setting `0` is unlimited, allowing the
 Pod to consume more than the `max` CPU value.
-<5> The minimum amount of memory that a single container in a Pod can request.
+<5> The minimum amount of memory that a single container in a pod can request.
 Not setting a `min` value or setting `0` is unlimited, allowing the
 Pod to consume more than the `max` memory value.
 <6> The default amount of CPU that a container can use if not specified in the `Pod` spec.
@@ -91,21 +91,21 @@ Pod to consume more than the `max` memory value.
 
 A limit range allows you to specify the minimum and maximum CPU and memory limits for all containers
 across a pod in a given project. To create a container in the project, the container CPU and memory
-requests in the `Pod` spec must comply with the values set in the limit range object. If not,
+requests in the `Pod` spec must comply with the values set in the `LimitRange` object. If not,
 the pod does not get created.
 
 Across all containers in a pod, the following must hold true:
 
 * The container CPU or memory request and limit must be greater than or equal to the
-`min` resource constraints for pods that are specified in the limit range object.
+`min` resource constraints for pods that are specified in the `LimitRange` object.
 
 * The container CPU or memory request and limit must be less than or equal to the
-`max` resource constraints for pods that are specified in the limit range object.
+`max` resource constraints for pods that are specified in the `LimitRange` object.
 
 * The ratio of the container limits to requests must be less than or equal to
-the `maxLimitRequestRatio` constraint specified in the limit range object.
+the `maxLimitRequestRatio` constraint specified in the `LimitRange` object.
 
-.Pod LimitRange object definition
+.Pod `LimitRange` object definition
 
 [source,yaml]
 ----
@@ -126,28 +126,28 @@ spec:
         cpu: "10" <6>
 ----
 <1> The name of the limit range object.
-<2> The maximum amount of CPU that a Pod can request across all containers.
-<3> The maximum amount of memory that a Pod can request across all containers.
-<4> The minimum amount of CPU that a Pod can request across all containers.
-Not setting a `min` value or setting `0` is unlimited, allowing the Pod to
+<2> The maximum amount of CPU that a pod can request across all containers.
+<3> The maximum amount of memory that a pod can request across all containers.
+<4> The minimum amount of CPU that a pod can request across all containers.
+Not setting a `min` value or setting `0` is unlimited, allowing the pod to
 consume more than the `max` CPU value.
-<5> The minimum amount of memory that a Pod can request across all containers.
-Not setting a `min` value or setting `0` is unlimited, allowing the Pod to
+<5> The minimum amount of memory that a pod can request across all containers.
+Not setting a `min` value or setting `0` is unlimited, allowing the pod to
 consume more than the `max` memory value.
 <6> The maximum limit-to-request ratio for a container.
 
 [id="nodes-cluster-limit-image-limits"]
 == Image limits
 
-A limit range allows you to specify the maximum size of an image
+A `LimitRange` object allows you to specify the maximum size of an image
 that can be pushed to an internal registry.
 
 When pushing images to an internal registry, the following must hold true:
 
 * The size of the image must be less than or equal to the `max` size for
-images that is specified in the limit range object.
+images that is specified in the `LimitRange` object.
 
-.Image LimitRange object definition
+.Image `LimitRange` object definition
 
 [source,yaml]
 ----
@@ -161,7 +161,7 @@ spec:
       max:
         storage: 1Gi <2>
 ----
-<1> The name of the limit range object.
+<1> The name of the `LimitRange` object.
 <2> The maximum size of an image that can be pushed to an internal registry.
 
 ifdef::openshift-enterprise,openshift-origin[]
@@ -188,19 +188,18 @@ addressed.
 [id="nodes-cluster-limit-stream-limits"]
 == Image stream limits
 
-A limit range allows you to specify limits for image streams.
+A `LimitRange` object allows you to specify limits for image streams.
 
 For each image stream, the following must hold true:
 
 * The number of image tags in an `ImageStream` specification must be less
-than or equal to the `openshift.io/image-tags` constraint in the limit range
-object.
+than or equal to the `openshift.io/image-tags` constraint in the `LimitRange` object.
 
 * The number of unique references to images in an `ImageStream` specification
 must be less than or equal to the `openshift.io/images` constraint in the limit
 range object.
 
-.Imagestream LimitRange object definition
+.Imagestream `LimitRange` object definition
 
 [source,yaml]
 ----
@@ -215,11 +214,11 @@ spec:
         openshift.io/image-tags: 20 <2>
         openshift.io/images: 30 <3>
 ----
-<1> The name of the limit range object.
+<1> The name of the `LimitRange` object.
 <2> The maximum number of unique image tags in the `imagestream.spec.tags`
 parameter in imagestream spec.
 <3> The maximum number of unique image references in the `imagestream.status.tags`
-parameter in the imagestream spec.
+parameter in the `imagestream` spec.
 
 The `openshift.io/image-tags` resource represents unique image
 references. Possible references are an `*ImageStreamTag*`, an
@@ -231,24 +230,24 @@ restrict pushes to an internal container image registry in any way, but is usefu
 restriction.
 
 The `openshift.io/images` resource represents unique image names recorded in
-imagestream status. It allows for restriction of a number of images that can be
+image stream status. It allows for restriction of a number of images that can be
 pushed to the internal registry. Internal and external references are not
 distinguished.
 
 [id="nodes-cluster-limit-pvc-limits"]
 == Persistent volume claim limits
 
-A limit range allows you to restrict the storage requested in a persistent volume claim (PVC).
+A `LimitRange` object allows you to restrict the storage requested in a persistent volume claim (PVC).
 
 Across all persistent volume claims in a project, the following must hold true:
 
 * The resource request in a persistent volume claim (PVC) must be greater than or equal
-the `min` constraint for PVCs that is specified in the limit range object.
+the `min` constraint for PVCs that is specified in the `LimitRange` object.
 
 * The resource request in a persistent volume claim (PVC) must be less than or equal
-the `max` constraint for PVCs that is specified in the limit range object.
+the `max` constraint for PVCs that is specified in the `LimitRange` object.
 
-.PVC LimitRange object definition
+.PVC `LimitRange` object definition
 
 [source,yaml]
 ----
@@ -264,7 +263,7 @@ spec:
       max:
         storage: "50Gi" <3>
 ----
-<1> The name of the limit range object.
+<1> The name of the `LimitRange` object.
 <2> The minimum amount of storage that can be requested in a persistent volume claim.
 <3> The maximum amount of storage that can be requested in a persistent volume claim.