A job resource represents a one-time task to perform on the cluster. As with most cluster tasks, jobs are executed via pods. If a job's pod fails, then the cluster retries a number of times that the job specifies. The job does not run again after a specified number of successful completions.

Jobs differ from using the kubectl run and oc run commands; both of the latter create only a pod.

Common uses for jobs include the following tasks:

The following example command creates a job that logs the date and time:

[user@host ~]$ oc create job \ 
date-job \ 
--image registry.access.redhat.com/ubi8/ubi \ 
-- /bin/bash -c "date" 

You can also create a job from the web console by clicking the Workloads → Jobs menu. Click Create Job and customize the YAML manifest.

A cron job resource builds on a regular job resource by enabling you to specify how often the job should run. Cron jobs are useful for creating periodic and recurring tasks, such as backups or report generation. Cron jobs can also schedule individual tasks for a specific time, such as to schedule a job for a low activity period. Similar to the crontab (cron table) file on a Linux system, the CronJob resource uses the Cron format for scheduling. A CronJob resource creates a job resource based on the configured time zone on the control plane node that runs the cron job controller.

The following example command creates a cron job named date that prints the system date and time every minute:

[user@host ~]$ oc create cronjob date-cronjob \ 
--image registry.access.redhat.com/ubi8/ubi \ 
--schedule "*/1 * * * *" \ 
-- date 

You can also create a cronjob from the web console by clicking the Workloads → CronJobs menu. Click Create CronJob and customize the YAML manifest.

A deployment creates a replica set to maintain pods. A replica set maintains a specified number of replicas of a pod. Replica sets use selectors, such as a label, to identify pods that are part of the set. Pods are created or removed until the replicas reach the number that the deployment specifies. Replica sets are not managed directly. Instead, deployments indirectly manage replica sets.

Unlike a job, a deployment's pods are re-created after crashing or deletion. The reason is that deployments use replica sets.

The following example command creates a deployment:

[user@host ~]$ oc create deployment \ 
my-deployment \ 
--image registry.access.redhat.com/ubi8/ubi \ 
--replicas 3 

You can also create a deployment from the web console by clicking the Deployments tab in the Workloads menu.

Click Create Deployment and customize the form or the YAML manifest.

Pods in a replica set are identical and match the pod template in the replica set definition. If the number of replicas is not met, then a new pod is created by using the template. For example, if a pod crashes or is otherwise deleted, then a new one is created to replace it.

Labels are a type of resource metadata that are represented as string key-value pairs. A label indicates a common trait for resources with that label. For example, you might attach a layer=frontend label to resources that relate to an application's UI components.

Many oc and kubectl commands accept a label to filter affected resources. For example, the following command deletes all pods with the environment=testing label:

[user@host ~]$ oc delete pod -l environment=testing

By liberally applying labels to resources, you can cross-reference resources and craft precise selectors. A selector is a query object that describes the attributes of matching resources.

Certain resources use selectors to find other resources. In the following YAML excerpt, an example replica set uses a selector to match its pods.

apiVersion: apps/v1
kind: ReplicaSet
...output omitted...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
      pod-template-hash: 7c84fbdb57
...output omitted...

Like deployments, stateful sets manage a set of pods based on a container specification. However, each pod that a stateful set creates is unique. Pod uniqueness is useful when, for example, a pod needs a unique network identifier or persistent storage.

As their name implies, stateful sets are for pods that require state within the cluster. Deployments are used for stateless pods.

Stateful sets are covered further in a later chapter.