How To Upgrade Kubernetes Cluster | EKS Upgrade | DevOps Shack

Hello team and welcome back to the channel. So it's been quite long since I uploaded a video, but here I am. So many of you have continuously asked me to make a video on Kubernetes cluster upgrade and that's the reason that I'm making this video. This video is not going to be a basic level video. This is very advanced level plus from scratch and that means that I'm going to show you how to create a cluster for our demo, then how to set up a scenario using which we can start the upgradation and also I'm going to show you what is the hierarchy that we have to follow in order to upgrade the cluster so that you have complete and detailed knowledge of Kubernetes cluster upgradation. So that if you are going into company and asked this task has been assigned to you to order to upgrade the cluster, you should be able to do it very easily without any issues. But you need to make sure that you're watching the video till end so that you don't miss out any of the steps while doing the upgradation for your own demo. So make sure to watch it till end. Also, if you're new on the channel, make sure to subscribe to the channel so that you don't miss out any of the new videos. Now with that being said, let's get started. So team, whenever we talk

about EKS cluster upgrade, it's not a very simple task because for people who are beginners in DevOps might think that executing a command like this AWS EKS update cluster version and the version that you want to upgrade to, you might think that this command might update your cluster, this single command. But in reality, this single command is going to upgrade just the control plane. That means it's just going to upgrade the master nodes and not the whole cluster. So in order to upgrade the whole cluster, what exactly we need to do? So we need to follow a proper hierarchy. If I explain you in detail, let me make this table bigger using which I can explain you properly. So whenever we talk about like upgrading cluster EKS cluster, we have to upgrade it in phases. For example, first of all, we have to make sure that we are upgrading the control plane master node, right? Then we have to proceed and we have to upgrade the add-ons where we have to upgrade kube proxy, core DNS, VPC CNI, the networking components. Once that is done, then we move to next component which is node groups. Now when you are upgrading node groups, you need to make sure key there is no downtime because on the node groups there will be applications deployed. So you don't want the downtime to happen. So we are going to follow rolling update which is going to make sure key there is no downtime. Similarly, as we move ahead, we can upgrade the workloads, but that is kind of optional. If it is required, then only we upgrade the workloads. So you can see key simply just upgrading the master node or the control plane, it does not mean that your whole cluster is upgraded. You have to upgrade multiple components of your cluster in phases, that also in proper flow so that eventually no issue occurs. So now we can say that when we talk about cluster upgrade, it's not a the single upgrade. It's upgrade of four separate core components. Right? So that's what we are going to do. Now in order to achieve this like how exactly we are going to achieve this and so that you can understand also. So first of all, we are going to set up a scenario where cluster with lower version of Kubernetes, right? And then I'm going to explain you how you can upgrade things in phases. First we have to start with control plane, then we move to next component like that. We'll be we should be able to upgrade our Kubernetes cluster. One very important thing guys that many people miss or many people do not know that you should definitely know is understanding the how exactly upgrade happens. For example, let us say someone said that I want my a cluster to upgrade from 1. 30 to 1. 34. This is not possible in one upgrade. That means key from 1. 33 directly you cannot jump to 1. 34. You can definitely jump from 1. 33 to 1. 34 because 1. 33 next version is 1. 34. That is possible. But if you want to jump upgrade your cluster from 1. 30 version to 1. 34, the way that you have to go is something like this. 1. 30, then you have to upgrade to 1. 31, 1. 32, then 1. 33 and then you jump to 1. 34. So this is also something a very important concept that you should be definitely knowing, okay? So now we are going to set up our cluster and then we are going to set up a scenario where we'll be having a cluster which is of 1. 33 and then we are going to upgrade it to cluster 1. 34. Again guys, I'm saying if you actually want to learn and understand the steps practically, make sure to watch this till end so that you understand the flow and later on when you are implementing it setting up a demo on your own machine, you should be able to do it very easily, right? So let us start with the demo.

