Pods, ReplicaSets, and Deployments- Kubernetes Fundamental - Ep. 4

20 years ago, a seed was planted and cared for

We painstakingly nurtured it and weathered it against adversity until one day it blossomed and the fruits of our labor began to show

Today, millions have learned, shared, and been inspired by what our community has produced

We proudly serve 21 million users from 204 countries in 2019. For our 85,000 technical articles, code samples, and videos, our 450,000 forum questions, and our highly anticipated conferences and events featuring keynote panels, live streams, and industry experts and influencers, we recognize and reward members for their dedication to the community

Through content contributions and mentorships, we ranked number 2,620 in the world with the reach of millions across our social media channels

Thanks to you, our global community of software and data developers grows stronger each day

For more information, visit us at csharpcorner.com. Good morning, everyone. Welcome to the Kubernetes Fundamental Series

This is session four. My name is Rodrigo. And today I will be talking about pods replica sets in deployments

So let's get started, shall we? So before we describe what replica sets are and deployments

let's do a short and quick recap about the things that we've seen up to this point

As you might remember, we were talking about the fundamental resources that we can deploy in a Kubernetes cluster

Of course, we want to run our container applications, right? So we have our containers

and those containers will be deployed into a pod. The pod is the smallest object

that we can deploy in a Kubernetes cluster, okay? That's where your containers are

You can have one container, or you can have more than one container

if you're, I don't know, implementing the sidecar design pattern or other design patterns that use more than one container

And those pods, it's quite strange if you deploy them directly. That's actually, I don't think that's something

quite real world. actually you don't deploy your pods directly. What you use is a replica set

And the replica set is this object that allows you to replicate the pods

And actually it has the configuration about how many pods you want

in your Kubernetes cluster at a given time. And then you use the deployment

Actually the deployment, I think that's more common. you create a deployment.jml file

and you deploy that.jml file to create the deployment itself. And the deployment has inside a replica set

which in turn has the definition of the pod that you want

and how many replicas of that pod you want. Okay. So as I mentioned before

you can have more than one container and there are others. there are other objects that we can deploy

in a Kubernetes cluster. I'm gonna talk about that maybe today, maybe in the next session, such as the service object

Anyways, then we explain the imperative versus the declarative approach of defining things

I mentioned before that the imperative way is when you type the commands

And those commands will execute and change the things that you're specifying in those specific lines

One of the things about the imperative way is that you're explicitly telling Kubernetes what to do

Instead, we use the declarative way. I think that's more real world

Actually, if you're looking for the CKA or CKAD certifications, you're going to be presented with a lot of JAML files

because that's the way that we use for this declarative approach. You can use JAML, you can use JSON

So the difference is that with this kind of text files, you are describing what you want

And Kubernetes is going to accomplish what you're trying to implement. Okay

Because Kubernetes is based on this desired state thing. So you're declaring the desired state of things and Kubernetes is going to fulfill that desire for you

Okay. So, and then we talked about that declarative is the preferred way, as I mentioned before

And we can also use a hybrid approach, which is just execute your imperative commands and obtain the JML or JSON structure

And then use that for creating your declarative manifest files. So here's an example of creating a pod by using kubectl run

kubectl run is the command that we use to create a pod. In this case, it's creating a my nginx

that's the name of the pod and it's using the nginx image

If you don't specify a fully qualified name, it's going to use the Docker Hub registry

which is the default, okay? And here's another example of creating a namespace

I'm going to talk about namespaces in the following sessions. So as you can see, I'm using kubectl again

This time it's using the create command for creating this namespace. Here's another example of the declarative approach

Actually, we created a manifest file from scratch by using Visual Studio Code

and some of its plugins for creating this YAML files In this case as you can see we have four main elements such as API version kind

metadata, and spec. So API version is the API version that you want to use

It's related to the Kubernetes version that you're using. Kind is the kind of object

that you want to deploy. Metadata is the group of all the metadata elements

that you want to specify for this particular object. And finally, spec is the place where you specify

the traits of that particular pod. In this case, it's just specifying

that the name will be NGINX and it's based on the NGINX image

So with the hybrid approach, as I mentioned before, we can use this command to output the Jamel content

and then create a Jamel file. So you can use it directly, maybe not

maybe just use the structure for, as a baseline, right? And well, actually I think that's pretty handy

Other commands, kubectl delete for deleting objects, kubectl edit for editing objects

And finally, kubectl replace for replacing the properties of a specific object inside the cluster

