Merge pull request #1980 from joshrosso/statefulsets-typo-concise

statefulsets.md: Fix typos and make some statements more concise
This commit is contained in:
devin-donnelly 2016-12-20 19:28:12 -05:00 committed by GitHub
commit 7d1b3536e4
1 changed files with 12 additions and 13 deletions

View File

@ -32,12 +32,12 @@ following.
* Ordered, graceful deployment and scaling. * Ordered, graceful deployment and scaling.
* Ordered, graceful deletion and termination. * Ordered, graceful deletion and termination.
In the above, stable is synonymous with persistent across Pod (re) schedulings. In the above, stable is synonymous with persistence across Pod (re)schedulings.
If an application doesn't require any stable identifiers or ordered deployment, If an application doesn't require any stable identifiers or ordered deployment,
deletion, or scaling, you should deploy your application with a controller that deletion, or scaling, you should deploy your application with a controller that
provides a set of stateless replicas. Such controllers, such as provides a set of stateless replicas. Controllers such as
[Deployment](/docs/user-guide/deployments/) or [Deployment](/docs/user-guide/deployments/) or
[ReplicaSet](/docs/user-guide/replicasets/) may be better suited to your needs. [ReplicaSet](/docs/user-guide/replicasets/) may be better suited to your stateless needs.
### Limitations ### Limitations
* StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5. * StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
@ -52,7 +52,7 @@ The example below demonstrates the components of a StatefulSet.
* A Headless Service, named nginx, is used to control the network domain. * A Headless Service, named nginx, is used to control the network domain.
* The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods. * 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/user-guide/volumes/) provisioned by a * The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/user-guide/volumes/) provisioned by a
PersistentVolume Provisioner. PersistentVolume Provisioner.
```yaml ```yaml
@ -106,7 +106,7 @@ spec:
### Pod Identity ### Pod Identity
StatefulSet Pods have a unique identity that is comprised of an ordinal, a 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, stable network identity, and stable storage. The identity sticks to the Pod,
regardless of which node it's (re) scheduled on. regardless of which node it's (re)scheduled on.
__Ordinal Index__ __Ordinal Index__
@ -141,13 +141,12 @@ Note that Cluster Domain will be set to `cluster.local` unless
__Stable Storage__ __Stable Storage__
Kubernetes creates one [PersistentVolumes](/docs/user-guide/volumes/) for each Kubernetes creates one [PersistentVolume](/docs/user-guide/volumes/) for each
VolumeClaimTemplate, as specified in the StatefulSet's volumeClaimTemplates field VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
In the example above, each Pod will receive a single PersistentVolume with a storage with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled
class of `anything` and 1 Gib of provisioned storage. When a Pod is (re) scheduled onto onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
This must be done manually. This must be done manually.
### Deployment and Scaling Guarantee ### Deployment and Scaling Guarantee
@ -157,9 +156,9 @@ This must be done manually.
* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. * Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
* Before a Pod is terminated, all of its successors must be completely shutdown. * Before a Pod is terminated, all of its successors must be completely shutdown.
The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/#deleting-pods). The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/#deleting-pods).
When the web example above is created, three Pods will be deployed in the order When the nginx example above is created, three Pods will be deployed in the order
web-0, web-1, web-2. web-1 will not be deployed before web-0 is web-0, web-1, web-2. web-1 will not be deployed before web-0 is
[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until [Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until
web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before