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

content/en/docs/reference/glossary/cronjob.md

@@ -11,7 +11,7 @@ tags:
 - core-object
 - workload
 ---
- Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
+ Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule.
 
 <!--more-->
 

content/en/docs/reference/glossary/job.md

@@ -2,7 +2,7 @@
 title: Job
 id: job
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion
+full_link: /docs/concepts/workloads/controllers/job/
 short_description: >
   A finite or batch task that runs to completion.
 

content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -158,8 +158,8 @@ A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, t
 ### Job Template
 
 The `.spec.jobTemplate` is the template for the job, and it is required.
-It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), except that it is nested and does not have an `apiVersion` or `kind`.
-For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec).
+It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that it is nested and does not have an `apiVersion` or `kind`.
+For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec).
 
 ### Starting Deadline
 

content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md

@@ -237,7 +237,7 @@ Do not leave your WordPress installation on this page. If another user finds it,
 
 
 * Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-* Learn more about [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/)
 * Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
 * Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/)