Resource name constraints (4) (#19121)

xref: #17969, #19099, #18746

content/en/docs/concepts/architecture/nodes.md

@@ -131,6 +131,8 @@ Kubernetes creates a node object internally (the representation), and
 validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary
 services are running -- it is eligible to run a pod. Otherwise, it is
 ignored for any cluster activity until it becomes valid.
+The name of a Node object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 {{< note >}}
 Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.

content/en/docs/concepts/configuration/secret.md

@@ -68,6 +68,8 @@ echo -n '1f2d1e2e67df' > ./password.txt
 
 The `kubectl create secret` command packages these files into a Secret and creates
 the object on the API server.
+The name of a Secret object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 ```shell
 kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
@@ -137,8 +139,10 @@ See [decoding a secret](#decoding-a-secret) to learn how to view the contents of
 #### Creating a Secret manually
 
 You can also create a Secret in a file first, in JSON or YAML format,
-and then create that object. The
-[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+and then create that object.
+The name of a Secret object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+The [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
 contains two maps:
 `data` and `stringData`. The `data` field is used to store arbitrary data, encoded using
 base64. The `stringData` field is provided for convenience, and allows you to provide

content/en/docs/concepts/policy/resource-quotas.md

@@ -37,6 +37,9 @@ Resource quotas work like this:
   the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements.
   See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
 
+The name of a `ResourceQuota` object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 Examples of policies that could be created using namespaces and quotas are:
 
 - In a cluster with a capacity of 32 GiB RAM, and 16 cores, let team A use 20 GiB and 10 cores,

content/en/docs/concepts/services-networking/endpoint-slices.md

@@ -32,6 +32,8 @@ for a Kubernetes Service when a {{< glossary_tooltip text="selector"
 term_id="selector" >}} is specified. These EndpointSlices will include
 references to any Pods that match the Service selector. EndpointSlices group
 network endpoints together by unique Service and Port combinations.
+The name of a EndpointSlice object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 As an example, here's a sample EndpointSlice resource for the `example`
 Kubernetes Service.

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

@@ -78,11 +78,13 @@ spec:
           servicePort: 80
 ```
 
- As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
- For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
+As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
+The name of an Ingress object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
  Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
  is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
- Different [Ingress controller](/docs/concepts/services-networking/ingress-controllers) support different annotations. Review the documentation for
+Different [Ingress controller](/docs/concepts/services-networking/ingress-controllers) support different annotations. Review the documentation for
  your choice of Ingress controller to learn which annotations are supported.
 
 The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)

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

@@ -73,6 +73,8 @@ balancer in between your application and the backend Pods.
 A Service in Kubernetes is a REST object, similar to a Pod.  Like all of the
 REST objects, you can `POST` a Service definition to the API server to create
 a new instance.
+The name of a Service object must be a valid
+[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
 
 For example, suppose you have a set of Pods that each listen on TCP port 9376
 and carry a label `app=MyApp`:

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

@@ -287,6 +287,8 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume
 ## Persistent Volumes
 
 Each PV contains a spec and status, which is the specification and status of the volume.
+The name of a PersistentVolume object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 ```yaml
 apiVersion: v1
@@ -577,6 +579,7 @@ Support for the additional plugins was added in 1.10.
 {{< /note >}}
 
 ### Persistent Volumes using a Raw Block Volume
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -595,6 +598,7 @@ spec:
     readOnly: false
 ```
 ### Persistent Volume Claim requesting a Raw Block Volume
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolumeClaim
@@ -608,7 +612,9 @@ spec:
     requests:
       storage: 10Gi
 ```
+
 ### Pod specification adding Raw Block Device path in container
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -665,6 +671,7 @@ To enable support for restoring a volume from a volume snapshot data source, ena
 `VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager.
 
 ### Create Persistent Volume Claim from Volume Snapshot
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolumeClaim
@@ -693,6 +700,7 @@ To enable support for cloning a volume from a PVC data source, enable the
 `VolumePVCDataSource` feature gate on the apiserver and controller-manager.
 
 ### Create Persistent Volume Claim from an existing pvc
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolumeClaim

content/en/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -116,6 +116,8 @@ specifies an expression that just gets the name from each pod in the returned li
 ## Writing a ReplicationController Spec
 
 As with all other Kubernetes config, a ReplicationController needs `apiVersion`, `kind`, and `metadata` fields.
+The name of a ReplicationController object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 For general information about working with config files, see [object management ](/docs/concepts/overview/working-with-objects/object-management/).
 
 A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

content/en/docs/tasks/administer-cluster/declare-network-policy.md

@@ -90,10 +90,11 @@ To limit the access to the `nginx` service so that only Pods with the label `acc
 
 {{< codenew file="service/networking/nginx-policy.yaml" >}}
 
+The name of a NetworkPolicy object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 {{< note >}}
-
 NetworkPolicy includes a `podSelector` which selects the grouping of Pods to which the policy applies. You can see this policy selects Pods with the label `app=nginx`. The label was automatically added to the Pod in the `nginx` Deployment. An empty `podSelector` selects all pods in the namespace.
-
 {{< /note >}}
 
 ## Assign the policy to the service

content/en/docs/tasks/configure-pod-container/configure-service-account.md

@@ -95,6 +95,9 @@ metadata:
 EOF
 ```
 
+The name of a ServiceAccount object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 If you get a complete dump of the service account object, like this:
 
 ```shell