Merge branch 'master' of git://github.com/kubernetes/website into release-1.12

* 'master' of git://github.com/kubernetes/website: (222 commits) Add temporary owners for 1.13 release (#11453) fix Minikube 404 error. (#11461) Resolve conflicts against dev-1.13 for /ko contents (#11439) replace `run` with `create deployment` (#11392) Updated list all pods with -o wide comment (#11394) fix broken link for KubeletConfiguration (#11423) Update on pod-priority-preemption.md (#11418) Add guidelines for working with localized content (#11415) Update what-is-kubernetes.md (#11399) Remove redundant close tags and little bit formatting (#11389) Add SysEleven MetaKube as hosted solution (#11393) Add rui to sig-docs-zh team (#11391) fix Improper translation (#11384) Add pigletfly(WangBing) as a sig-docs-zh-reviewer (#11370) update link to CloudProvider Interface (#11228) Fix the "my-scheduler-as-kube-scheduler" ClusterRoleBinding. (#11112) fix non-existing "CloudProvider Interface" link (#10953) Updated ingress.md (#11213) Further updates to TLS Bootstrapping (#11258) Updated 'exec' description (#11365) ...
2018-12-03 17:11:43 -05:00
parent 4fa6d715ec b1dde5578c
commit 6e094fa640
399 changed files with 3635 additions and 14434 deletions
@@ -1,5 +1,5 @@
 ---
 title: "Workloads"
-weight: 60
+weight: 50
 ---

@@ -14,8 +14,9 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com

 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
+
 {{< note >}}
-**Note:** All **CronJob** `schedule:` times are denoted in UTC.
+All **CronJob** `schedule:` times are denoted in UTC.
 {{< /note >}}

 For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
@@ -20,7 +20,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
 You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

 {{< note >}}
-**Note:** You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
+You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
 {{< /note >}}

 {{% /capture %}}
@@ -57,7 +57,7 @@ In this example:
  as long as the Pod template itself satisfies the rule.
  
  {{< note >}}
-  **Note:** `matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map 
+  `matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map 
  is equivalent to an element of `matchExpressions`, whose key field is "key", the operator is "In",
  and the values array contains only "value". The requirements are ANDed.
  {{< /note >}}
@@ -74,11 +74,11 @@ In this example:
 To create this Deployment, run the following command:

 ```shell
-kubectl create -f  https://k8s.io/examples/controllers/nginx-deployment.yaml
+kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```

 {{< note >}}
-**Note:** You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future instrospection, for example to see the commands executed in each Deployment revision.
+You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection, for example to see the commands executed in each Deployment revision.
 {{< /note >}}

 Next, run `kubectl get deployments`. The output is similar to the following:
@@ -145,14 +145,14 @@ nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app
 The created ReplicaSet ensures that there are three `nginx` Pods running at all times.

 {{< note >}}
-**Note:** You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
+You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
 `app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
 {{< /note >}}

 ### Pod-template-hash label

 {{< note >}}
-**Note:** Do not change this label.
+Do not change this label.
 {{< /note >}}

 The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
@@ -163,7 +163,7 @@ and in any existing Pods that the ReplicaSet might have.
 ## Updating a Deployment

 {{< note >}}
-**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
+A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
 is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
 {{< /note >}}

@@ -307,7 +307,7 @@ In any case, if you need to perform a label selector update, exercise great caut
 all of the implications.

 {{< note >}}
-**Note:** In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
+In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
 {{< /note >}}

 * Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,
@@ -326,7 +326,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha
 (you can change that by modifying revision history limit).

 {{< note >}}
-**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
+A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
 new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
 for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
 do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling.
@@ -373,7 +373,7 @@ nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
 ```

 {{< note >}}
-**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
+The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
 ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
 Kubernetes by default sets the value to 25%.
 {{< /note >}}
@@ -681,7 +681,7 @@ nginx-3926361531   3         3         3         28s
 ```

 {{< note >}}
-**Note:** You cannot rollback a paused Deployment until you resume it.
+You cannot rollback a paused Deployment until you resume it.
 {{< /note >}}

 ## Deployment status
@@ -754,13 +754,13 @@ attributes to the Deployment's `.status.conditions`:
 See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.

 {{< note >}}
-**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
+Kubernetes will take no action on a stalled Deployment other than to report a status condition with
 `Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
 example, rollback the Deployment to its previous version.
 {{< /note >}}

 {{< note >}}
-**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
+If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
 safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
 deadline.
 {{< /note >}}
@@ -865,7 +865,7 @@ this Deployment you want to retain. The rest will be garbage-collected in the ba
 it is 10.

 {{< note >}}
-**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
+Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
 thus that Deployment will not be able to roll back.
 {{< /note >}}

@@ -916,7 +916,7 @@ from `.spec.template` or if the total number of such Pods exceeds `.spec.replica
 Pods with `.spec.template` if the number of Pods is less than the desired number.

 {{< note >}}
-**Note:** You should not create other pods whose labels match this selector, either directly, by creating
+You should not create other pods whose labels match this selector, either directly, by creating
 another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
 do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
 {{< /note >}}
@@ -206,7 +206,7 @@ back-off count is reset if no new failed Pods appear before the Job's next
 status check.

 {{< note >}}
-**Note:** Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
+Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
 {{< /note >}}

 ## Job Termination and Cleanup
@@ -16,7 +16,7 @@ weight: 20
 {{% capture overview %}}

 {{< note >}}
-**NOTE:** A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
+A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
 {{< /note >}}

 A _ReplicationController_ ensures that a specified number of pod replicas are running at any one
@@ -16,7 +16,7 @@ weight: 40
 StatefulSet is the workload API object used to manage stateful applications.

 {{< note >}}
-**Note:** StatefulSets are stable (GA) in 1.9.
+StatefulSets are stable (GA) in 1.9.
 {{< /note >}}

 {{< glossary_definition term_id="statefulset" length="all" >}}
@@ -144,7 +144,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name)  | StatefulSet Domain
 kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |

 {{< note >}}
-**Note:** Cluster Domain will be set to `cluster.local` unless
+Cluster Domain will be set to `cluster.local` unless
 [otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
 {{< /note >}}

@@ -93,7 +93,7 @@ time as frequent voluntary disruptions.  We call this set of features
 ## How Disruption Budgets Work

 An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
-A PDB limits the number pods of a replicated application that are down simultaneously from
+A PDB limits the number of pods of a replicated application that are down simultaneously from
 voluntary disruptions.  For example, a quorum-based application would
 like to ensure that the number of replicas running is never brought below the
 number needed for a quorum. A web front end might want to
@@ -25,7 +25,7 @@ Pods in a Kubernetes cluster can be used in two main ways:
 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
 * **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.

-The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information on Pod use cases. For more information, see:
+The [Kubernetes Blog](http://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:

 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
 * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
@@ -55,7 +55,7 @@ A Pod can specify a set of shared storage *volumes*. All containers in the Pod c
 You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the pod is *evicted* for lack of resources, or the Node fails.

 {{< note >}}
-**Note:** Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
+Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
 {{< /note >}}

 Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
@@ -51,7 +51,7 @@ Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
 the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.

 {{< note >}}
-**Note:** A Pod Preset is capable of modifying the `.spec.containers` field in a
+A Pod Preset is capable of modifying the `.spec.containers` field in a
 Pod spec when appropriate. *No* resource definition from the Pod Preset will be
 applied to the `initContainers` field.
 {{< /note >}}