I mentioned the difference between kubectl create and kubectl apply. The difference is that kubectl apply

if the object doesn't exist, it will be created. And kubectl create, if the object doesn't exist

is going to return an error. That's the difference, okay? So I mentioned the manifest files

Those are the files that we create by using. Actually, you can do that from scratch if you're willing to do it

However, there are a lot of applications and templates that we can use

such as the ones that we can find in Visual Studio Code

So for instance, let me open here the terminal and let's create session four

session four right and let's open up visual studio code and here i just want to create a demo.jamml

file and here i'm gonna use pod and as you can see i have this intellisense thing so i can press

tab and i have this nice placeholders that i want that i can use for specifying some of the

elements in some of the values of those elements in this file

such as, I don't know, my awesome pod or something, and then the image, I don't know, NGINX again

and the port will be 80 or something, right? So I have already a manifest files for creating a pod

This is great. Of course, you can do that or you just can first type API version, then kind, right

And then metadata and finally spec. And then you create all those different elements

However, you need to know the different properties and the structure of that particular object that you want to create

I don't remember if I mentioned that before. However, we have the kubectl explain

man, I think I didn't mention this. kubectl explain is awesome because it allows you to obtain the help

for a particular element in a manifest file. For instance, let's, I don't know

I want to know more about metadata.name. So you execute this command

and this will return the help for this particular element. Of course, this is gonna return an error

because I don't have a cluster yet. Let's do that. Let's run the terminal as an administrator

And here, I'm gonna do the following. Remember that we're using MiniQube

as the technology for deploying the cluster. So I can run MiniQube, delete

So this is gonna delete all the different virtual machines that were before

And let me show you that I'm gonna open up Hyper-V Manager

And this is deleting those virtual machines, right? So this is stopping the virtual machines

deleting the virtual machines, and then I can create a new cluster

So let's wait for this. And again, Minikube, start, and then the driver will be Hyper-V, Hyper-V

and then the nodes will be, let's say three. And this is gonna deploy a cluster with three nodes, okay

So let's wait for that. In the meantime, let's go ahead and continue with this recap

I mentioned API version, which is the version of the API that you want to use, right

We can use the API versions command to obtain all the different compatible API versions

that your cluster supports. The kind is the kind of object that you want to deploy

Metadata here is the place where you specify all the different traits about that particular object

and metadata, such as name, namespace, labels, and annotations, and some other things

and finally spec which is the specification of that object per se okay so when you create

those objects in your cluster each object has an auto-generated UID actually you don't

manage those ideas directly or reference those ideas directly however is something that you

you should know each object has its own identity. Then I talked about pods

which is the primitive object for running an application. This is the place where you deploy your containers

Okay, this is the smallest object that we can create in a Kubernetes cluster

And generally speaking, there's a one-on-one mapping between a pod and a container

And of course you can deploy more than one container in a single pod for some scenarios

such as any containers, the ambassador pattern, the adapter pattern, or the sidecar pattern

that is used by DAPR, which is some fantastic framework for creating distributed applications and microservices

Actually DAPR is based on this sidecar design pattern. So actually what you use is the pod for deploying your containers However you don scale an application by just adding more containers to a pod okay You don have

What you use is a replica set. And that's what I'm going to explain today

Cool. I mentioned the lifecycle of pods and some of the commands that we can use to manage pods

So let's wait for this cluster to be created. As you can see, those three virtual machines

are already deployed. And it looks like it's going to finish sometime soon or not

Okay, let's wait for this. Anyways, there are other container, I'm sorry

there are states for containers as well. We have the life cycle states for the pods

and we also have container states. So you can know if a container is running or it's not

Cool. So let's talk about replica sets. So this object, it allows you to specify a number of pods

that you want to execute at any point. So this is based on the promise theory

that Kubernetes implements. So that promise theory is related to the desired state of things

So you define this desired state and Kubernetes is gonna fulfill that desired state

for you automatically. You don't have to do anything about that. That's actually one of the objectives

and goals of Kubernetes, okay? So you can use this replica set object independently

However, usually we define it inside a deployment. A deployment in itself has a replica set

That's an inherent replica set, okay? Back in the day, some years ago

we have the replication controller. And actually that's the original form of replication in Kubernetes

Then ReplicaSit was created. I think this is the way to go nowadays

But of course, if you, I don't know, if you open a book about Kubernetes, an old one

or a video or blog post about Kubernetes, And if it's, I don't know, if it's, I don't know

