Resource name constraints (3) (#19120)

xref: #17969, #19099, #18746

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

@@ -33,7 +33,7 @@ one of its arguments.
 A limit range is enforced in a particular namespace when there is a
 `LimitRange` object in that namespace.
 
-### Overview of Limit Range:
+### Overview of Limit Range
 
 - The administrator creates one `LimitRange` in one namespace.
 - Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
@@ -43,7 +43,6 @@ A limit range is enforced in a particular namespace when there is a
   requests or limits for those values; otherwise, the system may reject pod creation.
 - LimitRange validations occurs only at Pod Admission stage, not on Running pods.
 
-
 Examples of policies that could be created using limit range are:
 
 - In a 2 node cluster with a capacity of 8 GiB RAM, and 16 cores, constrain Pods in a namespace to request 100m and not exceeds 500m for CPU , request 200Mi and not exceed 600Mi
@@ -76,6 +75,8 @@ Here is the configuration file for a LimitRange object:
 {{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}}
 
 This object defines minimum and maximum Memory/CPU limits,  default cpu/Memory requests  and default limits for CPU/Memory resources to be apply to containers.
+The name of a LimitRange object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command:
 

content/en/docs/concepts/services-networking/service.md

@@ -167,6 +167,9 @@ subsets:
       - port: 9376
 ```
 
+The name of the Endpoints object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 {{< note >}}
 The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or
 link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6).

content/en/docs/concepts/storage/persistent-volumes.md

@@ -41,7 +41,6 @@ resource.
 
 See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
 
-
 ## Lifecycle of a volume and claim
 
 PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle:
@@ -51,9 +50,11 @@ PVs are resources in the cluster. PVCs are requests for those resources and also
 There are two ways PVs may be provisioned: statically or dynamically.
 
 #### Static
+
 A cluster administrator creates a number of PVs. They carry the details of the real storage, which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
 
 #### Dynamic
+
 When none of the static PVs the administrator created match a user's `PersistentVolumeClaim`,
 the cluster may try to dynamically provision a volume specially for the PVC.
 This provisioning is based on `StorageClasses`: the PVC must request a
@@ -440,6 +441,8 @@ The CLI will show the name of the PVC bound to the PV.
 ## PersistentVolumeClaims
 
 Each PVC contains a spec and status, which is the specification and status of the claim.
+The name of a PersistentVolumeClaim object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 ```yaml
 apiVersion: v1

content/en/docs/concepts/workloads/controllers/cron-jobs.md

@@ -27,7 +27,8 @@ that the cron job controller uses.
 {{< /caution >}}
 
 When creating the manifest for a CronJob resource, make sure the name you provide
-is no longer than 52 characters. This is because the CronJob controller will automatically
+is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+The name must be no longer than 52 characters. This is because the CronJob controller will automatically
 append 11 characters to the job name provided and there is a constraint that the
 maximum length of a Job name is no more than 63 characters.
 

content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -114,6 +114,7 @@ The output is similar to this:
 ## Writing a Job Spec
 
 As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
+Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
 

content/en/docs/concepts/workloads/pods/pod.md

@@ -203,5 +203,7 @@ Your container runtime must support the concept of a privileged container for th
 Pod is a top-level resource in the Kubernetes REST API.
 The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition
 describes the object in detail.
+When creating the manifest for a Pod object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 {{% /capture %}}

content/en/docs/tasks/administer-cluster/namespaces.md

@@ -101,7 +101,8 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/
     kubectl create namespace <insert-namespace-name-here>
     ``` 
 
-Note that the name of your namespace must be a DNS compatible label.
+The name of your namespace must be a valid
+[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
 
 There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
 

content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md

@@ -33,6 +33,8 @@ kubectl create configmap <map-name> <data-source>
 ```
 
 where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from.
+The name of a ConfigMap object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 When you are creating a ConfigMap based on a file, the key in the \<data-source> defaults to the basename of the file, and the value defaults to the file content.
 

content/en/docs/tasks/debug-application-cluster/audit.md

@@ -235,6 +235,8 @@ spec:
 ```
 
 For the complete API definition, see [AuditSink](/docs/reference/generated/kubernetes-api/v1.13/#auditsink-v1alpha1-auditregistration). Multiple objects will exist as independent solutions.
+The name of an AuditSink object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 Existing static backends that you configure with runtime flags are not affected by this feature. However, the dynamic backends share the truncate options of the static webhook. If webhook truncate options are set with runtime flags, they are applied to all dynamic backends.
 

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -178,6 +178,8 @@ The beta version, which includes support for scaling on memory and custom metric
 can be found in `autoscaling/v2beta2`. The new fields introduced in `autoscaling/v2beta2`
 are preserved as annotations when working with `autoscaling/v1`.
 
+When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 More details about the API object can be found at
 [HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).