From aa27de5959f7ea0bef43aa590934d80e28e5cf7e Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 15 Oct 2020 11:14:16 +0100 Subject: [PATCH] Tweak wording for Workloads overview --- content/en/docs/concepts/workloads/_index.md | 84 +++++++++++++------- 1 file changed, 54 insertions(+), 30 deletions(-) diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md index 21e57aed03..2c9dd8aa8e 100644 --- a/content/en/docs/concepts/workloads/_index.md +++ b/content/en/docs/concepts/workloads/_index.md @@ -8,50 +8,74 @@ 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. +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. +Kubernetes pods have a [defined lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). +For example, once a pod is running in your cluster then a critical fault 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` to recover, even if the node later becomes healthy. -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. +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 +that make sure the right number of the right kind of pod are running, to match the state you specified. -Those workload resources include: +Kubernetes provides several built-in workload resources: -* [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. +* [`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" >}}). + `Deployment` is a good fit for managing a stateless application workload on your cluster, + where any `Pod` in the `Deployment` is interchangeable and can be replaced if needed. +* [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) lets you + run one or more related Pods that do track state somehow. For example, if your workload + records data persistently, you can run a `StatefulSet` that matches each `Pod` with a + [`PersistentVolume`](/docs/concepts/storage/persistent-volumes/). Your code, running in the + `Pods` for that `StatefulSet`, can replicate data to other `Pods` in the same `StatefulSet` + to improve overall resilience. +* [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) defines `Pods` that provide + node-local facilities. These might be fundamental to the operation of your cluster, such + as a networking helper tool, or be part of an + {{< glossary_tooltip text="add-on" term_id="addons" >}}. + Every time you add a node to your cluster that matches the specification in a `DaemonSet`, + the control plane schedules a `Pod` for that `DaemonSet` onto the new node. +* [`Job`](/docs/concepts/workloads/controllers/job/) and + [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) + define tasks that run to completion and then stop. Jobs represent one-off tasks, whereas + `CronJobs` recur according to a schedule. -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. +In the wider Kubernetes ecosystem, you can find third-party workload resources that provide +additional behaviors. Using a +[custom resource definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), +you can add in a third-party workload resource if you want a specific behavior that's not part +of Kubernetes' core. For example, if you wanted to run a group of `Pods` for your application but +stop work unless _all_ the Pods are available (perhaps for some high-throughput distributed task), +then you can implement or install an extension that does provide that feature. ## {{% 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 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/) +* [Run automated tasks with a `CronJob`](/docs/tasks/job/automated-tasks-with-cron-jobs/) + +To learn about Kubernetes' mechanisms for separating code from configuration, +visit [Configuration](/docs/concepts/configuration/). + +There are two supporting concepts that provide backgrounds about how Kubernetes manages pods +for applications: +* [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. 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). +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.