Merge remote-tracking branch 'upstream/master' into zacharysarah-merged-master-dev-1.18

2020-03-03 12:07:32 -08:00
parent 78193337e4 c04ffcdce8
commit 4582f017e2
115 changed files with 3895 additions and 613 deletions
@@ -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
@@ -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).

@@ -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
@@ -106,11 +110,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-9si5l   1/1       Running   0          1m
@@ -120,11 +126,13 @@ frontend-qhloh   1/1       Running   0          1m

 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-9si5l -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
@@ -169,11 +177,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-9si5l   1/1     Running       0          1m
@@ -183,17 +193,20 @@ pod2             0/1     Terminating   0          4s
 ```

 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
 ```
@@ -215,6 +228,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
@@ -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.