So team, before we start with the hands-on demo, first thing that I would recommend you to is watch this part where you I'm going to explain you the exact flow that we are going to implement the demo. So first thing that we are going to set up is set up EKS cluster and we are going to set up the version 1. 33 so that final target can be to upgrade the whole cluster to 1. 34, right? Also, after setting up EKS cluster 1. 33, I'm going to manually introduce an error inside the cluster. So I'll be downgrading the version of kube proxy. Why I am downgrading or why basically I'm introducing the error inside kube proxy because this section that you see upgrade insights, as of now you can see here everything like it's fine. But as soon as I introduce error, so here it's going to show error. The reason that I'm going to be introducing error in the cluster because the one thing you need to understand in reality in productions level is that before you upgrade the cluster, you need to make sure key whatever errors are there inside the cluster, first you need to fix that. That is the reason I'll be introducing and introducing an error here so that I can show you key first we need to fix kube proxy or whichever component is having error and then only we can proceed with the upgradation of the cluster. So that will be the production level thing. Once we have done that, second thing what we are going to do, we are going to fix the error of kube proxy or whichever component I introduced the error. So we are going to fix the error, right? That will be second task. Third thing that we are going to do is you actually need to understand in what flow we need to upgrade the cluster. So let's say these are the main components inside the cluster where we have control plane, add-ons. Inside add-ons we have the network components, kube proxy, core DNS and VPC CNI. Then we have node groups, the worker nodes and the workload. Whatever pod you deploy inside the cluster, those will be the work workloads. So here you need to understand key when we talk about upgrading the cluster, we need to follow an hierarchy where first you need to upgrade the control plane, the master node. Second you move to upgrading the components inside add-ons. Means we need to upgrade these things, kube proxy, core DNS, VPC CNI. And third we upgrade the node group, the actual worker nodes. Okay? And optionally we can upgrade the workload. Note that upgrading workloads is kind of optional. If it is required, then only we are going to do. Okay? So it's not like that key we can directly upgrade the whole cluster in one go. We need to go in proper phases and again this is the flow that you need to follow. First, upgrade control plane, then upgrade the add-ons which is kube proxy, core DNS, VPC CNI, then upgrade the node groups. If there are multiple node groups available, then one by one you have to upgrade and finally we upgrade the workloads. So this is what we are going to do, okay? So kube proxy we fix, then what we are going to do, we are going to upgrade control plane first, then add-ons, the networking components, the node groups, workloads and that is how we are going to upgrade the whole cluster. But again, to understand in practically these things, you need to follow the video where I can show you the proper demo, okay? And after these things are done, then we can confirm and then we can say that our EKS cluster is upgraded to 1. 34. Okay? So yeah, now let us start with the demo. So team, now let us understand the

prerequisite for implementing this demo, implementing the cluster upgrade demo. So there will be certain things that we need to make sure that we have installed them on our machine. First thing guys, I'll be using Windows machine and I'll be using VS code because we don't want to use any third like third VM because it's going to cost something. So instead of that, we could use Windows machine and VS code inside it and we can execute all the commands inside it. Second thing that we'll be needing is AWS CLI so that we can communicate with our AWS account. Third thing that we are going to do, we are not going to be using root user to create the cluster. Instead, we'll be creating a separate IAM user to create the cluster, right? It's better this option will be much better than using a root user. Fourth thing that we have to do is install EKS CTL. Now this is the tool that we are going to use to create the cluster so that once we run the command it's going to connect to CloudFormation and then the cluster will be created. Next thing we are going to do is set up kubectl. kubectl will be required so that we can communicate with the EKS cluster. Also, guys, one very important thing that we need to make sure that we are doing is making sure that these two tools are added to path so that we can call these tools from anywhere because you know, like when you install Java, uh so you have to add the path of the home directory of Java so that we can call it from anywhere. Similar we have to do for these two scenarios, right? So, let us set up.

