Introduction to Core Objects & workloads - Kubernetes part 2
Tags: kubernetes, aws
Published: 2023-12-27 11:12:39

Hi folks, so I hope you guys enjoyed my first blog about Kubernetes introduction and here we go again with the core objects and workloads of Kubernetes. There are pods, namespaces, labels and selectors. Now we can observe the one by one.

**Pods:**
Pod is the smallest unit that can be deploy into the cluster. A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. 
So, when creating a pod we can use some commonly use commands, I will add them below for your understanding.
`kubectl -f <filename.yaml>`
Using this command you can create a pod and the content that need to create the pod should be attach into filename file in YAML format.
After creating the pod you can list all pods using command, 
`po`
So, those are the main concepts about the pods in brief. Then let's dive into labels.


![selectors & labels](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ffv00hc8hlvsslq2odnh.jpg)
**Labels:**
Key/value pairs called labels are affixed to objects, such Pods. Although labels do not immediately imply semantics to the main system, they are meant to be used to indicate distinguishing features of objects that are meaningful and important to users. Subsets of objects can be arranged and chosen using labels. At the moment of creation, labels can be affixed to objects, and they can be added or changed at any point. A set of defined key/value labels may be present in each object. Every key for a certain item needs to be distinct. Then let's move on to our next topic, that is selectors.

**Selectors:**
Another important component of Kubernetes is selectors. `selectors` is a field present in most Kubernetes objects that selects based on labels. Set-based and equity-based selectors are the two different varieties. More sophisticated operations like in, not in, or, and exists are possible with the latter. Both the equality-based match labels and the set-based match expressions must be true if they are supplied.

In services, labels and selectors are important. For example, a service uses labels and selectors to choose which pods to send traffic to. The service will route traffic to the pods that fit the label app nginx if ports are labeled based on app nginx and the selector is based on {app nginx}. This is about selectors and then we will go through the workloads and their methos.

**Workloads:**
A Kubernetes application is called a workload. Using Kubernetes, your workload is executed inside a collection of pods, regardless of how many interdependent components it consists of. A cluster of containers that are currently executing on Kubernetes is represented by a Pod.

Pods in Kubernetes have a specified lifespan. For instance, if a catastrophic defect occurs on the node where a pod is executing in your cluster, all of the pods on that node would fail. Even if the node later recovers, Kubernetes views that degree of failure as final and requires you to construct a new Pod in order to recover.

However, you don't have to actively manage each Pod, which will greatly simplify your life. Alternatively, you can use workload resources to handle a group of pods under your control. These resources set up controllers to ensure that the desired number and kind of pods are operating in the desired state.

Numerous workload resources are integrated into Kubernetes, those are replicaset, deployment, demonset, statefulset, job and cronjobs. Now I'll go through one by one.

**Replicaset:** - This is the primary method of managing pod replicas & their lifecycle. And always this will ensure the desired number of pods are running. This yaml file that added below will help you to get some idea about the yaml file format when creating a replicaset.


![replicaset](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fi8xpzqzpw4iqspof3sr.PNG)

**Deployment:** - This is the way of managing pods via replicaset, because we cannot create a replicaset directly. We will create a replicaset using deployment. And also this will provide rollback functionality and update control. This updates are managed through the pod-template-hash label. This is an example yaml file for an deployment.

![deployments](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/da7wiviii6rauxqpyff3.PNG)

**Demonset:** - This demonset will ensure that all nodes matching certain criteria will run an instance of the supplied pod.And also this demonsets are ideal for cluster wide services such as log forwarding or monitoring.

![demonset](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gje1nl898tvq5z3j86hx.PNG)

**Statefulset** - Statefulset is tailored to managing pods that must persist or maintain state. It will assign an unique ordinal name following the convention of , 
<statefulset name> <ordianl index>
And also it will be useful when stable, unique network identifiers, stable, persistent storage and ordered, graceful deployment and scaling.

![statefulset](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h3wnhhu6m68zxb1hpg3p.PNG)

**Job** - All workloads that we learn before are used to continuous running clusters. But if we need some workload to run until their task is completed, we use jobs.  In jobs it always running for a specific task and after it is completed, the job will terminated.

![Job](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/731i04u0h2h789mdnvpb.PNG)

**CronJobs** - Cronjobs are an extension of the job controller, it provides a method of executing jobs on a cron-like schedule. 

- Schedule - the cron schedule for the job.
- SuccessfulJobHistoryLimit - the number of successful jobs to retain.
- FailedJobHistoryLimit - the number of failed jobs to retain.

![Cronjob](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x7hx144i6o3lvrarmiyq.PNG)

References:

- https://kubernetes.io/docs/concepts/workloads/controllers/
- https://theithollow.com/2019/01/31/kubernetes-services-and-labels/