whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Apply templates, some edits for style guide conformance (#4537)

Browse Source 
* edit for template, style guide conformance

* fix whitespace errors

* fix template errors
This commit is contained in:
Jennifer Rondeau
2017-07-31 19:43:08 -04:00
committed by Andrew Chen
parent d32de1bedb
commit d27df547b2
3 changed files with 121 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/workloads/controllers/deployment.md
+62 -56
View File
@@ -5,25 +5,29 @@ assignees:
title: Deployments title: Deployments
--- ---
{:toc} {% capture overview %}
## What is a Deployment?
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController). [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController).
You only need to describe the desired state in a Deployment object, and the Deployment controller will You describe the 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
change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new ReplicaSets, or remove existing Deployments and adopt all their resources with new Deployments.
create new ReplicaSets, or remove existing Deployments and adopt all of their resources with new Deployments.
**Note:** You should not manage ReplicaSets owned by a Deployment, otherwise you are racing with the Deployment **Note:** You should not manage ReplicaSets owned by a Deployment. If you do so, you are racing with the Deployment
controller! All of the use cases should be covered just by manipulating the Deployment object. Consider opening controller! 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. an issue in the main Kubernetes repository if your use case is not covered below.
{% endcapture %}
{% capture body %}
## Use Case
A typical use case is: A typical use case is:
* [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not. * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
* Later, [declare the new state of the Pods](#updating-a-deployment) you want to run by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old to the new ReplicaSet in a controlled rate. Each new ReplicaSet that is created, updates the revision of the Deployment. * [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment will not be stable. Each rollback updates the revision of the Deployment. * [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
* [Scale up the Deployment to facilitate more load.](#scaling-a-deployment) * [Scale up the Deployment to facilitate more load.](#scaling-a-deployment)
* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout. * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck * [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck
@@ -32,7 +36,7 @@ A typical use case is:
## Creating a Deployment ## Creating a Deployment
Here is an example Deployment. It creates a ReplicaSet to bring up 3 nginx Pods. Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods.
{% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %} {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %}
@@ -44,7 +48,7 @@ deployment "nginx-deployment" created
``` ```
Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of
the resources being created or updated. It will be useful for future introspection; for example, to see the the resources being created or updated. It is useful for future introspection: for example, to see the
commands executed in each Deployment revision. commands executed in each Deployment revision.
Then running `get` immediately will give: Then running `get` immediately will give:
@@ -59,7 +63,7 @@ This indicates that the Deployment's number of desired replicas is 3 (according
the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`)
is 0, and the number of available replicas (`.status.availableReplicas`) is also 0. is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
To see the Deployment rollout status, simply run: To see the Deployment rollout status, run:
```shell ```shell
$ kubectl rollout status deployment/nginx-deployment $ kubectl rollout status deployment/nginx-deployment
@@ -67,7 +71,7 @@ Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out deployment "nginx-deployment" successfully rolled out
``` ```
Running the `get` again a few seconds later, should give: Running the `get` again a few seconds later should give:
```shell ```shell
$ kubectl get deployments $ kubectl get deployments
@@ -95,31 +99,30 @@ nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app
nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
``` ```
The created ReplicaSet will ensure that there are three nginx Pods at all times. The created ReplicaSet ensures that there are three nginx Pods at all times.
**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case, **Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
`app = nginx`), i.e. don't overlap with other controllers (including other Deployments, ReplicaSets, `app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
StatefulSets, etc.). Kubernetes won't stop you from doing that, and if you end up with multiple StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
controllers that have overlapping selectors, those controllers may fight with each other and won't behave controllers have overlapping selectors, those controllers may fight with each other and won't behave
correctly. correctly.
### Pod-template-hash label ### Pod-template-hash label
**Note:** This label is not meant to be mutated by users! **Note:** This label is not meant to be changed by users!
Note the pod-template-hash label in the example output in the pod labels above. pod-template-hash is added by the Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
Deployment controller in every ReplicaSet that a Deployment creates or adopts. Its purpose is so that children Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
ReplicaSets of a Deployment will not overlap among them. It is computed by hashing the PodTemplate of the ReplicaSet ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet
and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels, and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels,
and in any existing Pods that the ReplicaSet may have. and in any existing Pods that the ReplicaSet may have.
## Updating a Deployment ## Updating a Deployment
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) **Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
is changed, e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, is changed, for example if the labels or container images of the templaet are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
will not trigger a rollout.
Suppose that we now want to update the nginx Pods to start using the `nginx:1.9.1` image Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image
instead of the `nginx:1.7.9` image. instead of the `nginx:1.7.9` image.
```shell ```shell
@@ -134,7 +137,7 @@ $ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited deployment "nginx-deployment" edited
``` ```
To see its rollout status, simply run: To see the rollout status, run:
```shell ```shell
$ kubectl rollout status deployment/nginx-deployment $ kubectl rollout status deployment/nginx-deployment
@@ -244,14 +247,14 @@ It is generally discouraged to make label selector updates and it is suggested t
In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
all of the implications. all of the implications.
* Selector additions require the pod template labels in the Deployment spec to be updated with the new label, too, * Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,
otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does
not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
creating a new ReplicaSet. creating a new ReplicaSet.
* Selector updates, i.e., changing the existing value in a selector key, result in the same behavior as additions. * Selector updates -- that is, changing the existing value in a selector key -- result in the same behavior as additions.
* Selector removals, i.e., removing an existing key from the Deployment selector, do not require any changes in the * Selector removals -- that is, removing an existing key from the Deployment selector -- do not require any changes in the
pod template labels, no existing ReplicaSet is orphaned, and a new ReplicaSet will not be created, but note that the pod template labels. No existing ReplicaSet is orphaned, and a new ReplicaSet is not created, but note that the
removed label will still exist in any existing Pods and ReplicaSets. removed label still exists in any existing Pods and ReplicaSets.
## Rolling Back a Deployment ## Rolling Back a Deployment
@@ -260,11 +263,11 @@ By default, all of the Deployment's rollout history is kept in the system so tha
(you can change that by modifyingrevision history limit]). (you can change that by modifyingrevision history limit]).
**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the **Note:** 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 (i.e. `.spec.template`) is changed, new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
will not create a Deployment revision -- so that we can facilitate simultaneous manual- or auto-scaling. do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
This implies that when you rollback to an earlier revision, only the Deployment's pod template part will This means that when you roll back to an earlier revision, only the Deployment's pod template part is
be rolled back. rolled back.
Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
@@ -627,7 +630,7 @@ due to some of the following factors:
One way you can detect this condition is to specify a deadline parameter in your Deployment spec: One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the
number of seconds the Deployment controller waits before indicating (via the Deployment status) that the number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
Deployment progress has stalled. Deployment progress has stalled.
The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report
@@ -782,7 +785,7 @@ the same schema as a [Pod](/docs/user-guide/pods), except it is nested and does
`apiVersion` or `kind`. `apiVersion` or `kind`.
In addition to required fields for a Pod, a pod template in a Deployment must specify appropriate In addition to required fields for a Pod, a pod template in a Deployment must specify appropriate
labels (i.e. don't overlap with other controllers, see [selector](#selector)) and an appropriate restart policy. labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is
allowed, which is the default if not specified. allowed, which is the default if not specified.
@@ -797,19 +800,19 @@ allowed, which is the default if not specified.
for the Pods targeted by this deployment. for the Pods targeted by this deployment.
If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by
the API. If `.spec.selector` is unspecified, `.spec.selector.matchLabels` will be defaulted to the API. If `.spec.selector` is unspecified, `.spec.selector.matchLabels` defaults to
`.spec.template.metadata.labels`. `.spec.template.metadata.labels`.
Deployment may kill Pods whose labels match the selector, in the case that their template is different A Deployment may terminate Pods whose labels match the selector if their template is different
than `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It will bring up new tfrom `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new
Pods with `.spec.template` if number of Pods are less than the desired number. Pods with `.spec.template` if the number of Pods is less than the desired number.
**Note:** You should not create other pods whose labels match this selector, either directly, via **Note:** You should not create other pods whose labels match this selector, either directly, by creating
another Deployment or via another controller such as ReplicaSets or ReplicationControllers. Otherwise, another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this. do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
If you have multiple controllers that have overlapping selectors, the controllers will fight with each If you have multiple controllers that have overlapping selectors, the controllers will fight with each
other's and won't behave correctly. other and won't behave correctly.
### Strategy ### Strategy
@@ -830,10 +833,9 @@ the rolling update process.
##### Max Unavailable ##### Max Unavailable
`.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number `.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number
of Pods that can be unavailable during the update process. The value can be an absolute number (e.g. 5) of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5)
or a percentage of desired Pods (e.g. 10%). The absolute number is calculated from percentage by or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by
rounding down. This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. By default, a rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.
value of 25% is used.
For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled
@@ -843,12 +845,12 @@ at all times during the update is at least 70% of the desired Pods.
##### Max Surge ##### Max Surge
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
that can be created above the desired number of Pods. Value can be an absolute number (e.g. 5) or a that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
percentage of desired Pods (e.g. 10%). This can not be 0 if `MaxUnavailable` is 0. The absolute number percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
is calculated from percentage by rounding up. By default, a value of 25% is used. is calculated from the percentage by rounding up. The default value is 25%.
For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
rolling update starts, such that the total number of old and new Pods do not exceed 130% of desired rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired
Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the
total number of Pods running at any time during the update is at most 130% of desired Pods. total number of Pods running at any time during the update is at most 130% of desired Pods.
@@ -914,3 +916,7 @@ it is created.
[Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers [Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
additional features, such as rolling back to any previous revision even after the rolling update is done. additional features, such as rolling back to any previous revision even after the rolling update is done.
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/controllers/replicaset.md
+18 -10
View File
@@ -6,10 +6,7 @@ assignees:
title: Replica Sets title: Replica Sets
--- ---
* TOC {% capture overview %}
{:toc}
## What is a ReplicaSet?
ReplicaSet is the next-generation Replication Controller. The only difference ReplicaSet is the next-generation Replication Controller. The only difference
between a _ReplicaSet_ and a between a _ReplicaSet_ and a
@@ -18,6 +15,13 @@ the selector support. ReplicaSet supports the new set-based selector requirement
as described in the [labels user guide](/docs/user-guide/labels/#label-selectors) as described in the [labels user guide](/docs/user-guide/labels/#label-selectors)
whereas a Replication Controller only supports equality-based selector requirements. whereas a Replication Controller only supports equality-based selector requirements.
{% endcapture %}
{% capture body %}
## How to use a ReplicaSet
Most [`kubectl`](/docs/user-guide/kubectl/) commands that support Most [`kubectl`](/docs/user-guide/kubectl/) commands that support
Replication Controllers also support ReplicaSets. One exception is the Replication Controllers also support ReplicaSets. One exception is the
[`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command. If [`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command. If
@@ -33,16 +37,16 @@ creation, deletion and updates. When you use Deployments you don't have to worry
about managing the ReplicaSets that they create. Deployments own and manage about managing the ReplicaSets that they create. Deployments own and manage
their ReplicaSets. their ReplicaSets.
## When to use a ReplicaSet? ## When to use a ReplicaSet
A ReplicaSet ensures that a specified number of pod “replicas” are running at any given A ReplicaSet ensures that a specified number of pod replicas are running at any given
time. However, a Deployment is a higher-level concept that manages ReplicaSets and time. However, a Deployment is a higher-level concept that manages ReplicaSets 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 ReplicaSets, unless Therefore, we recommend using Deployments instead of directly using ReplicaSets, 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.
This actually means that you may never need to manipulate ReplicaSet objects: This actually means that you may never need to manipulate ReplicaSet objects:
use directly a Deployment and define your application in the spec section. use a Deployment instead, and define your application in the spec section.
## Example ## Example
@@ -79,8 +83,8 @@ frontend-qhloh 1/1 Running 0 1m
## ReplicaSet as an Horizontal Pod Autoscaler target ## ReplicaSet as an Horizontal Pod Autoscaler target
A ReplicaSet can also be a target for A ReplicaSet can also be a target for
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/), [Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). That is,
i.e. a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
the ReplicaSet we created in the previous example. the ReplicaSet we created in the previous example.
{% include code.html language="yaml" file="hpa-rs.yaml" ghlink="/docs/concepts/workloads/controllers/hpa-rs.yaml" %} {% include code.html language="yaml" file="hpa-rs.yaml" ghlink="/docs/concepts/workloads/controllers/hpa-rs.yaml" %}
@@ -94,9 +98,13 @@ of the replicated pods.
kubectl create -f hpa-rs.yaml kubectl create -f hpa-rs.yaml
``` ```
Alternatively, you can just use the `kubectl autoscale` command to accomplish the same Alternatively, you can use the `kubectl autoscale` command to accomplish the same
(and it's easier!) (and it's easier!)
```shell ```shell
kubectl autoscale rs frontend kubectl autoscale rs frontend
``` ```
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/controllers/replicationcontroller.md
+41 -30
View File
@@ -5,33 +5,40 @@ assignees:
title: Replication Controller title: Replication Controller
--- ---
* TOC {% capture overview %}
{:toc}
## What is a ReplicationController? 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 _ReplicationController_ ensures that a specified number of pod "replicas" are running at any one A _ReplicationController_ ensures that a specified number of pod replicas are running at any one
time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
always up and available. always up and available.
If there are too many pods, it will kill some. If there are too few, the
ReplicationController will start more. Unlike manually created pods, the pods maintained by a {% endcapture %}
ReplicationController are automatically replaced if they fail, get deleted, or are terminated.
For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade.
For this reason, we recommend that you use a ReplicationController even if your application requires {% capture body %}
only a single pod. You can think of a ReplicationController as something similar to a process supervisor,
but rather than individual processes on a single node, the ReplicationController supervises multiple pods ## How a ReplicationController Works
If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the
ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a
ReplicationController are automatically replaced if they fail, are deleted, or are terminated.
For example, your pods are re-created on a node after disruptive maintenance such as a kernel upgrade.
For this reason, you should use a ReplicationController even if your application requires
only a single pod. A ReplicationController is similar to a process supervisor,
but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods
across multiple nodes. across multiple nodes.
ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
kubectl commands. kubectl commands.
A simple case is to create 1 ReplicationController object in order to reliably run one instance of A simple case is to create one ReplicationController object to reliably run one instance of
a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated
service, such as web servers. service, such as web servers.
## Running an example ReplicationController ## Running an example ReplicationController
Here is an example ReplicationController config. It runs 3 copies of the nginx web server. This example ReplicationController config runs three copies of the nginx web server.
{% include code.html language="yaml" file="replication.yaml" ghlink="/docs/concepts/workloads/controllers/replication.yaml" %} {% include code.html language="yaml" file="replication.yaml" ghlink="/docs/concepts/workloads/controllers/replication.yaml" %}
@@ -61,14 +68,14 @@ Events:
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v
``` ```
Here, 3 pods have been made, but none are running yet, perhaps because the image is being pulled. Here, three pods are created, but none is running yet, perhaps because the image is being pulled.
A little later, the same command may show: A little later, the same command may show:
```shell ```shell
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
``` ```
To list all the pods that belong to the rc in a machine readable form, you can use a command like this: To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this:
```shell ```shell
$ pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) $ pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
@@ -98,7 +105,7 @@ the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nes
`kind`. `kind`.
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
labels (i.e. don't overlap with other controllers, see [pod selector](#pod-selector)) and an appropriate restart policy. labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is allowed, which is the default Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is allowed, which is the default
if not specified. if not specified.
@@ -110,23 +117,23 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
The ReplicationController can itself have labels (`.metadata.labels`). Typically, you The ReplicationController can itself have labels (`.metadata.labels`). Typically, you
would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified
then it is defaulted to `.spec.template.metadata.labels`. However, they are allowed to be then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be
different, and the `.metadata.labels` do not affect the behavior of the ReplicationController. different, and the `.metadata.labels` do not affect the behavior of the ReplicationController.
### Pod Selector ### Pod Selector
The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A replication The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A ReplicationController
controller manages all the pods with labels which match the selector. It does not distinguish manages all the pods with labels that match the selector. It does not distinguish
between pods which it created or deleted versus pods which some other person or process created or between pods that it created or deleted and pods that another person or process created or
deleted. This allows the ReplicationController to be replaced without affecting the running pods. deleted. This allows the ReplicationController to be replaced without affecting the running pods.
If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will
be rejected by the API. If `.spec.selector` is unspecified, it will be defaulted to be rejected by the API. If `.spec.selector` is unspecified, it will be defaulted to
`.spec.template.metadata.labels`. `.spec.template.metadata.labels`.
Also you should not normally create any pods whose labels match this selector, either directly, via Also you should not normally create any pods whose labels match this selector, either directly, with
another ReplicationController or via another controller such as Job. Otherwise, the another ReplicationController, or with another controller such as Job. If you do so, the
ReplicationController will think that those pods were created by it. Kubernetes will not stop you ReplicationController thinks that it created the other pods. Kubernetes does not stop you
from doing this. from doing this.
If you do end up with multiple controllers that have overlapping selectors, you If you do end up with multiple controllers that have overlapping selectors, you
@@ -174,7 +181,7 @@ Pods may be removed from a ReplicationController's target set by changing their
### Rescheduling ### Rescheduling
As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent). As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent).
### Scaling ### Scaling
@@ -208,13 +215,13 @@ A ReplicationController will never terminate on its own, but it isn't expected t
## Writing programs for Replication ## Writing programs for Replication
Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself. Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (for example, cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself.
## Responsibilities of the ReplicationController ## Responsibilities of the ReplicationController
The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
@@ -242,12 +249,12 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and
### Bare Pods ### Bare Pods
Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (e.g., Kubelet or Docker). Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker).
### Job ### Job
Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own
(i.e. batch jobs). (that is, batch jobs).
### DaemonSet ### DaemonSet
@@ -259,3 +266,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
## For more information ## For more information
Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
{% endcapture %}
{% include templates/concept.md %}