From 6635262bbc5db7c8af96e8d909163d0243a6facd Mon Sep 17 00:00:00 2001 From: Kubernetes Prow Robot Date: Thu, 5 Mar 2020 11:28:38 -0800 Subject: [PATCH] Resource name constraints (4) (#19121) xref: #17969, #19099, #18746 --- content/en/docs/concepts/architecture/nodes.md | 2 ++ content/en/docs/concepts/configuration/secret.md | 8 ++++++-- content/en/docs/concepts/policy/resource-quotas.md | 3 +++ .../docs/concepts/services-networking/endpoint-slices.md | 2 ++ content/en/docs/concepts/services-networking/ingress.md | 8 +++++--- content/en/docs/concepts/services-networking/service.md | 2 ++ content/en/docs/concepts/storage/persistent-volumes.md | 8 ++++++++ .../workloads/controllers/replicationcontroller.md | 2 ++ .../tasks/administer-cluster/declare-network-policy.md | 5 +++-- .../configure-pod-container/configure-service-account.md | 3 +++ 10 files changed, 36 insertions(+), 7 deletions(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index cf7bdac64b..338e9a2408 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/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. diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 61995234e3..356c252fb5 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/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 diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 92f43fe3a3..d48c2db88a 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/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, diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 99df547592..4b347f47ec 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/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. diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 6739cf1bd0..667e374110 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/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) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 3ca465c64a..fbecdb3316 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/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`: diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index e61dfe48ba..003b1836c5 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/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 diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index d214fca612..bf020b958b 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/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). diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md index edb389c46f..0fdbff57b8 100644 --- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md +++ b/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 diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index f42bc8e1fd..f4917b36a9 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/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