Improvement for LimitRange Documentation.

content/en/docs/concepts/policy/limit-range.md

@@ -11,14 +11,18 @@ weight: 10
 
 <!-- overview -->
 
-By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster.
+By default, containers run with unbounded
+[compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster.
 Using  Kubernetes [resource quotas](/docs/concepts/policy/resource-quotas/),
 administrators (also termed _cluster operators_) can restrict consumption and creation
 of cluster resources (such as CPU time, memory, and persistent storage) within a specified
 {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
-Within a namespace, a {{< glossary_tooltip text="Pod" term_id="Pod" >}} can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace. As a cluster operator, or as a namespace-level administrator, you might also be concerned about making sure that a single object cannot monopolize all available resources within a namespace.
+Within a namespace, a {{< glossary_tooltip text="Pod" term_id="Pod" >}} can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace.
+As a cluster operator, or as a namespace-level administrator, you might also be concerned
+about making sure that a single object cannot monopolize all available resources within a namespace.
 
-A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for each applicable object kind (such as Pod or {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}) in a namespace.
+A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for
+each applicable object kind (such as Pod or {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}) in a namespace.
 
 <!-- body -->
 
@@ -29,7 +33,6 @@ A _LimitRange_ provides constraints that can:
 - Enforce a ratio between request and limit for a resource in a namespace.
 - Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
 
-
 A LimitRange is enforced in a particular namespace when there is a
 LimitRange object in that namespace.
 
@@ -40,43 +43,49 @@ The name of a LimitRange object must be a valid
 
 - The administrator creates a LimitRange in a namespace.
 - Users create (or try to create) objects in that namespace, such as Pods or PersistentVolumeClaims.
-- First, the `LimitRange` admission controller applies default request and limit values for all Pods (and their containers) that do not set compute resource requirements.
-- Second, the `LimitRange` tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any `LimitRange` present in the namespace.
-- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates a `LimitRange` constraint, your request to the API server will fail with an HTTP status code `403 Forbidden` and a message explaining the constraint that has been violated.
-- If you add a `LimitRange` in a namespace that applies to compute-related resources such as
- `cpu` and `memory`, you must specify
-  requests or limits for those values. Otherwise, the system may reject Pod creation.
-- `LimitRange` validations occur only at Pod admission stage, not on running Pods.
-  If you add or modify a LimitRange, the Pods that already exist in that namespace
-  continue unchanged.
-- If two or more `LimitRange` objects exist in the namespace, it is not deterministic which default value will be applied.
+- First, the LimitRange admission controller applies default request and limit values for all Pods (and their containers) that do not set compute resource requirements.
+- Second, the LimitRange tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
+- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates a LimitRange constraint,
+your request to the API server will fail with an HTTP status code `403 Forbidden` and a message explaining the constraint that has been violated.
+- If you add a LimitRange in a namespace that applies to compute-related resources such as `cpu` and `memory`, you must specify
+requests or limits for those values. Otherwise, the system may reject Pod creation.
+- LimitRange validations occur only at Pod admission stage, not on running Pods.
+If you add or modify a LimitRange, the Pods that already exist in that namespace continue unchanged.
+- If two or more LimitRange objects exist in the namespace, it is not deterministic which default value will be applied.
 
 ## LimitRange and admission checks for Pods
 
-A `LimitRange` does **not** check the consistency of the default values it applies. This means that a default value for the _limit_ that is set by `LimitRange` may be less than the _request_ value specified for the container in the spec that a client submits to the API server. If that happens, the final Pod will not be schedulable.
+A LimitRange does **not** check the consistency of the default values it applies. This means that a default value for
+the _limit_ that is set by LimitRange may be less than the _request_ value specified for the container in the spec
+that a client submits to the API server. If that happens, the final Pod will not be schedulable.
 
-For example, you define a `LimitRange` with this manifest:
+For example, you define a LimitRange with below manifest:
+{{< note >}}
+The following examples operate within the default namespace of your cluster, as the namespace
+parameter is undefined and the LimitRange scope is limited to the namespace level.
+This implies that any references or operations within these examples will interact with elements
+within the default namespace of your cluster. You can override the operating namespace
+by configuring namespace in the `metadata.namespace` field.
+{{< /note >}}
 
 {{% code_sample file="concepts/policy/limit-range/problematic-limit-range.yaml" %}}
 
-
 along with a Pod that declares a CPU resource request of `700m`, but not a limit:
 
 {{% code_sample file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" %}}
 
-
 then that Pod will not be scheduled, failing with an error similar to:
 ```
 Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit
 ```
 
-If you set both `request` and `limit`, then that new Pod will be scheduled successfully even with the same `LimitRange` in place:
+If you set both `request` and `limit`, then that new Pod will be scheduled successfully even with the same LimitRange in place:
 
 {{% code_sample file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}}
 
 ## Example resource constraints
 
-Examples of policies that could be created using `LimitRange` are:
+Examples of policies that could be created using LimitRange are:
 
 - In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi for Memory with a max limit of 600Mi for Memory.
 - Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs.
@@ -97,5 +106,4 @@ For examples on using limits, see:
 - [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
 - a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
 
-Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for context and historical information.
-
+Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for context and historical information.