Merge master into dev-1.20 to keep in sync

content/en/docs/concepts/workloads/_index.md

@@ -3,5 +3,55 @@ title: "Workloads"
 weight: 50
 description: >
   Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
+no_list: true
 ---
 
+{{< glossary_definition term_id="workload" length="short" >}}
+Whether your workload is a single component or several that work together, on Kubernetes you run
+it inside a set of [Pods](/docs/concepts/workloads/pods).
+In Kubernetes, a Pod represents a set of running {{< glossary_tooltip text="containers" term_id="container" >}}
+on your cluster.
+
+A Pod has a defined lifecycle. For example, once a Pod is running in your cluster then
+a critical failure on the {{< glossary_tooltip text="node" term_id="node" >}} where that
+Pod is running means that all the Pods on that node fail. Kubernetes treats that level
+of failure as final: you would need to create a new Pod even if the node later recovers.
+
+However, to make life considerably easier, you don't need to manage each Pod directly.
+Instead, you can use _workload resources_ that manage a set of Pods on your behalf.
+These resources configure {{< glossary_tooltip term_id="controller" text="controllers" >}}
+that make sure the right number of the right kind of Pod are running, to match the state
+you specified.
+
+Those workload resources include:
+
+* [Deployment](/docs/concepts/workloads/controllers/deployment/) and [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
+  (replacing the legacy resource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}});
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/);
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for running Pods that provide
+  node-local facilities, such as a storage driver or network plugin;
+* [Job](/docs/concepts/workloads/controllers/job/) and
+  [CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
+  for tasks that run to completion.
+
+There are also two supporting concepts that you might find relevant:
+* [Garbage collection](/docs/concepts/workloads/controllers/garbage-collection/) tidies up objects
+  from your cluster after their _owning resource_ has been removed.
+* The [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
+  removes Jobs once a defined time has passed since they completed.
+
+## {{% heading "whatsnext" %}}
+
+As well as reading about each resource, you can learn about specific tasks that relate to them:
+
+* [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
+* Run a stateful application either as a [single instance](/docs/tasks/run-application/run-single-instance-stateful-application/)
+  or as a [replicated set](/docs/tasks/run-application/run-replicated-stateful-application/)
+* [Run Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+Once your application is running, you might want to make it available on the internet as
+a [Service](/docs/concepts/services-networking/service/) or, for web application only,
+using an [Ingress](/docs/concepts/services-networking/ingress).
+
+You can also visit [Configuration](/docs/concepts/configuration/) to learn about Kubernetes'
+mechanisms for separating code from configuration.

content/en/docs/concepts/workloads/controllers/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "Controllers"
+title: "Workload Resources"
 weight: 20
 ---
 

content/en/docs/concepts/workloads/controllers/deployment.md

@@ -752,7 +752,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
     REVISION  CHANGE-CAUSE
     1   <none>
     ```
-* Get the rollout status to ensure that the Deployment is updates successfully:
+* Get the rollout status to ensure that the Deployment is updated successfully:
     ```shell
     kubectl get rs
     ```

content/en/docs/concepts/workloads/controllers/replicaset.md

@@ -233,7 +233,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
 
 ### Pod Template
 
-The `.spec.template` is a [pod template](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) which is also
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates) which is also
 required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
 Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
 
@@ -351,7 +351,7 @@ Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods t
 
 ### Job
 
-Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicaSet for Pods that are expected to terminate on their own
+Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are expected to terminate on their own
 (that is, batch jobs).
 
 ### DaemonSet

content/en/docs/concepts/workloads/pods/_index.md

@@ -145,7 +145,7 @@ from a _pod template_ and manage those Pods on your behalf.
 
 PodTemplates are specifications for creating Pods, and are included in workload resources such as
 [Deployments](/docs/concepts/workloads/controllers/deployment/),
-[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[Jobs](/docs/concepts/workloads/controllers/job/), and
 [DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
 
 Each controller for a workload resource uses the `PodTemplate` inside the workload
@@ -264,7 +264,7 @@ but cannot be controlled from there.
 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
 
 To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
-  * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+  * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
   * [Borg](https://research.google.com/pubs/pub43438.html)
   * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
   * [Omega](https://research.google/pubs/pub41684/)

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -77,13 +77,13 @@ have a given `phase` value.
 
 Here are the possible values for `phase`:
 
-Value | Description
-:-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
-`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
+Value       | Description
+:-----------|:-----------
+`Pending`   | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
+`Running`   | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
 `Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
-`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
-`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
+`Failed`    | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
+`Unknown`   | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
 
 If a node dies or is disconnected from the rest of the cluster, Kubernetes
 applies a policy for setting the `phase` of all Pods on the lost node to Failed.
@@ -228,7 +228,8 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 ## Container probes
 
 A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
-performed periodically by the [kubelet](/docs/admin/kubelet/)
+performed periodically by the
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
 on a Container. To perform a diagnostic,
 the kubelet calls a
 [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by