maybe three years from now, or it's older than that, then you can see the replication controller being mentioned

However, replica set is the way to go, okay? So cool, how can we create the replica set objects

So let's go back here to the terminal, kubectl get nodes, let me execute this

to know if everything is running correctly. Config get nodes, is that it

Config, I'm sorry, get nodes, I'm sorry. And the other one is config, I can remember the other command

for obtaining the information about the cluster. Anyways, this is running. Okay, I have three nodes

and I want to execute the other command that I was telling you about

which is explain pod metadata dot name. In this case, as you can see

it's telling me the description about that particular element inside the pod object

So I'm obtaining this help, this command, contextual help about that here in the terminal

which is great. I think this is a great way to learn

about the Kubernetes objects. Another example could be, I don't know, specs

This is spec and then containers. Is that the name? Yes, containers

So as you can see, for instance, this containers element has art command

and from image, liveness pro names, the name ports and so on and so on and so on

I'm telling you this because this is a great way to understand the structure of objects in Kubernetes

Let's go back here and let's open up Visual Studio Code again

I'm going to open up this demo.jamo file again. But this time I'm going to use the repli word

and then I'm gonna press top. As you can see, I'm creating a replication controller

This is the one that I was telling you about that this is the old object

And of course, this is not going to work. Of course it's going to work

but I don't want to deploy this kind of object, okay? I need something to tell me the structure of the replica set

I want to create a replica set. I believe this plugin that has the replication controller

template doesn't have the replica set template. However, let's search for this

in the Kubernetes documentation replica set, Kubernetes schema or something, right? And here's the replica set

And here's an explanation about replica sets. And I'm gonna copy this. Okay

And I think that's enough. Okay. So let's do this. I'm gonna create this replica set

I think the difference is in the match labels. element I'm not sure I mean the difference between replica set and replication controller

anyways as you can see the API version is different this is one of the differences

because because replica replication controller uses the v1 API version in replica set is using

apps slash v1. So we have API version, kind, metadata, just the regular stuff that I told you about

Of course, I'm going to explain labels and some other things such as match labels

and annotations later in this series, okay? However, here, as you can see

inside this spec element, we have the replicas element. With this value, you're telling Kubernetes

how many replicas you want for this specific pod. So in other words, you don't need to specify

a replica set inside the spec You just specify your pod and then with the replicas element

you're telling how many replicas you want. In this case, it's going to create this PHP Redis container

Actually, let's do this. My nginx and then again, and this is because this is the image

that I've been using since day one. So I think this is great

nginx, this is a type of nginx. My nginx, okay. So this is the structure of a replica set object

Actually is very similar to the pod specification. Actually, this is the pod specification. Okay

So let's do this, my pod.jml. Let's create a pod just to see the differences side by side

So this is the pod. Okay. And this is the replica set

And if we compare the spec, actually it's almost the same. Actually, you know what

This is the pod. This spec that is inside this other spec

this is the spec for the replica set. And this is the spec for the pod

Okay. So this is the comparison. This one against this other one

So inside the spec of the replica set is the replica settlement

that you use for specifying how many replicas you want. And you have other things such as selectors

match labels and so on. And here's the pot. Okay. So as you can see, this is like a copy of the pot spec

Actually, if you copy this and then you paste this inside the spec

it should work. This should totally work. Okay. In theory, this should work

Actually, you know what? Let's do this. So I just want to get rid of the resources element because I don't want to talk about resources today

And my Nginx, my Nginx, Nginx, and then the image should be Nginx

And this should work. Okay. This is actually what we had before I deleted the entire element

And so actually I'm going to just undo the changes because I don't want to mess with the names

This is the thing that the code that I pasted, let me show you one thing

because this is not going to work if I continue with this, okay

So let's close this. And again, I have API version kind metadata

the meta and the spec, this is the spec for the replica set

the spec for the pod. Why in the world, this is not going to work

if I deleted this other elements? Well, actually I wasn't deleting this

I was just changing the name of the image. The thing is, I don't want to confuse you today

The thing is that those labels are quite important. Those labels are the way that the replica set uses

for detecting what are the pods that this replica set object is going to manage

Okay, that's the reason why I'm explaining and I'm mentioning this. Anyways, bear with me friends, okay

We're going to see labels later in this series. Okay, so my Nginx

Nginx. This is safe to change. This is nothing wrong, okay? This is just using the front-end labels, which is fine

Those pods will have the front-end labels and that's great, okay. So let's try to deploy this