So, first of all, make sure that you have VS Code installed. I have just created one folder, Kubernetes Demos, and currently we are inside that folder. So, first thing that we are going to do is create one directory. This directory will be named DevOps Tools. This is the folder inside which we are going to install our tools. So, I'm running command mkdir C DevOps Tools. Now, once directory is created, first things that First thing that we are going to do is install AWS CLI. So, I'll be executing this command. So, also guys, I have written all these commands in separate uh file which you'll be able to get from the description in the link. So, you can get it. So, now we are going to execute this command to download the first tool which is AWS CLI. So, now it's uh let's wait for this to complete. We will select and click on next. Now, it's going to install. It will take few minutes, I guess. Once it is completed, then we can proceed. So, team, as we can see, uh AWS CLI is installed. That's good. We can proceed to next steps. Next, we are going to install kubectl. So, we will execute First, we have to download the EXE file. Once we have downloaded, we are going to push this file or paste this file to DevOps Tools folder, the one that we created previously, right? So, once it is downloaded, we are going to move it and let's wait for this to complete. Net is slow a little bit, I be I guess. Okay, so this is done. Now, you can see on left side kubectl. exe file has been created which we are going to move to DevOps Tools folder. Once that is done, this is fine. Next thing what we want to do, we are going to install next tool which is EKS CTL. So, for EKS CTL, we have We actually have to download a zip package. And once you download, on left side you'll be able to see that zip folder and once it is present, we have to extract it so that we can get the EKS CTL file. Right? So, I will run the tar command. And this is going to extract it. Now, you can see EKS CTL file is also extracted which we are going to move to DevOps Tools folder. Now, these EXE files are copied or moved to DevOps Tools folder. Now, what we are going to do, we are going to add this path the DevOps Tools path in C drive to the environment variables so that afterwards we can access these tools, EKS CTL, kubectl from anywhere on the system. Right? So, let us do that. For those who are not able to understand what exactly I'm talking about, you might know that whenever you install new tools, uh you have to provide You have to set up the path which generally we do here. So, most of the tools' path is added here. Right? So, I'm going to execute this command. Sorry. Okay. You see what error it is giving? It's basically giving error because VS Code is not running as administrator. And if I want to Basically, my requirement is that all the users on this machine should be able to access those tools. So, first of all, what I'm going to do, I'm going to start VS Code as an administrator. And once it is done, then I can execute the same command to add those tools. Uh basically add the Add those tools' path inside the environment variables so we can execute this. And once it is done, you can see now it is successful. Same command is successful now. So, this means basically now every user on this machine will be able to execute those commands. Means uh which commands I'm talking about? EKS CTL and kubectl. So, this is done. I'll be removing this zip folder because it's not required anymore. Right.

Right. Next thing what we want to do, we want to create an IAM user. For that, we will go to browser. We'll go to AWS account and here you have to search for IAM. And here go to users and click on create user and you can provide anything. Let's say I'll just provide uh new user, Aditya AWS. I'll provide access to AWS console management console as well and I'll get I'll set up a custom password. And I will uncheck this option so that user is not required to create new password after login. So, click on next. And here click on attach policies directly and for this demo I'll be giving the administrator access which is permissions less than root, but still it has like almost all the permissions. So, for this demo we could utilize this. Once we have selected this policy, we can click on next and click on create user. Once you create user, you'll be able to get the username password and this URL as well. This is quite important so just note it down somewhere and keep it. Right. So, now next thing what I will do, I will go back to VS Code. Here I will run the command AWS configure which is going to give us uh option to provide credentials of the newly created IAM user. Okay, so I have executed the command and it is asking for access key ID, right? We will go back to our user. Users list we will go. Select the user and scroll down to security credentials and create access keys. Select the first option, command line interface because for that only we are creating the access keys and check this up box as well. Click on next and create access keys. Once you have created, copy the access key. Paste it here. Then it is asking for secret access key. So, that also we can copy from here and paste it. Default region name, right? So, whichever region is nearest to you, you could use that. So, for me it is going to be Mumbai. I'll be using that AP-South-1. Click enter. And again click enter. So, now basically what has happened, we are connected to our AWS account using the newly created user which is Aditya-AWS. Right? Next step what we are going to

do, create a cluster of version 1. 33. So, let us do that. Okay. Team, next thing what we are going to do is create a cluster of version 1. 33. For that, we could use EKS CTL command. We can run the command EKS CTL create cluster, name of the cluster which is prod-upgrade-demo. Region we can provide. Again, you can select the region that is nearest to you. For me, it's Mumbai. And version we are defining which is 1. 33. A node group name also I'm giving as ng-1 and node type I'm selecting t3a. xlarge which is going to be a little bit bigger machine, but it's going to be useful for demo. You can use t2. medium also if this is not working for you. So, you can simply replace this with t2. medium. Two nodes I'm creating and with this cluster is going to be a managed cluster. So, once I click enter, it's going to start creating the cluster on my AWS account and using the same user that we have created, the IAM user. You can see CloudFormation will has started using the stack and now it's going to take few minutes to create the cluster. So, we will wait for this to complete. Team, as you can see, the cluster has been created and since we have already installed kubectl, so we can execute the command kubectl get nodes just to confirm. So, you can see currently we have two worker nodes available. Version is 1. 33, right? One question you might think, Aditya, how you are able to run this kubectl get nodes command because as of now we did not like set up the kubeconfig file. So, if you look closely, you can see saved kubeconfig file here. That means we are already having kubeconfig file. So, if you are already having it, then that's why we are able to access the cluster.

