Update docs to use batch/v1beta1 cronjobs (#5475)

cn/docs/concepts/workloads/controllers/cronjob.yaml

@@ -1,18 +0,0 @@
-apiVersion: batch/v2alpha1
-kind: CronJob
-metadata:
-  name: hello
-spec:
-  schedule: "*/1 * * * *"
-  jobTemplate:
-    spec:
-      template:
-        spec:
-          containers:
-          - name: hello
-            image: busybox
-            args:
-            - /bin/sh
-            - -c
-            - date; echo Hello from the Kubernetes cluster
-          restartPolicy: OnFailure

docs/concepts/jobs/cronjob.yaml

@@ -1,18 +0,0 @@
-apiVersion: batch/v2alpha1
-kind: CronJob
-metadata:
-  name: hello
-spec:
-  schedule: "*/1 * * * *"
-  jobTemplate:
-    spec:
-      template:
-        spec:
-          containers:
-          - name: hello
-            image: busybox
-            args:
-            - /bin/sh
-            - -c
-            - date; echo Hello from the Kubernetes cluster
-          restartPolicy: OnFailure

docs/concepts/workloads/controllers/cron-jobs.md

@@ -22,8 +22,10 @@ on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) forma
 **Note:** The question mark (`?`) in the schedule has the same meaning as an asterisk `*`,
 that is, it stands for any of available value for a given field.
 
-**Note:** ScheduledJob resource was introduced in Kubernetes version 1.4, but starting
+**Note:** CronJob resource in `batch/v2alpha1` API group has been deprecated starting
-from version 1.5 its current name is CronJob.
+from cluster version 1.8. You should switch to using `batch/v1beta1`, instead, which is
+enabled by default in the API server.  Further in this document, we will be using
+`batch/v1beta1` in all the examples.
 
 A typical use case is:
 
@@ -32,8 +34,8 @@ A typical use case is:
 
 ### Prerequisites
 
-You need a working Kubernetes cluster at version >= 1.4 (for ScheduledJob), >= 1.5 (for CronJob),
+You need a working Kubernetes cluster at version >= 1.8 (for CronJob). For previous versions of cluster (< 1.8)
-with batch/v2alpha1 API turned on by passing `--runtime-config=batch/v2alpha1=true` while bringing up
+you need to explicitly enable `batch/v2alpha1` API by passing `--runtime-config=batch/v2alpha1=true` to
 the API server (see [Turn on or off an API version for your cluster](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
 for more).
 

docs/concepts/workloads/controllers/cronjob.yaml

@@ -1,4 +1,4 @@
-apiVersion: batch/v2alpha1
+apiVersion: batch/v1beta1
 kind: CronJob
 metadata:
   name: hello

docs/user-guide/cronjob.yaml

@@ -1,18 +0,0 @@
-apiVersion: batch/v2alpha1
-kind: CronJob
-metadata:
-  name: hello
-spec:
-  schedule: "*/1 * * * *"
-  jobTemplate:
-    spec:
-      template:
-        spec:
-          containers:
-          - name: hello
-            image: busybox
-            args:
-            - /bin/sh
-            - -c
-            - date; echo Hello from the Kubernetes cluster
-          restartPolicy: OnFailure

docs/user-guide/kubectl-conventions.md

@@ -38,7 +38,8 @@ In order for `kubectl run` to satisfy infrastructure as code:
 * Deployment, using `extensions/v1beta1` endpoint - use `deployment/v1beta1` (default).
 * Deployment, using `apps/v1beta1` endpoint - use `deployment/apps.v1beta1` (recommended).
 * Job - use `job/v1`.
-* CronJob - use `cronjob/v2alpha1`.
+* CronJob - using `batch/v1beta1` endpoint - use `cronjob/v1beta1`(default).
+* CronJob - using `batch/v2alpha1` endpoint - use `cronjob/v2alpha1` (deprecated).
 
 Additionally, if you didn't specify a generator flag, other flags will suggest using
 a specific generator.  Below table shows which flags force using specific generators,