This scenario takes you through the basics of Job resources on Kubernetes. Chapter 12 of the 2019 O'Reilly Kubernetes Up & Running, 2nd edition book from Kelsey Hightower, Brendan Burns, and Joe Beda has a very nice explanation of Jobs. Therefore, this scenario is simply a manifestation of their explanation in Katacoda form.
A free PDF copy of the book that includes the Jobs chapter is here.
A Job creates Pods that run until successful termination (i.e., exit with 0). In contrast, a regular Pod will continually restart regardless of its exit code. Jobs are useful for things you only want to do once, such as database migrations or batch jobs. If run as a regular Pod, your database migration task would run in a loop, continually repopulating the database after every exit.
The Job object is responsible for creating and managing pods defined in a template in the Job specification. These pods generally run until successful completion. The Job object coordinates running multiple pods in parallel.
As a prerequisite, we assume you have an introductory working knowledge of Kubernetes covered in the First App scenario of this course.
In the following steps you will learn:
- how Jobs are defined and work in Kubernetes,
- how Kubernetes resilience recovers failed jobs,
- how Job can serially or in parallel,
- why it's more efficient to run Jobs in parallel,
- how Jobs can process a work queue.
The Jobs feature is described in the Kubernetes documentation. More references to documentation are listed at the end of this scenario.
Jobs are much like Pods, but differ since they terminate once the task is completed. The Job feature ensures the job complete successfully and can optionally rerun the tasks until success is reported.
Job efficiently run in parallel. Where once you may have been inclined to multi-thread the application in the container, you can instead keep the container a simple task runner and rely on Kubernetes resource management and Job parallelism to achieve threading with a more effective pattern.
When combined with a queuing or messaging mechanism, Jobs can asynchronously process any tasks you decide to design.
To further this thinking consider investigating serverless or function implementations on Kubernetes. In many ways, Jobs are a primitive form of what various serverless solutions achieve as functions. Take a look at Knative based solutions to understand how you may someday want to evolve your Jobs into Functions.
With these steps you have learned:
- ✔ how Jobs are defined and work in Kubernetes,
- ✔ how Kubernetes resilience recovers failed jobs,
- ✔ how Job can serially or in parallel,
- ✔ why it's more efficient to run Jobs in parallel,
- ✔ how Jobs can process a work queue.
- Book: Kubernetes Up & Running, 2nd Edition
- PDF copy of book is here.
- Kubernetes Up and Running Demo (kuard) App
Your Kubernetes Cluster
For this scenario, Katacoda has just started a fresh Kubernetes cluster for you. Verify it's ready for your use.
kubectl version --short && \
kubectl get componentstatus && \
kubectl get nodes && \
The Helm package manager used for installing applications on Kubernetes is also available.
helm version --short
You can administer your cluster with the
kubectl CLI tool or use the visual Kubernetes Dashboard. Use this script to access the protected Dashboard.