Kubernetes Workloads (Deployments, Jobs, CronJobs, etc.)

 

Deployments

In Kubernetes, Deployments provides updates for pod and replica sets. It is basically a tool to manage how the pod will behave inside the cluster.

Once we declare the desired state in the YAML file, the deployment controller makes sure the actual state to desired

Benefits of Deployment

1. It provides a feature of rollback in case the current version is not stable.
2. We can scale up the application in case of an increased workload.

Creating a Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

In this example, we are creating a deployment named “nginx-deployment ” which is having the label “app:nginx”. The deployment will create 3 replicas in this case.

The spec selector will define how the created ReplicaSet finds which Pods to manage. It will basically match the label app: nginx and identify which pods are managed by it.

In the template section, we are defining the metadata about the pods like labels, containers name, images.

To create the deployment we can run this command.

kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

Run kubectl get deployments to check if the Deployment was created.

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s

Statefulset

It is a type of workload in Kubernetes, which is used to manage stateful applications. This helps in managing the deployment and set of pods by providing guarantees of the ordering and uniqueness of the pods.

Statefulsets are useful for stateful applications such as databases that require persistent storage and network.

It is useful for application that requires an ordered rolling update feature.

Example

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

In this example, we are creating a stateful set named “web”. It will have 3 replicas. The template section will contain the spec about the pods which will be created. It mains the unique identity of each of the pods and data will store in volume mount and saved even pod got deleted or recreated.

Daemonsets

A Daemonset will make sure that each node will create a copy of a pod. Whenever a new node is added to the cluster pod will be created and if we delete a node pod created on that node will also be deleted with it.

Features of Daemonsets:

It is used by logging agents to collect logs of every node.

It is used for node monitoring purposes and ensuring security policy purposes

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

In this example, we are creating DaemonSet with the name “fluentd-elasticsearch” with labels as k8s-app: fluentd-logging.

It will match the label “name: fluentd-elasticsearch” and manages them .

The template section of Yaml will be the metadata of the pods that will be created.

Toleration is defined so that if the pod will be created on the control plane node.

The containers section of YAML will contain names and images of container-related details. Limit and resource requests are configured to be used by the pod. Volume mounts details are provided such that it mounts on the host path i.e. the node on which the pod is running and uses the path /var/log.

Cron Jobs

A cronjob creates jobs that are scheduled. It is useful for taking backups, report generation, log rotation, and so on.

Example

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

In this example, we are creating a CronJob with the name “Hello” which will be scheduled to run every minute. The templated section will contain the metadata of pods created so basically we are creating a container of image busybox which run commands of date and Hello from the Kubernetes cluster.

Jobs

A job will create one or more pods and run specific tasks on it and the job controller will monitor the status of running jobs and mark it complete once the task is complete.

If a pod fails, the Job controller can automatically restart it until the desired number of successful completions is reached.

Example

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

In this example, we are creating a Job with the name pi. The template section will contain the details about the container name and image and the command to run once the pods start.

The backoff limit is nothing but for handling job failures by setting a number of retries it will be for the pods.