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
---
{:toc}
## What is a Deployment?
{% capture overview %}
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
[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
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 of their resources with new Deployments.
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
create new ReplicaSets, or remove existing Deployments and adopt all their resources with new Deployments.
**Note:** You should not manage ReplicaSets owned by a Deployment, otherwise you are racing with the Deployment
controller! All of the use cases should be covered just by manipulating the Deployment object. Consider opening
an issue in the main Kubernetes repository, if your use case is not covered below.
**Note:** You should not manage ReplicaSets owned by a Deployment. If you do so, you are racing with the Deployment
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.
{% endcapture %}
{% capture body %}
## Use Case
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.
* 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.
* [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.
* [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 is not stable. Each rollback updates the revision of the 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.
* [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
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" %}
@@ -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
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.
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`)
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
$ 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
```
Running the `get` again a few seconds later, should give:
Running the `get` again a few seconds later should give:
```shell
$ 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
```
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,
`app = nginx`), i.e. 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
controllers that have overlapping selectors, those controllers may fight with each other and won't behave
`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
controllers have overlapping selectors, those controllers may fight with each other and won't behave
correctly.
### 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
Deployment controller in every ReplicaSet that a Deployment creates or adopts. Its purpose is so that children
ReplicaSets of a Deployment will not overlap among them. It is computed by hashing the PodTemplate of the ReplicaSet
Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
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 in any existing Pods that the ReplicaSet may have.
## Updating a Deployment
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`)
is changed, e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment,
will not trigger a rollout.
**Note:** 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 templaet are updated. Other updates, such as scaling the Deployment, do 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.
```shell
@@ -134,7 +137,7 @@ $ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited
```
To see its rollout status, simply run:
To see the rollout status, run:
```shell
$ 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
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
not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
creating a new ReplicaSet.
* Selector updates, i.e., 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
pod template labels, no existing ReplicaSet is orphaned, and a new ReplicaSet will not be created, but note that the
removed label will still exist in any existing Pods and ReplicaSets.
* Selector updates -- that is, changing the existing value in a selector key -- result in the same behavior as additions.
* 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 is not created, but note that the
removed label still exists in any existing Pods and ReplicaSets.
## 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]).
**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,
e.g. updating 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.
This implies that when you rollback to an earlier revision, only the Deployment's pod template part will
be rolled back.
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 we can facilitate simultaneous manual- or auto-scaling.
This means that when you roll back to an earlier revision, only the Deployment's pod template part is
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`:
@@ -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:
([`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.
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`.
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
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.
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`.
Deployment may kill Pods whose labels match the selector, in the case that their template is different
than `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It will bring up new
Pods with `.spec.template` if number of Pods are less than the desired number.
A Deployment may terminate Pods whose labels match the selector if their template is different
tfrom `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new
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
another Deployment or via another controller such as ReplicaSets or ReplicationControllers. Otherwise,
the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this.
**Note:** 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.
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
@@ -830,10 +833,9 @@ the rolling update process.
##### Max Unavailable
`.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)
or a percentage of desired Pods (e.g. 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
value of 25% is used.
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 (for example, 10%). The absolute number is calculated from percentage by
rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.
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
@@ -843,12 +845,12 @@ at all times during the update is at least 70% of the desired Pods.
##### Max Surge
`.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
percentage of desired Pods (e.g. 10%). This can not be 0 if `MaxUnavailable` is 0. The absolute number
is calculated from percentage by rounding up. By default, a value of 25% is used.
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 (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
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
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
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
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.
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/controllers/replicaset.md
+18 -10
View File
@@ -6,10 +6,7 @@ assignees:
title: Replica Sets
---
* TOC
{:toc}
## What is a ReplicaSet?
{% capture overview %}
ReplicaSet is the next-generation Replication Controller. The only difference
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)
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
Replication Controllers also support ReplicaSets. One exception is the
[`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
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
provides declarative updates to pods along with a lot of other useful features.
Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless
you require custom update orchestration or don't require updates at all.
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
@@ -79,8 +83,8 @@ frontend-qhloh 1/1 Running 0 1m
## ReplicaSet as an Horizontal Pod Autoscaler target
A ReplicaSet can also be a target for
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/),
i.e. a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). That is,
a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
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" %}
@@ -94,9 +98,13 @@ of the replicated pods.
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!)
```shell
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
---
* TOC
{:toc}
{% capture overview %}
## 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
time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are
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 a homogeneous set of pods is
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
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
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
{% endcapture %}
{% capture body %}
## 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.
ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
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
service, such as web servers.
## 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" %}
@@ -61,14 +68,14 @@ Events:
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:
```shell
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
$ 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`.
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
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
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.
### Pod Selector
The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A replication
controller manages all the pods with labels which match the selector. It does not distinguish
between pods which it created or deleted versus pods which some other person or process created or
deleted. This allows the ReplicationController to be replaced without affecting the running pods.
The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A ReplicationController
manages all the pods with labels that match the selector. It does not distinguish
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.
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
`.spec.template.metadata.labels`.
Also you should not normally create any pods whose labels match this selector, either directly, via
another ReplicationController or via another controller such as Job. Otherwise, the
ReplicationController will think that those pods were created by it. Kubernetes will not stop you
Also you should not normally create any pods whose labels match this selector, either directly, with
another ReplicationController, or with another controller such as Job. If you do so, the
ReplicationController thinks that it created the other pods. Kubernetes does not stop you
from doing this.
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
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
@@ -208,13 +215,13 @@ A ReplicationController will never terminate on its own, but it isn't expected t
## 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
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.
@@ -242,12 +249,12 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and
### 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
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
@@ -259,3 +266,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
## For more information
Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
{% endcapture %}
{% include templates/concept.md %}