Next thing what we have to do, we will quickly go to the browser and here we have to go to the EKS cluster, the one that we have just created. So, you can go to search and you can search for Elastic Kubernetes Service. And it's going to show you. Here you can see certain things. For example, cluster name, uh status active and version, right? So, we will open this. Now, what we are going to do? So, set up a scenario where we are going to basically downgrade it. Okay? So, here first of all, click on add-ons and you can see All the add-on components are here, CNI, CoreDNS, kube-proxy. Right? So, [snorts] what we are going to do? So, here we are going to select kube-proxy. We are going to open that. So, on the kube-proxy page, you have to click on edit and here we are going to expand this option and we are going to downgrade it to the lowest available version. Whatever version you are able to see that is lowest or basically oldest, you can select that. So, we'll scroll down and we will select this one. And we'll click on save changes. Okay, so these changes will take some place and once that is done, then we can proceed. So team, once you have downgraded the kube proxy in add-on section, we kindly wait for this to complete. You can see now it is active and it this is the older version that we have downgraded, right? Once you have done that, once this completed and status is showing active, then you should go to upgrade insights and you have to click here refresh insights. It will take some time to like it refresh completely. Once it is completed, you'll be able to see certain errors here in the inside status. And once we are able to see error, then only we can proceed further. So team, once the refresh inside part is completed and you'll be able to see two errors present. The errors where we have downgraded the system, which was kube proxy, right? So and here also on the dashboard page, you'll be able to see that there are errors in the upgrade inside section.

Next step what we have to do, so we will go back to our VS code. So team, as of now what we have done, we have downgraded kube proxy. And overall also our cluster is on 1. 33. So now what I'm going to do, I'm going to create some deployment so that we can perform like upgradation of the cluster without any downtime. Right. So how do we confirm that? We can confirm that using uh using this deployment. So if there are no issue happens or if the deployment does not crash during the upgradation, we can say that there was no downtime, right? And no application was affected. So let's say I'm doing a deployment of nginx. And once I have done the deployment, we can verify also. We can run kubectl get all. And here we should be able to see that nginx pod has been created and it has been running for last 8 seconds, right? So basically now our scenario is ready. Where the scenario is that let's say our manager says, "You kindly upgrade the Kubernetes cluster without having any downtime and we also have some deployments or some applications running. So these applications should not be affected by the deployment, right? Also, one thing that you should be able to notice and make sure that you do it is take screenshots before we start with the upgrade, right? So let's say first of all, I'll just take few screenshots. So I will take this screenshot page where we have some information. I'm going to save it. So next we are going to take screenshots. click on upgrade insights. We will remove the filter of passing and here also we are going to take screenshots so that later on also we can compare and if required, we can utilize it. So we will save this as well, right? Next thing we are going to take uh screenshot of the node group. So we will go to compute. Here we have node groups, right? So let us take screenshot of it as well. This is basically, you know, when you are actually doing production upgrade, so this is quite useful to take screenshots. So later on, if something goes wrong, we can verify those things, right? Next thing we are going to click on add-ons. And from here also we are going to take screenshot for the like current versions. And I'm going to save this as well. And now next thing what I'm going to do, I'm going to run get the pods. kubectl get pods hyphen n. And we are going to get the information about let's say I'll just run for a means all. So these are the current number of pods that are running, okay? So we are going to take screenshots for them as well. These are basically pods of all the namespaces. Right. And side by side we are also going to take screenshot of the worker nodes. kubectl get nodes. Okay. So basically now we have the current state screenshots also for everything, right? And now we can proceed with the upgradation. Now as I told you previously, the hierarchy will be something like this. First we are going to upgrade the control plane, then add-ons, then node groups and then workloads. Workloads is like only if required. It's not mandatory. For other three, they are required, but for workload, basically our deployments, if it is required, then only we are going to upgrade them. So team, basically let us understand the current scenario, where exactly we are at and where we want to go, right? So

