Rename Job concept page

(including Netlify redirects)

content/en/docs/concepts/_index.md

@@ -41,7 +41,7 @@ Kubernetes also contains higher-level abstractions that rely on [controllers](/d
 * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
 * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
 * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [Job](/docs/concepts/workloads/controllers/job/)
 
 ## Kubernetes Control Plane
 

content/en/docs/concepts/configuration/overview.md

@@ -34,7 +34,7 @@ This is a living document. If you think of something that is not on this list bu
 
 - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
 
-  A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
+  A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate.
 
 
 ## Services

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

@@ -2,7 +2,7 @@
 reviewers:
 - erictune
 - soltysh
-title: Jobs - Run to Completion
+title: Jobs
 content_type: concept
 feature:
   title: Batch execution

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

@@ -12,8 +12,8 @@ weight: 70
 
 The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource
 objects that have finished execution. TTL controller only handles
-[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for
-now, and may be expanded to handle other resources that will finish execution,
+{{< glossary_tooltip text="Jobs" term_id="job" >}} for now,
+and may be expanded to handle other resources that will finish execution,
 such as Pods and custom resources.
 
 Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager
@@ -33,7 +33,7 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both
 The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
 up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 `.spec.ttlSecondsAfterFinished` field of a Job, as in this
-[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
+[example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
 The TTL controller will assume that a resource is eligible to be cleaned up
 TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
 TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete