Hey, guys, we are recording this session, we are beginning to discuss Kubernetes first with a brief introduction of what this thing is and then we do most of the discussions actually live hands-on with the setup exercises. And we will be using this beginning point which I just pasted in Slack chat. That point is where the instructions are written down, but they'll help us in walking through hands-on material as we go along. We are recording the sessions, we have a video at the end, and let us go understand first of all what is this thing. So let's go. Do a Google search on what is this thing. So this thing is actually a product. It came from a company called Google. Google has been managing this services in their own business for many, many years, I think more than 20 years now. And for the past 15 or so years, they have been using a product called Borg system. This is their internal system, which is their internal large-scale cluster management. And so they wrote this paper on the Borg system. And I think about two years or so ago, they decided to release this product, Kubernetes, in open source. And so it is based on 15 years of experience building and running production workloads at Google. That's the foundation of this product, which is what we today see on GitHub. You can see that the latest version available is v1.10. These are the versions available. Let's go see what is the source on GitHub. If you go to GitHub and say Kubernetes, you will probably find it. And so here is the product page, and here is the repository. So that's the source code. We will use this source code, but not directly. We'll use a service that will be using this source at the service side. But let's begin understanding what this thing actually does on a plain sheet of paper like that. And so if you notice that there are two things we're talking about. One of them is this thing that is the product. This product is available in open source, and we just discussed that. This product is also available in form of services, ready-to-use services. And these services are using this product, and those services are provided to us in form of the running Kubernetes service. So implementation is done by many, many companies, and these companies are your usual suspects. One of them is the Google company, or rather Google Cloud. Another one is Microsoft's Azure Cloud. Another one is... Let's go actually see the list of who are these companies that are Kubernetes compliant service providers. What does that mean by compliant service? So there is this agency that decides whether your service is exactly compliant with Kubernetes standards or not, and they are the Cloud Native Compute Foundation. And this conformance test is actually listed out at this website, Cloud Native Compute Foundation, and they have a systematic method of evaluating whether a particular service complies with and is actually fitting the requirements of the Kubernetes service. So that is this list here, Kubernetes certified service providers. And here you will see that there are quite a bit of them listed. In fact, here is the list of all the service providers that provide Kubernetes compliant services. And here, one of them should be Google. Actually, there's a fully interactive view map right now. These are even more comprehensive than I saw previously. But if you look at the certified Kubernetes distribution, so if you look at that platform, focus on the platform itself as to who is providing that in terms of cloud-based solution, we will have a list. And so here we see a list of the companies called Google Cloud, Amazon Cloud, Azure Cloud, Baidu Cloud, Digital Ocean, Fujitsu, a bunch of other companies provide the solution that is basically running Kubernetes in a compliant manner, meaning how it meets the requirements laid out by this foundation, Cloud Native Compute Foundation. This foundation is, let's see who the members of the foundation are. The members are basically all these companies that you already know are most common suspects in the arena of cloud computing. You have Alibaba, AWS Azure, all the usual suspects that you think of are together. And there are a whole host of other companies that are also members. And they are together a part of the Cloud Native Compute Foundation, who in turn sets standards about what Kubernetes compliance means, and as a consequence, they have a variety of different providers that are compliant to Kubernetes as a solution. And as a consequence, you have these companies providing you Google Kubernetes Engine is one example. So here is you can try it for free. I think many of you already have an account, so you should just use that account, and it's going to give you $300 of access. Other companies, similarly, AKS from Azure is another service provider that gives you managed Kubernetes solution. And we use that they operate pretty much similar because they are pretty much compliant to the Kubernetes standard. So that's what this brief or from a top level perspective of who the service providers are and what that service they provide is basically a standardized version of running this thing running in the cloud. That's what you see when you use their services. So that is using a readymade service is one way to use it. So this is one way. The other way is the hard way. The hard way requires you to get machines and then install Kubernetes yourself, which is difficult. It takes a lot of time to plan the whole thing. And yes, we have an exercise to do this way also, the hard way. You get a bunch of machines and you create a cluster and you use the product and you run it yourself. Nobody to help you. No automation, no scripting. You have to really understand what it takes to run a Kubernetes cluster. You do this the hard way. And it is also a recommended way to really learn and run Kubernetes yourself in production. So that is a possible way that many companies actually go. If you have the people, processes, money, a budget, all the things needed to make these things happen. That's a valid approach to go the hard way, doing it yourself is also a valid, valid approach. It is easier for us to begin learning the easy way. And the easy way is actually pretty darn easy because these guys have done the work for us. And there are many, many such companies that provide, so we'll just use one of the examples and the example that I have to begin with for our understanding is this example that I think I have written down here. And that's what the easy way of using Kubernetes to understand what it does for us. So that is what our beginning point will be for this particular idea is right here, the easy beginning point. We'll use this service to understand what it actually does for us, implement a variety of details around making that service functional for us, run some applications, run some services for ourselves inside that cluster. And then we'll switch over to this hard way method also. But for right now, the easy way is the way to begin. So let's understand what does Kubernetes actually give you. We will be in our exercise, we'll use Google Cloud as an example. In that specifically, we use the Google Kubernetes engine as a readymade service for us to consume. And when we use that service, what we usually get is a readymade cluster, ready cluster. But what is a cluster? Let's go understand that. So a cluster is basically a bunch of machines put together in which there is something like, you know, you have these machines out there that operate together as a cohesive unit. So it's basically one unit, one. This thing is a unit, the whole cluster together. Inside the cluster, you will have classification of some sorts, like, you know, you have some of these guys will be, you know, worker nodes, and other machines will be the manager nodes. The number of managers is typically in odd number. So you have one manager or three managers or five managers like that you can have set up if you want to set up like that for yourself. And you can have any number of workers on the other side. And that's where the workload actually runs right here. Workload is typically run on the workers. But when you use services like these, or Amazon or Microsoft or other companies, you know, you don't even have to focus on this segment, no worries. So ignore, practically ignore. Because they give you a control plane. The control side of the manager side, you don't have to worry about it. And more importantly, you don't even have to pay for it. It is $0. It is just given to you. This whole component of the management infrastructure, or the management machines, the control plane, all the logic associated is given to you for free, you know, that that's how it goes. So that's the benefit of using a service $0. You just get the management infrastructure from a very small implementation perspective. This boils down to if you want a two machine cluster, you just pay for these worker machines. And you don't have to pay for the manager machines at all. So nothing here, no money spent in that direction, because this is given to you for free when you're going through Google or Microsoft or Amazon or other other companies, most of them give you for free the management infrastructure. You pay for the worker machines. So from a practical usage perspective, you go to a cloud and you say, give me a cluster. I want three or four or five, any number of nodes. So let's call it n worker nodes. They will give you that. That's it. They'll readymade give you a cluster and you just have a cluster on the other on the other on their side, on these guys' side, they will have a management control infrastructure. So they will have a management layer, which will allow you to manage these nodes, which will be n worker machines. And that's what you pay for and you use here. And you also interface with this, but you don't pay for it $0. That side is taken care of from a financial perspective. You just run your work workload here and you use that set of machines in a systematic manner. So now using this set of machines that you have is a fashion in which you actually don't even bother about where you are putting a load. So you have some work item and you were to assign it to some machines. You don't really worry or even think about where you will put that work item. So this item of work that you want to run on which node you want to run in your cluster. You don't have to worry about because there is a component inside Kubernetes that runs in the management plane that actually is responsible for scheduling. Scheduling what? Scheduling the work items that you have. So it decides where is the best place to run your work. And so you don't have to worry about it. So you just give it a work item. It just runs on the cluster somewhere. It will find out the best place to run and it will run it in that location. For example, here is the idea of a cluster. So you can set up a cluster. And so I think the subsequent steps that I have in this exercise are best done if you do it yourself. And that I think is a recommended approach. So since we just began discussing what Kubernetes is, it is a good idea to have a cluster ourselves. Get a ready cluster and get it functional quickly and then use it as we go about describing the concepts underneath. And there are lots of components built in. And each one of these has a link somewhere here that has additional steps or things to do about what that thing is itself. So let's begin with that idea. The first one idea is what is a cluster? And so in here you will put several machines together as a cohesive unit and you will set up a cluster for ourselves. So that is how you do it. So let's go do that. So it's fairly simple to doing it. So you start your virtual machine and in there you put it on and then you follow these steps. The steps are simple. It requires you to have a login with Google, which basically is a Gmail address. And then you have to have a service provider account with Google Cloud, which I think most of you already have. And so we'll use that service account that you have already through Google. And that's what I will be also using. I will use my own service account that I have in the Google Cloud. And I'll begin using that in this on the right half of the screen in which I'm setting up a command line right there and setting this command line to interface with the Google Cloud. And I will be logging on to the Google Cloud right here on this command line. So that's what involves setting up a service provider account. You need to have this Google G Cloud SDK. So do we have a G Cloud SDK? I think you might not have it, but let's check. It's command not found. That means we don't have it. So we'll install G Cloud SDK. How do you install? You follow these steps. So you have to follow these steps to create an environment variable. So somebody just came in. Let's see who came in. Gustavo. Hi, Gustavo. How are you doing? Hello. Doing good. Yeah. We are just beginning to set up our own Kubernetes cluster in Google Cloud. So just want you to be aware of that. That's what I was covering actually. So here we have a command line open and we will be using these steps to install a Google Cloud SDK and then begin interfacing with the Google Cloud and create our own cluster, create a Kubernetes cluster and try to understand what it gives us. And then we will go through a variety of exercises in that cluster for ourselves. So here we have to create an environment variable that defines the current distribution. So here we have this distribution is I think this Uber to Linux distribution. We should start to capture that particular release and grab it and export that in a system variable, environment variable. So I'll go pretty much like that. I have exported this reference and if you now echo that thing, echo the Cloud SDK repo, you will find what it gives us. So it's the Cloud SDK for the operating system, Debian version called trustee is what we are interested in. That's what we put that in a environment variable. Next we will add Cloud SDK distribution URI. So let's go grab this line and what we are really doing is looking at our app repositories and actually it should be CD and there you have a list of repositories that we in our system. If you go look at that, we will find that we don't have, where is this exactly? It's the sources.list.d. So to go one more step, sources.list.d and then list out what we have and we have Docker, we have Heroku, we have Octave, we have these guys, but we don't have Google Cloud. So we will add that as a packet source. So here's what it takes. So you just echo that line into a file with a T. That T command, this pseudo T will drop in this line beginning with Deb into that file. So we'll just run it. It'll ask you for the password and then we have that line in that file. The file we created was this file we just created. If you cut that file, you will find that it contains this line we wanted. So this is the line we want. Now that we have this line, we can update our app cache. So it says pseudo app update and then it will update the app cache and then it will allow us to install Google Cloud SDK and there it is. So we have our Google Cloud SDK getting about to be installed and we'll move on. So it should install very, very quickly as soon as the app cache updates and the updating is about to finish. There we go. And it has an error. It says in public key not verified. So we have to check that error. Oh, we missed that. Not the public key. We missed that one step. That's why it was not verified. We had to curl that key and add it to our app key store like that. Didn't we do that? Grab the key and then update again, update the app cache like that and it should grab the key and report success. Once it reports the app cache successfully updated, we should be able to install the cloud SDK and connect it to create a cluster for us. Creating cluster is simple. The actual installation of SDK is a little bit like a three-minute exercise. So we will wait for that to finish and see what the next step is. Duplicate entries, apparently, duplicate list entries, which I want to remove. Let me just see if I'm missing a step here because there is some step missing for importing the cloud platform key. Am I running this correctly? Okay. Let's go grab that copy and run it here in full screen like this. Now it added the key. Now also, I think I ran that previous command twice. So this duplicate sources list entry is something that I want to remove. So this Google Cloud SDK has double entries in there. So I will go edit that and remove the double entry that I accidentally typed, which is going to be sudo vi Google Cloud SDK list. It has two entries, the same thing twice. I need to remove one of them. I removed that and then go update, sudo app update. This should clean up. It should clean up because now we have the key as well as our entries are not duplicated for no reason. This should clean up the app cache and then we should be ready to run. And so the actual installation step is this one. Come on, 20%, 30%. I hate waiting, but sometimes you have to wait. I think it cleaned up nicely. Now we should install Google Cloud SDK. So it is doing it now. And once it installs that SDK, we should be able to move forward. Now since we are installing, we don't need to update Google Cloud SDK because we just installed it. So I'm going to skip this part. It is not necessary. And then we configure G Cloud. Running this step is not going to hurt even if you have it. So this installation is going on, but it is not a necessary step to upgrade or update G Cloud SDK unless you're doing it after a couple of days, in which case it is a good idea to update the SDK. And so it's asking me a yes or no question. I'll say, yes, go ahead and do it. And so it is going to now install Google Cloud SDK. It is doing that, which is a good thing. And then we will configure that SDK. This SDK basically configuration means you have to let the SDK know that you are a legitimate Google Cloud user and thereby you have to authenticate yourself with the Google Cloud. And so that authentication step involves you to go to this website. It will actually open up the browser and give it to you access, and so you can log in using your Gmail address and tell the Google Cloud SDK that you are a valid user. That validation has to happen once you G Cloud auth log in. That validation is necessary. And the installation has finished. So I should be able to now validate myself, say, hey, Google, it is me. And so it opens up web browser and says, okay, then if it is you, then log in. Prove it to me that you are indeed you. And so it is actually trying to ask me to log in, which is exactly what I'm going to do. I'm going to say, you know what, here is me. And here is my password. So it confirms that. So I'll grab my password and give it to them so that it authenticates myself with the SDK. And where is my Google account? Where is Gmail? Is it this Gmail? Okay. There is no password. It's right there and paste it in this window. And that should sign me in. Oh, it's asked me to verify. So fine. I verify myself. Try again another way. And then the other way is to get a phone call. Wow. Whatever. Okay. Call me, Google. You want me to verify? So call me. I will answer this call and here is Google calling me and I am going to get the code number. Thank you for using Google phone verification. Remember, you should not share this code with anyone else and no one from Google will ever ask for this code. Your code is 3 0 5 1 7 2, again, your code is 3 0. Okay. I got the code. I logged in and it is authenticating. It is asking me, should Google cloud access your Google account? And I say, yeah, allow. And once I do the authentication, it will transport and basically save the credentials in the local workstation. And it tells me that the authentication is successfully completed. That means I can use Google cloud on the command line in this machine, which is beautiful. So I will go and maybe minimize this window. And go back to my command line terminal right there. And in that terminal, let me minimize this first. Where are you? Please minimize. There we go. And in this window, now I should be able to operate in my Google cloud. The thing I notice, it is giving me a notice here. It says gcloud.login no longer writes application default credentials. You need to use, if you need to use ADC, you have to go do this step. We don't need to use ADC. So we don't have to worry about that warning notification right there. It tells me that I'm logged in and my current project is none. Okay. So you can change your setting by running this step. gcloud config set project ID, which is what I intend to do. But if you are doing it like the first time, you will probably not even have a project. That's very likely possible, very, very likely that you will not have a project to begin with. Which means you have to create a project. And so you create a project like this, gcloud projects create and then give it some random name. Like I have taken this name already, cloud genius labs. So that name is not available anymore. So I will see what names I have chosen and maybe use that name instead. So you will go to cloud.google.com and there you can create this visually on a browser also. Not necessary to do it the command line way, but just understand that you have to actually select a project and work in context of that project. So here you're going to go to the console in Google cloud right there. And here you will find, go to console and then you will find your projects. You will have nothing to begin with. So you create a new one. I have a project, so I will use the existing one. And that's what I'm looking to find the name of my project. It should be right here somewhere in the upper section. Not in the bookmark. Hold on Google, please tell me what are you doing API waiting for API calls. Fine. You know, I don't like waiting Google, don't you? Okay, there it is. So it says select a project and here I'm going to select the names of projects that I have. And so I will identify and why is it so slow? So all the projects, there is a project called cloud genius labs one, two, three. So I use that great. So that's the project name I have and that is what I want to use. So I will say G cloud config set project and then cloud genius labs one, two, three. That's the name I will use in my command line right here. In this window. I'll say, you know, give me a project, give me a rather understand that I want to use this project. So it says, okay, basically to respond saying, yeah, I know, updated the property, core project property. And so that property, these details are stored in a configuration locally. You can examine those configurations right here by, let's go follow, there is a step in which you can actually examine what configurations are stored in your computer locally. So that's what I will be running through. I'm I have assigned a project here already. A couple of administrative steps that we had to finish through is to select a region and compute zone. So I'm choosing the, you know, us west one region and zone. And that is what this selection requires you to select a physical location where you will have your cluster to be created. I'm choosing that US West one a section and updating that in my configuration definition. I'm selecting G cloud configuration set container new scope behavior true. This is a change, a recent change in Google cloud SDK that requires a new behavior. So we'll say, okay, get the new behavior. I really don't care about old and new, but just want to reduce the noise that this cloud SDK throws at you. So that's why we are just selecting the new behavior so that things don't change on you too frequently. Then we are exporting a bunch of references in environment variable names like that. Here is one. Another one is I'm selecting a compute zone, which is one a West one a like that. And then I will export my project ID in another environment variable. What this does is basically put the cloud genius labs one, two, three in a environment called my project. And I will be using this project, my project as a reference in my environment. That's why I exported it. So you can echo it and see what value it has and you will see that the value it has taken dollar my project should come back with cloud genius one, two, three, cloud genius labs one, two, three. I think that's the name of my project that came back. And then what I will do is export my cider block. What is my cider block? It is the IP address slash 32 for my location. I want to have that cider block in this environment variable. So I am basically grabbing the IP address for me in my location using an API call and then curling that I output from that website to get the IP address for my location and then exporting that in this environment variable called my cider. If you run these things step by step, which is what I intend to do. So I will actually run it like this. I'll say, yeah, I'll say curl and then say minus S and then paste. If you call this, it actually gives you the IP address of the location where you're sitting at. It just dumped that IP address right there. That's the IP address of my current machine. This one, and it doesn't have a new line character at the end. So the next prompt just takes over, which is a good thing. I want it like that. And what I want to do is take the IP address 7359, whatever that number is, and then append it with a slash 32. That's what this thing actually is doing slash 32. So if you now understand this whole segment, you are exporting that value. And as a consequence, the public facing IP address cider block for your location will be whatever it is, like I have 7359, 110, 24. And so it will pop up something like that, which is a security measure, by the way, whatever we just did here is a security measure we want to use. And we want to control and limit access to your cluster only from your location, from your cider block. If you're in the company, in the Boeing company, you have to identify what is your public facing cider block, pretty much like this. You can run this command and it will get you your cider block in your location, wherever you are. If you are doing for a larger team, you want to probably modify this number 32 to something like 24, or depending on your network configuration, you have to choose your cider block carefully so anybody in your company can operate and nobody else. That's how you can limit who can physically access the cluster. That's what we are really trying to do. Now all this configuration information that we have is actually stored in a folder called dot cube. That's where it is. Okay, is there no such file? Let's see. There should be a place like that, CD, CD dot cube. Okay, I think the warning you got is exactly what this was, it is not storing your credentials in that local location. So we will see, you can skip the RM step basically for now. Let's go further and identify the G cloud configuration stored that we have set. It should give us a summary of the configuration that we have set in all these previous steps. So you should expect to see a set of configuration that we have already set for our G cloud. And you can see that we chose our US West 1A. We chose the zone, the region, the container scope behavior, the core account, disabled usage reporting, the project ID and account active configuration that we have chosen is the default configuration. That's what we have captured and saved in this location. Now we should be able to proceed forward. What we are now trying to do is something that you have done already in another cloud. What we are really creating is a virtual private cloud, VPC. In Amazon, that's what it's called. In Google cloud, they don't call it VPC, they call it VPN. Don't confuse with virtual private networking concept. Don't confuse this VPN with this VPN that you see on Wikipedia. So in Wikipedia, you see this VPN, which has a different meaning. And you have done an exercise with, maybe you haven't, we will do an exercise with this also. This VPN is a way to connect to another computer, another network in a different location and pretend that you are there. You probably use VPNs in your company. And so that VPN is different from what we are now talking about in the context of Google cloud. Here, virtual private network is like virtual private cloud. Same name here, like in Wikipedia, you see this reference of VPN. This and this, these two are same name, but different things. Just understand that. We are not talking about what Wikipedia describes, but we are talking about what Amazon calls it VPC, AWS VPC. That's what is very similar to Amazon VPC is what is similar to what we are going to do now is create a virtual private cloud. In Amazon is what is known as a virtual private networking Google cloud. So let's clear these out and we'll create one. We'll create a VPN, this name, in our Google cloud. And let us see what we want to call it. We want to call it cloud genius. We'll use the project ID that we have here already called cloud genius labs. One, two, three, your ID will be different. And I will use a subnet mode called auto. So this is what is going to create. So as soon as I create a VPC, it should pop up right here in this window. And in that window, you should see that you now have a virtual private network created for you in the Google cloud, because we are using G cloud SDK, that network should pop up right here somewhere. So let's go close out these windows and not that window. Okay, do it again. And here we will go to console.google.cloud.google.com. And then we look at what virtual private networks do we already have? We probably have nothing except we have a project called cloud genius labs one, two, three. But inside that project, we have not much, nothing much. Because I don't use this particular login much. So that's why you don't have anything. And you will probably not see any virtual private network on the tab on the left side when I click on it. It is slow today. Why are you slow? Going round and round on me there it is VPN VPC network. So you click on that. And you should find that I don't have a network. You will probably see that you have a default network. And so in VPC networks, if I click on that one, it should show me that I have a let's see what shows up. If you should see a default network, I will see nothing because I have probably deleted all of the networks. And so I probably will see that I have no local VPC network in the current project. Fine. I will now create one pretty much like that. It creates the name will be cloud genius. And it will create a VPC directly right here. It should show up. It takes about a few seconds. And then we proceed forward. What we like to do now is when you do it the first time, you will probably see a prompt. The prompt will say, you know, APIs are not enabled. So it will say, do you want to enable and retry? You should say yes to it. If the APIs are not enabled, then this command will not succeed. So you say yes, and it will then succeed. It will enable the API. And sometimes it will fail. It will fail because, you know, it doesn't require, it doesn't satisfy the requirement, which is billing requirement. The requirement is you have to have billing enabled. Bottom line is you have to give them money. Everybody wants money. So you give them money and they give you $300 of freebie. So use that freebie, but you need to select billing ability and you need to give them a credit card just in case you run out of those $300 and go beyond that. And so that's why they require you to have billing enabled. Otherwise it will fail. And if it fails, you go to the web browser and you give them your credit card there and then it will not fail. And next time it will create that virtual private network. Like I am going to see a new VPC created as soon as the command finishes and it did finish. And it tells me that, you know, you have this created a new cloud genius network, which is nice. So I should see the network right here in the browser, but in the meanwhile, we'll just go proceed further because I don't want to like, you know, slow down for no reason. So just assume that there's going to be a network created because you saw in the command line, right? So you enable billing, which is necessary. You have to give them a credit card, even though they give you $300 of free usage. Next you want to enable compute engine API. That's another API. You have to go and go to the web browser and enable that API. If you don't enable the API, it will not let you create a cluster. Simple as that. So enable the API, put the billing information, and then you can inspect all the networks that you have running by looking at. So you can see in the browser, this VPC network called cloud genius shows up. And that is nice. It has a bunch of different subnets already created for us automatically because we chose to create that automatically. We said subnet mode, auto, and therefore we have a bunch of subnets already created for us. We'll see what networks do we have, and it should come back with saying you have one cloud genius network with subnet mode auto. It's a regional network with the West region. Next. What do we do next? I think we are getting to a point where we can have a cluster now. So before we set clusters, we had to have a set of firewall rules for us to go inside the cluster, inside the virtual private VPC network, and also allow customers to access. We had to open certain ports, and that requires us to create in Amazon language. It is called security groups, which will allow traffic of certain types to go in, traffic of certain types to go out. And those rules, conditions are controlled by firewall. And Amazon calls it security groups, Google Cloud calls it firewall rules. So we create firewall rules. There are three rules we create. One which will allow ingress, so going into the, basically allowing us to ping our machines. So that ping is what we are really creating, ability to ping. And that idea is basically allowing ICMP connections. And we are saying rules ICMP, and from any location on the internet, let people ping. And that is one rule. So we create, take that rule and put it right here and say, hello, okay, open up that rule. So create a firewall, allow people to ping from any location that's doing it. We'll create one more rule. This rule will allow connection from any source in the network IP range in inward. So this ingress rule. And basically this allows connections from any of the sources in the network to any of the sources in the network. So any to any within the network. If you're within the network, your sources range are these IP addresses. So if you're within the VPC network, any machine can talk to any other machine. That's what we want to enable. So you have to explicitly allow machine to machine communication within the network. And for that, we have this, another rule, we are going to create that one. And so here we've created an ICMP ping rule right there. It allows that ICMP pinging. Next rule is just allowing machine to machine communication between machines within the cluster. That's going to happen right now. And then the third rule, which is the one which allows me like from my location, very, very specific, very narrow allows me to go in. And so here's that rule. And that rule is going to allow me. And this me is defined by my cider. And so my cider is already defined in a previous step, which is my IP address slash 32. Your cider will be different. That's why we have it evaluated in an expression and saved in the environment variable like that. And now we create an ingress rule for me to go in to TCP port number 22. Okay. Allowing me to SSH. Okay. Create that. I'm creating that. So it's creating this firewall rules and I'm going to proceed forward. I will carve a subnet. This subnet is where I would like to have my machines created. So I'm creating a specific named subnet for me. I have used auto subnets, but then I'm also creating another subnet just for me so that I will know my IP address ranges very, very clearly. And so here I'm saying, you know, create a subnet called CG, a short name CG in the network called cloud genius, the bigger network, the VPC network, and use this range 10 64 00 slash 19. And I'm going to define another range for pods, another range for services within the cluster. And these are IP address ranges that I want to be super aware of as to what did I choose. So I just named them exactly what I want and then create a subnet like CG inside my network called cloud genius with these specifically named IP address ranges. And I know what they are. And I am basically creating three subnet ranges like that. And here you see that there is a range defined for the subnet and a secondary range for pods and another secondary range for services. We'll talk about what pods are and what services are soon as this thing gets up and running. So we'll do that. We are also enable another API on the web browser. This web browser allows you to create a cluster. This Kubernetes engine API allows G cloud SDK to stand up a cluster. So you enable this by visiting that link, that link available right there. You click on that link, it should open up the web browser and enable that particular API called Kubernetes engine. That is necessary. Without this action, you cannot proceed further. I have already clicked on that link and enabled the API. So it will not bother me, but it will definitely bother you if you're doing it first time. It will disable and not do anything and fail on you. You need that API to be enabled. So you click on the link, enable it, and then bring up the cluster. Now bringing up the cluster is simple, easy part. You have to export your My CIDR already, which I think we have done already, get your public facing IP, which you already understand. So we have done these steps in a previous command. We have also My Project exported out in a variable. So we have that Cloud Genius Labs also taken care of. So these steps are already done. What is necessary to create a cluster, to bring up a cluster is these things, lots of things there. So let's go copy all these things and get ready to understand what it does for us. So I'm going to copy that. And right now we have G Cloud Networks list will show us that you have one network. We have a firewall list. Is it firewall or firewall rules list? I think it's firewall rules, which will show you a list of firewall rules that we have. We have three rules set in place. One of them is for pinging. The other one is to allow machine to machine communication. And the third one is to allow me to go in. These three rules right there, allow ICMP, allow internal communication, allow SSH communication. These three rules are set. The compute network is created called Cloud Genius. And now we are ready to create a cluster. The cluster creation is this one long step, that's it. Now inside here, there are certain things that we need to understand and maybe a little bit peak, a little bit. So we'll go to read it very carefully and then run it as opposed to just blindly running it. So we'll open a editor and in there, we'll see what we have. We have our My Project. Even before that, we have certain things like a name of the cluster. I choose Andromeda and then a project name. The name of the project, which is in my example, Cloud Genius 1, 2, 3, Cloud Genius Labs 1, 2, 3. That's the name is an environment variables. I don't have to worry about, it'll automatically pick it up. This is OK, enable basic authentication. I'm disabling that and checking the cluster version available, 196 GKE 0. Is that the latest version? Probably, maybe not, maybe we'll identify, is that the latest version or not? So we'll go and check. What do you have G Cloud? Can you tell me what version do you have currently at the latest versions? And so we can go, by the way, create this cluster entirely on command line as well as exactly right here on the browser also. So it's up to us as to how you want to create a cluster. I prefer to not use the browser window, although I show it to you. I don't like to use it because that's how I am set up. So you can create a cluster by following these clicks on the browser, but I don't like that approach. But it's a perfectly valid approach. It's just that I don't like it, so I don't use it. In here, you will find a way to actually select the version number that we have in mind. Like, for example, I have this version number in mind in line number 5. Can I identify that thing in here? You bet. You can see that I can select, by the way, they're giving you 188 GKE0 as the default version. You can choose newer versions like 197 GKE0 or 196 GKE1. That basically depends on what you want. You can select any of these. These are valid choices as of right now. I have selected 196 GKE0 in that example here, which will, if I run it as is, it will fail because there is no such choice available anymore. The only choice available is this one or the other choice that you saw. I'm going to pick the latest, by the way. I'm going to pick this latest 197 GKE0. That's my choice going to be. And therefore, I will change this to 197 GKE0. Awesome. Then I will decide how big the machine I want it to be. So I'm selecting the machine size to be n1 standard 1. That's the size of the machine, the minimum size. I think it is the minimum size you can get. Maybe you can get a bigger machine. So the one CPU machine is called n1 standard 1. You can get a smaller machine also, but that's not what I recommend. You have free money, so use it. Yeah, just don't go to small machines. This is too small for examples and exercises. For practical usage, this is the beginning point. n1 CPU, 3.75 GB memory. That's how you should begin. And you can venture in this direction, but I don't suggest that you do. It's usable, but not a good idea. So just skip that. Just go here. You can go bigger machines, totally go as big as you want, as much money you have. But this is a good point. You can further customize this to exactly what type of machines you want to get. And it lets you customize. Like you can choose the number of cores, number of memory, extended memory, or CPU platform. You can get Skylake, Broadwell, Sandy Bridge, so you can basically choose what CPU platform you like. And you can choose GPUs. So you can choose how many GPUs, what types, and you can get, you know, if you're doing like machine learning or artificial intelligence, you can decide that this is something that I want. So you can get a Tesla, get it, eight GPUs on one machine with one core and some more memory apparently is needed. So you can decide what machine configuration is necessary for a given type of workload and that creates a type, a template that will be repeatably used in that node pool that will be used to create a set of machines in your cluster. We are just going to go with N1 standard one. Each of these machines require some operating system to run. And in Google Cloud, there are only two choices. Either you get, let's go with the default selection right now. So one CPU and bare minimum memory, which is basic view and go to the N1 standard one. So that's a choice in the machines that you will create. You have choice of operating systems and you get only two choices. I think only two. And they are Ubuntu and container optimized OS. This OS is a custom made OS. It is also Linux. It is custom made for use by Google in Google Cloud Kubernetes engine. So they maintain it. I like this choice. I don't necessarily even want to worry about what machines have, don't even have to worry about the machines themselves because I'm not using the machines themselves directly. I don't even care about the existence of those machines. All I care about is whether my application is running or not. And my applications will run in containers and parts and we create services. But I don't want to deal with these machines, by the way. And that is why I don't even think twice about what operating system is there underneath because I don't care. So I just go with the defaults because I don't want to deal with that machine. In fact, I will treat it like a cow, like a cow by cow. And here you can select how many of those you want. So three, four, 50, 100, any number, just get that number. You get a large cluster. It must be within 500 when the master zone is set to US Central 1A. So it has to be less than 500, apparently, in that location, in the 1A location, Central 1A location. So you have to choose a different route, but we are not creating hundreds of thousands of machines. So I'm just getting two or one. One is good to begin with. And what we'll actually do is actually make it scalable. So we don't even have to decide how many machines we want at a given point. We'll just say, give me one to begin with, like that, in line number 10. And then put that machine in the Cloud Genius network, which we just created, which is line number 11. Enable logging, enable monitoring, put the machines inside my subnetwork that I created called CG, and enable IP aliases, enable a secondary range for pods and another secondary range for services. And then enable auto scaling, automatically grow and shrink the number of machines I have. Like here, get at least one machine, minimum number nodes, and up to 11 machines. That's my arbitrary choice. In line number 20, this is a totally arbitrary number I have put. You can put whatever number you like, as long as Google is okay with it. And in this example, it will scale between one and 11 machines. I am enabling network policy, enabling master authorized networks. And this line number 22 is a critical security step. What you're really doing in line 22 and 23 is that you are limiting access to your cluster only from your authorized networks, meaning your location. So if that is not set correctly, 23, it will not allow you to access your own cluster. So remember that this mysider expression has to be evaluated correctly, as you saw me do it already. You're enabling automatic upgrades, automatic node repairs, and a maintenance window of eight o'clock in the morning, and you're adding on HTTP load balancer. You're adding on horizontal pod auto scaling and a Kubernetes dashboard. So a bunch of different things that you're adding on. You're grabbing all this thing. We just made a change here in the version available with line number 5, 197, as opposed to 196, grabbing the whole thing right here, bringing in here, skipping the browser window, and running it like that. And say, okay, create a cluster for me. That's it. So you have a cluster. What does it say? You invoke beta. It's doing it. It's doing it. It says you invoke gcloud beta, but fine. Maybe I should just remove that beta reference to just regular reference. That is not necessary anymore. It used to be necessary before. There was a transition period before on, early on in a couple of months ago, but that step is not necessary. You can also drop the beta word from here, like it was there. I removed that like that. Now it is creating a cluster called Android MEDA, and we now have a cluster functioning. So we will use it. You can access the Kubernetes Engine cluster requirements. It requires the Kubernetes command line, and that command line is how you interface with your cluster. And that is a necessary installation needed. And that step is called out right there, which we should do that on a separate terminal on the side. We'll just say, okay. Oh, not here. Not this. Not this. We'll say gcloud components, install this component called kubectl. That piece is what will be used by me to interface with my cluster. So I need that binary, and it says the right way to do this is sudo apt install. So we'll say, okay, whatever you say. There we go. This is because we installed the gcloud SDK through sudo apt get install step. You want the kubectl installation to also happen with apt get install step. If you install SDK in another way, then the other way, like this way, is okay. But since we installed the apt installation method, this installation method is recommended. That's why we just saw it did it for us. So we're going to exit that command line. It is still doing the cluster creation, and it should report back that we now have a cluster. So we should go visit the web browser and see what we have here. In Kubernetes Engine, we should see a cluster getting up and running right now. We'll just refresh it and see what we have. There should be a cluster called Android beta listed and maybe getting ready. And that is what we are waiting for it to show up in the browser. And the browser is not showing us anything because it is waiting. Why is it Google so slow today? And so here it comes. Something is going to show up. I'm expecting that new cluster to pop up in the list in the browser window, and it should show up any moment. It is still getting created. So I see some rotation there, wait rotation. And on the command line, what's going on? It is done creating. It is running already. And the command line shows you that the browser is slow, still not showing anything. That is one of the reasons why I don't like. And by the way, you notice that I asked for one machines. It gave me two machines already, which is expected behavior. It might think that there's a need for two machines. So it scales up automatically to two. You can actually shrink it down. You can look at the Andromeda cluster, which is now ready. And it has two machines. And you can scale it down back to one if you like. But if you put some load on the machines in the cluster, it will automatically grow itself and become bigger. And so I think this site is just generally slow today. So I'm going to stop using this web browser. It is slowing me down, and I don't like it. I don't like these wait. OK. Here it shows. It shows you have a master version, the endpoint IP address, client certificate enabled, alpha feature disabled, current size two. Current total size is two machines. A master zone is 1A. Node zone is 1A. Network is Cloud Genius. Subnet is CG. All the usual suspects, the container range, service address range, logging enabled, monitoring enabled, authorized network. This is my IP address. It showed up right there. Network policy enabled, legacy authorization disabled, maintenance window 8 o'clock in the morning. And then there are some add-ons. The add-ons that we have are dashboard, I think. Add-ons are dashboard enabled and HTTP load balancing disabled. I thought I enabled it. It showed disabled. What did I type? I typed add-ons, horizontal pod autoscaling, add-ons, HTTP load balancing. I wanted it. It did not decide to give me. HTTP load balancing is disabled for some reason. We have to investigate why. I asked for it. It did not complain and it did not give. Let us see if there are some notes in the warning section here about this section which I asked for and it did not give us. I don't see any notes in this section that silently failed, but don't worry, it's not going to cause us trouble. So now that we have the cluster ready, we should use it. Let's go understand what we can do with it. And one thing I can definitely do is to not use this web browser, which is kind of slow. So closing it. So can we create this cluster from the UI end or you have to use it? Yes. UI also is okay. Everything you can do with the UI or command line or API, all three methods are okay. Since you haven't enabled the HTTP load balancing thing, you can do it on the UI. Just enable the UI, the HTTP load balancing thing. Potentially possible. Potentially. Yeah. Okay. Certain things may be, may not be allowed. Okay. Depends on what the implementation is. Certain things may not work. There is always a way, if you need that thing, HTTP load balancing, we'll have to find out a way to get that. And so right now, apparently it is disabled. Don't worry about it. We'll be able to go through it. No problem. So the cluster is ready. Bring up a cluster. Okay. So now we can reconfigure with the name of your cluster. So we have to set gcloud config, set container cluster, enter meta. This will tell gcloud that you now have the cluster in that name. So we just updated the property definition and we can now list out what does gcloud know about our setup. It shows that the cluster name is enter meta. That's what I wanted to see. And so now in case of emergency, if something goes wrong, here are some cancel operations in case of emergency. This is not necessary. It's a, it's a subsequent or over the, over the period of many, many sustained usage. If you want to upgrade a cluster and you want to cancel out the upgrade action, there are some steps written down. We don't want to run, you don't want to run those steps. So I'm skipping that. Cancel certain upgrade operations. This is how you can do it if you like, and you can destroy the cluster after the exercise later on. We are not destroying it right now. So this is how we destroy it. You say gcloud container cluster delete, but don't destroy it right now. Leave it running. There is an alternative approach to doing the same exercise using Terraform, which is defined in this section. We are also not doing this right now. So skipping it. And I think that particular step regarding creation and destruction of a cluster are written down here. Don't destroy it right now. We have the cluster up and running. So we'll go back a step. As you go back one step, you have the cluster ready. Now let's go understand what a node is. So we have these things, node and container and label. And we'd go through understanding all these things as on a live example. So right now in our cloud, in our network, in this cluster, we have two machines. You know that. You can see these things in gcloud, compute, clusters, list, cluster list, not plural, but just cluster. It should show what is the right syntax, gcloud, gcloud container cluster, container clusters. What was the typing before? Container cluster list. No? Clusters? Yes, OK, there it is. So the correct syntax is gcloud, container clusters, give me a list. And then you see that the list shows you a container cluster you have called Andromeda 197. This is the master IP address. It runs n1 standard 1. This is the node version. There are two nodes available. They are running. That's what essentially a node is. So node is where a host, where the containers run. So in our example, if you draw this in a picture, we have two nodes. That's it. These nodes, we created them using, we created these machines using container operating system, container optimized operating system. Not Ubuntu. Let's use cause. They are n1 standard 1. And we created these two machines in a cluster using that command line we just saw. And that's the location where containers will run inside these machines somewhere. Where they run is decided by Kubernetes. So we don't have to worry about where exactly we run that container. It is handled for us. So that we can explore our nodes in our setup. So we can say kubectl get nodes to get the node that we have in our example, pretty much like that. It will go and grab those two machines that we have. It will respond back with the machine number one or machine number two. Both of them are up and running for seven minutes and nine minutes. You can see that the machine, older machine was created first, then it thought that it requires one more. So it grew one more machine after two minutes. And now we have these two machines running. We can further explore and actually identify to see if we can create a pod inside. So if you want to see that, if I want to target a particular pod, a pod by the way is a set of containers. So think of that before I use the word pod, I should define a pod is like p-pod. And so you have this p-pod, which contains p's. And so think of these p's as containers. These are containers and this is a pod or a p-pod. And so the idea behind a pod is a collection of containers that need to run together. Idea behind a p-pod is a place where all the p's are sitting together. That's the same idea, p-pod, pod, same thing conceptually. These are containers as opposed to p's and this is the p-pod. So you have related containers together. You put them in a pod, they will go and live together and die together, migrate together. So if you want to target a particular machine, I want to have this pod run here. You can do that. You can actually dictate. So that's what we'll do, is actually dictate where do I want my pod to run. I will say that it should run here as a label that I want to assign. I'll say Kubernetes label nodes, these nodes that I have. One of these nodes, this one I want to take and label that node as should run here. So I'll just label it, it should run here. So that particular node 3SXW was labeled as should run equals here. I just added a label to that node. What that does is now gets me to target and when I now know that target label should run equals here, I can then very clearly target that node and I will create a pod in that node, in this node, not this, but this because I want to use that label to target it. You can create a pod very simply by creating a YAML file that looks like this. So here is the YAML file and we are creating a pod that contains a container called simple service, S-I-S-E, cloud genius, simple service is the image that we will be using. This image is available in Docker Hub and so that image is what I'm going to use and I want to expose 9876, that port number 9876 as a container port, expose that and select the node selector should run here. So wherever that node selector is, meaning this node, that's where that pod will run. So this pod I'm going to create using this YAML file, which one? That one. So you can see that file, you can actually call it and see the pod will show up. This is the YAML that you saw in GitHub, it's the same YAML I will actually now invoke and I will invoke this YAML using kube control to create a pod using a file that I'm passing on as an HTTP link. So basically passing the same HTTP link to kube control and say, hey, you create a pod. So it does create a pod. Let's go run it. It will go to GitHub, look at that YAML file and create a pod. Let's go see what it did. We'll say, kube control, please describe that node that I have. Which node? That one. That's what I want you to describe. So please get me the, oops, hold on, adjust and grab that node and show me that detail about that node. Please, please, please go show it to me. And here I see a lot of detail about that node. And what do I see? Let's go shrink a little bit and maybe run it one more time to see the detail. So I see that it has some memory, CPU allocation, machine ID, blah, blah, blah, all that. And then the most interesting things is that it shows me that it is starting kubelet, where is the pod description? Hold on. Non-terminated pods. Where is the pod definition here? It's node, I think that is this one, probably the last one. Let's go check the kubectl, kubectl get pods and see what pods we have. So we have one specific, on specific node pod is running and it is running on for one minute and it is running where? That's what I want to grab for. So I'll grab this command for on specific. And we should see some specific reference right there. And it should be right that is the on specific node is the name of the pod that you saw here. The name of the pod is on specific node. And it is running on that specific node, this 3SXW node. And it is right here where it is running. And it has taken 10% of a CPU and there are other things running on the node. But then we started only this one. These other things are part of Kubernetes cluster itself. So we don't have to destroy them or we don't have to focus on that action. But in this example, we created a pod on a specific targeted node, like this node I had in mind. So I labeled it saying should run equals here. And then with that label in hand, when I created a new pod with this structure, as you saw, I basically ran this YAML file in a create step like that. And when I create this again, it will fail or maybe not fail, but do nothing. Let's see what happens. When I run it again, it says it already exists. This pod on specific node already exists. And that's what we created. So it already exists. It's not going to create it again. We can say kubectl get pods, it'll show you that pod, kubectl as a typo. And this is me being lame, not typing properly. So I can overcome this deficiency that I have, which is not able to type kubectl efficiently by setting an alias, alias k equals kubectl. And now I just say k get pods, I get the pods, k get nodes, I get the nodes. And I know that this pod called on specific node is running on that node because I chose it like that. Further, what we want to do now is get rid of that pod. So we don't need that pod running. So we'll get rid of that particular pod that we have. And we just adjust this a little bit. So we created a pod and we can get the pod output in wide format if you like, it shows you more detail about the pod. It has an internal IP address, it is up and running for four minutes and it is called on specific node. Now here you saw the description about the node itself and the pod that we just ran on it. We can delete that pod very, very easily saying k as in kubectl delete pod and then the name of the pod on specific node and that should delete it. Now you don't have it anymore. It is terminating right now and it will soon go away. It is still terminating, it will disappear and the pod will go away from that particular node. So we have a clean machine going forward. The machine we used, we actually targeted it very specifically and we assigned it a label by the way, that label that we saw here in this example. We assigned this label to a machine so we can target it specifically and say you run it there if I want to override the default behavior, otherwise the scheduler will decide where it runs. We saw an example of a node, we saw an example of a pod and we explored nodes. What I want to now do is explore labels. How do we go further and label these things? So what I want to do is label a pod which has a label called environment equals development. That's the label. So here is the pod, you can see it. It has an environment called development and in that pod, we are defining a container. Its name is simple service, S-I-S-E and it also uses the same image called cloud genius simple service, exposes the same port 9876 on that container and now this becomes a definition for a pod that I want to create with a label called environment equals development. You're basically trying to understand what a label is and that's why this is the example to help you understand that. So what I will do now is first of all look at that yaml file that we have, it's to curlet and then we see that yaml shows up and now what I want to do is use this yaml to create a pod. So I'll say k, sorry not here, I'll say k create dash f and by the way this k business as you know is a kubectl alias, it saves me some trouble of typing kubectl because I don't seem to type it properly. So k create dash f and then the file, that yaml file which will define a pod. So here we go create another pod, so it creates that pod. Now we say k get pods, it gets you the pod that is called label example. So this is a label example pod is what you see right here, this segment is a kind pod, it has a metadata which has a labels environment equals development and that is a label example. You run a new pod with a label. Now here what we can do is ask kubectl to get me the labels, please show me the labels of all these pods, it will show you the labels. So labels are environment equals development, it is now running. You can see it without the label, k get pod simply or get the labels to show the labels. Now here what do you see is this show labels flag that I just added here, this flag gives you the extra labels output, so you can examine it if you like. What we can do now is add another label to the pod. So we can use the same kubectl command to label the pod with the name of the owner. Labels are basically arbitrary, you can assign whatever labels you like. So here I am assigning a label and that pod was labeled. You can now see the labels and you see that there is another label added right there. By the way, the labeling thing is actually a tremendously useful thing if you have a large number of containers running around in your cluster. You can then very carefully select these pods versus those pods and shortlist them, do something with them, create them, upgrade them, delete them, run it again, run it in another location, migrate them. You need to have these labels so that you can select, oh, I want that one or this one or something other. That's why you find that these labels come in very, very handy. You can assign labels just like I did here, or you can have the labels built in like right here into the YAML at the time of creation. This YAML file is a, I think we discussed YAML, right, YAML is what? YAML is not, YAML ain't a markup language. I think we discussed that, if I remember right, with Ansible. Ansible uses YAML as the file format for its playbooks and Kubernetes can also use YAML for its format for everything inside Kubernetes is mostly people use YAML. You can also use other types of file formats, but this is the most elegant that I like. So I use YAML, you can use JSON also. JSON is slightly more loaded, YAML is much more cleaner and succinct. So that's why I like YAML, so I use YAML. Okay, so we labeled a part with a custom label that I wanted, I have it, I can select these parts and select only the part that have that label like this, I get the part, I get the label example part showing up. Now what you can do is, you know, get another development, ENV development label, and we can basically get the same idea, you can see the same output will come back, except that the label selection was different this time, because this particular part has both labels. Okay, let's create set selectors. So we have to have another part, basically, that has two labels. This time the part will be different. The part will be called two labels. There's a label called environment production, another label called owner nilesh. So that's the part I want to use. And I will now use this particular part and create one. So we'll examine that part first in our command line, we'll say Curve and see what we have. So it shows you, it has two labels, one is production, one is nilesh, owner nilesh and environment production. And that is what I want to now create. So it says k create dash f, and then this file, it creates that part. So now you have two parts, k get parts, you get two answers, the label example and label example other example, it is pending right now. So it will start in a few, it should already be running by the way. So it is now running, it's still pending, we'll find out why it's pending. Then the next idea here is to get these parts in both that are in development as well as in production. You can get that pretty much selectors will go and operate and identify environment where the environment in this set, production, development, any one of those two, you just list them out. So you get both the parts showing up. This is a part example, so we don't have to specifically focus on why this is pending. So since we are actually listing out and enumerating various ways of focusing on a certain collection of parts, we are using labels as an example, that's what we are focusing on this particular step on. Now we can actually delete these parts because they're not really actually useful. So more of an illustration of what our label can do for us. So we'll go and kill them out. So we kill k, delete the part called label example, and k delete the part called what? Label example other. So here we delete that one, both are dead. And we say k get PO, both of them should be dead or terminating, it will die soon. Now both of them are dead. We can now proceed further with our exercises. So we got the idea of a label, you'll now understand what a pod is. We have actually used a bunch of pods already, but pod is basically a way to put containers together, in a P pod is used to put P's together, pod is used to put containers together. Containers together will be somebody who are closely related, like MySQL database and the corresponding application, you want to have that thing together, they're related, right? So tie them together in a pod. That's a way to think about if you have an application that requires two containers, you put them together in a pod and then deal with that as a set, as a pod, or as a construct that handles these two things simultaneously together, placing them in the same locations as you go along, as you run through the life cycle of that given application. So here is an example of a YAML file. So you basically have a kind, which describes the type or kind. You have an API version, which is mostly one, metadata, here you can define name, labels, and specification for what is inside that pod. And in the pod, you can have containers running some name and some image that you might have. And so now let's go explore what pods are. And so we'll go inside and, first of all, here, examine that we have no pods, all the pods are dead. And now we'll create some pods. So what we want to do is, this time we'll use creating pods without using YAML files. We'll actually go a little bit deeper and understand how do we construct a pod. So I'm going to basically start this command. We'll run an image. And whenever you run an image, it basically creates a container. You know this from Docker. So I am going to run kubectl, run, give it a name, and then give it an image reference and a port number. And when you do this, what happens as a consequence? Let's go see that. When you run this, it says some deployment created, deployment called SISC, simple service deployment created. Let's see what pods we have. It started a pod called SISC some random number, and it is running for 12 seconds. Nice. Let's see if we describe that pod and see what we have in terms of its characteristics. So I want to actually see the more detail behind this particular pod. So I will say, describe that part, please. And I want to actually grab the IP address for that part. So you see that this IP address I got is 1032.2.4. That's the IP address that you can see that we actually created in our example here. And this is the range name that you saw will be matching, the CG pods secondary range will be matching what we created. So let's go and compare our notes with what we actually ran in the command. When we ran the creation of this secondary range, we can see that in our networks detail. CG cloud, compute, network, list, I want you to describe that. So maybe we just refer to our notes of creation. So we just refer to the notes that could remind us the IP address, these are 1032 some number. So we go back a step and go to the place where we create the cluster right here. And here you will find that our creation was in our 32 secondary ranges right there. When we created the sub network called CG, we chose our CG, our pods will have a secondary range, 1032.0.0 slash 14. That's what we chose. And that's what we see right there in here, that the IP address assigned to that pod turns out to be exactly in where we expected it to be. That's how you see that this secondary range for CG pod that I have called out gets allocated to the pods. So pods are running on a separate CG pod network as we expected it to be because we wanted it like that. Okay, let's go further, further detail. So back here, and we see that we saw the IP address of the actual pod, we are able to grab the, to grab it. If you don't grab it, it gives you, it spits out a lot of detail. Let's go see what it gives you actually, if you just describe pod by, describe the pods, no not this. So kubectl, describe pods and which pod I want to get this particular pod, that one. If you describe that pod, it can give you a ton of detail. And I don't want all of that detail. I want to focus just on this segment. And that's what I grabbed here. And so now you have details about the pod that you just started as a run command kubectl run name. It started in deployment and it uses that image, the cloud genus simple service image and it exposes itself on that port. You can see these details here inside the pod description. It says it has a name of the pod. It has a label, run equals size, simple service, it is running. It has an image, which is the cloud genus simple service image. It is exposing a port 9876, which is what we wanted. It is running since that time. It has not restarted yet. It is ready and a bunch of other details. That's the pod detail. Next, what I want to do is, is find out the names of the nodes in the cluster, which I think we already did that through kgetnodes. We can do it this way or now we can see that there are three machines now. The machines have already scaled out. This new machine got created, this one, eight minutes ago, when I think we started a service out of pod or something like that. So that scaled automatically. You see that this scaling is happening because you're adding load to the cluster. Here, you can also see the compute instances used under the hood. These are the same machines here, these one, two, and three machines, the same ones, but you're using the gcloud compute instances list command to get to the nodes. What I want to do is actually connect to one of these machines. We can connect to them. We have a way to connect to them. We can use the gcloud compute SSH method. Now, this is a Google specific method to connect to SSH, and I want to connect it to one of the nodes in the cluster. We have three of them. We just grab one of the nodes like this one, for example, and say, you connect to that one, please, and get me in the zone west 1A. That's what I want to do is use gcloud compute SSH. It says, I don't have a SSH key for you because we did not set up anything. It says, warning public SSH key file for gcloud does not exist. Private key does not exist. You do not have an SSH key for gcloud, so SSH keygen will be executed to generate a key pair, and this will be creating a new public-private key pair for us, and it will be injecting into the Google Cloud these three machines, one, two, and three, and then give us access. Right now, I don't want to use a passphrase, so I'm just saying empty and empty again, and now a passphrase was not used. We have a new SSH key pair created in this location. The name of the key pair is called Google Compute Engine dot. The dot is actually irrelevant, and Google Compute Engine dot pub. This is the public key, and this is the private key. Then we have these two keys stored in that location dot SSH folder, and now we are connected. This command not only connects, but also generates a key pair if it doesn't exist, as you saw. We are connected. Welcome to Kubernetes. We are in that machine, the 3SXW. Now, here you can see UNAME, and it will tell you that this is some other Linux machine that I think is the container-optimized OS from Google. It is not Ubuntu, but that's what we chose, so let's go see cat etsy slash start release and see what release this is. You can see here details about the operating system used on that machine itself, which is a Google release of container-optimized operating system. This COS is actually based on Chrome OS, which you may have heard of, Chromium OS. That's the foundation of which is this project, Chromium OS. It is open source. That's what it is coming from, from that branch of that Linux distribution. We were able to connect to that node, as you saw, and now in that machine that we are connected in, my goal is to actually see if we can interface with the part that is running right there. You know, we are connected to the machine, so in there, can we call it? The idea behind connecting to this machine was to be able to call to what, a 10.32 dot, whatever that number was. Now, I don't remember that number, but to come out of it and come out of it and then say, okay, can I please describe that part for me like that, and get the IP address 10.32.2.4, and now I have the IP address, and I can connect to the machine again, and in that machine, I will say curl, and then 10.32.2.4, and then the port number, which is where the service is running, I said 9876, so colon, 9876 is the port number where the simple service runs, and in there, I would like to curl the info route, so say, show me something, so it sends the information about that simple service running in that container inside kubectl, get nodes, or get pods, that, oh, sorry, we are in the cluster, so we have to come out of the cluster, so oops, go back in again, and here, we'd say, get that output, so we got the output here, which is this segment. This is the output produced by the simple service. Now, on a separate window, you can see kubectl, get pods, and you have this pod that we are interfacing with, that is the pod that is running that simple service at the port number 9876, which we are interfacing with, and we are able to see that service functional, and it is responding to us on port number 9876, like that. That's the pod responding, and we are on the machine 3SXW, this is one of the three machines. Now, we have understood that the pod is actually responding, and we can now come out of that machine and then delete the deployment we have, which is, okay, delete the deployment that we created was called SISC, simple service, so it should delete that deployment, which should basically get rid of the creation step, which we started manually, like this. We said, run this deployment using this image and expose the port, and we were able to run it, and it ran, and then we connected to it, we curled it inside the cluster, and we saw that they're actually responding to us, and so we then deleted it. So now, we proceed further. What we want to do is, this time, create two containers, I mean, a pod containing two containers, and that is a different pod that looks like this. This is the pod which will have two containers. We'll see and understand what it actually does in a much more clear fashion. We'll grab that, oops, back, now here, what I want to do is look at that YAML file again one more time, like right here, and say, curl that YAML, and here, you will see that there are two pods, sorry, two containers in the pod, so here is the pod. It begins at this location, all the way up to this point. The name of this pod is called two containers, and in there, in the specification, there is a container with this name, and then another container with a different name. This container is called the simple service, which you saw running already, the simple service at that port, which is basically a simple service, actually, it is a simple service, and it has another container called shell, which runs the CentOS image, and it just does nothing but sleeps for 10,000 seconds in a bash prompt, so that's what shell will do. Shell is a different container, size is a different container, so two containers is the name of the pod, which runs two containers, so this is the part I want to create, it will create two containers. Let's say K get pods, and we have nothing, K get nodes, we have three machines. You see that the machines are now two, because it shrank, because it doesn't need the third machine anymore, so you saw that the machines that we had three before are now only two now, because it doesn't need the third one, it saved you some money and extract automatically. I didn't have to do anything, I didn't have to tell that, hey, go shrink or go grow, nothing. It just finds out that there is a need for more horsepower, gets more machines. When it finds out that there is no need for a new machine, it just shrinks itself to save you money. That is autoscaling in action live, and we now have only two machines, this machine and that machine, two of them running, and we don't have any pods, so we create one. We'll use this YAML to create a pod containing two containers, so let's go do that. The YAML is right here in that HTTP link, which is basically a GitHub link, but I have that YAML written down. I will create, say K create a pod called two containers with these two containers, so create the pod called two containers created. Now I have K get pod, it'll show you that there is two containers pod, and it is pending. In a short while, you'll see that the pod will be running, and we will have these two running as soon as it runs, it's still pending. It is probably pending because it may be creating new machines, we'll find out. It may be creating new machines to get it to in a working state, so we can see they get nodes, and it may be generating another machine, we don't know yet, we'll find out. But for right now, I want to get that two containers pod up and running, so I can execute some commands in that containers, inside the shell container, like this one. I want to connect to the shell container, and so that is what I want to actually go and invoke like that, and so I will see if it will not succeed because the pod needs to be running. If I run it, it will fail, and it doesn't have a host assigned. You can see that the pod, two containers, does not have a host assigned yet. It needs a machine like these guys, so it is probably waiting for a machine to kick start, and then it will run that pod. So let's see if we have the status of the pod. Is it running? No, it is not. It is probably waiting for machines. When that thing is ready, in about a couple of minutes, I think three minutes is the time I think I saw it was running the last time when I saw it, it should run in two minutes, the new machine pops up and the container runs. And when that happens, we should be able to execute in the two containers pod, specifically reference the shell container inside the two containers pod, and interface with dash i dash t and get a bash prompt. What we are really doing is connect to a container within a pod and get a bash prompt inside that container, in the shell container. And that is what we are waiting for this to happen. If it takes too long, I'll just skip this portion and move on. There is way too much work for us to go and explore, so we'll just see if it actually runs. It is not running. So we'll skip this step and see when it becomes ready, we can then invoke this step right there. But that's the only purpose of this step, so we can skip ahead. What I want to do now is identify to you that you can actually influence how much of memory and how much of CPU is consumed by these pods. And so the idea is to limit. What happens is if you don't specify, it just goes with the default. And you want to specify how much resource, how much memory, how much CPU do you want to intend to allocate to a given pod, you can specify that thing very, very clearly. If you don't do that, it picks up defaults. And defaults are not necessarily the right answer. So you will put some constraints, constraint around a pod. So how do you do that? So we'll look at a pod YAML that actually describes how to write memory and CPU constraints on a pod. So you can limit the amount of resource hog it will take. You might see it here. I am limiting the memory to only 64 megabytes. I should say maybe bytes. This is MI, which is a maybe. If you haven't heard of this word before, you should see that maybe byte. Have you in EBI. So this is the word. If you haven't heard of it, you should take a look. A simple way to think about this maybe business is like that. You probably know what a megabyte is and gigabyte and terabyte. All these things are familiar to you very, very likely. These guys, kilobyte, megabyte, gigabyte, you know these things. But when you use them in the decimal system, that's when you call them kilobyte, megabyte, gigabyte, which is customary normal usage of the word. But when you use that in a binary reference, you call them kilobyte, megabyte, gbbyte, terbybyte, terbybyte, xbbyte, zbbyte, yobbybyte. This is the nomenclature used when you're using binary references. So it is not 1000, but it is 1024. Just remember that. That's the way to describe binary notation of byte count. If you haven't heard of it, just remember that this is what Kubernetes uses is the binary references. So this 64mi is a megabyte reference. It means 64m in binary reference, not m as in what you know of a million or mega, not a million. Million mega is the same thing, isn't it? Yeah, I think so. So this is mega in English and in binary math, maybe, maybe byte, 64 maybe bytes and 500m CPU. This is like half a CPU, 50%, 500m is 50% CPU, one half of a CPU. That's how you constrain resources consumed by the pod containing this container using this image and that port and that many resources. So you limit your resource consumption and create a pod called constrained pod. You just constrain it to the requirements, the limits that you set. Now that you have this idea, you can create a pod. So k create a constrained pod like that. It creates another pod. I can say k get pods and you can see that the other pod called two containers is now running and this constrained pod is pending. So now that means k get nodes should show us that there are three machines, the first machine, the second machine and one more that just started three minutes ago, which is what was caused by this two container pod. It required another machine. So the machine got created and the machine gets ready. Then the pod starts running. Now that the pod is running, we can actually execute this step right here, which is to connect to the pod and then select the shell container inside the two container pod. And then IT, this is interactive, telly typewriter, give me a bash prompt, please, inside the shell container in the two container pod. So here we go and we get it. We get inside the two containers pod and we are in the shell container. And you can confirm this by running cat, let's see, release and it should tell us that this is a CentOS image and here it is, CentOS 7. You know that because that's what this pod is constructed out of. So if you look at that pod, this pod uses the CentOS 7 image in the shell container in the two container pod. So now that step succeeded because the machine was necessary and we have the machine. So it is now running and the other pod is probably also running by now. So we can get to see it. But before I run that command, I need to exit out of my two containers pod, shell container. So I exit and then get pods. And now I have seen this is still pending. So maybe need more machines. Maybe not. We'll find out what's going on. So we'll give it a two or three minute time. It should just fix itself. Right now it is only one minute old, so it should fix itself. And we exit and then we create a constraint pod. We then delete both the pods. So basically the idea here behind a constraint pod, like the one you saw here, is to limit the amount of resources consumed by the containers inside going like this. So you limit the memory CPU consumed to a certain limit that you set. And then when you understand these things, you can destroy the pods. So K get pods. We have both of them running now and K get nodes. We have four machines now. This is likely to happen. And you may not want it to happen, by the way. Sometimes you don't want to waste money for a silly little thing like I run some two container pod and a test service and you see that you're waiting unnecessarily for a bunch of machines to start and stop. You can actually put even narrower limits on your test containers to get them to quickly run without having to wait for another machine to get allocated. And that is a possibility. If you decide that instead of N1, standard one, you get a bigger box for your machines, then you don't have to schedule another machine, another underlying node, but it will just accommodate in the same machine run multiple containers. That is also a possibility. But as you saw, a new machine pops up to accommodate the constraint pod. It required half a CPU and the machine was taken away by the two containers pod. And so that's why you needed one more and it started. So now if you delete these two container pods and also delete the, sorry, k delete constraint pod and also, am I not typing properly? I think so. So copy that k delete, k delete PO constraint pod and k delete PO to containers. So both these pods are dead. Now k get PO, shows me nothing, both terminated, k get NO, should show me four machines and two of them will slowly disappear after some time. Okay, let's go further. You saw pods and you saw labels. Let's go see what the next idea is. The next idea is replication controller. This idea is, I think it is now old. It's an old idea. People don't use this idea anymore because what has happened is that there are newer ways to handle replication and deployment is the new idea. So replication controllers are slowly going away. They're still there, available, you can use it, but deployments and associated replica sets are replacing the replication controller construct. Just want you to understand that this idea was the original idea in Kubernetes evolution. It is slowly going out of style and people are using deployments going forward. You should also use deployments, but I have it here because for sake of completion. So we'll see what a replication controller is quickly, not spend too much time because it's kind of, in my mind, deprecated, but it is actually not deprecated, it is still a fully supported feature, but I don't use it because I like to use the newer things. So here let's go create something. What do we want to create? We want to create a replication controller. How do you define a replication controller? You just write another YAML file, this is how it looks like. And so we will see that YAML file in the command line. We'll grab that line and say, show me, curl that YAML. I see it. I see that the kind here is replication controller. It defines a specification for one replica. It has a selector and a template. The template has some name, some label and some specification for the template itself. That specification contains a container. A container has a name called simple service, which runs the same simple service. So that's the replication controller. It will maintain one replica of this simple service. That's the idea. So now let us see, what do we have? K, get replication controllers. Do we have any replication controllers right now? No we don't. So we create one. How do you create one? K, create with this file, go create. Whatever you have in the YAML file will be created. So we create and it creates a replication controller. And now we see it. It's there. Now we see K, get nodes. We see that there are four nodes. We see K, get pods. We see that there are one pod. One pod is called RCEX. The replication controller example is running. This example is the same name here with a appended FZKS, whatever the random string appended to the name, is the replication controller. It is ready and running exactly one pod because that's what the replicas that you wanted it to have. Now you can very easily scale the number of replicas here by saying, kubectl scale the replicas in this replication controller. Make it three, for example. It says scale it to three. And now get pods. You see that there are three pods. It's very easy to scale. Replication controller scales your pods, four seconds, four seconds, 59 seconds, the new two new pods created because the replication controller was able to scale them. And now you can delete the replication controller pretty simply so that, you know what, I don't want you anymore. It'll go away and it goes away. Now I have, do I have any pods? They're terminating. Do I have any nodes? They probably are there. They're still there. Four of them. Great. Now let's go forward. With the idea of replication controllers understood, we'll focus more time on replica sets and deployments. Deployments are the way to actually go going forward. So replica sets are structured pretty much similar to what you saw in the replication controllers. And let us see if we can actually understand what a deployment is. We actually ran one deployment already. If you haven't noticed, if you don't remember, we say kubectl run size, something, image name, port number. It creates a deployment by itself automatically. So that's the default way of handling things. It will eventually replace the replication controller construct. And now here is an example of how a deployment looks like in the YAML format. But this is not good enough for me. I would actually run some hands-on exercises. So here are the hands-on for deployments. What we want to do is understand what deployment is. So what it does is a supervisor for pods. What did I just say? You know, you have pods, these guys running a bunch of containers. You want to have a supervisor for these pods so they can interface and scale out and, you know, automatic part scaling. If you remember, in our initial construction of the cluster, we set horizontal pod autoscaling. And that is a feature that we used. That is why you see that these pods are able to scale horizontally effortlessly. And also, the machines are scaling because the machines are also, the cluster itself is set up in autoscaling deployment. So now, if you want to create a deployment, let's go first of all look at our example YAML. So we'll call this example and look at it, what it has. In there, you will find that the kind is deployment. The name is size deploy, simple service deploy. It has two replicas. There's some metadata with a label, app colon size, and a specification, which has containers. In there, we have just one reference. This reference is to a service, sorry, is to a pod that I want to call size. It uses an image and port exposure. And it has an environment that I am calling out with a value and a name. Value is 0.9. And name is the version that I am assigning to the environment variable. So it has basically a 0.9 version of the simple service deployed is what I would like to remind you. With that reference in hand, it will create two replicas of this particular container. And once we say k create, and then give it the YAML file, it will create. And then you have a deployment ready. You can say k get deploy. And you will see the deployment. And here you will see and notice very, very clearly what is the desired state, what is the current state, what is the up-to-date value, the available number of pods. You wanted two replicas. You got two replicas. The current is two replicas. The desired is two replicas. The moment you change your desire, it will automatically increase the number of available and current pods running in your cluster. And that is what we are looking at the deployment. Now let us see if there is a replica set corresponding to this deployment. So k get replica set. And we will find that it gives you a replica set. This is the replica set for the deployment that you're looking at. And the corresponding pods, k get pods. You see that it has two pods because we wanted two replicas. We have them, both of them running for a minute. Now let us see what we can do with these two pods and see how we can scale the deployment. It's fairly easy. Once you have the cluster up and running, scaling and using Kubernetes is easy. Setting it up is the hard part and we'll do the hard part also. So don't worry about that part, the hard way exercise. That is really hard. And yes, it will take me a lot of time because everything is manual. Everything is automatic and no scripting. So completely it's a lot of work. You will see me do it and you should also do it to get a clear understanding of what this thing does it take to set up your own cluster inside your company on your own machines. That's where you do the hard way. The easy way is easy. This is the easy way. Okay. Let's see. Get pods. We saw that. We'll describe one of these pods, right? We have these two pods running. We would say, you know, kubecontroller, kubecontroller, please describe one of these pods to me and I want to grab its IP address. That's what I want to find out. Here, please let me access the IP address. So I see that the IP address is 1032.3.5. That's what I wanted. I can actually narrow it further and focus by gripping IP. I get the answer right there. And now what I want to do is get the names of nodes in the cluster. So you know that already right here. And then you can do it the other way also, which is a simpler way, kgetnodes. And you get the node names. So I got that name here is what I want to use and I want to connect to it. How do you connect to it? You say gcloud compute ssh and then the machine name and then the zone name. The zone name is what us-west-1a. And so I'm going to connect to that machine. Now here, what I want to do is find out what this guy is doing, that part that I have in mind that I grabbed for the IP address. That part, I want to find out what it has. And so from within the cluster, curl the part. So I'm inside the cluster and I want to curl it. How do I curl it? That's a curl and then the IP address followed by port number 9876 slash info. That's the endpoint that the simple service actually is rendering. And you should see what you see. And it is not responding. Did I type it right? Yes, I did. But apparently it is not responding to me. It should. Is there typing anything wrong? No. Okay. If that happens, it's very easy. You just kill the part. K, come out of that first. And then K get deployments. And you saw the deployment there and you just K get parts and you basically kill the part. The deployment will take care of your parts and it will automatically grow back to number two. So I am going to kill these parts. So K delete PO and then take this part and just kill it. And then the other part also kill it, both the parts. And nothing matters. It doesn't matter whether you kill them or not because the deployment will keep track of how many parts you need and it will create them. Right there you see the two new parts popped up. And I terminated these two guys. You see I terminated the J9, Z7, this one. And I also terminated this guy, H, J, T, V. They're both terminating. And these two are already running. It got created like five seconds and 17 seconds ago. These five minutes, two minutes ago, the older parts are dead. And now I have only two running and the new ones are running. So they should be a different IP address. Try to describe these parts. And what I will do is K describe pod, that one. And then grab its IP address. And then connect to the machine that I had. And then in the machine, curl. Curl what? Curl this, add port number, 9876, 9876 slash info. And I get the response. That particular part was misbehaving, so I killed it. Deployment automatically generated two new parts and they are healthy. That happens occasionally. If that happens, you just shoot the cow. Simple. But shooting the cow is even way more easier in case of a pod, it doesn't even take much time. It's like a blip of less than a second and it is dead. And in the same sub-second, another pod is started also. So it is just done for you. You won't even blink an eye and you will have a dead container and a living container, a new one created. And there it is. So we have the response coming out back from the service. And that's where it is. And by the way, you see this from reference here. This is interesting. This is where the machine IP address is. This is the IP address assigned to the node, the machine called 3SXW. This machine has this IP address. This pod itself has a 1032 IP address. The machines have a different IP address ranges. So each one of them has a different subnet and a different IP address reference that you know are used. What I want to now do is come out of that machine and upgrade my deployment from version 0.9 that I had before. If you recall, I had this version 0.9 called out in the pod definition. If you look at the pod definition right here, where is that? Not this. If you had the pod definition, where are we? Deployments. And where I create a pod, create a deployment, where is that? 0.9. But where is the deployment? There it is. Here's the YAML file. It has the simple service value 0.9 called out. That's the version number of the service currently running. And what I want to do is upgrade the deployment to another version. So I will do that. What I will do is change to a different YAML file. This YAML is different than the previous YAML. So the previous YAML is D9. This is the previous one? It's D09, is it? Oh yeah, it's 0.9, not just D9, it is 0.9. This is the older YAML with a version 0.9 and a newer YAML, curl. The new YAML I want to upgrade my deployment to version 10 or version 1.0. That's what I'm really trying to accomplish is upgrading my deployment. So this is the new one. This is the current one that is currently running, the current deployment. And I want to change my deployment using a new YAML. So I will do that. What I need to do is basically apply the new YAML. This YAML needs to be applied on top of the existing deployment. So initially when I created a deployment, you say k create dash f. This time you want to upgrade it and apply a new design. You say k apply and then paste the new YAML. And when you do that, it says deployment configured, meaning it took effect. So now if you look at k get replica set, you see that there is an old deployment 10 minutes ago and there is a new deployment 12 seconds ago. And that is ready already in current and desired and all that. This one is not desired anymore. As a consequence, you have k get nodes for the k get pods and you have pods and they are now running 34 seconds and 36 seconds ago, which are recently started or recently created. They are now running the later version of your YAML. Now what we can do is connect to one of those pods by basically getting the IP address of one of these two pods. So let's say k describe the pod and say that pod. So get me that pod IP address, please. I'll say, okay, you please give me the IP address for that part. And I get the IP address, that one. That's what I want to grab. And I want to now connect back to the cluster in the cluster. I would like to now ping it, or rather curl it, and say that IP address colon 9876 slash info. And here you will see version 1.0 output right there. This version is coming from the container inside a new deployment that we just applied. We apply a new YAML version 1.0, which is what you see the response coming back from this new IP address, which is this new pod, which is created as a consequence of the new application of a new version of deployment number 10 as opposed to deployment that we had before, which was 09. That was the way you update your deployments. You just put a new YAML file and k apply, boom, updates. Now we'll come back on that machine, come out of the machine, and we can see what has happened to our deployments by looking at our deploy history. We can say that, you know what, show me the deployment history, and it shows you there is a revision number 1, revision number 2. And we can easily roll back. If something goes wrong, say, oops, I made a mistake, 1.0, not good, 0.9, good, go back, no problem, easy. How do you go back? You just say, deploy, undo deployment, back to revision 1. And so here you say, kubectl, roll out, undo the deployment that I did by mistake, I was stupid, roll back. So it says, okay, fine, I did. And now you can see the roll out history, roll out history again. And you'll see that there is a revision number 2 and revision number 3, as opposed to 1 and 2. You can see the parts that are now running. And these parts are now running 0.9, 0.9, 1.0 is terminated. 21 seconds ago, 19 seconds ago, 3 minutes ago, terminated. And now you can again go back and examine that these new parts are running 0.9 as opposed to 1.0, which was a mistake. So we revision rolled out and undid the deployment, undo. You can basically undo, redo your deployments at a larger scale by defining exactly what needs to be running in that deployment. And set that out in a YAML file and apply and roll back. And all of these things are easily possible. And now that we have done this rollback of a deployment, I would like to delete my deployment. So I'll say, you should die. So it says, bye bye. It dies. Next. Okay, back here. Now we talk about the next logical idea. So now if you look at the picture, I think it's a good idea to think about. So now let's go look at picture. What we have been doing is at the bottom, we had some machines. We started with two and we got some more occasionally we see that these machines go away and sometimes they come back as in when we add some parts. We can add part directly to a specific machine. We can not specify a particular machine. We can not label them, label them, select them, destroy them, create them, whatever we want. These are parts. If you run a part in the control of a replica set in a deployment, then you have the ability to scale it effortlessly and go back in time revision history. You saw the example of 0.9 and 1.0. You saw the example of scaling from one to three. Those are easily possible because these things control how many parts are running in your cluster for a given deployment. So that is now, I hope, understood. And I would like you to make sure that you can ask questions anytime. So please do ask that if you have an idea or a question at any time, just ask that. It's important to make sure that you get the answers correctly. And here, what I want to now do is help you understand another logical construct, which is kind of difficult to understand, and that's why I'm drawing this picture to help you understand. You saw that these machines had an IP address of some sorts. It was a 10.64 or some number. Each of these machines have a unique IP address, and you can have any number of machines as you grow the cluster. Similarly, the parts that get created inside typically get a... They were getting an IP address of 10.32 dot whatever, dot whatever. That's the IP address you were seeing in our parts. And you saw me that I kill a part and I get a new one with a new IP address. And these IP address are dynamic. They change with the part. Parts can be ephemeral. You can kill them. They get created again automatically through a deployment. The deployment will control how many of these parts of a different type that you have, and they will all be having a dynamic IP address. That's such a nightmare. Such a nightmare. You saw me doing with the nightmare right now is just find the IP address and then go to the part and then, oh my God, how do I even remember those IP addresses? That is a problem that I want to now solve. And for that, we have a thing called service. So you saw these ideas called nodes at the bottom, which are basically machines. You saw the idea of a part. You can label them and do whatever you want with them. You saw the idea of a deployment and a replica set, which will control how many parts you have, how they scale, how they revision, how they grow and shrink, all that. And now you understand that these parts have a dynamic IP address, which is such a nightmare because the parts IP address will be keep on changing and you don't want that to be changing so dynamically with parts coming away and growing and shrinking and all that. You would rather have a static reference so that you can refer to these services that you will rather refer to these parts by some kind of a named reference. So think of this named reference is what is a service and think of it as your DNS inside the cluster. So here you can call my simple service, you can call it by the name, whatever name you choose. Like I choose this name XYZ, that's the DNS name I want to give. And what this service construct will do is automatically align the name to a dynamic IP address, automatically align itself. And there is this thing called DNS already in your cluster. It runs a DNS service within the cluster for you. You can see that by saying k get nodes and then describing one of these nodes. You can say one of these nodes, grab it and say k describe. And here if you describe that node, you will find that it runs kubeDNS. And this is a service running in the cluster, which is what is the foundation behind this DNS idea that I just mentioned to you is what a service will do for you is that it will let you call these deployments, not by their dynamic IP address, but a name that you can remember and assign and use. And so you don't have to actually remember these IP addresses like 10.32.2.35. How do I even, why do I even bother to remember those things? It's ugly, ugly, not doing it. So get a service in place. And what service does is it is an abstraction which defines a logical set of parts. And you can call it microservice if you're into buzzwords. So you can call it microservices architecture or whatever architecture you can come up with. But that's what this thing is. I don't like buzzwords. I don't use them. But yeah, you can call it microservices architecture if you like, just for the sake of talking about it in some big meeting. But that's BS. It is just a service. It's basically a DNS translation. Okay. Now, what do we do with it? So how do we create it? So you create it like this. You define a service like that. And let's do some example exercises. So here we go. Create services. We create a service by looking at an example, part and a service to go with it. So two YAMLs, two YAMLs. One is a replication controller. And the other one is going to be a service. Let's go see these two YAMLs side by side rather in a clear fashion so we can understand. Let's grab the service YAML first. So I will grab the service YAML and curl it. And here you see it is actually very, very simple. It is a YAML file that is this small. It has a kind called service. It has a name called simple service as opposed to S-I-S-E. You can choose whatever name you like. It has a specification that has a port number 80 that is mapped to the internal port inside the pod or 9876 if you recall. The pod itself is showing its services on a different port, 9876. Whereas this service would like to expose itself on port number 80. So you do this port mapping right there. Port number 80 mapped to port 9876 inside the pod. The pod is running simple service. And you have a selector is how you actually select. And this service will select all the pods, all the pods that have this selector. And it automatically will load balance itself between this port number 80 at the service level and the target. The Siri thinks that I am talking to her, Siri is bad. So the simple service is this port number 80 will connect itself to all the pods that have this selector. All of them. If you have two, it will basically do a load balancer inside. It looks something like this in a picture. You have this simple service is the service that you are creating. It has port number 80. It has a selector called app colon SISC. And inside you have a bunch of pods and that have these labels. So they have different addresses, 10.32.x.y, 10.32.p.q. And so you have this simple service. It will do mapping like this between this port and that 9876. Between this port and 9876 and do an automatic load balancer for you for free. You don't even have to think twice about it. And if you grow the number of pods, like one more, no problem. Another, no problem. And all these pods automatically construct themselves in form of a DNS based resolution by this name, simple service that exposes itself on port number 80. And it will divide one, two, three, four, round robin, already round robin load balancing happening for you without you having to do any extra work. And that is what this service does. So if you take this YAML and apply, so say K create, dash F and apply. By the way, there is a trick here. You don't even have to say create every single time when you create. You can just say K apply even if it doesn't exist. Even if that thing doesn't exist, you can just say apply and it creates. If it doesn't exist, it will create a new service and it should create that service. Which is simple service created, even if you use the word apply as opposed to create, apply is just fine. Simple service gets created. Now you can say K get service and you will find that the service is listed. The service called simple service gets a static IP address within the cluster at port number 80 and it is up and running for 14 seconds. Now that service doesn't know anything because there are no containers, no parts. So say K get PO, there are no parts here, only the service. So there is nothing to connect to. I mean, the service has no idea about these things yet because there are no parts available yet. So we'll create parts next and we'll give them a label like that. So it automatically gets connected to these parts as you will see as I create a new replication controller using this YAML. That YAML is called that YAML and you will see that I'm going to create a new replication controller with one replica. It has a selector called app.siac, which is what this selector will match. And then it uses a template, it has some name, it has a label and it has a specification for a container with a name siac that uses this image and a port. So when you install or apply this replication controller, it will create a new container, a new part and a new RC, a replication controller. And so we'll say K apply dash F and get me a new replication controller like that and go. So it creates it. Now you have K get nodes or K get parts. There's a part available now and it is running. And now your service is connected to the part automatically because you now have one part. Like not these, not these, not these, we're just one. That part is now running in control of our application controller, which says replicas are one. There is one part. You can grow the replica account and it will automatically include that in the service declaration as you see. So we now have a supervised part running. We can check that part out by saying that, you know what, give me the name of the part which has this label matching app colon SISC. And the part is this one. You know that now. Now you can describe the part if you like to get the details like this and say, you know, give me the part, please describe the part. And so it is a description, there's an IP address right there. And what we want to do is you can connect to the cluster and ping that thing by its IP address, like usual, like we have done before. So we'll get connect to the cluster and we'll say connect to the cluster is like this. So we're going to connect to the machine inside and in there we'll say curl. Curl what? Curl this IP address with a port number 9876 and then slash info. You saw that this is coming directly from the part with an IP address, which is ugly. So what I want to rather do is refer to it by the service, the service IP. So let's go see the service IP address. So we'll come out of this first and k get services. And here you see the service, you see the service IP address. That IP address doesn't change until you kill the service. This is a static IP. It is also used as a DNS name for the simple service. So we can use this as a DNS name also, but let's go back to the machine. In the machine we'll now curl again. This time I want to curl this service IP address and not port number 9876, but port number 80 and go to the info location. Here I find the same thing except that I'm going through the service. I'm going through this IP address and then it is connecting me to the part at this port and showing me what I am seeing here. And that's what you will see when I say 1094 4751 colon 80. Show me what you have and it shows you what it has. It is showing you that the host is the service IP address, not the part. Doesn't matter because you're not dealing with the parts anymore. You're dealing with the service. Now this is also called a VIP for some reason. What's the reason VIP? Maybe virtual IP. Okay. So what's your IP? It's called VIP. That IP address that you saw here is a virtual IP address. It is fictitious, made up, not real. It is just associated on the fly dynamically, so statically assigned to that service name. And now what we can do is do some fun steps a little bit here. Let's see. These are interesting. You have to pay attention to understand these things. So give me a second. What I am going to do is show you routing of traffic within the service through and through the part. You have to pay real careful attention to what I'm going to do because this is kind of clumsy. So I am inside the machine called 3SXW right now. And here what I want to do is to see how the traffic goes to the part. And what I want to do is to show you how the traffic goes from this IP address, which is the service IP, and this port, which is number 80, to the actual part running underneath at some other 1032 IP address. And that you can see through IP tables, which is the Linux utility on the firewalls utility. And that is managing traffic primarily in Linux boxes. So we will go and check sudo iptables-save and grep for simple service. So let's go see what we have. And it's easier if I do it on the full screen so you can really pay attention to what's going on. So here I clean up my screen and then run the iptables command to grep for simple service. And here you see that there is a forwarding happening, let's go see where it is. This is the port number 80 when it is receiving the traffic, and then it is denating to destination. And the destination is the pod IP 103216, port number 9876. That's what's happening. So you can see that this traffic routing, this blue line is what I'm showing you in iptables right there. Default simple service tcp j dnat to destination, and then the destination IP address and port number. This is your pod IP address. Now let's go make it a little bit more interesting. And the idea would be to actually scale the replication controller we have. We have k get rc, we have one replica, I'm going to make it two machines or two pods. So I will do that. I'll just scale it. And what this will do is scale. So we got two pods now, k get pods, we got one and two. One is three seconds old, one is seven minutes old. Now, what I would expect is that this service is now mapping to two of these parts, not just one, but two parts, because that's what we have two parts, because our replica replication controller is now two. So we have this part and this part, they have a IP address here and IP address there. And this should be routing 50% of traffic here and 50% of traffic here. That is what load balancing will do in round robin fashion. If you just have two pods, one service, it will distribute the load. And let's go see now that we have two pods. Let's see what IP tables will show us. And it will see that the probability module, 50% probability module will be used in IP tables. So you understand what I'm talking about. Let's go connect to the machine again. And in there, we'll examine the IP tables again and grab for the same simple service. And I'm going to go full screen again so you can see properly. Now here you start picked up yet, not picked up, so you still see only one, which is not what I expected. So let's go check, get parts, it is pending. That's why it's not picked up, it is pending. That's why it is not showing us the probability distribution of 50% probability of these two pods serviced by the same service name. And so here is an example output that you can see on the website, which is showing you what I'm expecting to see after the pod gets up and running. It is not running, but this is the website, this is pending. So k get nodes, we have three nodes. So k get pods, container creating, so it's progress. And this one started a minute ago, so it is basically just barely starting. And that's why you see container creating. And as a consequence, this container will start soon, which means it should be started by now. Which means we should be able to go inside the cluster and then check the IP tables. And then we see it. We see what we see. Let's go check one more time. One more time. Show me the IP tables, please. Please. There we go. And here you see that it is sending you 50% random probabilities, 50%. And that's the statistics module in IP tables. That is what is used to send traffic in these two destinations. One of them is the pod 1032.1.6 and the other one is pod 1032.2.3. Those two pods are being the backend and this service itself is the front end in all internal to the cluster yet. We are not yet exposed outside. We'll come outside of the cluster also. And we'll then have actual users connect to services and use these services from outside from a real life user. We are using it inside the cluster. We are going services inside the cluster. Everything is all within the cluster right now. But we are building our understanding of what that cluster container cluster is and then we'll expand. We'll go through a full-fledged example of what these things will do for us for real life for a real customer. And that takes time to build up. So the things are written down and we'll follow these examples along as we go. I will now help you understand this piece before I pause recording. And so the idea here as you saw is the statistics module of IP tables is using the random probability, random mode and 50% probability and distributing the load. Coming on the simple service at the cluster IP address, port number 80, diverted destination to these two addresses and that's what you see right now. With this, I will exit from the cluster, compare my notes and delete the service and delete the replication controller like that, delete the service like this and delete the replication controller like that. And for right now, what I would like to also do is delete the cluster because I'm done with this. I'll create a new cluster next time. So we have a cluster. We know how to create it. We also know how to delete it. So we know how to bring up the cluster. We know how to reconfigure. We know how to destroy the cluster. We'll say gcloud container clusters delete and we'll say, yeah, please go ahead and get rid of the cluster itself. And then we'll say yes to it and the cluster is dead. It will be dead. And now I stop recording. Next time we'll resume, create a new cluster and continue the journey in understanding the detail behind this beautiful architecture of Kubernetes as to how it will help us create whatever you like. Basically, you run your applications inside this structure. And if you want to use buzzwords, but I don't like to use them, so I am not using them. I'm going to stop recording and I'm here for questions.