Let's go back to the terminal and I have those couple of files

and then kubectl apply and then the file and then the demo.jml file

So as you can see, the Replica set object was created successfully

At least this is the status that the apply command is telling me

And how can we know if those pods were created and the replica set was created

So remember that we have the get command and you specify the name of the object

that you want to query. In this case, I'm gonna use pods

I could be using pod as well. Pod or pods is the same

So as you can see, this is creating those pods. And actually those three pods

are running correctly. So let's go back here to Visual Studio Code

and let's change the replicas to 10 instead of three. And let's run again, the apply command, okay

I'm changing the replica set object. And now if I execute the get pods command again

you can see that now I have 10 replicas instead of three. Okay

So Kubernetes is fulfilling this desired state for me. I'm not creating each of those pods manually, right

I'm just specifying, hey, you know what, Kubernetes? I want 10 replicas of this pod

And the specification of the pod is this, okay? This is great

This is great because actually this is one of the main traits of Kubernetes

fulfilling the desired state of things. So let's verify this. What happens if I delete this pod

which in this case, it has the frontend-47 blah, blah, blah name, okay

What's that name? Remember that when we created the pod manually, I had the chance to name the pod

with whatever name I wanted, right? In this case, it's using the name of the replica set

which is frontend, okay? And then a hash name, okay? So it's making sure that those pods have different names

and of course different IDs. So what happens if I delete the frontend dash 47.5

and blah, blah, blah. Let's do this, okay? kubectl delete pod and then the name, okay

And then I execute again, get pods. So I was fast enough and quick enough

to execute the get pods command again to see that the 96 pod

this one is being created, right? So if I execute again, this is running

So there's no old, the old pod was deleted. However, because of the desired state of things

Kubernetes is fulfilling that and is creating an additional pod for me

because I want to have 10 instead of nine, right? Make sense

So this is actually the heart of Kubernetes, fulfilling the desired state of things

So I have three, four, five, six, seven, eight, nine, 10. And I can identify this newly created pod

because of the H, right? Cool. And I can also query for those replica set objects

So actually you can execute kubectl get and then replica set, okay

Or another alias is rs. So as you can see, I have this front end replica set

And it's telling me some important and interesting things, such as the desired number of pods and how many pods are currently running. cool so

I can also use kubectl describe and the name of this replica set

so as you can see if I execute the describe command against the front end

replica set I'm obtaining all the details about that replica set so it's telling me that

So those pods were created, right? And there was this last pod that was created after the fact

Cool. And what happens if you delete the replica set? So let's do this, kubectl

delete replica set, and then the name, which is frontend. And of course those pods will be deleted

The pods will be deleted automatically if you delete the replica set that was controlling

and grouping all those pods. Okay. Make sense? That's why the match labels and labels

and some of those things are I'm gonna describe that and explain that

maybe in a couple of sessions. However, we can see that if you delete the replica set

all the pods will be deleted as well. Cool, so now let's talk about deployments

The deployment is the object that we actually use most of the time, generally speaking

when deploying applications in the Kubernetes cluster. Okay. Actually, it's almost similar to the replica set

It's almost the same. However, the deployment has a trait, a different trait, which is controlling the rollbacks

and rollouts of those applications in a safely way. So the deployment object enables you to deploy

and manage updates for pods in a cluster. Yeah I guess you can use replica sets in real world applications However you use deployments most of the time because the deployment uses a replica set inside

And it manages the life cycle of pods because if you create a pod manually

that pod is not going to be relaunched if it fails or something

That actually is the responsibility of the replica set. And of course, there's a replica set inside of deployment

The thing is that if you changed a replica set, it wouldn't take an effect on existing pods

So for instance, if you want to, I don't know, Let's change the, I don't know

the resource limits or even the image name, okay? If you change the image name

and some specific properties about the replica set, such as the spec element

the replica set will not do anything special, okay? This is important

That's why the deployment is better in this case. And actually that's the object that we use most of the time. Okay

And this is why this is telling me that it's a higher abstraction. Okay

It wraps one or more replica sets and it provides control rollouts

And of course you can roll back those rollouts as well. So yeah, the best practice is to use a deployment

Let's create our deployment and let's see what happens. Okay, so let's go back here

and let's create my deployment.jml. And here I'm gonna write deployment

gonna press tab. And again, this is the deployment object, which is inside the apps forward slash V1 API version

version very similar to the replica set okay and actually i think this is uh basically the same okay

