A Guide to Kubernetes (Part 2): Different ways to deploy your application.

Deployments, Jobs, CronJobs and their use cases.

👋 I am Aurimas. I write the SwirlAI Newsletter with the goal of presenting complicated Data related concepts in a simple and easy-to-digest way. My mission is to help You UpSkill and keep You updated on the latest news in Data Engineering, MLOps, Machine Learning and overall Data space.

This is a 🔒 Paid Subscriber 🔒 only issue. If you want to read the full article, consider upgrading to paid subscription.

---

This is a continuation of the Part 1 on Kubernetes where we covered:

• Why Kubernetes for Data Engineering and Machine Learning.

• General Kubernetes Resources for application configuration:

  • Namespaces.

  • ConfigMaps.

  • Secrets.

• Deploying Applications:

  • Pods.

  • Deployments.

  • Services.

As we have already covered in the first part of the article - Pods are almost never used by themselves. This is due to the fact that it would be hard to scale Pods almost in the same way as raw containers - you would need to define multiple Pods and make sure that they are always running. That is why K8s provides multiple special workload resources that take care of deploying and scaling sets of pods for you, you simply define the rules of how to do that.

Today we will talk about the different ways you can deploy sets of Pods to a Kubernetes cluster. We already covered one of the options in the last article - the Deployment. In this issue we will review it and introduce 3 new ways that supplement what Deployments can not do. The four ways are:

• Deployment.

• Job and CronJob.

• DaemonSet.

• StatefulSet.

In this Newsletter episode I cover :

• Deployment.

• Job and CronJob.

In the next one:

• DaemonSet.

• StatefulSet.

Together with explanations of each I will provide:

• Use cases.

• Example Kubernetes resource definitions that you can use to create the resources in your local or remote Kubernetes cluster.

This part of the guide assumes that you have successfully finished all of the setup requirements from Part 1 as they are needed for you to be able to follow the tutorial. Additionally, it will be useful to read through the entirety of Part 1 as we will be using terms explained there without spending much time explaining them in this article.

Why is it useful to know all of the ways to deploy an application in a Kubernetes cluster?

The premise has been set - you develop your application, containerise it and then deploy it to Kubernetes in the form of a Pod. This is how you deploy a single instance of your entire software system, most likely your system is composed of multiple applications. You will need multiple sets of applications running in your cluster performing different kinds of work and communicating with each other in different ways. In order to scale your end-to-end application flow, you will need to employ ways of horizontal and vertical scaling for different parts of the system.

This is where different ways of managing sets of Pods come into play. If you either already have worked with Kubernetes in real life, or you are about to, you will very soon run into situations where using Deployment for every application type cuts just short in specific functionalities. 

Let's see why. It is very helpful to start thinking from the ground up and find out the functionalities each of the application deployment types lack. Let’s start with the Deployment.