diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index c96ae1f5c7..15f3f7e234 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/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 diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 8627978427..f2feb36515 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/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 diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6e83992421..03c58c6525 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/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). diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 42451f0089..5e8c6d67f3 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/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 diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4519cb4bec..aa6a07788b 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/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. diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index ef5f904079..037187499a 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -246,6 +246,9 @@ spec: caBundle: ``` +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, diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md index 7ca0a45a0f..4b1d424066 100644 --- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/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`.