kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #829 from Kashomon/master 

Capitalize replica set -> Replica Set for consistency.
pull/833/merge
johndmulhausen 2016-07-14 12:49:28 -07:00 committed by GitHub
parent 383a1a95e1 8240c9259a
commit 0025e131e6
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/user-guide/replicasets.md
View File

@ -22,16 +22,16 @@ instead. Also, the
imperative whereas Deployments are declarative, so we recommend using Deployments imperative whereas Deployments are declarative, so we recommend using Deployments
through the [`rollout`](/docs/user-guide/kubectl/kubectl_rollout/) command. through the [`rollout`](/docs/user-guide/kubectl/kubectl_rollout/) command.
While replica sets can be used independently, today it's mainly used by While Replica Sets can be used independently, today it's mainly used by
[Deployments](/docs/user-guide/deployments/) as a mechanism to orchestrate pod [Deployments](/docs/user-guide/deployments/) as a mechanism to orchestrate pod
creation, deletion and updates. When you use Deployments you don't have to worry creation, deletion and updates. When you use Deployments you don't have to worry
about managing the replica sets that they create. Deployments own and manage about managing the Replica Sets that they create. Deployments own and manage
their replica sets. their Replica Sets.
## When to use a Replica Set? ## When to use a Replica Set?
A Replica Set ensures that a specified number of pod “replicas” are running at any given A Replica Set ensures that a specified number of pod “replicas” are running at any given
time. However, a Deployment is a higher-level concept that manages replica sets and time. However, a Deployment is a higher-level concept that manages Replica Sets and
provides declarative updates to pods along with a lot of other useful features. provides declarative updates to pods along with a lot of other useful features.
Therefore, we recommend using Deployments instead of directly using Replica Sets, unless Therefore, we recommend using Deployments instead of directly using Replica Sets, unless
you require custom update orchestration or don't require updates at all. you require custom update orchestration or don't require updates at all.
@ -44,7 +44,7 @@ use directly a Deployment and define your application in the spec section.
{% include code.html language="yaml" file="replicasets/frontend.yaml" ghlink="/docs/user-guide/replicasets/frontend.yaml" %} {% include code.html language="yaml" file="replicasets/frontend.yaml" ghlink="/docs/user-guide/replicasets/frontend.yaml" %}
Saving this config into `frontend.yaml` and submitting it to a Kubernetes cluster should Saving this config into `frontend.yaml` and submitting it to a Kubernetes cluster should
create the defined replica set and the pods that it manages. create the defined Replica Set and the pods that it manages.
```shell ```shell
$ kubectl create -f frontend.yaml $ kubectl create -f frontend.yaml