Resource name constraints (2) (#19119)

xref: #17969, #19099, #18746

content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -128,7 +128,12 @@ Regardless of how they are installed, the new resources are referred to as Custo
 
 ## CustomResourceDefinitions
 
-The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource.
+The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+API resource allows you to define custom resources.
+Defining a CRD object creates a new custom resource with a name and schema that you specify.
+The Kubernetes API serves and handles the storage of your custom resource.
+The name of a CRD object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 This frees you from writing your own API server to handle the custom resource,
 but the generic nature of the implementation means you have less flexibility than with

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

@@ -39,7 +39,8 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f
 
 {{< codenew file="controllers/daemonset.yaml" >}}
 
-* Create a DaemonSet based on the YAML file:
+Create a DaemonSet based on the YAML file:
+
 ```
 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ```
@@ -50,6 +51,9 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and
 general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
 [configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.
 
+The name of a DaemonSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.
 
 ### Pod Template

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

@@ -1020,6 +1020,8 @@ can create multiple Deployments, one for each release, following the canary patt
 As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
 configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
+The name of a Deployment object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 A Deployment 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/controllers/replicaset.md

@@ -58,22 +58,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```
 
 You can then get the current ReplicaSets deployed:
+
 ```shell
 kubectl get rs
 ```
 
 And see the frontend one you created:
+
 ```shell
 NAME       DESIRED   CURRENT   READY   AGE
 frontend   3         3         3       6s
 ```
 
-You can also check on the state of the replicaset:
+You can also check on the state of the ReplicaSet:
+
 ```shell
 kubectl describe rs/frontend
 ```
 
 And you will see output similar to:
+
 ```shell
 Name:         frontend
 Namespace:    default
@@ -103,11 +107,13 @@ Events:
 ```
 
 And lastly you can check for the Pods brought up:
+
 ```shell
 kubectl get pods
 ```
 
 You should see Pod information similar to:
+
 ```shell
 NAME             READY   STATUS    RESTARTS   AGE
 frontend-b2zdv   1/1     Running   0          6m36s
@@ -117,11 +123,13 @@ frontend-wtsmm   1/1     Running   0          6m36s
 
 You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
 To do this, get the yaml of one of the Pods running:
+
 ```shell
 kubectl get pods frontend-b2zdv -o yaml
 ```
 
 The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
+
 ```shell
 apiVersion: v1
 kind: Pod
@@ -166,11 +174,13 @@ The new Pods will be acquired by the ReplicaSet, and then immediately terminated
 its desired count.
 
 Fetching the Pods:
+
 ```shell
 kubectl get pods
 ```
 
 The output shows that the new Pods are either already terminated, or in the process of being terminated:
+
 ```shell
 NAME             READY   STATUS        RESTARTS   AGE
 frontend-b2zdv   1/1     Running       0          10m
@@ -181,17 +191,20 @@ pod2             0/1     Terminating   0          1s
 ```
 
 If you create the Pods first:
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```
 
 And then create the ReplicaSet however:
+
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```
 
 You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
 number of its new Pods and the original matches its desired count. As fetching the Pods:
+
 ```shell
 kubectl get pods
 ```
@@ -213,6 +226,9 @@ For ReplicaSets, the kind is always just ReplicaSet.
 In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
 Refer to the first lines of the `frontend.yaml` example for guidance.
 
+The name of a ReplicaSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
 
 ### Pod Template

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

@@ -109,10 +109,15 @@ In the above example:
 * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
 * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
 
+The name of a StatefulSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 ## Pod Selector
+
 You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
 
 ## Pod Identity
+
 StatefulSet Pods have a unique identity that is comprised of an ordinal, a
 stable network identity, and stable storage. The identity sticks to the Pod,
 regardless of which node it's (re)scheduled on.

content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md

@@ -246,6 +246,9 @@ spec:
   caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
 ```
 
+The name of an APIService object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+
 #### Contacting the extension apiserver
 
 Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver,

content/en/docs/tasks/manage-daemon/rollback-daemon-set.md

@@ -132,7 +132,8 @@ NAME                               CONTROLLER                     REVISION   AGE
 ```
 
 Each `ControllerRevision` stores the annotations and template of a DaemonSet
-revision.
+revision. The name of a ControllerRevision object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
 `kubectl rollout undo` takes a specific `ControllerRevision` and replaces
 DaemonSet template with the template stored in the `ControllerRevision`.