update with master content resolving merge conflicts

2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
@@ -16,7 +16,7 @@ One CronJob object is like one line of a _crontab_ (cron table) file. It runs a
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.

 {{< note >}}
-All **CronJob** `schedule:` times are based the timezone of the master where the job is initiated.
+All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
 {{< /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).
@@ -47,7 +47,7 @@ It is important to note that if the `startingDeadlineSeconds` field is set (not
 A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.

 For example, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
-`startingDeadlineSeconds` field is not set. The default for this field is `100` seconds. If the CronJob controller happens to
+`startingDeadlineSeconds` field is not set. If the CronJob controller happens to
 be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.

 To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
@@ -48,9 +48,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields.  For
 general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
-[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/object-management-kubectl/overview/) documents.
+[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.

-A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) section.
+A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.

 ### Pod Template

@@ -0,0 +1,246 @@
+---
+reviewers:
+- enisoc
+- erictune
+- foxish
+- janetkuo
+- kow3ns
+title: DaemonSet
+content_template: templates/concept
+weight: 50
+---
+
+{{% capture overview %}}
+
+A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod.  As nodes are added to the
+cluster, Pods are added to them.  As nodes are removed from the cluster, those Pods are garbage
+collected.  Deleting a DaemonSet will clean up the Pods it created.
+
+Some typical uses of a DaemonSet are:
+
+- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
+- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
+- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/).
+
+In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
+A more complex setup might use multiple DaemonSets for a single type of daemon, but with
+different flags and/or different memory and cpu requests for different hardware types.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Writing a DaemonSet Spec
+
+### Create a DaemonSet
+
+You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
+
+{{< codenew file="controllers/daemonset.yaml" >}}
+
+* Create a DaemonSet based on the YAML file:
+```
+kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
+```
+
+### Required Fields
+
+As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields.  For
+general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
+[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.
+
+A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.
+
+### Pod Template
+
+The `.spec.template` is one of the required fields in `.spec`.
+
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+
+In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
+labels (see [pod selector](#pod-selector)).
+
+A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod-states)
+ equal to `Always`, or be unspecified, which defaults to `Always`.
+
+### Pod Selector
+
+The `.spec.selector` field is a pod selector.  It works the same as the `.spec.selector` of
+a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
+
+As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the
+`.spec.template`. The pod selector will no longer be defaulted when left empty. Selector
+defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is created,
+its `.spec.selector` can not be mutated. Mutating the pod selector can lead to the
+unintentional orphaning of Pods, and it was found to be confusing to users.
+
+The `.spec.selector` is an object consisting of two fields:
+
+* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchExpressions` - allows to build more sophisticated selectors by specifying key,
+  list of values and an operator that relates the key and values.
+
+When the two are specified the result is ANDed.
+
+If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
+
+Also you should not normally create any Pods whose labels match this selector, either directly, via
+another DaemonSet, or via other controller such as ReplicaSet.  Otherwise, the DaemonSet
+controller will think that those Pods were created by it.  Kubernetes will not stop you from doing
+this.  One case where you might want to do this is manually create a Pod with a different value on
+a node for testing.
+
+### Running Pods on Only Some Nodes
+
+If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
+create Pods on nodes which match that [node
+selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
+then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
+If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
+
+## How Daemon Pods are Scheduled
+
+### Scheduled by DaemonSet controller (disabled by default since 1.12)
+
+Normally, the machine that a Pod runs on is selected by the Kubernetes scheduler. However, Pods
+created by the DaemonSet controller have the machine already selected (`.spec.nodeName` is specified
+when the Pod is created, so it is ignored by the scheduler).  Therefore:
+
+ - The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
+   by the DaemonSet controller.
+ - The DaemonSet controller can make Pods even when the scheduler has not been started, which can help cluster
+   bootstrap.
+
+
+### Scheduled by default scheduler (enabled by default since 1.12)
+
+{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
+
+A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
+node that a Pod runs on is selected by the Kubernetes scheduler. However,
+DaemonSet pods are created and scheduled by the DaemonSet controller instead.
+That introduces the following issues:
+
+ * Inconsistent Pod behavior: Normal Pods waiting to be scheduled are created
+   and in `Pending` state, but DaemonSet pods are not created in `Pending`
+   state. This is confusing to the user.
+ * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
+   is handled by default scheduler. When preemption is enabled, the DaemonSet controller
+   will make scheduling decisions without considering pod priority and preemption.
+
+`ScheduleDaemonSetPods` allows you to schedule DaemonSets using the default
+scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
+to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
+scheduler is then used to bind the pod to the target host. If node affinity of
+the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
+performs these operations when creating or modifying DaemonSet pods, and no
+changes are made to the `spec.template` of the DaemonSet.
+
+```yaml
+nodeAffinity:
+  requiredDuringSchedulingIgnoredDuringExecution:
+    nodeSelectorTerms:
+    - matchFields:
+      - key: metadata.name
+        operator: In
+        values:
+        - target-host-name
+```
+
+In addition, `node.kubernetes.io/unschedulable:NoSchedule` toleration is added
+automatically to DaemonSet Pods. The default scheduler ignores
+`unschedulable` Nodes when scheduling DaemonSet Pods.
+
+
+### Taints and Tolerations
+
+Although Daemon Pods respect
+[taints and tolerations](/docs/concepts/configuration/taint-and-toleration),
+the following tolerations are added to DaemonSet Pods automatically according to
+the related features.
+
+| Toleration Key                           | Effect     | Version | Description                                                  |
+| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
+| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+    | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    |                                                              |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    |                                                              |
+| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler.                                                    |
+| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler.                      |
+
+
+
+
+## Communicating with Daemon Pods
+
+Some possible patterns for communicating with Pods in a DaemonSet are:
+
+- **Push**: Pods in the DaemonSet are configured to send updates to another service, such
+  as a stats database.  They do not have clients.
+- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs.  Clients know the list of node IPs somehow, and know the port by convention.
+- **DNS**: Create a [headless service](/docs/concepts/services-networking/service/#headless-services) with the same pod selector,
+  and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
+  DNS.
+- **Service**: Create a service with the same Pod selector, and use the service to reach a
+  daemon on a random node. (No way to reach specific node.)
+
+## Updating a DaemonSet
+
+If node labels are changed, the DaemonSet will promptly add Pods to newly matching nodes and delete
+Pods from newly not-matching nodes.
+
+You can modify the Pods that a DaemonSet creates.  However, Pods do not allow all
+fields to be updated.  Also, the DaemonSet controller will use the original template the next
+time a node (even with the same name) is created.
+
+
+You can delete a DaemonSet.  If you specify `--cascade=false` with `kubectl`, then the Pods
+will be left on the nodes.  You can then create a new DaemonSet with a different template.
+The new DaemonSet with the different template will recognize all the existing Pods as having
+matching labels.  It will not modify or delete them despite a mismatch in the Pod template.
+You will need to force new Pod creation by deleting the Pod or deleting the node.
+
+In Kubernetes version 1.6 and later, you can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
+
+## Alternatives to DaemonSet
+
+### Init Scripts
+
+It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
+`init`, `upstartd`, or `systemd`).  This is perfectly fine.  However, there are several advantages to
+running such processes via a DaemonSet:
+
+- Ability to monitor and manage logs for daemons in the same way as applications.
+- Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications.
+- Running daemons in containers with resource limits increases isolation between daemons from app
+  containers.  However, this can also be accomplished by running the daemons in a container but not in a Pod
+  (e.g. start directly via Docker).
+
+### Bare Pods
+
+It is possible to create Pods directly which specify a particular node to run on.  However,
+a DaemonSet 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, you should
+use a DaemonSet rather than creating individual Pods.
+
+### Static Pods
+
+It is possible to create Pods by writing a file to a certain directory watched by Kubelet.  These
+are called [static pods](/docs/concepts/cluster-administration/static-pod/).
+Unlike DaemonSet, static Pods cannot be managed with kubectl
+or other Kubernetes API clients.  Static Pods do not depend on the apiserver, making them useful
+in cluster bootstrapping cases.  Also, static Pods may be deprecated in the future.
+
+### Deployments
+
+DaemonSets are similar to [Deployments](/docs/concepts/workloads/controllers/deployment/) in that
+they both create Pods, and those Pods have processes which are not expected to terminate (e.g. web servers,
+storage servers).
+
+Use a Deployment for stateless services, like frontends, where scaling up and down the
+number of replicas and rolling out updates are more important than controlling exactly which host
+the Pod runs on.  Use a DaemonSet when it is important that a copy of a Pod always run on
+all or certain hosts, and when it needs to start before other Pods.
+
+{{% /capture %}}
@@ -67,7 +67,6 @@ In this example:
  the Pods run one container, `nginx`, which runs the `nginx`
  [Docker Hub](https://hub.docker.com/) image at version 1.7.9.
  * Create one container and name it `nginx` using the `name` field.
-  * Run the `nginx` image at version `1.7.9`.
  * Open port `80` so that the container can send and accept traffic.

 To create this Deployment, run the following command:
@@ -841,7 +840,7 @@ attributes to the Deployment's `.status.conditions`:
 * Status=False
 * Reason=ProgressDeadlineExceeded

-See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
+See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions.

 {{< note >}}
 Kubernetes will take no action on a stalled Deployment other than to report a status condition with
@@ -975,13 +974,13 @@ can create multiple Deployments, one for each release, following the canary patt

 As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
-configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/object-management-kubectl/overview/) documents.
+configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.

-A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
+A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

 ### Pod Template

-The `.spec.template` is the only required field of the `.spec`.
+The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.

 The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an
 `apiVersion` or `kind`.
@@ -998,7 +997,7 @@ allowed, which is the default if not specified.

 ### Selector

-`.spec.selector` is an optional field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this deployment.

 `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -45,7 +45,7 @@ kubectl get pods --output=yaml

 The output shows that the Pod owner is a ReplicaSet named `my-repset`:

-```shell
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -61,7 +61,7 @@ metadata:
 ```

 {{< note >}}
-Cross-namespace owner references is disallowed by design. This means: 
+Cross-namespace owner references are disallowed by design. This means:
 1) Namespace-scoped dependents can only specify owners in the same namespace,
 and owners that are cluster-scoped.
 2) Cluster-scoped dependents can only specify cluster-scoped owners, but not
@@ -124,8 +124,8 @@ Here's an example that deletes dependents in background:
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+  -H "Content-Type: application/json"
 ```

 Here's an example that deletes dependents in foreground:
@@ -133,8 +133,8 @@ Here's an example that deletes dependents in foreground:
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+  -H "Content-Type: application/json"
 ```

 Here's an example that orphans dependents:
@@ -142,8 +142,8 @@ Here's an example that orphans dependents:
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+  -H "Content-Type: application/json"
 ```

 kubectl also supports cascading deletion.
@@ -100,7 +100,10 @@ that just gets the name from each Pod in the returned list.
 View the standard output of one of the pods:

 ```shell
-$ kubectl logs $pods
+kubectl logs $pods
+```
+The output is similar to this:
+```shell
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```

@@ -213,6 +216,12 @@ status check.
 {{< note >}}
 Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
 {{< /note >}}
+{{< note >}}
+If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
+will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
+`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output
+from failed Jobs is not lost inadvertently.
+{{< /note >}}

 ## Job Termination and Cleanup

@@ -340,7 +349,7 @@ The pattern names are also links to examples and more detailed description.
 | Single Job with Static Work Assignment                               |         ✓         |                             |          ✓          |                     |

 When you specify completions with `.spec.completions`, each Pod created by the Job controller
-has an identical [`spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).  This means that
+has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).  This means that
 all pods for a task will have the same command line and the same
 image, the same volumes, and (almost) the same environment variables.  These patterns
 are different ways to arrange for pods to work on different things.
@@ -54,7 +54,7 @@ Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes clus
 create the defined ReplicaSet and the Pods that it manages.

 ```shell
-kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
+kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```

 You can then get the current ReplicaSets deployed:
@@ -162,7 +162,7 @@ Suppose you create the Pods after the frontend ReplicaSet has been deployed and
 fulfill its replica count requirement:

 ```shell
-kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
+kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```

 The new Pods will be acquired by the ReplicaSet, and then immediately terminated as the ReplicaSet would be over
@@ -184,12 +184,12 @@ pod2             0/1     Terminating   0          4s

 If you create the Pods first:
 ```shell
-kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml
+kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
 ```

 And then create the ReplicaSet however:
 ```shell
-kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml
+kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
 ```

 You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
@@ -215,7 +215,7 @@ For ReplicaSets, the kind is always just ReplicaSet.
 In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
 Refer to the first lines of the `frontend.yaml` example for guidance.

-A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
+A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

 ### Pod Template

@@ -281,7 +281,8 @@ curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
 Once the original is deleted, you can create a new ReplicaSet to replace it.  As long
 as the old and new `.spec.selector` are the same, then the new one will adopt the old Pods.
 However, it will not make any effort to make existing Pods match a new, different pod template.
-To update Pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
+To update Pods to a new spec in a controlled way, use a 
+[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as ReplicaSets do not support a rolling update directly.

 ### Isolating Pods from a ReplicaSet

@@ -3,7 +3,7 @@ reviewers:
 - bprashanth
 - janetkuo
 title: ReplicationController
-feature: 
+feature:
  title: Self-healing
  anchor: How a ReplicationController Works
  description: >
@@ -116,9 +116,9 @@ specifies an expression that just gets the name from each pod in the returned li
 ## Writing a ReplicationController Spec

 As with all other Kubernetes config, a ReplicationController needs `apiVersion`, `kind`, and `metadata` fields.
-For general information about working with config files, see [object management ](/docs/concepts/overview/object-management-kubectl/overview/).
+For general information about working with config files, see [object management ](/docs/concepts/overview/working-with-objects/object-management/).

-A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
+A ReplicationController also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).

 ### Pod Template

@@ -152,7 +152,7 @@ If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.s
 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, with 
+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.
@@ -289,5 +289,3 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).

 {{% /capture %}}
-
-
@@ -209,7 +209,8 @@ described [above](#deployment-and-scaling-guarantees).
 `Parallel` pod management tells the StatefulSet controller to launch or
 terminate all Pods in parallel, and to not wait for Pods to become Running
 and Ready or completely terminated prior to launching or terminating another
-Pod.
+Pod. This option only affects the behavior for scaling operations. Updates are not
+affected.

 ## Update Strategies