current scenario is that currently our cluster is on version 1. 33. And final goal is to upgrade this version to 1. 34, right? But as of now we have also like in introduced some error in kube proxy. This was manual just for like what kind of scenarios you might get in reality. So uh we have upgraded down upgraded this down to 1. 30, right? Now as per the hierarchy, what was the first component that we needed to upgrade upgrade? It was control plane. But before you jump to control plane, you need to do one thing that is quite important, which is to make sure that here the upgrade inside error, whatever error are here, that needs to be fixed before we jump to control plane upgrade, right? So first thing that we are going to do is fix these issues. So here what exactly we need to do? So here the primary error as we as of now that we are having is kube proxy. So we are going to go add-ons, go to kube proxy and here we are going to click on edit. select the latest version as per the current state of Kubernetes. So we are going to take 1. 33 because as of now our cluster is in 1. 33 only. So we are going to take the latest version of that for kube proxy and click on apply changes. Okay. Now you might think key Aditya, why did we like introduce this part? Why did we downgrade our kube proxy? Even though we our main target was to upgrade this to this. So main thing that you need to understand this I introduced this so that you should understand key in case like in addition of upgrading the cluster were already existing errors. For example, currently our cluster is on this, but inside that the kube proxy was already downgraded to this and it was giving error. That means first before we jump to upgradation, we need to fix this issue. For which what I have done, I have made sure key the kube proxy we have upgraded it to the latest version as per the current version of Kubernetes. Our current version of Kubernetes is what? If I show go here, you can see 1. 33. So kube proxy I have upgraded it to uh 1. 33 latest version, right? So it's going to get upgraded and now we have to wait for some time. Once it is done, then we can proceed with the next steps. Also guys, meanwhile this is happening, this upgradation of kube proxy is happening, quickly we should be going to our VS code and we should verify a few more things. So basically now what we have to do, we have to check if there are any new pods getting created inside the Kubernetes. So if I show you kubectl get pods hyphen a, run this. And here you'll be able to see that kube proxy pods are just recently created. You can see 94 seconds, 97 seconds. Rest of the pods are already running from quite long time. So you can see as soon as we changes upgraded kube proxy component, new pods got created, okay? And make sure that you are able to see there should not be any error. So as of now you can see status is ready, status is running. So no error, so we are good to go, right? So uh once this is done, then we can proceed. Also we will go back to our clusters, go to prod cluster and we have to make sure key all the errors in upgrade insights have been removed, right? So we'll click on refresh insights one. Okay. And we have to wait for it because once these errors are removed, then only we can proceed with the final upgrade of the cluster. And you need to make sure key all the inside status are showing passed or passing. So team, here as you can see in upgrade inside section, now all of the uh inside status is showing passing. That means we are good to go. Same thing you can see on upgrade insights, it's showing passing, right? So that's good. Now we

can click on upgrade and here we have to select the latest version. So see, currently we are in 1. 33 and as I told you key if you want to upgrade the cluster, you can move to next version. So currently we are in 1. 33 and if I want to upgrade to next, I can just go to 1. 34. If I want to go to 1. 35, then I need to upgrade to 1. 34 first. So we'll select this one, click on upgrade. Now upgradation of the cluster will take some time. So once this is happening, what we can do meanwhile, we can go here and we can run kubectl version. And here I can see currently our kubectl version is 1. 33. So let's upgrade this as well. So team, let us quickly set up the kubectl version 1. 34. I can first download the exe file for that. Then we are going to move it to the DevOps tools folder, okay? So let's wait for it. It's taking a little bit of time. Okay, so once it is downloaded, then we can proceed because once it is completed, you'll be able to see that kubectl. exe is present in our current directory. Then only we can copy it to DevOps tools folder. So, let's wait for this. So, team, as of now, the control plane has been upgraded, which is to 1. 34. If you remember correctly, I told you there is an hierarchy that we need to follow. First, we upgrade control plane. So, as

of now, the control plane has been upgraded to 1. 34. But, as we move ahead you are not to upgrade the complete cluster, we have to upgrade the add-ons also. That is kube-proxy, CoreDNS, VPC CNI, right? So, next step would be to upgrade these. So, for that, we are going to click on add-ons. And here, wherever update version, like you see wherever update version thing visible, make sure to upgrade it. So, we are going to click on CoreDNS. Click on edit. And here, we are going to select the latest version, which is this one. We will click on save changes. Similarly, we are going to go to uh next component in add-ons, which is uh VPC CNI. So, we'll open that. Click on edit. And this also we are going to upgrade to latest version, which is this one. Click on save changes. Next, again go to add-ons. And last, we have kube-proxy. So, open that. Click on edit. And now, upgrade this to latest version, which is this one. And click on save changes. Now, as of now, inside the add-ons, you can see uh nowhere it is showing upgrade option. Because whichever was in uh like uh older version, we have upgraded all of them, right? So, now we have to wait for this to complete. And once the

