Skip to content
Permalink
Browse files

Resource name constraints (4) (#19121)

  • Loading branch information
k8s-ci-robot committed Mar 5, 2020
1 parent 066b9f3 commit 6635262bbc5db7c8af96e8d909163d0243a6facd
@@ -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.
@@ -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
@@ -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,
@@ -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.
@@ -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)
@@ -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`:
@@ -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
@@ -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).
@@ -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" >}}

{{< note >}}
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
@@ -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

0 comments on commit 6635262

Please sign in to comment.
You can’t perform that action at this time.