Kubernetes Workloads-Deployments, Jobs , CronJob etc
Kubernetes Workloads
Kubernetes is a powerful container orchestration platform that enables you to deploy, manage, and scale containerized workloads. Kubernetes workloads refer to the applications and services that you deploy and manage on a Kubernetes cluster.
Here are some common types of Kubernetes workloads:
Deployment: Deployments are the most common way to deploy applications in Kubernetes. A deployment is a set of identical pods, usually running the same container, that are managed by a controller. Deployments enable you to easily update and roll back your application to previous versions.
StatefulSet: StatefulSets are used for stateful applications that require stable, unique network identifiers and persistent storage. Examples of stateful applications include databases, message queues, and key-value stores.
DaemonSet: DaemonSets ensure that a specific pod is running on every node in the cluster. This is useful for monitoring agents, log collectors, and other system-level services.
Job: Jobs are used for batch processing and one-off tasks. A job creates one or more pods to run a task, and terminates them once the task completes.
CronJob: CronJobs enable you to schedule periodic jobs in Kubernetes. You can use CronJobs to schedule backups, perform maintenance tasks, and run other periodic processes.
Deployment:
In Kubernetes, a Deployment is a high-level resource that defines a desired state for a set of identical pods. Deployments are the most commonly used workload in Kubernetes as they provide a declarative way to manage application updates and rollbacks.
Here's how a Deployment workload works in Kubernetes:
You define a Deployment object in a YAML file. This file includes the specification for your application, including the container image, number of replicas, and any other configuration options.
You use the kubectl command-line tool to create the Deployment object on your Kubernetes cluster.
Kubernetes creates the desired number of replicas (pods) of your application based on the Deployment specification. Each pod runs a copy of the same container image.
If the number of replicas specified in the Deployment changes, Kubernetes will automatically create or destroy pods to match the desired state.
If you need to update your application, you can update the Deployment specification and apply it to your cluster using kubectl. Kubernetes will automatically create a new set of pods with the updated configuration, and will gradually switch traffic to the new pods while removing the old ones.
If there are any issues with the new pods, you can roll back the Deployment to a previous version using kubectl. Kubernetes will automatically create a new set of pods with the previous configuration and gradually switch traffic back to the old pods while removing the new ones.
Here is the Deployment of Django Application:
- Create Deployment YAML file:
#filename:deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: django-todo-deployment
namespace: django-todo-ns
labels:
app: django-todo
spec:
replicas: 3
selector:
matchLabels:
app: django-todo
template:
metadata:
labels:
app: django-todo
spec:
containers:
- name: django-todo
image: trainwithshubham/django-todo:latest
ports:
- containerPort: 8000
- Apply the YAML file to your cluster
kubectl apply -f deployment.yaml
- Verify the Deployment
kubectl get deployment django-todo-deployment
kubectl get pods -l app=django-todo
Update the Deployment (optional)
qRoll back the Deployment (optional)
Click here for detailed steps to deploy the application
StatefulSet
A stateful application is an application that maintains state or data that persists across multiple user or system interactions. In other words, the application keeps track of data that changes over time and needs to be preserved even if the application is restarted or redeployed. For example, a database is a common type of stateful application.
StatefulSet is a Kubernetes workload object that manages stateful applications. It is used to deploy and manage stateful applications that require stable network identifiers, persistent storage, ordered deployment, and scaling.
Unlike a Deployment object that manages stateless applications, a StatefulSet maintains a unique identity for each of its Pods. It provides guarantees about the ordering and uniqueness of Pods, and provides stable network identities and persistent storage for each Pod. This makes StatefulSet ideal for stateful applications like databases, messaging systems, and other applications that require reliable and predictable storage.
When a StatefulSet is created, it will create a specified number of Pods, each with its unique hostname and network identity. Each Pod will be created in sequence and the StatefulSet will not create the next Pod until the previous Pod is running and ready. This ensures that Pods are created and started in the correct order, and that each Pod has a unique network identity.
StatefulSets also support scaling, rolling updates, and deletion of Pods. When scaling a StatefulSet, new Pods are added in the same order as the original Pods, ensuring that the order is maintained. During rolling updates, Pods are updated one at a time, ensuring that the stateful application remains available throughout the update process.
To deploy an application using a StatefulSet in Kubernetes, you can use the following steps:
Create a YAML file for your StatefulSet, defining the desired state of your application. The YAML file should specify the number of replicas, the Pod template, and any other required configuration, such as persistent volumes or network settings.
Here is an example YAML file for deploying an application using StatefulSet in Kubernetes:
apiVersion: apps/v1 #apiVersion and kind specify that this is a StatefulSet object. kind: StatefulSet metadata: #metadata specifies the name of the StatefulSet. name: mongodb #spec defines the desired state of the StatefulSet, including the number of replicas, selector, service name, Pod template, and volume claim templates. spec: replicas: 3 # replicas specifies the desired number of replicas for the StatefulSet. selector: #selector specifies the label selector used to match Pods to the StatefulSet. matchLabels: app: mongodb-app #serviceName specifies the name of the Kubernetes Service used to access the StatefulSet. serviceName: mongodb-service #template specifies the Pod template used to create new Pods. template: #metadata specifies the labels for the Pods. metadata: labels: app: my-app #spec specifies the container template for the Pods, including the image and ports. spec: containers: - name: my-container image: mongodb-image:latest ports: - containerPort: 8080 #volumeMounts specifies the volume mount points for the container. volumeMounts: - name: my-volume mountPath: /data #volumeClaimTemplates specifies the templates for the persistent volumes used by the Pods, including the access mode, storage class, and storage size. volumeClaimTemplates: - metadata: name: my-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: my-storage-class resources: requests: storage: 1Gi
Apply the YAML file using the
kubectl apply
command. For example:
Copy codekubectl apply -f statefulset.yaml
- Verify that your StatefulSet has been created and is running correctly using the
kubectl get
command. For example:
arduinoCopy codekubectl get statefulset
kubectl get pods
- You can perform various operations on your StatefulSet, such as scaling the number of replicas, updating the image, or deleting the StatefulSet using the
kubectl scale
,kubectl edit
, orkubectl delete
commands. For example:
perlCopy codekubectl scale statefulset my-statefulset --replicas=3
kubectl edit statefulset my-statefulset
kubectl delete statefulset my-statefulset
Note that when using StatefulSet, it's important to consider the ordering of Pod creation and deletion, as well as the preservation of stable network identities and persistent storage. You may need to configure additional settings, such as Pod deletion policies or storage volume claims, depending on the requirements of your application.
DaemonSet
In Kubernetes, DaemonSet is a workload that ensures that a copy of a specific Pod runs on every node in a cluster. DaemonSets are typically used to run system-level services or network daemons that need to be present on every node.
When you create a DaemonSet, Kubernetes schedules a Pod on each node in the cluster that matches the Pod's node selector. When a new node is added to the cluster, Kubernetes automatically creates a new Pod on that node. Similarly, when a node is removed from the cluster, Kubernetes will automatically terminate the corresponding Pod.
DaemonSets are useful for tasks that need to be performed on every node in the cluster, such as logging, monitoring, or networking. They can also be used to deploy sidecar containers that run alongside other containers in a Pod.
To deploy a DaemonSet in Kubernetes using a YAML file, you can follow these steps:
- Create a YAML file for your DaemonSet. The YAML file should define the desired state of your DaemonSet, including the Pod template, labels, and any other required configuration, such as node selectors or tolerations.
Here is an example YAML file for a simple DaemonSet:
yamlCopy codeapiVersion: apps/v1
kind: DaemonSet
metadata:
name: my-daemonset
spec:
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image:latest
ports:
- containerPort: 8080
- Apply the YAML file using the
kubectl apply
command. For example:
Copy codekubectl apply -f daemonset.yaml
- Verify that your DaemonSet has been created and is running correctly using the
kubectl get
command. For example:
arduinoCopy codekubectl get daemonset
kubectl get pods -o wide
- You can perform various operations on your DaemonSet, such as updating the image, adding node selectors or tolerations, or deleting the DaemonSet using the
kubectl edit
orkubectl delete
commands. For example:
perlCopy codekubectl edit daemonset my-daemonset
kubectl delete daemonset my-daemonset
Note that when using DaemonSet, it's important to consider the scheduling and placement of Pods across the nodes in the cluster. You may need to configure additional settings, such as node selectors, pod affinity/anti-affinity rules or tolerations, depending on the requirements of your application.
Job
Job is a workload that creates one or more Pods to perform a task and then terminates the Pods when the task completes. Jobs are typically used for batch processing or one-time tasks, such as data processing, data backup, or data migration.
When you create a Job, you specify the desired number of successful completions for the task, as well as the container image to use, the command to run, and any other required configuration.
Here is an example YAML file for a simple Job:
apiVersion: batch/v1
kind: Job
metadata:
name: test-job
spec:
completions: 1
template:
spec:
containers:
- name: test-container
image: test-image:latest
command: ["echo", "Hello, Savita!"]
restartPolicy: Never
In this example, the Job runs a single Pod that runs the command echo "Hello, Savita!"
. The completions
field is set to 1
, which means that the Job will complete successfully once the Pod completes successfully. The restartPolicy
field is set to Never
, which means that the Pod will not be restarted if it fails.
To deploy this Job using the YAML file, you can use the kubectl apply
command:
Copy codekubectl apply -f job.yaml
You can then monitor the status of the Job using the kubectl get jobs
command:
arduinoCopy codekubectl get jobs
This will display information about the Job, including its name, the number of successful completions, the number of failed completions, and the status of the Pod.
If you need to make changes to the Job, you can edit the YAML file and use the
kubectl apply
command again to update it. You can also delete the Job using thekubectl delete job
command:
perlCopy codekubectl delete job my-job
CronJob
CronJob workload creates Jobs on a regular schedule. CronJobs are used for scheduled tasks, such as backups, data processing, or other batch jobs that need to run at specific times.
When you create a CronJob, you specify the schedule for when the Job should be created, as well as the container image to use, the command to run, and any other required configuration.
Here is an example YAML file for a simple CronJob:
yamlCopy codeapiVersion: batch/v1beta1
kind: CronJob
metadata:
name: sample-cronjob
spec:
schedule: "*/5 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: sample-container
image: sample-image:latest
command: ["echo", "Hello, World!"]
restartPolicy: OnFailure
In this example, the CronJob runs a Job every 5 minutes that runs the command
echo "Hello, World!"
. Theschedule
field uses a standard cron expression to specify when the Job should be created. TherestartPolicy
field is set toOnFailure
, which means that the Job will be restarted if it fails.To deploy this CronJob using the YAML file, you can use the
kubectl apply
command:
Copy codekubectl apply -f cronjob.yaml
You can then monitor the status of the CronJob using the kubectl get cronjobs
command:
arduinoCopy codekubectl get cronjobs
This will display information about the CronJob, including its name, the last time it ran, and the status of the last Job.
If you need to make changes to the CronJob, you can edit the YAML file and use the
kubectl apply
command again to update it. You can also delete the CronJob using thekubectl delete cronjob
command:
perlCopy codekubectl delete cronjob sample-cronjob
Thank you Shubham Londhe for KubeWeek challenge. This inspires all learners to showcase their learning and improve their knowledge.
#devops #kubeweek #kubernetes #kubeweekchallenge #trainwithshubham
Thank You!!
Subscribe to my newsletter
Read articles from Savita Shelar directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by