Skip to content

Commit 48c3aaf

Browse files
committed
Added information about batch job
Signed-off-by: knrt10 <[email protected]>
1 parent 13339da commit 48c3aaf

File tree

3 files changed

+63
-0
lines changed

3 files changed

+63
-0
lines changed

Diff for: batch-job/Dockerfile

+2
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
FROM busybox
2+
ENTRYPOINT echo "$(date) Batch job starting"; sleep 120; echo "$(date) Finished succesfully"

Diff for: exporter.yaml

+14
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
apiVersion: batch/v1
2+
kind: Job
3+
metadata:
4+
name: batch-job
5+
spec:
6+
template:
7+
metadata:
8+
labels:
9+
app: batch-job
10+
spec:
11+
restartPolicy: OnFailure
12+
containers:
13+
- name: main
14+
image: knrt10/batch-job

Diff for: readme.md

+47
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,8 @@ This is just a simple demonstration to get a basic understanding of how kubernet
9999
- [Creating the DaemonSet](#creating-the-daemonset)
100100
- [Running Pod that perform a single completable task](#running-pod-that-perform-a-single-completable-task)
101101
- [Introducing the Job resource](#introducing-the-job-resource)
102+
- [Defining a Job resource](#defining-a-job-resource)
103+
- [Seeing a Job run a pod](#seeing-a-job-run-a-pod)
102104

103105
4. [Todo](#todo)
104106

@@ -1443,6 +1445,51 @@ In the event of node failure, pod on that node that are managed by the Job will
14431445

14441446
As shown below, it tells how a pod created by a Job is rescheduled to a new node if the node it was initially scheduled to fails. It also shows both a managed pod, which isn’t rescheduled, and a pod backed by a ReplicaSet, which is.
14451447

1448+
For example, Jobs are useful for ad hoc tasks, where it’s crucial that the task finishes properly. You could run the task in an unmanaged pod and wait for it to finish, but in the event of a node failing or the pod being evicted from the node while it is performing its task, you’d need to manually recreate it. Doing this manually doesn’t make sense especially if the job takes hours to complete.
1449+
1450+
An example of such a job would be if you had data stored somewhere and you needed to transform and export it somewhere. You’re going to emulate this by running a container image built on top of the busybox image, which invokes the sleep command for two minutes. I’ve already built the image and pushed it to Docker Hub, but you can peek into its Dockerfile in the book’s code archive.
1451+
1452+
![Job resource](https://user-images.githubusercontent.com/24803604/72050330-e2f81f00-32e6-11ea-9bba-ec9603835138.png)
1453+
1454+
> Pods managed by Jobs are rescheduled until they finish successfully.
1455+
1456+
#### Defining a Job resource
1457+
1458+
Create the Job manifest as in the following listing. You’re going to create a file called **exporter.yaml** (you can create it in any directory you want), or copy from this repo, where you’ll find the file with filename [exporter.yaml](https://github.com/knrt10/kubernetes-basicLearning/blob/master/exporter.yaml). The following listing shows the entire contents of the file.
1459+
1460+
```yml
1461+
apiVersion: batch/v1
1462+
kind: Job
1463+
metadata:
1464+
name: batch-job
1465+
spec:
1466+
template:
1467+
metadata:
1468+
labels:
1469+
app: batch-job
1470+
spec:
1471+
restartPolicy: OnFailure
1472+
containers:
1473+
- name: main
1474+
image: knrt10/batch-job
1475+
```
1476+
1477+
Jobs are part of the `batch` API group and `v1 API` version. The YAML defines a resource of type Job that will run the `knrt10/batch-job` image, which invokes a process that runs for exactly 120 seconds and then exits. The image is already been pushed on dockerhub by me.
1478+
1479+
In a pod’s specification, you can specify what Kubernetes should do when the processes running in the container finish. This is done through the `restartPolicy` pod spec property, which defaults to `Always`. Job pods can’t use the default policy, because they’re not meant to run indefinitely. Therefore, you need to explicitly set the restart policy to either `OnFailure` or `Never`. This setting is what prevents the container from being restarted when it finishes (not the fact that the pod is being managed by a Job resource).
1480+
1481+
#### Seeing a Job run a pod
1482+
1483+
After you create this Job with the `kubectl create` command, you should see it start up
1484+
a pod immediately:
1485+
1486+
`kubectl get jobs`
1487+
1488+
```bash
1489+
NAME DESIRED SUCCESSFUL AGE
1490+
batch-job 1 0 2s
1491+
```
1492+
14461493
## Todo
14471494

14481495
- [ ] Write more about pods

0 commit comments

Comments
 (0)