Jobs

Jobs in the cluster do not have any special configuration apart from necessary security context. We provide sample configuration for you convenience. If you will start from example below, don’t forget to change the following according to your needs:

• Job name in section metadata.name
• Labels (Optional)
  • Sections metadata.labels and spec.template.metadata.labels (possible to have multiple key:value pairs in both)
  • See section below on the meaning of labels and decide if you would like to include some
• Restart Policy
  • Section spec.template.spec.restartPolicy
  • Can be defined to "Never" or "OnFailure", both have their specific meaning and we strongly recommend to check the official documentation
• Container image
  • Section spec.template.spec.containers[].image (an array, there can be multiple containers)
  • If you don’t have a pre-prepared image, you can create your own according to our documentation which lists tips on how to create functional image
  • If you are unsure about the container image creation, contact us with questions
• User
  • Section spec.template.spec.containers[].securityContext.runAsUser (set for every container)
  • Your container image might define different user than 1000
• Resource requests
  • Section spec.template.spec.containers[].resources
  • Define requests and limits for both CPU, memory
  • Optionally, you can request a GPU according to GPU documentation section
• Volumes and volumeMounts
  • Volumes
    • Section spec.template.spec.volumes[] (an array, there can be multiple volumes)
    • An array of ALL volumes that can be mounted to the containers of Job
    • Volumes can be of many types, the most frequently used ones are PersistentVolumeClaim, ConfigMap, Secret
  • VolumeMounts
    • Section spec.template.spec.containers[].volumeMounts[] (an array, there can be multiple volumeMounts)
    • An array of volumes to be mounted in a particular container (it is defined for every container individually)
    • Only items listed in spec.template.spec.volumes[] can be mounted in a container
    • 💡

      Name of the volume in section spec.template.spec.volumes[] is the same as name when specifying a volumeMount.

apiVersion: batch/v1
kind: Job
metadata:
  name: secure-job-name
spec:
  template:
    metadata:
      labels:
        app: secure-job
    spec:
      securityContext: # Pod security context
        fsGroupChangePolicy: OnRootMismatch
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: secure-container
        image: nginx:latest
        securityContext: # Container security context
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          runAsUser: 1000
        resources: # Resource requests and limits
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        volumeMounts: # Volume mount for the container
        - name: config-volume
          mountPath: /etc/config
          readOnly: true
      restartPolicy: Never
      volumes: # Volumes definition
      - name: config-volume
        configMap:
          name: example-configmap

More configuration options are available, we recommend to check official Kubernetes documentation which explains the Job object and its possibilities.

A Word On Labels

Label fields (metadata.labels, spec.template.metadata.labels) are not required but we recommend to use them for better organization of objects.

More on metadata.labels:

• These labels apply to Job itself and are used to organize Job objects which makes it easier to identify and filter jobs using command line (e.g. kubectl get jobs --selector) or programatically

More on spec.template.metadata.labels:

• When Kubernetes creates a Pod for the Job, the Pod inherits labels defined in spec.template.metadata.labels which makes it easier to identify and filter pods using command line (e.g. kubectl get pods --selector) or programatically
• Labels help organize resources logically, e.g., you might label all resources belonging to a specific application or environment
• Some Kubernetes features (like Network Policies, Services, or monitoring systems) rely on labels to identify which Pods they apply to and without them these features may not work correctly
• Jobs, Deployments, and other higher-level controllers typically use labels in their template for consistency across created resources