status becomes active, then we can proceed with the next step, which is to upgrade the node groups. Right? So, let's wait for the add-ons component to get upgraded. So, team, uh once this has been done, you can click on add-ons. And now, you can check the status. kube-proxy 1. 34, metric server, it is also like updated to uh latest version. So, as of now, on right side, nowhere you'll be able to see like upgrade version thing. Because all of these add-on components are now upgraded. Right? Next step would be what? We should go to our VS code. And here, if I run kubectl get nodes. And here, what you can see, the worker nodes are currently still in 1. 33. And I as I told you, control plane we have upgraded, add-ons we upgraded, next step to node groups. So, we will go to our browser. Go to compute. Go to here, you can see uh this is the node group name, ng-1. So, we are going to click on now update now. Note uh like note down one thing, if you have multiple node groups, then you have to update them one by one. So, here we will click on update now. And here, we will click uh make sure that this option is selected, update node group version. Update strategy, make sure that you are using rolling update. This will make sure that there is no downtime, because it's going to upgrade worker node one by one. And now, click on update. So, this is also going to uh take some time. And you can check the status in detail here. kubectl get nodes, and you can add hyphen W to show the like uh ongoing status. So, we'll run it. And let's wait for this to complete. So, team, one very interesting thing you should be able to see here, you can see our original worker nodes were like this. 169193. These were the original work uh worker nodes, right? Which were running for 133 minutes. Next thing what happened, you can see two new worker nodes joined the cluster, 67-7 and 86-93. These two uh new worker nodes joined the uh joined the cluster. And basically, what happened, so if I explain you with respect uh with help of a diagram, then it will be much clear clear. Let's say this is my Kubernetes cluster. And initially, there were two worker nodes available. W1 W2. When we ran the upgrade command for these worker nodes, what actually happened, two new worker nodes joined the cluster. Which was worker node three and worker node four. And then the workloads, the pods of whatever we have deployed, they shifted from these two worker nodes to here and here. Right? Once uh pods were uh shifted there, and worker nodes got created, then these worker the older worker node deleted. And that is how the upgradation of the worker nodes was done. And if you see closely here, if I run kubectl get pods hyphen A, so all the pods are running fine. You can see there is no issue now. Right? Now, few things you need to understand very clearly key once upgradation has been done, workload was not required to update in our case, because we did not create our uh like whatever pods we had, right? Especially the engine export, we didn't want to upgrade it. So, it was fine. Current status of our cluster is that, as you can see, current is 1. 34, the Kubernetes version. If I go to compute section, worker node, uh if I refresh the page, let's see worker node is Okay, it's still in updating status. So, once it is updated, then it will be showing you here uh that it is updated or active. And here, the latest version should be showing, which is 1. 34. Right? But, one thing you need to make sure once everything is updated, the worker nodes, the add-ons, the control plane, if everything is upgraded, you need to do again one interesting thing that we did previously. Take screenshots. Previously, we took screenshots of the current state. Now, after upgradation, you need to take screenshots again. And whatever task has been given to you in order to upgrade the cluster, you have to provide all those screenshots that, okay, current state is this. Okay? So, this is how you should be upgrading. So, let's wait for few more minutes so that we can confirm that our worker uh node group also got upgraded from 1. 33 to 1. 34. So, let's wait for it to complete. So, team, after few minutes, it will take a little bit of time, but you can go to compute. And here, in node groups, you'll be able to see the uh release version is 1. 34. This will confirm that node groups have been also upgraded. So, overall, the cluster will be upgraded to 1. 34 version. And if you want to upgrade it to next version, same process you need to follow. Right? And now, next thing that we can do is delete the cluster. So, for that, we could run the command eksctl delete cluster, then cluster name, and the region in which the cluster exist. Okay? So, I hope this video was useful. And if it was, then make sure to give it a like. And if you're new on the channel, make sure to subscribe to the channel. So, thanks for watching, guys. And have a nice day, everyone.