You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: readme.md
+47
Original file line number
Diff line number
Diff line change
@@ -99,6 +99,8 @@ This is just a simple demonstration to get a basic understanding of how kubernet
99
99
-[Creating the DaemonSet](#creating-the-daemonset)
100
100
-[Running Pod that perform a single completable task](#running-pod-that-perform-a-single-completable-task)
101
101
-[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)
102
104
103
105
4.[Todo](#todo)
104
106
@@ -1443,6 +1445,51 @@ In the event of node failure, pod on that node that are managed by the Job will
1443
1445
1444
1446
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.
1445
1447
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.
> 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
0 commit comments