let's change those values for instance the name of the application say my deployment okay and the

and the image name will be NGINX, and the container port will be 80, okay

I just want to get rid of that resources element, okay? It's okay, it's okay if I have this yellow squiggly line

it doesn't matter right now, okay? So let's compare those two files

As you can see, of course, kind is different, right? Metadata, of course, the deployment has the name

and the replica set has labels as well. So I guess it's almost similar, right

So let's change the number of replicas inside the deployment. where will be the place where we can implement

this replicas element? So this is inside this spec, replicas. Let's do this

Let's go back to the terminal. Let me see if I don't have any kind of replica set

Okay, I deleted all the pods by deleting the replica set. Okay, let's execute kubectl apply

and then the name of the file, which is my deployment.jml. So the deployment is created successfully

And now let's see kubectl get pods. So as you can see, again, I have 10 pods

However this time the name of each pod has the name of the deployment dash and then the name of the replica set dash

And the hash, instead of just using the replica set prefix. And another thing is that the name of the replica set

was created randomly. This is another hash string. And let's see what happens if I execute kubectl

kubectl, kubectl, kubectl, get replica set. And the name of this replica set is my deployment dash

that randomly created name. The desired state is 10, 10 pods are running

in this moment. And now I can get all the different deployments

Okay, get deployment or get deployments, those two are alias, okay. And I have my deployment object that I just created

It says ready 10 over 10. This is, I wanted 10 pots and 10 pots are ready

pods are running. This is the summary of that line and some other things such as up to date

and available in DH. Let's see what happens if I execute OY

As you can see, this is telling me some other things such as the containers, images and the selector

which is a topic that I'm going to explain when I explain the labels and annotations, okay

Cool. So this is telling me that everything is running correctly. I have 10 pods inside a replica set

that is inside a deployment, okay? So everything is running correctly. What happens if I changed one of the elements

inside the deployment object. In other words, what happens if I go back to Visual Studio

and edit the, I don't know, maybe the spec of the container

Let's do this. However, let's go here to hub docker com and search for NGINX because I need other tag

I don't know, maybe 1.22, okay? 1.22, I want to use this other image name

Of course, that's a different image name, right? So what happens if I apply this

jaml file again? kubectl apply, my deployment, Okay, it's telling me that it was configured

and now let's execute pods, get pods again. So this is interesting because those pods

all the pods were terminated gracefully and then it's starting and creating other pods

Right now, new 10 pods are running right now. However, I have 10 pods that were using the NGINX image name

and then I changed the image name to use the 1.22 tag

And then Kubernetes detected that and gracefully terminated all the previous pods

and created new ones, okay? Without me doing anything Again this is the desired state of things This is the promise theory that Kubernetes offers right

Let's do that again. Let's change this image name to other thing

I don't know. You know what? Let's use Redis or MySQL or something

It doesn't matter. I just want to change the image name and I want to download another

completely different image name. So I can have enough time to show you the things

that are happening in that particular moment. Okay, so I'm changing the image name to Redis

and let's apply this deployment again. Let's execute get pods. And as you can see, those new pods are being created

One, two, three, four, five. Okay. Some others were running at that moment

And now all 10 pods are running again. And I guess this is because I had the Redis previously

So it wasn't what I expected. I expected to, you know, to download everything from scratch

So anyways, I have a lot of different image names right now

Anyways, it doesn't matter. Okay, it doesn't matter. This is being controlled and managed by the deployment object

Just make sure that you identify that those pods are being created again

And the previous pods are being terminated gracefully. Okay, so I think this is what I had for today

So kubectl get deployment and these the pods are being changed by the fact that I'm changing the manifest file

That's one of the traits about deployments. And yeah, so in the next session

I'm going to talk about services because those pods are running, right

However, it's not that you're going to query those pods directly. And let me show you why

Let's see what's going on here. As you can see, each pod has its own IP address, okay

However, pods could be terminated and could be created again. So the IP address and the name of

of course, the name of the pod is quite volatile, right? And the IP address as well

So it's not that you're going to query those pods directly. You're not going to execute nothing

against those pods in a direct way. You need something in the middle

and that's the service object that we're going to deploy in the next session

And I'm going to talk about more things about the deployment objects

such as rollbacks and rollouts and the history of the rollouts and those things

And yeah, thank you very much for your time. And let's see if we have some questions

Okay. So the stream will end after I end the show. Okay

So thank you very much for your time, friends, and see you on the next session about this Kubernetes series