Hey guys, we are recording this session and what you will see now is a view into a production cluster that I have already running. The reason I am going to show you this view is to give you a perspective of all the components inside a Kubernetes cluster. Let's begin by looking at what this WeaveScope thing is. WeaveScope. WeaveScope is basically a method to detect processes and containers running in a Kubernetes cluster. And what this is is an open source project. You can actually go to that GitHub location and install it. And so it should probably take you to GitHub. But yeah, it is on GitHub. So you can install it on Kubernetes like this. So follow one step, follow second step, and connect. That's all I did here. And so let's go see how many containers do I have running. And so let's go filter them. And here. Okay. Are you sounding far away from microphone? I am far, far away from microphone. Yeah, that was far away. Now it should be fixed. So thank you for catching, Travis. I am now back to how I should be. I forgot about the microphone. So yes, so the microphone is back close to me. Now let's go inspect this thing that we have at our disposal. We have, first of all, hosts. So let's begin with host. Host is the machine that runs or constitutes the cluster. So host, I have this host here, this one, and this one, two machines running right now. And they are connected in a specific manner. They're connected for outbound internet connections, they're connected for inbound internet connections. And there are some cloud images available. And that's the bottom line. At this moment in my cluster, I have an auto-scaling cluster and I have two machines, or I should say W instead of M. Call it W1, W2. So this is your W1, this is your W2. Two machines running. They're big size machines and I have them running. You can see this visually on a command line when I say, k get nodes. And so I get two nodes. Those are the two machines running, the latest version of Kubernetes as of yesterday. That's these machines. That is one and that's another. Now collection of these machines is called a pool. So my pool constitutes these two machines, one and two. And that's the pool. I have only one pool. You can have multiple pools. So W1 and W2 is together. I call it my Deadpool. That's just a funny name. That's the name of my pool here. You can see the name reference. And so the Deadpool is actually a good pool, it's not dead, but it contains two machines. This pool is a auto-scaling pool, meaning it can scale the number of workers I have like that to any number I like. And I think I put a limit of six for some reason at this moment. That's just a limit. You can see if I add more load to this cluster, that the number of machines will grow. Currently, the limit is up to six machines. So one, zero, one, two, three, four, five. It will grow to W0, W1, W2. That's what I currently have, one and zero and one will grow or shrink if I put more load or less load. How do you put a load? You basically put pods. These pods sit on a network. I'll show you how you visually see the network. I'm using a different net, not the weave net. That's why the weave net will entry, will show you nothing here, but I'll actually draw it out for you so you'll understand what network I'm talking about. And I'll also correspondingly map these things in a production setup so you will understand what these connections are and what do they mean to you from a user's perspective. So here is the Google Cloud implementation, we'll go to Kubernetes cluster. And as I described to you, you're looking at a cluster here with a pool called Deadpool, right there, here. And this Deadpool currently is two machines, size is two machines. It has a total of four CPUs and total of 15 GB RAM. And it is enabled for automatic upgrades, enabled for automatic repair, automatic scaling. And the minimum size is one, the maximum size is six. That's the number six that I was talking about before, which is how many machines can it grow to W1, W2, like that, and it can go up to W6. So that six is the upper bound that I have set. It's an arbitrary number. It depends on how much money you have in your credit card. That's what it basically boils down to. And so that is my pool here. I call it Deadpool. You can call it whatever you like. That's the name of that pool. Having seen this pool, you will see that this is the only pool I have in a cluster. And in my cluster currently, you can add more pools by editing the cluster in a visual fashion, or you can do all these things you can do on command line even better. And that's a recommended way, because it gives you finer granular controls on what you can do. So here, you can add more pool like that. And you can decide how big the machines will be in that pool. This pool will be that other pool. And in that other pool, we will have machines of big size. And they can have all these characteristics that you already know, like how many machines you want, whether it is auto scaling on or off. And so minimum size is one, maximum size is 100. And like that, you can go and make your really big cluster if you want. That's the point. It is very wasteful of me to do that, so I'm not actually doing it. But you get the idea. Having seen that concept, let's go back to WeaveScope again. So this is how you start it. And the WeaveScope installation is here. So if you look at these connections currently, you see that our pool has connections to inbound and outbound. And in this pool, we have a bunch of pods running. What is a pod? A pod is a collection of containers, like in very simple terms. If you saw me remember the diagram that I draw, it's a container, another container like that. And you put any number of containers in a pod. And that's your pod. So think of it like a pea pod, and these are peas. So that's how you relate to, and these are containers running inside a pod. So that's the concept here is in a pod, you will have containers, sometimes one, sometimes more, depending on what you want to keep. So let's now go and inspect our pods. So we saw the hosts. Now we go to pods. And here you see I have lots of pods running. And so let's go filter it, narrow it down to just one application. There are all these pods showing apparently currently. So I will like to narrow it down to just one application that will give you a clear idea about how does this site run. That's what I'm going to describe to you. How does this site actually run? What does it take for it to underneath under the hood? What does it take to make it run in a Kubernetes cluster? That's what I'm going to illustrate with actual live example on a Weave scope so you can see it visually. If you now try to look for this domain inside the cluster, you will find that the very first thing you need to have in order for you or a user to go to that site is a route that has a domain name like b.a.cloudgv.us, that name, and it needs to go to some IP address. And that's where the dig query will resolve. So if you dig this name, it should resolve to some IP. And that should reach some IP address somewhere in some cloud. And so in our example, it is going to be the Google Cloud. And here, the next thing you should have is a way to enter the cluster. So no traffic is allowed either outside or inside. Please zero traffic unless you have this method that allows entry into the cluster, enter the cluster. This concept is, I think, one of the most important concepts in Kubernetes to be specific. And the first thing that is needed for this entry to be allowed inside the cluster is called ingress. Now, this ingress is what you will see here. And the application, sorry, this route is coming from the internet. It is showing you an inbound connection. And that inbound connection takes you to the nginx ingress. That's the ingress I'm talking about. So I have implemented this ingress using nginx. You can implement, nginx is open source, by the way. There are commercial ingress solutions also available. I don't care about them. So I don't talk about them. But I would talk about certain other open source ingress solutions that are also available. They're also good. And it is up to you what you want to pick and choose depending on a given application. How do you decide which is the best one of all three or many, many more? You basically try them all. And you find out what is the best for a given customer, for their need. And that's the real answer to finding out which the best product, because all of them are good. Having said, I'll give you another example of this ingress, it is called traffic. The spelling is kind of weird, traffic. The pronunciation is like traffic, but the spelling is this. And so that's the product that you have in open source. Let's go see it. And so traffic is this product. They call it cloud native edge router. But what exactly it is, they can call it whatever you want. It is a reverse proxy, and it is an ingress. So it allows you to get in and it's also a reverse proxy. So a reverse proxy is something that you already know. If I want some domain cnn.com, and I want to say times, nytimes.com. And I have both of them running on the common IP address. So people will come on the same front endpoint. And now I have a reverse proxy sitting here. And that reverse proxy will already understand that you want to get cnn.com and you want to get New York Times. So I will divert your traffic to the appropriate boxes or appropriate services inside. This is the cnn service, and this service is your nytimes service. So I will divert your traffic accordingly to the correct services running inside the cluster. That's the point of reverse proxy. And it also has this method of entering inside the cluster. So ingress is built in ingress. So this is also a relatively new but open, that is GitHub open source solution available that you can use. And they also provide you a commercial support if you like, but I'm talking about GitHub. So it is available for open free as in freedom. That is another good one. Another good solution. I just don't have it running. So I cannot show it to you, but it's easy to run. And all it takes is a YAML file. And the YAML file is here. You can just look at it. So let's go see it. So you'll see how to run it. And so here is the getting started configuration. And here is an example of what it can do for you. So you see you ask for api.domain.com, you go to the traffic proxy, the traffic guy will find out that you want API. So it will just pass you to API. You want to go domain.com slash web. So you request that and traffic reverse proxy will take you to this location. You want back office on the domain.com will take you to one, two, three multiple black offices. So heavy high end service, the multiple machines running handling your request. So that will be transported over to your back office. That's the underlying idea behind a reverse proxy. That's the implementation. This is your private public boundary inside is private, that is outside. And it also acts as an ingress solution. It's ingress. So let's go back to our command line here and see what ingress do I have. So if you say K, by the way, K is an alias. So which K? Which K will tell you what K is. K is an alias to kubectl, this kubectl, which is what the full command is when you want to type. I'm just lazy. So I don't type kubectl. I just type K. Which K? kubectl. So it's the Kubernetes control action or whatever you, the full, there is a full form for that, but that's how you interface with Kubernetes. So K, kubectl, when I say K, get ing, I will have multiple ingresses for multiple services running inside. Let's see what do I get. So here are the bunch of services currently running for which I have an active ingress. So there are how many ingresses we have, so let's go see that. So one is for this site called Hi, the other is called Chat, the other is Coursebook. And then the main site here, that's what you know about and you use it. There is also another site that you don't know about that you shouldn't be going to, but it's okay. You can go. And that is a staging site. There is also a site called Strapi, which I'm experimenting with. So that bunch of sites all running on the same IP address. And these ports, these ports are available, but they get redirected to here. This is HTTPS. And that is automatically direction happens. And some of these services are old, like here, 86 days old and 86 days old. And some of them are relatively new and there's like a four day old, four day, one hour, four day, one hour old. So it's a new idea that I just put in place to stage something that I'm experimenting with right now. And that's a separate service, kind of sort of looks similar to the main site, but it's my testing site. So you can go there, don't, but you can, I mean, nothing prevents you from going there and you can even log in and see, but it's kind of pointless. So it's not meant for public consumption, it's for me. And so, by the way, you have access to it also, so don't worry about that. You can still go and see, but there's nothing to see, nothing interesting to see. And then of course there are things. So having, having seen and understood what an ingress is, is for every domain that you have in question, there is a way to define a place to go inside like this is actually a site. Let's go see what that site is. So maybe this chat, you may have seen this one already. Let's go see that site here and we will go to a browser and open that site and you will see that this site opens up the chat invitation. So here you can type your email address and invite yourself and that's how you can get onto the cloud genius Slack channel. This site is just a simple site with this one page that all it does is, is to let people in into Slack, into here. And that's the purpose of that site. It's a separate service running Node.js application and I'll walk you through. So that's one example we'll go into detail with. Another site, this high site, it's another different product running a system. I call it my customer relationship management system. And so that is loading up. You can see that there are people who visit this site, my main site, not this site. Nobody goes here, by the way. Nobody visits because nobody has a permission to go in. This is just for me. And you can see already visually that my customer base is here. Yeah, some here. And that's where most visitors come from onto my main site. So I will talk about this. This is also another open source product. This is conceptually similar to Salesforce.com or HubSpot or other things that you may have seen before. Let's go see what you're talking about HubSpot. That's a commercial service. So what I do is use my own open source product that can do something like this, like HubSpot or like Salesforce.com. You may have heard of these or used these services. I think your company has this service. You probably in your company have this solution called Salesforce.com. It's a customer relationship management software. Now what I do is not use these commercial products and not HubSpot. But I use this. Now what is this thing? This thing is called Motic. It is available here. And so it is free and open source marketing automation. So most of my interactions with you are actually automatic. And yes, I am the person behind them. So I write every single thing that I use automation tools to send you communications, messages. But many of my work is already automated. This is one such tool that I use and I am showing you right here. And that, but I will also be discussing in our discussion right now. There are other things here like this site, Coursebook that you probably never visit, but you actually do visit every time you log in. This is my login tool. So let's go see that Coursebook site. There's nothing to see there. You can go there and you actually go there every single time you log in. You can see the traffic and I'll show you that traffic right now. So here, if you go to a, let's see, a browser. So come on brother there. And here I open a new tab and let's see, I go inspect and then I go to the site. Now, what do you see is the site opens up and now we'll see the network activity. Here is the network and I will clear everything. And now I will try to log in. You will see as soon as I log in, click the login button, click. The first thing you will notice is traffic going. Let's see where the traffic goes. Hold on. Okay, where is my, yeah, there, there. So the traffic is the pen and the traffic goes to Coursebook. The first thing it goes to Coursebook. Then it goes to GitHub and then bunch of GitHub things. All these GitHub. They're waiting for GitHub to log in. And here I need to log in first before it will hand it back to that site. And that's how I handle authentication. And that's how you see that the authentication login is very, very simple, you know, doesn't even want you to type in something. You just click and log in. That's, that's all it takes. So now you will see that in action, you have seen it in action already. But I will log in one more time just to illustrate the point. The point here I'm going to do right now is a login method. So which means I need to log in as somebody else. That's a test account. Then I authorize. That's another login step. It's a step that I'm, you know, making sure that the person is authorized and that authorization is going to GitHub and it is still on GitHub. As soon as I click the authorize button, you will see that the authorization flow goes back to the main course book site, which you never visit, but you actually do is it. So now let's see clear. And I now authorize. So as soon as I authorize, it goes back to, let's see that. Okay. Too much, too much, too much info. Okay. Go back, go back here. It goes to course book again, after GitHub goes to course book and then hands off control back to the main site. And then it's all on the main site that that's okay. In the meanwhile, it also goes to this high site to interface with the other site that I have. Like here, you can see the high interaction and bunch of other things like search chat capabilities. And so this chat window and all that, that interfaces later on the site opens up very quickly primarily because I store everything in a static site location. So the whole site is actually static. It doesn't require to have a database, but I do have a database and I'll talk about that also. And so here the example implementations continue. Now we'll see that in here is this ingress. Now when I mentioned a database, I would like you to know that you don't need to have an ingress to a database. I hope that idea is clear to you when I said, you know, you don't need to have an ingress to a database, but I do have a database. And what I'm really saying is that, is that you don't need to have, hold on, yes. What I'm saying is you don't need to have an ingress to a database because nobody from outside directly accesses a database. They should not be accessing, they should access an ingress point like the B.A. point and that application that runs that site should handle it. The application that I have it running is called, what is it called here? That's the name. So this is the application that runs B.A.CloudGini.us, the site itself. It is called Course Book UI. It's a static site. That is this site in that container. So the traffic coming from the internet goes to the ingress and the ingress diverts it to the application, which runs here in that container. That is actually a pod. So you will now see the pod in action here. When I say K get PO, which is pods, you will see a bunch of pods. And so one of the parts that we are talking about right now is this idea that I just mentioned, which is this is the main endpoint where you enter from. That's the ingress. Now it will be transported over directly to this pod, the UI pod. If you go to this endpoint and come in from there, it will transport yourself to this other pod, which is the staging pod, because that's a staging site. You can go to that site, by the way, if you like. And you will see that it goes to a different pod, which is also running for 18 hours. This other part is running for slightly longer because I keep updating the pods and keep updating the images underneath the pod, the sites completely change. And so that's what I occasionally do every other day or day, every day when I feel happy with the staging, that I switch the image and make it go live, but then you see it. You usually don't go here. You don't go here typically. But now that I told you, you can go there, but don't. And so you will see what I am currently staging. And that's the idea behind a staging area, which I just discussed. Staging goes to here, the actual site goes to this pod. So that's the relationship you will see now in that UI that I'm going to go back to. So now if you go to look at the ingress point, it takes you to the UI, this UI, and it also takes you to the chat service, which is another service that I mentioned here, like here. That one, the chat service, it connects to a separate pod for itself. And that is this pod, chat pod runs the chat service. And this is the ingress point for that. And that is what you see visually on, come on, 50% screen and adjust this a little bit. So this chat container or the chat pod here is connected through the ingress, as you can see that connection. And the traffic that will be coming from the internet goes to the ingress point and gets sent to the chat pod. And that's it. It also can connect to the world outside. It's an outbound connection to the internet. This is the inbound connection to the internet, so this can go outside if it wants to. That's the scenario of a simple pod, just chat. It has nothing else, just one container running in one pod, nothing else. So very, very simple site. So that's the idea behind that site. Let's see some of the other pods here also. So you understood this pod, which is the main site that connects also to ingress. You will also, let me clear up my ink and I'll re-layout this thing a little different. So you'll see the whole ideas again for the other sites that we did not discuss yet on a visual perspective. Let's make it wider. And you will see here that this ingress actually connects to a multiple other pods also. Like I mentioned already, here is your course book container. This is the backend container, coursebook.cloudgd.us that you don't visit ever. But you actually do, because behind the scenes it goes there for logging authentication. This is the main UI container where you see whatever you see. And this is the staging one, actually. This is the main UI container. That's the staging area. This is the backend authentication connector that lets you connect with GitHub and log in. This is the chat site. And there are other sites also, let's go see others also. So scrolling a little, erasing my ink and scroll. Come on, scroll please, there we have. So I am going to broaden the view and see all the pods to let us see the other pods and all the other containers also. So here what you will see now is I will show you a look at the third idea. So we discussed host, we discussed pods, pods contains containers, and we now will look at services. A service is basically the idea here. So say k get svc services. So I see a bunch of services here. Let me just make it a little smaller, get fit properly on a page. So here you see these services. There are services for this thing called the Motic application, there is a service for chat, there is a service for course book, there is a service for database, there is a service for the user interface for the front end for customer usage, the b.a.site is the staging site, there is a Kubernetes service, there is a NFS server service, there is an Nginx ingress controller service, there is a default backend service, and a Google Cloud SQL proxy service. And another service that I have running, which I'm testing this one. And so these services actually interface directly with these pods. So the idea behind this example that I'm going to now do another live demonstration right now in a live setup is what I will do is scale and scale as in not scale the machine, but just scale the pod. You will see a variety of implementations of scaling for a deployment that I will now show you simply. What I will do is scale my application. So imagine if lots of people like you start to visit this site. And if that happens, it will be a great thing. And this site will automatically grow. The growth happens like this. I'll show you how it grows. So let me get a white sheet of paper first. There. So the white sheet is opening up. And here I will draw the growth scenario. So from a user's perspective, you have machines here. Let's call them W, not M. So W worker one, worker two right now, two workers. Each of them can contain 110 containers approximately. That's my limit I have set. And in there, I have containers running. So C1, C2, C3, they may be a part of a pod P2, and this is a part of a pod P1. And so that might be the case. And they may be sitting here or here. We don't know exactly where it sits. So one of the two machines will have these pods running. We don't exactly know where it goes and sits, because we don't care. Because we will have more machines like that, and it should be able to transparently handle and don't make me pay attention to the idea about where do I place my pod. And that pod placement is automatically scheduled by Kubernetes, so you don't have to worry about it. With that idea understood, what I would like to do is I would like to scale my application. So in my application, I have the B.A.CloudGini.us site. It has an ingress point, and that ingress point maps to, I said pod, but actually it maps to a service. And that service in turn maps to these pods. And now that you have that, another level of abstraction like this in place, what now happens is you can have another such pod running here, and another such pod running here of the P1 type, the one that contains this application. So you can now scale your pods horizontally. This idea is called pod horizontal auto-scaling, the full name for it, pod horizontal auto-scaling. And what it does is it lets you scale your pods across, horizontally, on a cluster of machines like this. So if you have traffic, like I currently have how many pods running for the course book UI application? Let's see. One ready, one running, and zero restarts for the last two days and five hours. That's just what I have running. If there is load, meaning lots of people visit the site, right now it's not that heavy. But if people visit the site, what will happen is something I will now simulate. You will see that now. I will simulate that scenario. And what I will do is, let's see, Safari, and go to console.cloud.google.com. And there I will go look at that particular service and scale it. So I will manually scale it, but it should happen automatically when people visit the site. So you're looking at the services that I'm currently running. And the service I want to scale is this course book UI service, that service. And that service has a pod running, which is this pod. And so that is the current pod that you're looking at. This VPC, VX name, whatever that name is, is the one that you see here. Where is that? VPC, VX, the same pod I was talking about before. That's what you usually see here. And what you can do is look at its deployment. And if you see the deployment, you will find in the workloads is the deployment here. And in that deployment, you could take the action to auto scale. And you can say, you know what, make it a bigger number. And here I can actually, this is the minimum number of pods. I can say, make it two, so I will say two. And then I auto scale, can make it maximum number of pods to say 20. And so it will auto scale depending on workload. But to simulate that auto scaling, I just increased my minimum number from one to two. And what will happen as a consequence? You will see what I'll do that, by the way, I'm canceling it right now, because I want to show you that there is currently only one pod running here. This one. The name of that pod is this name. So just remember that name, VPC, VX, that's the name. It's only one running at this moment. The zero restarts for the last two days or five hours. And that has an ingress point here and a cluster IP. We'll talk about cluster IP also. But what I want to now show you is the idea of scaling. And I will simulate that scaling manually by looking at the auto scale action and increasing the minimum number required to two. That's a manual scaling, which is not strictly necessary because all these things scale by itself. I don't have to do it manually. But just to illustrate the point, I'm going to do this manually so that you can see what happens. And this number can grow to any number you like. So I can put it 20, 25, it doesn't matter. And then I say auto scale. When I say auto scale, what do you think will happen is you will see two containers or two pods running the same service. So I'll go auto scale now and you will see it visually. I'm auto scaling and you'll refresh to see that there are more pods popping up here. And let's go to the deployment. Go to the UI. Did it save or what? The auto scalar minimum replicas is two. It saved. And so yeah, here's a new part starting up. You see that it is currently yellow, meaning it has a warning going on that will automatically fix that scenario and you will have this running and this running both of them will show green color in just a matter of a minute. And you now have two automatically scaled pods and they have a common endpoint, internal endpoint. This is the service IP address, cluster IP address. And that is where it is bound to this domain inside. So now if you look again at the picture I wanted to draw when a user comes into this site B.A. whatever that domain is, it comes into the ingress point, which is this ingress, which is mapped to the service. It goes inside to a service first. That service has this internal name, an internal IP address, which is this endpoint. And that is where the service is mapped. If you remember and recall our exercise when we did this before, we had set a service range here. It's a secondary address range for services. We had said that already for us, that we will say our services will belong in this range. So remember that number, 1094018. That number is the range of services IP address. That's a cluster IP you will see matching to the service here. That you will see on the other screen as I switch away to the other screen by erasing my ink. But remember that 109400 here and then go back to here. And you will see that this is the IP address range that I expected. And that is where services get allocated onto a cluster IP for this service. That service maps to one and two, currently two. You can have more based on auto scaling. And this is where the user comes in through the ingress, goes to the service, and service then maps to the two pods. And these pods run the container that I have inside that pod. And you will now see that they should be green by now. So I'm going to clear it, clear my ink and refresh this page to say refresh. And you should see both of these are running green colored. And there they are two containers running green. And one of them was the old name, which was VPC VX name. And now we have a new name, a different container running zero restarts. One just started just now. This one is old, still running. And we now have erasing my ink to scroll forward. You will see that we have a min max relationship here, minimum two, sorry, minimum two, maximum 20 based on CPU utilization metric. And that scaling should have happened automatically, but there is not enough people right now on the site to make it grow. That's why I set this number to manually artificially to just illustrate the point that we now have two containers running. Having seen this idea, let's clear the drawing and go back to the terminal here and examine the pods we have running. And you will see that we now have how many parts for UI, we have one, the new one, and this one is the old one, so two parts for the same service. One started three minutes ago, the one started two days, five hours ago, the identical service. So from a user's point of view, you don't know which part you are hitting, but the ingress will handle that and the service will manage it. So having seen this, we now erase this ink and go to look at the deployments as to what is the other idea behind a deployment. So let's go K, get, deploy. And you will see that I have various deployments here. What does that deployment do from our point of view, which I just dealt with the coursebook UI, the main site, it has now two desired, two current, two are up to date, two are available for the last two days and 20 hours. So if I want to switch and change my entire website with a tiny little change, if I want to, I can very easily do that. And what you need to do is to look at this deployment and change the underlying Docker image. You need to change that image in the deployment and I will do that live as a consequence. You will see that the site looks different after five minutes, different. I'll point out what the differences will be very minute, tiny little differences I have made already. So you will see the differences coming as I change the Docker image. Currently Docker image is some number and I will put in a new number in there and you will see what you will see when I deploy a new deployment. And by the way, you will not notice downtime. I will change the website and you will not see anything going down. You can actually keep on hitting the website left and right, keep on clicking something on the website and you will not notice any downtime whatsoever as I completely change the everything under the hood. Like basically that's what I'm going to do right now. You will see me do it and you will watch that you will notice that you don't actually notice anything that is causing you downtime, but you will see that the site actually materially changes the change itself is very small because that's the change. It's just a small change, but I am actually going to change the entire image under the hood. You will now see me do this live. What I will do now is look at this course book UI and first of all, read its deployment description and then I will change the deployment image name and I'll see what goes on live. I will now change a folder where I have a readymade instruction to do how do you change the deployment image because I don't remember anything and I don't want you to remember anything. I want you to just focus on concepts. All these commands that I type, I don't have to remember because they're written down somewhere on the website or Google is there always. What I will do now is go to a folder where I have these things written down and list that out and how do I change the deployment image on the front end like this. All I need to do is to say kubectl set image for this deployment to a new image number. That's what I need to do. What I will do is run that command, but then this image number is actually a git log entry from the past. Let's see what a git log entry for the past was. It was this number. That was the number that I made a last commit on my git repository and built a new image. That is the tag for this image that gets loaded in this deployment. What I need to do is just change the tag that changes the image. The images that I currently have, the one I built last night was on Docker Hub. You will see that tag there. Let's go to Docker Hub, find out the tag that I currently have for the front end. Apparently, I updated that in 19 hours ago and the name is stage. That's the name. The tag name is just stage because that's the staging area which has it. I will use this new name in place of this old name I have. The old name is a96, whatever that number is, long number. That's the last git log entry. This git log format, whatever that was, when I ran that command, it gave me this number. That number matches this tag. That's the last tag that I have two days ago. What I want to do is use this tag. I will basically say kubectl set image deployment for this deployment corebook UI equals my name followed by frontend followed by colon stage because that's the name I want to use and I have currently this image. I want to choose a different image and that's the image change I will be now doing. Once I do that change, you will see the change going live without causing downtime. Let's go see that. How do you construct that command? You basically copy these things all the way up to here and say like this and say stage. What this will do is go modify the deployment in a live production setup and replace this tag, the old number, with a new tag stage and you will see that now. Right now, on this site, you don't see, I think you don't see something here will pop up. What will pop up? One of the changes I made in the last time was that you will see right above this, there will be some message here. Some new message will pop up here, like a chat message from somebody. You probably know them. That message will pop up. That's a test that I'm going to show you in a staging scenario. You will also see certain changes in this button inside if you click on that link. But that's just a change. I will now execute these changes and you will not see any downtime. I hope you don't see any downtime because downtime can happen. I'm not just bragging about it. I'm seeing that this is how it is done and see if it actually doesn't cause a downtime. I think it will not cause a downtime. So here, that UI, the Cloud Genius UI currently runs these containers that we have, these two, one and two, and they are both running the same image. The image they're using is this A9651, whatever that number is, that long number. That's the underlying image that we have the containers running, and that's this image. Same number. I will now change it. I'll set it to stage. So you will see now, set, image updated. Now let's see what the deployment is doing. And you will refresh and go to the deployments. And here you see yellow. You see that there are two applicas pending termination, pods have warnings. And so there are some warnings issued. Something is new running right now. This thing, pods have warnings, and you will probably see that it goes down to, I think it picked up the new image. I can see it. The new image picked up. The old one is still running. It will validate the new one first. It is still yellow issuing warnings. That has to run correctly first. When it runs correctly, then it destroys this one. Then the second one gets destroyed. You will see that happen right now as I refresh my screen. This one is currently yellow, it has a warning. The old one is running fine since March 2nd. And it has two pods running. This one has only one. So you will see that once the warnings finish away, that this will die. You will see that this new container number 579B will stay. This will die. These containers will also die. I think they're old ones. This is a new one. And that's the new container. So it is yellow. And now I will refresh because I think it should have resorted the issue that it has to check health for each of the pods that currently runs under the hood on the new ones. When the new ones become healthy, then it feels that, okay, it's good to try them out. And so it kills the old ones. So that's what you will see now when I clear my ink. And I will refresh the page. And you will see something now. And what do you see? Well, you see that the new ones have taken over. And the old one is gone. The stage has taken over. And we have three pods currently running. And they are all new. But why are there three running? There should be only two running. But apparently it updated to three. Probably because you guys are hitting the site. Maybe that's the reason. I don't know why it scaled out a little bit bigger than the number two that I wanted. Maybe because it hit the target utilization on the container. So it thought that there's a need for one more. So it just grew. But we have three containers running almost at the same time with this new image that we have just deployed. And tell me if you caused a downtime. Did you see a downtime? I bet not. I bet. If you saw, just tell me that you saw notice downtime. We just changed the entire application image and let's go see it. Let's go see the site. So you will see the site. You have to clear your cache if you, maybe, maybe not. Maybe not. Maybe you don't have to clear the cache. I'll just examine the site here and I'll point out the changes. I'll go to the front page and there is this thing that I mentioned here that you will see is a test. This message about the message that is a new addition that I just put that in stage. That was a chat message coming from Kara South. I don't know if you know her, but that was very nice. And so very beautiful commentary here, so I thought I should just let the world know about it. And so that's the change that I made. You can reward these changes very easily, very effortlessly, again, without causing downtime. You will see that how you do it. I will now show you that idea. So here you saw me do this image change by setting a different number as opposed to the old number. Now what I will do is see how we can roll back. Oops, I made a mistake. Say if that happens that, oops, I made a mistake. I want to roll back. How do I roll back? Well, you first check the rollout history. How do you check the rollout history? I don't remember. So I have a shortcut for that. And rollout history is this how you see it. So you say K, rollout history and deployments, and then the deployment is course book UI. Show me the history of deployments. So I see that there are these deployments that I have. So the last one I had was this number. So I want to roll back. How do you roll back? You say undo front end. So the front end UI that I have, I can undo. So the undo command is written in that script. Undo front end is how you do it. This is how you do it. So all you do is say K, rollout, undo deployment.v1.apps slash course book, course book UI. All these things are documented in Kubernetes documentation on their site. So you don't have to remember these things. There is no point in remembering because you just a Google search. How do I undo the deployment? Google. And you will find this answer that I just have it saved in a file like that, somewhere in my folder. So I do this every single day. I just say undo deployment, undo front end, so it just undoes the whole thing. So as an undo, as I execute this undo step, you will see what happens. It rolls back. What does it do here? Well, it will go back to the old image. So let's go refresh and you will see what's going on is that it is trying to load the old image right there. And the current stage image is running, but I rolled back. So now the old image is put back in place and boards have warnings. So it is waiting for that to settle. And once it settles down this image, then it will kill this image. Roll back. So even as I ring that image, stage image will be dead. The new ones running this image, the old one image, the stable image that I wanted to keep live, did not actually want to go stage yet. I'm not ready for the stage to go live. So I just showed you the staging of the quick demo. But the concepts where I'm really trying to drive is you can change the entire application under the hood. Doesn't matter. The users don't even notice. And if you did notice, please tell me that you noticed some downtime on the site. And I think I told you to go hit and you probably hit. And that's the reason why it probably scaled. And so currently it is like one updated, four ready, three available, one available. And that's what's going on. So you will see that as I refresh my screen, it must have happened, you know, correcting the warnings and this one is probably active, this one is dead. And so you will see that happen as I clear my ink and refresh the page. And that's what you will see. It is still has warnings. And so it is doing something apparently, let's go figure out what it's doing. And so it does not have minimum availability. Okay. Pods have warnings. Well, the site should be functional. Let's go check the site. This warning happens. The site is functional. We have, I think one of the pods is causing warnings. So let's go see what's going on again, refreshing the deployment details. It should handle itself. Yeah, it handled itself. So you can see that the course book UI is currently running four containers now. Okay. And that's fine. So four containers and they are using the image that I expected them to use, which is not stage, it is that number, which is the final get commit that I wanted to use. And so that is not the staging deployment. So it basically came back and I have four containers running. They will probably go down to two containers at some point once you stop hitting them. And so that is what I want to also show you, but I probably cannot demonstrate that live because you'll probably keep on hitting the site. So it's going to stay like that until I deliberately scale it down. Let's say minimum one and maximum three and say auto scale. So it will shrink it down to three. Right now we have four. So I'll force it down to three and, and contain it and limit it to that number three as the max. So you see that I'm going to auto scale that. And I did one of these three or four containers will die. Which one? I don't care. But one of them will die in a matter of a few minutes. The three parts are warnings. One of them is getting dead. They're getting, they're killing it. This one is getting killed because I set my constraint min max one three. So that constraint is put in place and that's the underlying idea behind running, you know, one image and iterating on it in its various flavors. So you can change the code, create a new image, push it out and roll back, undo the deployment. If you don't like it, things of that nature. So now let's recap what we just discussed and do this on our own in other contexts with a slightly more involved example. This was just the front end portion. So now I will go back to the white sheet of paper and erase this red ink and scroll a little bit here. So now what did we just discuss is the idea that we have a user who visits a domain name that reaches the ingress point. The ingress point hands it off to a service point and service, you know, connects to a multiple pods, the same type of pod in multiple copies. Any number of copies limited to whatever number you set, the min max limit. And this is where it will automatically act as an arbitrator and allow traffic to be spread across multiple pods of the same type, like that, any number. And that limit is what you set in your budget, basically, it's a budget limit. How much money you want to spend on this thing. That's the kind of budget. Now these are pods, the pods together constitute a deployment. Pods can contain containers inside, C1, C2, like that, or in my example, the one I just showed you, it's only one container, just one in that pod. And this constitutes a deployment, you have to map that to a service and associate that service to an ingress with a domain name to make it work for the user. Now all these scenarios you just saw, they all, to begin with, work with port number 80, so HTTP protocol. But you want to make sure that you redirect this traffic to HTTPS. And that redirection needs to happen automatically, and also a certificate needs to be issued for TLS, for that site, for this domain automatically. And this automation happens through a set of containers that I have deployed already that you will see now. I will now switch my screen to show you that. The second idea that we have, the next idea we are beginning to discuss is how do you automate certificate handling, because without a proper certificate, you will not have service that is actually useful. So here, any of these sites that I mentioned, by the way, let's go refresh this and it should die down to three containers right now, those three containers running, give me just a second, I need to close my window here, it is getting chilly. I was sitting in the sun and now the sun is gone. And now it's very dark suddenly, apparently. And I don't pay attention to that, but I need to switch the lights. Okay, come on. My lights are not responding, whatever. So let's go look at the HTTPS scenario. So the HTTPS scenario is implemented again in form of a bunch of containers. And you will see them in the cube system namespace. So I just threw another name at you called namespace. And so namespace, I think I mentioned this already in the last session. We called out namespace as a collection to segregate production and deployment and this and that. And so production deployment, staging deployment, testing deployment, this deployment, that deployment, so it's a namespace. So what you have in Kubernetes is a different namespace called cube system, which is the system namespace. And here you will see that there are certain pods running that handle the idea behind getting me an SSL certificate. And where are those guys? Where are you hiding? Not in the view, okay. Maybe not. Maybe I'm in the wrong section. So let's go to the pods, and there we have the cube system pods, and let's go see all of them, pods, all namespaces, and here we should see them all. Where is it, there, yeah. That's what happens if you have too many things running. So there the cert manager, this pod, cm cert manager, that's the name of the pod. So now in order to understand what that thing does, let's go first of all to the cert manager github page. And so that cert manager is from this team that creates the product to get you automated TLS certificates. And so this is the collection of services and pods that you have to run in a Kubernetes cluster to get you automation of TLS certificates, and it's very easy to run. It might look kind of, you know, kludgy and lots of details and all that, but I'll simplify it very, very easy to get this to work. What you're really looking at right now is a Git repository containing this product called cert manager. And this automatically provisions and manages inside Kubernetes. So here you have to define what do you want to run and what's the DNS name for that. It is specified DNS name. So I have say chat.cloudgenie.us as the domain name, and you'd also make sure that it maps to the correct IP address, the public IP for the cluster that you have. That needs to map on a DNS level. Once that mapping is done, then you go run this product in your cluster. And it takes care of the whole thing. And yes, this is code, but it is already built in form of another image. You just take that image and deploy it. And then it does this thing for you automatically generates certificates, automatically renews them every three months, two months, or whatever the time period is, I think it's two months. And so a certificate is issued for three months and this thing renews it every two months. So you already have a validity of at least one month going forward, going in the future. And that's the concept behind this is a properly maintained service, lots of forks. You have good people behind it that maintains it and it is open. And that is natively supported inside Kubernetes. So let's see how you implement this. So we will now scroll and see what the concept under the hood is. So here you have to have, first of all, an issuer of a certificate. An issuer of a certificate is somebody like Let's Encrypt. So you already know them. You have this agency that called Let's Encrypt Staging, Let's Encrypt Production, or other services that you can use. So I think we are going to focus on this service called Let's Encrypt Production Service. And that is where this certificate manager deals with. That's a company or agency that provides you certificates in production usage. There's a staging also provided. This is for testing and staging certificate. If you're testing it out, there are some relaxed limits, relaxed limits for testing available here. They're not good for actual production usage, but it's good for testing and staging deployment. So you can use that if you're trying it out, but when you're ready, use this. The search manager connects with Let's Encrypt and gets you a certificate, for example, this domain that you have. And so it will get you the signed key pair, and you can put that as a Kubernetes secret in your cluster. And Kubernetes will automatically use that secret when a user wants to go to foo.bar.com. Same thing here. You want to go to example.com and www.example.com. You want to get a certificate from there. By the way, these names are reserved names. And so they're not actually available to you, but you can substitute that with your own domain name. And so when you have your own domain name here, you can ask search manager to get you certificates. So it can get you a signed key pair from Let's Encrypt provided your DNS name maps correctly to the IP address of the cluster. So this DNS name that you have here needs to correctly map. And then all you need to really do is run this image that is an image ready, available on Docker Hub. And we'll read the documentation now. How do you run it? And the certificate will get created and it gets stored in a secret inside Kubernetes. And that's where Kubernetes will know to use the correct TLS certificate for an ingress request. Anytime anybody requests for an ingress, you will see the search showing up. Having discussed this, I will now read the doc a little bit and get to understand how do you deploy it. So docs can be daunting to read, honestly, mostly all open source products, the documentation is not the best because people assume that you already know what you're doing and they just don't bother describing occasionally. But sometimes documentations are actually good. For example, this one, installing the certificate manager, how do you install it? There are ways to do that. The easiest way to install is actually using Helm. Helm is another open source product and this thing gives you a one line command to install the whole thing. Where is that? Actually, there are four lines. Yeah. So there are the steps, but let's go understand what Helm does by the way quickly. So Helm is a tool, Helm.io, I think, oh no, Helm.what, Helm, just Helm, search. So Helm will pop up, Helm.sh, that's the website. It is a package manager for Kubernetes. So like, you know, sudo apt-get install this, apt-get install that, yarn install this, npm install that. Whatever these commands are that you install packages on your software, on your laptops running Linux. That's a package manager. Like, for example, in Macintosh, you will see that you want to install some package. Let's say, you know, I want to get the wget package, I say, brew install wget. So it will install wget for me. It's going to do that right now. And that's the package manager running. It's going to update homebrew and get the wget package and install it here. And then we have it. We have wget at that stage. Right now, I don't have it. So it's going to, so it's already installed apparently. It installed wget and said, you know what, I have it already, you want to reinstall, you can reinstall. So that's the package manager in action. That was brew for Macintosh, like apt for Linux. And this Helm is for Kubernetes. So you deal with the whole cluster as if it's one unit. And you say Helm install blah, it will install it for you. So you just saw brew, this thing that I just showed you is a package manager for Macintosh. That this thing is the package manager. It is also open source, by the way. So this is the best way to install packages on Mac is this. Not what Apple tells you. This is much better, much cleaner. And we'll talk about that later when we are doing a Mac session. But right now, Kubernetes, Helm is the way to install. And let's go to my cluster and see what I have installed, Helm LS. So it'll show you a list of things that I've installed already. And here you will see that I have installed three things using Helm. And those three things are CM, the certificate manager. It was installed on December 5, last year. It is running in the kube system namespace, the Kubernetes system. The second package I have installed is nginx ingress. It was deployed as late as I think last month, like a few days ago, because I updated that package to the latest version. And that is the Kubernetes ingress package. And the third package is something that I also deployed. This is a custom package built just for Google Cloud. It is a security technique that Google enforces on you. If you want to use SQL server, then you have to go this route. So it's just something that is unique to Google Cloud that you have to have. The point is, I need a MySQL server, but I don't want to manage it, don't want to manage. So what I do, when I don't want to manage, I rent. But I rent from where? Well, I go to Google, say, hey, Google, can you rent it for me? I want this. So they say, okay, take it. And they give it to me, but then I have this cluster, Kubernetes cluster. And they give it to me outside the cluster. So well, now I cannot go there. But I want to use it. I rented it from them. And so inside the cluster, I cannot go to this, this is like outside in some other part of the Google Cloud. And this is like isolated, everything isolated about Kubernetes. You can do nothing with Kubernetes if you don't have access to it the proper way. It is so strict that you can do nothing. Without following their methods of security, you cannot go inside your own cluster. It is so difficult if you don't understand the access patterns, I will walk you through them later on. If you don't understand those details, it is impossible to get in, impossible to get out, impossible to run anything. That's one of the biggest stumbling blocks about Kubernetes is so secure that it's so hard to learn. And that's where people struggle most of the time, by the way. Just want you to know that that security pertains to Kubernetes is so strong and very difficult to wrap your head around is that that's the reason why people struggle most of the time is to just get this to work for them. That's the beginning stumbling block, security. So I am here, I'm running my pods, and this pod, and that pod, and this pod, and you know, like that. A bunch of things are running and all that, but I want to access this service, which is outside. And so I want to get the MySQL server. I cannot bring it here, Google will not give it to me. So what I do is I set up this new pod. It is the Google Cloud SQL proxy pod. So it makes that thing appear here. It's just an appearance of that thing is here. And there are lots of security things going under the hood to make this happen. And that is a readymade image provided to us by Google, that Google handles the security related details behind it. But it makes your outside resources appear as if they are inside here. That's the only reason I have that custom deployment to access a database that I don't want to bother managing myself. You know, it's a hassle. I have it. I have, by the way, other databases running here, Mongo database is running here. And this cloud genius site actually connects to the Mongo server. And you will see that also in another example, as I will describe it. But this thing, you can also get MySQL to run here, very, very simple. But I just did not want to bother managing that setup and database backups and all that. So I just said, yeah, I'll pay you money. You rent it. You run it and rent it to me. And then they gave me outside and I said, oops, how do I get it here? I want it here because I want everything inside my cluster. So they said, okay, use the proxy. So the proxy makes it appear as if it is local to me. That's the point of that third item that I have in my Helm listing. So now back to our insert manager. This is deployed and running. And it is, by the way, runs beautifully. It has never given me any trouble. To get this to work correctly, you have to follow these instructions. Which ones? These ones. The first is to get a custom road resource definition resource created. What is a CRD resource? Custom resource definition. That's a way for this particular product to create a separate resource. Like a new resource gets defined inside, by the way Kubernetes lets you define resources. And what is a resource? Like k get p, sorry, k get p, what is a resource, pods, a resource, k get svc, service, service is a resource, k get ingress, ingress is a resource. So k get xyz, well, xyz is not a resource, so it doesn't know what to do with it. But k get crd, that is a newly created resource just by the insert manager. So you see there are certificates stored in here. And those are, no, they are not certificates, they are custom resource definitions. So one such custom resource definitions will be certificates. And that's where I will be storing my certificates in that custom resource definition. So it's a CRD is a new type that I need to create for me to store my certificates inside using search manager. That's the action that you will see when you run this resource creation just for search manager. Once that is taken care of, then you create a namespace for search manager. This step is optional, by the way, I did not use that step. I just use that kubectl default namespace. If you can see my k get ns, sorry, k get namespace, you will see that I have only three namespaces or four namespaces, default, public, system, and this new one called weave, which I just installed to show you the visual interaction with the cluster. I don't have this extra namespace called search manager, because I don't have to, because I did not bother. You can actually skip that piece. Then you can label the search manager namespace to disable resource validation. I think I did not have to do this. I don't remember doing that. That's potentially a unnecessary step, but I don't know. I don't recall doing that disable action. Then you update your repository. This is like sudo apt-get update scenario, and this repository for Helm charts or the sources that gets installed is stored in helm.sh. Here you will find there are lots of charts. If you know navigation or ocean exploration, you will probably already understand the word helm, and there you have the thing called charts, which is also navigational terms. Something to do with navigation. I don't understand these ideas much like a Navy person, like a military Navy or a captain of a ship ideas. I don't understand those things, but I think that's where these names come from. The phrase helm, the phrase chart, they come from some kind of naval aviation or naval, I don't know. There is some correlation between the word helm and something to do with the ocean. I don't understand it, but I do understand what helm is and what a chart is. A chart is basically a package that you install, and here ready-made package is available. Bunch of things already available, and by the way, this is the best way to install applications on a cluster, a Kubernetes cluster. Discover and launch great ready applications. That's the point. Here you can search for search manager, and you will find there is a chart. It says no chart. How come there is no chart? There is a chart. Let's go see stable and cert, certificate, no, there it says stable chart manager. That's the chart you want to install like that. Just run that action, it will install the chart. What it actually does under the hood is go to Docker Hub, and there you will find there is probably an image corresponding to sort manager. That's the image it will take and run it for you. That sort manager Docker image is, where do they hide these things? The jet stack. Okay. Jet stack is the name of the team that creates it. Jet stack, sort manager, okay, jet stack, and then show me all your images. Oh, man, it creates so much. And hide it. Where is the sort manager image? Come on. No, they don't want to show it to me. I'll do Google search. You will find it there. Definitely find it. Google sort manager Docker image. And that is this. And so that's the sort, they switched it to Bitnami company. Apparently so. Apparently the management of this sort manager image is with another company called Bitnami. That's the image. And that's the image that I think the chart uses. The source code is from JetStack, but the image management happens from a team different from JetStack, and that is the Bitnami team does it. And so you have to install this Docker image, which is built using this source code, the same JetStack source code that you saw before. And let's go see live. What does that do for us when you deploy this? So when you go to our cluster in the production cluster that we have here. And let's see what workloads we have that are running the sort manager. And those are hidden currently. So you can see that they are a system object and I have labeled system object false. So any system related deployments are not visible to me right now. So I will skip this false and then I'll see a larger number of deployments showing up. And one of them is the sort manager deployment. And that deployment is running, chugging along for several months now. And this uses the, okay. So the image is actually stored in a different location, not Docker Hub. You can see that it is stored in Quay IO. And what is Quay? Quay is from another company called CoreOS that got acquired by Red Hat, that got acquired by IBM. So this is now IBM. And this is another Docker Hub. Think of it as a Docker Hub. And here you can also search for images. So image, sort manager. And that's where you will actually find the real image that I think the help chart has. So here is JetStack sort manager controller, sort manager webhook, and all these images are available from this location. Sort manager controller is the name of the image. And the current image that we have right now is the version. What's the version number? Docker pool doesn't give me the tags. There are the tags. The tags are 12 hours ago. We have a tag name that is the manifest. But what's the tag name? Do they not go by names anymore? Apparently so. They occasionally use names. Most of the time they use git hashes, but sometimes they will use a name. Just like I showed you the name stage versus a git commit hash. So let's see the latest release is... How do you find the latest? 10 days ago, canary is not what I want. Canary is like an early warning image that people build to get some early warning of what is coming down in the future. If they create a future image, they will put that name canary for that to test it out. So I think the stable image is not beta. The stable image is not alpha. It is not alpha. They don't have a name for it, which is very strange. The tag history, and we go down the history and you will find that they don't have a stable listing. They have to go further down, I guess. And they don't have any further history beyond that, which is kind of crazy. But there is a version six, so they don't show it to you, whatever. It's there. It's not visible, but I have pulled it. And you can see that I'm using that image in actual deployment, version 0.5.2, December 5, 2018. That was the search manager image that I have deployed. And it came from this help chart that you looked at early on. Where was that? There's help, help, there. And that is your help repo, which actually brings down all the packages. And then the actual action to install is like this. Help install certificate manager in the namespace certificate manager, version number, and select the stable chart. That's what actually happens. You can run these on a different cluster. I cannot run these directly on my production cluster without testing because I might disturb these certificates that I currently have running. And so that is a valid certificate. It's a valid system. I don't want to disturb that in a live production system. And that's why I am not running these steps. You can totally run it on a test cluster and experiment with that because that will help you round out the missing pieces that most places don't describe these details in terms of how do you get a proper SSL certificate, which is what I'm talking about right now. You have to do these steps in order for you to get a TLS certificate for your domain and map that to the IP address. Then users will come here with HTTPS and they'll reach the ingress point, which will go to service, which in turn will go to your deployment, which will have a collection of pods of the same type, any number of them, and they will internally will have containers, any number of them, depending on what you define. And that's where this deployment will scale and your customers will continue to access your services. That's the layer of abstraction that you need to have. And you have to do these things one time for a cluster so that it automatically generates certificates for you and puts that in the right spot for the cluster to interface with a browser and shows you the right certificate every single time you deploy a new site. That certificate creation is automated like this. Having seen this, what I would like to do now is let's experiment with another cluster and actually put an ingress in place. So I think we can execute these steps, but we need to have a separate cluster. For that to happen, let's see if we have a cluster that we can bring together quickly and we'll run these. So let's see if we can put an ingress in place, ingress with the proper DNS and all that, which takes a little bit of work, but I think it is important to understand these details as to how do you make these things actually happen for a real example. So what I will now do is go straight to the point where we can start a cluster. So you will see that here I have that page on the left side, which tells me how to instantiate a new cluster. Let's see if we have a K get PO currently running a cluster. Apparently I don't, which means I need to log in. So K, no, not K, it's gcloud auth login. It will start a browser and then I will log in here and I'll say, are you, am I logged in already? Apparently so. So I just click my name and it logs me in and so I say allow access and now I'm logging into the terminal. So I apparently logged in successfully, which is nice beauty. So now I have logged in and it tells me that I'm logged in, which is awesome. Now let's see, we can actually create a cluster. So beginning with these steps, first of all, get the public IP address for my location and then get the project name for my account. So I have those two. I will now verify the public IP and it is correct. I will also verify my project name, which is also correct. Now I can set a cluster cluster setting up is like this. So simple copy and paste. Now you have a cluster in two minutes. There it goes. So it just sets up a new cluster, but it doesn't have a network, right? So we're missing some network steps. So the network is not valid. So I had to go scroll back and actually create these firewalls and cluster. The network has to create, which I think I don't have because I destroyed the whole thing. So here's a VPC network. You can create G cloud compute network, create like that to create a new network. So we are basically beginning with a new cluster. We have a hold on. What does it say? Cluster. Something already exists, US central one. Something it says already, it could not find the resource already exists. Okay. There's a network or cloud genus already existing here. Is that what you're telling me? I think so. So let's go to the browser and find out what do we have there? Apparently there's a network already existing. So go to console.cloud.google.com where you will find, hello, respond, please. Hello, Google. Why are you slow? Okay. So let's go see the network in navigation, VPC networks. See if we have a network there by a different command in the past on that. That's what happens in a stale account. If you have a fresh new account, you don't have these problems. And so let's see in a VPC network, do we have a network like that already? We might. And so apparently there is a network here. And so I need to destroy that network is not what I want. I want the one created by me in my region of choice, not in that location. Apparently that was in some other location called central one. I don't want it to be in central one. I want to be in the region of my choice because all other commands that we have are written down in... So I'm deleting that particular cloud genius network, deleting it, it's going to go away. And I should not have any other things in my setup, so no external IP, no firewall rules and no routes. Routes are probably still there. They're dying right now because the VPC network is dying. The routes will also go along with it. It is getting killed. When this gets killed, I will now create a network in the region of my choice, not in that location. And I'll also create a subnet that will handle our pods and services. That subnet creation is somewhere here written down. Where is that? I need to do these things also, I think. That's the reason why we ran into that problem is that I am skipping ahead and I skipped these steps. So gcloud config set, compute zone, and new behaviors, those pieces I think I was missing. Let me just finish those pieces quickly. So project create, we don't have to do that. We have to set the project configuration, which is what this thing is. We have to set the zone selection, and then we have to select this compute new scope behavior. And then we say, choose my region as West1A, choose my zone as West1A and region as West1. And then I have my project name already selected. And then I have my public IP already set. My old configuration, if any, is deleted. My gcloud config list shows me the configuration I want. And now I can establish a VPC network, which is this. And then I will enable billing and create firewall rules like this, one, two, and three. Three rules I'm going to create. They will show up here. So currently the new VPC network is getting created, it will pop up right there, and it's popped up. I will now create three firewall rules for us to have the cluster operate correctly. Without these things, you will not be able to go inside your own cluster. And that is something that I want you to pay attention to, the creation of firewall rules, which needs to happen after this action to create a network. The network is called Cloud Geneside and Net. So the three files I will now create, one, two, and the three, the third one. These three are basically allowing a ping, any to any ping, allowing access for any machine to any machine within the cluster, and third one is allowing access for me from my location to the cluster. So the second rule is putting in place, the third rule is the one that allows me access to my cluster. And that me definition is in that my CIDR variable that defines my current public facing IP address. And that is what is a critical step for you to allow access to yourself, like that. And so that third firewall rule is in place. We now are ready to carve a subnet like this, and that carving of the subnet will happen and will show up here in our listing here, currently doesn't exist. So you will see that happen and show up as soon as I finish that command creation command, which will create two subnets, one, sorry, one subnet with two subranges. So this is the subnet called CG, and it will have two secondary ranges, one for pods, one for services. The pod will go around 1032 and services will run 1094. But that is now created. And so we will now bring the cluster up. Now the cluster should succeed. The cluster will come up now like this. And so we'll verify this creation of a CG subnet in here. As soon as the command finishes, we'll go to the browser refresh and see that there is a new subnet with a secondary range for pods and a secondary range for services that will show up here as soon as the command finishes. And it is doing that right now. And so once it finishes, I will go here and see that I have a new... Come on, Google, why are you so slow today? Hello, Google. This is the part I dislike. I don't like to wait for clouds. I would rather not. Okay, come on, show me the VPC subnet called CG. Yes, right there. Here is the VPC subnet that we created. It has a pods secondary range and a services secondary range that is created. Having seen that, we are ready to start a cluster. The chat message, patience is a virtue, not with clouds. Patience is not a virtue. Patience is virtue with people, not with machines. So I am patient with people, but I'm not patient with any machine. I don't tolerate that nonsense. One of the reasons I don't use certain clouds is because they suck. They're so slow. I need to have the cloud respond to the way I talk. If I say something will happen, it should happen at that moment. If it doesn't, the cloud sucks for me. That's how it goes. Today, this Google Cloud is not behaving properly. It repeatedly happens. I will stop using it. It needs to respond in a predictable manner every single time. If I say that this will happen, then it should happen, and it should happen in the time in which I finish talking about it. Otherwise, I'm waiting, and that is something that I don't like. But sometimes you have to wait for this cluster creation idea, which is like a gigantic step. By the way, if we do this exercise manually, do the whole thing, it'll take six hours. I'm just kidding. Three hours. It takes me three hours if I describe the whole thing and talk you through the concepts of building everything from scratch. That is a separate, intense, painful exercise. It is called... It is painful, by the way. It is called Kubernetes the hard way, and that is this exercise, and it is actually a fabulous exercise, and nothing is automatic. Absolutely nothing is automatic here. It says bootstrap Kubernetes on big machines, any cloud, any machine, wherever you have. Bring your own machines from eBay and put them together in a physical cluster on your desktop, on the tabletop, and connect them together this way. That is also... It works. Just bring machine from eBay, and just assemble them together, and put a cluster of machines, and run through this set of exercises with no scripts. Every command you have to manually type, you have to understand the whole thing. This exercise. By the way, it is extremely popular, even though it is hard, there are 14,000 stars and 2,597 forks. It's a very popular exercise. People do this. I do this every time I run the bootcamp, unless you say no to it, in which case I will not, because it is intense, and I will still do it unless you prevent me from doing this mechanically boring work. It is mechanical. Most of the time it is copy and paste. The copy from here, paste it there. That's the actual action, but that's not the point. The point is that we are understanding this step-by-step process. How do you build a cluster from scratch? What does it take under the hood? What is going on? What's the magic? You see magic happening, and I'm showing it to you in a live production, and I'm now going to show you the same thing in our newly established cluster, which is getting ready. The master is healthy, and soon the nodes will come up, and the more the worker nodes, and then they will also become healthy, and that will behave like magic. But it is not. It is this. This tutorial helps you understand that. So if you are into Kubernetes, and if you really like the product, and you want to go further in that direction, you should ask for this, the hard way. It is hard. So ask for it. I'll do it. If you don't ask for it, I might skip, honestly, but I'll let you decide. Just one of you, if you ask, only one is what I need. If one of you says, please do this exercise, I will do it. Having said that, let me give you a link, so you can read, and you can say that later on. You don't have to say right away. So read about this, and tell me later on whether you want this to be done, because it will give you perspective on what does it take, prerequisites, and this is going to cost you money, like $5 per day or something like that. And there are $300 free coupon available. So basically, step by step, nothing is scripted, you have to understand every single thing and move along. So by the way, the cluster is ready. The cluster ready means we can go to a browser window. That is that browser sucks. I'm going to close that browser window here, and we're not going to use the same, open the same window in a different browser here on the real machine. So let's see if I can open that one, and here I have the VPC network, and oh, you know what? That cloud genius VM sucks. It's not Google. That VM sucks. That's why it is slow. The browser and the network on the workstation, the cloud genius workstation, that is slow. So I should not be complaining about Google Cloud. I should be complaining about cloud genius VM. I mean, VM in general sucks, any VM sucks, just a matter of fact. The VMs are slow, and that's what I was running into. I was trying to use the browser window, and it's just horribly slow, and so that was the problem. Not Google Cloud. Google Cloud is just fine. See that? CG shows the range, shows the network, shows you the cluster that we just created. Cluster we created is called Android Meta. It has three nodes here, and it has a pool called default pool with a minimum of one and a maximum of 11. That's the three node cluster we just set. What I want to do now is set Helm. I want to begin from the beginning point. I want to let people inside the cluster. So let's first of all set Helm, Helm.sh. How do you set it up on a VM? Let's go follow along. So we'll go see here, how do you set up Helm? Let's say get Helm, and so how do you set Helm on installation, Helm client, desired version, and then unpack it. So we get the desired version. The version is 213.0. And so I want to get that package. How do you download it? So you get the release of the package, and I think that's the download link, right there. This should be download link. Is it? Is it a download link? No, it is not. So where is the download link? There. Here are the download links. So download 213.0, you have to get for AMD Linux 64-bit, that one, AMD 64. So copy the link, and download, like that, the downloading, now have it now, locally. And so once that is downloaded, available, I need to expand it and install Helm. So Helm is the beginning point for us to install our certificate manager and our ingress. Once those things are set in place, we should be able to just easily deploy any services inside. And that's the beginning step, Helm. Now let us see if we can get, by the way, these things are also written down somewhere on the website. So how do you install Helm? Is it written down on somewhere here, maybe, where is the website? Go there and search for Kubernetes, and there is a result. And you go search for Helm. Now this one, CI-CD setup, this one is TLS protected services. What is this? Ingress. Okay. And so we have that written down here. I think we did cover up to this point, volumes, namespaces, the last time. I think, I don't remember where we were the last time, head checks, service discovery. I think we were somewhere here. And what we are really talking about right now is at this step about ingress. So to get our hands on ingress, we're going to set up NGINX ingress as an example, which is what I will be doing. So we set up, we have a cluster running. So provision and ingress, we'll be using this ingress. And before beginning, we connect to the cluster. So we'll do that. And first of all, set up Helm. The Helm is available now locally. We'll install Helm for which you have to go to the Helm exercise, where is Helm.sh, here. And get Helm is these steps. So you binary download, then you unpack the binary, add it to your path and you're good to go. So the binary is now locally available, that is this binary, and I need to unpack it. So I say tar extract that file called Helm, so it extracted like this. The file is now available locally, it is called, what is it called? I think inside this folder, let's go inside that folder. And what do we have? We have Helm and Tiller both, there's a Helm command and a Tiller command. Tiller is the corresponding cluster side component for Helm. Again, it's also a navigational phrase, which I don't understand what Tiller is, but I know what Tiller is. I mean, in this context, I know. In navigation context, I have no idea. And so this Helm and Tiller are both commands, we need to move to our application path and execution path. So that's what I'm doing now. I'll grab these things and move Helm to the user local bin. But it is a protected path, so I have to go sudo. And then type the cloud genus password. And cannot move. Okay, I should say dot slash, this file, yeah, move it. What do you mean cannot move? You have the file there. And so move that file sudo mv Helm to this location. You are the typo. There was a typo here, use, it should be usr, usr slash local slash bin. Now it goes and similarly sudo mv tiller slash usr slash local slash bin. So now I have two commands running, one is Helm command, and the other is Tiller command. So what I will need to do is, first of all, check our cluster. So okay, get nodes, how many nodes I have? Three. Now I need to install Helm on the cluster, the Tiller component needs to be installed on the remote cluster. So we'll do that, Helm initialize. And let's go read the doc. So getting started guide should tell us exactly how do you follow that. I think it is installing Helm is Helm init. So I also cross check with my website, I should have some instruction there also. So let's go check that. Where is the site? Here and where is Helm? Install Helm, that was the easier method in my website apparently, but just one liner gives you Helm. And so that was an easier method to install Helm. We have to say, first of all, installing Helm is the hard way I did it, which is the one I just did. The easier way is right on my website that I forgot about, install Helm, it's just one line, is that one line. I have scripted all these things for you. And so you can use that method, install Helm, the easier method, just one liner. Having seen this, I will now have to go create a cluster role binding. And these are the issues that you will now understand or start to understand what I'm talking about is the ideas about security in Kubernetes. So everything you do in Kubernetes needs to have a role as to who's doing, what is that thing doing and why should it be allowed. For every such action inside a cluster, you need to have a service account and a corresponding role binding that will allow access based on role. So this idea is called role-based access control, RBAC. That is for every single thing in a Kubernetes cluster, you have to have an RBAC property set. That property is what we are setting for our tiller. And so what we are really creating is this service account and a role binding in our cluster. We are going to create that using this action. And once that is created, we will then be able to install Helm on the cluster. Without that creation of this step, you cannot do this step. So you have to have a service account and a role binding for role-based access control on your cluster. If you don't have it, you can run these commands. It will not work. You have to provide permission for every single, you want to move something from here to there, you need permission. That's how strict Kubernetes has become. And you can blame it on these guys, which is actually a good thing. You can blame it on RBAC controls. Every single thing requires permission with a service account. Otherwise, nothing will move. Nothing will work. Just want you to realize that this is the stumbling block. The biggest stumbling block for new learners of Kubernetes is RBAC. You have to pay attention to it and watch. What I'm going to do now is to create a role-based access control for our Helm and for the tiller to work correctly. So that's what I'm going to do right now is apply the tiller, RBAC, YAML. So we'll go look at that. First, let's go examine that file. That file is available here. And so this file, what it does, it creates, that's the YAML file that we are going to create a service account for tiller and a role-based authorization, cluster role binding for tiller. So these are two parts. This is part number one, which creates a service account. And this is part number two, which creates a CRB, cluster role binding, both for tiller. Tiller is the server-side component of Helm. So that's the YAML file we are applying to the cluster, which will create one and two. That's what I'll be now running. And the action to run is apply that file. And that goes like this. So when I do it, I now have a service account for tiller created and a role-based access control for tiller created. Now I can actually use Helm without this action, without the proper authorization for role-based access controls and having a proper service account for any service, the service will not work. Nothing will work. Having said, initialize Helm and use the tiller service account we have in place. So the service account I want to use is the tiller account, which I just created, and initialize Helm on the cluster. And if you already had done this before, upgrade Helm on the cluster also. In the cluster, if you have Helm already, an older version, and you now have a newer version of Helm, you want to upgrade that. So here it goes. It will go create these things on the cluster and report back success, and it did. And so it said, happy Helming, which means it has succeeded. So we can now use Helm to run arbitrary applications that we feel like on our cluster that we have running here. And we have Helm running, which gives us a great level of flexibility. So now let us see what we can do to get our Nginx ingress installed, so the ingress route, which is letting us get inside. To get inside a cluster, you need to have an IP address. We don't have one yet. I mean, we have IP addresses, but they are not externally accessible. We have cluster and we have three machines. Each of them, they have IP addresses. You can see the IP addresses here. And yes, you will find that these machines have IP addresses and they are external. But if you try to ping them and try SSH, nothing will work because they are protected. Nothing is open. What you need to actually do is to get a external IP address, which is different from these three addresses. You have to actually get a static IP address assigned. In Amazon's language, they call it elastic IP address. In Google's language, they call a reserve a static IP address. That's what we'll be doing now, but without using the browser. So we're not using the browser. Instead, we are going to create a new elastic IP address or a static IP address like this without the browser. And so that's the action here is you wait 60 minutes for Tiller to settle down. I think Tiller settles down by now. And so we then sleep 60, which is kind of pointless. We slept 60 seconds already because we are talking about Hellman Tiller and all the things. So we don't have to skip this action. We can skip sleep action. We can just export these things. So let's see what we have here. That export action will try to gather gcloud compute address list. So what are these lists we have? We have nothing because we don't have a public IP address. So we have to have a public IP address, which we can create like either the browser or this command line, your choice. So let's go read the command line first and understand what it does. So it says gcloud compute on this project, create an address and you need to give it a name so the name has to be here and the region of your choice and network tier is premium tier. So I put it just go with the premium tier because it performs better. And that's the name you have to provide here. And so that you can do in a command line basis like that, or you just close it out and give it a name and do it in the browser window. So I'm going to give it a name called, let's call it to what static IP or something like that. Right? Static IP. That's the only IP I have, which is publicly accessible, going to be public accessible. And it is going to be a premium network tier and it's going to be IPv4 and it's going to be a regional service. I'm going to going with default choices. So here I'm going to say attached to nothing. I'm not attaching it to any of the three machines we have. Just remember this idea, not attaching it. You can, but I'm not because I actually want to attach it to the ingress that I want to create, not going directly to a machine. We are not dealing with machines. We are dealing with the cluster as a whole, as one unit. So we are not attaching this IP address to any one box because it defeats the whole purpose. What I really want to do is I want to treat these three boxes like they are cattle. And you will see that it grows and shrinks automatically. It already does treat my machines as cattle. It will kill a machine if I don't need it. We add one more cow if I want one, if I need one. So that is already happening. You have to think like this when you're dealing with a cluster to not worry about individual machines because they are managed by the service, the Kubernetes service, that Kubernetes controller will actually instantiate new cluster, new machines in the cluster, new nodes in the cluster, grow and shrink depending on how much load you put on your cluster itself. So right now I'm going to give it some name. Description is optional and I'll just reserve an IP address. So now I have new IP address coming up for me. It will come. By the time it comes, I will see it. How do I see it? I just run this command again and I see that there is an IP address allocated to me. That one, which is different from the machine's IP addresses I have, let's go compare that. So here are the new IP address I got, which is different from, this is different from these three machines. So I have IP one, two, three are the three machine instances, which is, I don't care. Don't care about these. They're ephemeral. They are short-lived. They will die. Let them die. This is not going to die. It is statically assigned to me, not to a machine. It is not in use, which is a problem, but assigning it to a machine is going to be bad idea. So I want to fix the problem by actually assigning it and making use of it. But just want to point out one thing here. If you somehow decide to not use this for some reason, now let's say that for some reason you forget that you have a static IP assigned and not in use. If that's the case, Google will charge you money for not using. They want you to know that, that if you create a machine or create an IP address, static IP and not use it, well, you'll get a bill for not using because they want you to use it. So you want to use it for something. So that's what I will do now. If you use it, it is not going to be charged for where they give it to you. If you just leave it unused, they will charge you a bill for that. Having said that, I will now proceed to making use of it. How do you make use of that? Well, you first of all get that variable in a variable value, that IP address inside a variable like this. So now I have the static IP in the variable called static IP. You can now cat it or echo it. So here is the echo. The echo action will show me the IP address. And there is a mistake in the command apparently. So it should be awk print two instead. So apparently the output has changed awk print three, instead of that, it should be awk print two. I'll fix that. The output of this command has changed. It used to be the third argument. Now it is the second argument. So you run the command again like that, say print dollar two. And then you echo and you get the IP address correct. That's what I just made a change. You see that here. That's the IP address, not the third argument, which is this argument is the third argument. You wanted to get the second argument. So I got that second argument by changing dollar three into dollar two. That change you will see happen here at the end of the session. I will make that change and push it. And that is a change I just noticed in the update to gcloud SDK. So that's how I am grabbing that IP address in my variable called static IP. And having that variable in my hand, I need to do something with this IP address. What do I need to do? I use this as my wildcard entry to a domain that I own. So what does that mean? It means let's say if I have xyz.com domain, I go create a wildcard entry for DNS records and I map it to this number. That's what I would like to have. And this is a wildcard, meaning any service I run, you know, like B dot A dot or chat or hi or hello or whatever, they all will get captured by the same address. A record wildcard entry. I need to create that before I can demonstrate a live TLS delivery, a TLS certificate. That mapping needs to happen. So I have a domain that I will be using as a test domain. And that's a different domain, not my cloud genus website domain, but a different set of domain that I usually don't use. I will map everything to that IP address now. And then I will proceed forward with installing nginx ingress and other bunch of things. So you will see that now. I will need to grab this IP and go to my CloudFlare control panel. So I'll say CloudFlare control panel where my DNS is, and I'll create a wildcard entry right there. Like come on, shrink, yeah, shrink. So log in and let's pick one domain. Which one do I pick? Okay. Let's go with this domain, cloud seminar. And DNS. And I have a wildcard entry already that points to this IP address. So I want to change it to this, or not this, but to this. And save. So now every site on this domain called thecloudseminar.com, thecloudseminar.com, that domain, will point to the new cluster here. And we'll dig, we'll say dig, say xyz.thecloudseminar.com, give me what do you have. So I get the answer. The answer I get is exactly what I expect. This is what I expected because that's the address I put in here for wildcard, for dig, for dig works. That's what I wanted to work. And that just worked. Nice. So we'll now go away from this Cloudflare thing and resume our exercise. In our exercise, what we have done up until now is that we have the static IPs assigned to our cluster. We got that piece here. And now we want to instantiate Helm chart for stable NGINX ingress. And of course, set our back true. So there are lots of things. I think I need to rewrite this a little bit differently. I'm going to copy the whole thing. It is too long a command. I'll rewrite this command in a manner that is easy to copy. Currently, it is not easy to copy. You have to scroll through all the way to the end of the file to get to the copy the whole command like that. I'm going to put that in multiple lines so you can read it. Here's the command, by the way. So it's a very long one. Let's go read that. Helm install. I'm going to give it a name called NG. I'll be installing the stable NGINX ingress package. I will also set role-based access controls true. I will also set the controller image from this location. I will set the load balancer to the static IP that I just obtained because that's where I will be using the static IP that we now have from our cluster. So now you can see that static IP I'm talking about is this IP address, which we obtained in here, which is stored in a variable called static IP is what I am using here. And I need to look at this image tag, which is kind of old right now. I think this tag is old. I think the latest tag is 21 or 22, probably. Let's go check. How do you check? You go to Quay.io and find the image number. So here we go Quay and say, what's the image number? So it gives you the latest image number is 23, not 22, but 23. Fine. Make it 23. And there is your new command. This command is what you want to use to install NGINX ingress and use the static IP address that you have from your cluster. This one, that one as your load balancer IP. And you take this command and you, first of all, check Quay get nodes, how many nodes you have? Three. Quay get pods. How many pods you have? None. And so we have nothing. Right? We have Quay get ingress, we have, sorry, Quay get ingress, we have no ingress. We have Quay get service, we probably don't have any services. And there's only a Kubernetes service running. What else we have? Basically nothing. It's just fresh cluster. Right? Say hell listing. We have nothing. Because we didn't install anything yet. So we want to install. We want to install this. Oops. I made a typing mistake apparently. Yeah. There's a typo. So break it, clear it. The typo is that I forgot to put in, is there a typo here? So the typo can happen when you have a trailing slash. A trailing slash is basically a slash after the, space after the slash. The slash has to be the last item in a line. If it is not the last item, you have a problem. So that's what I want to go and examine whether I don't have that problem or do I have a problem. How do I fix that? I go look at every single line ending. Is it a trailing slash or not? Yes it is. And that's how you can verify. Okay. And this is a correctly constructed command, which means we can execute it. How do you execute that? Just bring it here and paste. And apparently there is no typo. It's just how it is represented in multi-line command. So it should be looking okay. I think it just looks different. So breaking it. There was no typo. Doing it again. This time it will look okay, like that. Still not happy with it. Apparently there is a typo. So let's go figure out where the typo is. The typo license. Let me just type the whole thing item by item in one line. It's easier. Just I'll make a multi-line command into one line. Just break all these slashes, trailing slashes and put them in one big long line like that. You can see what I'm doing. So you can do it yourself when you run into that scenario. What I'm doing is I'm cutting out trailing slashes just like how it was to begin with. And now I have just one line to enter. And I'm going to cut that line and dump it in my terminal here. In a full screen setup so I can see the whole thing. And break clear and paste and run it. This will instantiate a new Helm deployment and lots of output comes along with Helm. That is something to read, to read this output because it is actually useful. You can see what the output says. And I will carefully read it for you so you will understand what's going on here. There are lots of output coming out from the command that I just ran. The action was to install stable NGINX ingress, set the role-based access controls, use this image from the query repository and the latest tag and use the IP address that I have as a static IP as the load balancer IP address. Having understood the action that we requested, the result is like this. Let me go full screen. And here you will see the result. And we go line by line understanding. So this is the command that I ran. The result is NG is the name, deployed, namespace used is default, status is deployed. This is actually a correct deployment. You see that the NGINX ingress controller is one second old. It has related parts created, two parts are getting created right now. None of them are ready. They're created, getting created, container creating. It has a service ingress controller with a load balancer, internal IP address and port mappings, one second old. It is pending an external IP. This external IP will be collected automatically and assigned the IP address that we have here. That's a variable reference. It will get picked up and show up here. In the next command I will be running, that's where you will see that this external IP pops up in the right spot for the NGINX ingress controller and will automatically start routing traffic to that IP address. You have a service account created, you have a cluster role created, cluster role binding created, deployment created, role age one second, role binding age one second. The NGINX controller has been installed. It may take a few minutes for the load balancer IP to be available. That IP address will pop up right here, which is currently pending. You will see further as I read ahead. Helm is a comprehensive deployment tool. You will see lots of output coming out of it. Most of it is very easy to understand and something to read. Now it also gives you how do you make use of this NGINX ingress that you have it in place now. How do you make use of the ingress? That's what it describes you in the notes section. Notes tells you, wait for the load balancer to pop up. You can watch the progress by running this action. You can see the action, they are giving you helpful suggestions. What action do you want to see to run this action will tell you whether the IP address is now visible. And yes it is. You can see the external IP address has popped up and associated itself with the ingress controller. Now as an example ingress you can create will look like this. And here is a YAML file. Now if you have TLS enabled for ingress, it will automatically use the TLS certificates. But if you don't have it, it will not be able to use it. Now this section that I'm highlighting right now is required only if TLS is to be enabled for the ingress. Now we have to set up a certificate manager also. We have not done that yet. We just have the ingress in place. We need to have a certificate manager also so we can get appropriate TLS certificates assigned to a domain like example.com and that name will automatically pick up the secret stored in this location called the secret name which will be populated by cert manager. So this helm deployment that you saw here is the ingress NGINX ingress deployment that you saw here. Now we have to have another cert manager tool also deployed in our cluster which will help us feed these secrets for a domain of our choice. It will grab the secrets from the let's encrypt service. Let's encrypt. You saw that service already in a previous example. Did I do that example with you? I don't know. Did I? Or is it all new to you? Am I talking to myself about let's encrypt or did I actually give you a live example? I don't remember discussion of let's encrypt for today. I missed you saying say again. I don't remember discussion of let's encrypt before today. Okay. Huh. So let me then describe this briefly. Let's encrypt is a service like you did explain what it is. Okay. Okay. Good. Good. Good. Okay. You mentioned let's encrypt. Okay. I did mention that's good. So that's good to know. I will now use it now. So we'll see how we can make it to serve our needs of getting a certificate in a cluster. And so what I'm going to do right now is to get to the point where we have, okay, go back to the VM here. So what I'm going to do now is look at our set of exercise instructions and create the certificate manager instance using Helm chart. So this action that I'm looking at is a watch action W. This W thing is a watch action. This W here dash W. It constantly looks for and waits for this external IP to populate. It has populated, but you have to break this action. This W is a continuous loop to break it now. So I broke it. So now we have the command line back to us. We have to now create ingress examples like this and map to a service. And that's what I will be doing now and also feed it with a proper cert manager. So I have shrunk my machine. And let's see if I can, okay, there we have the machine has shrunk into 50% of the screen. The other half will occupy the instruction set that we have here. And the next instruction is to install cert manager. That cert manager is the other tool that we need to get in place that will help us get certificates, TLS certificates. And so the cert manager install action is another long command that looks like somewhat like that, but different. And so here helm installed, name is cert manager, CM, namespace is cube system, set ingress arguments. And here is something to understand this idea, set ingress shim arguments, it actually uses the default cert issuer name. Let's include prod and default cert issuer kind is a cluster issuer. And then it uses this stable cert manager helm chart that installs. Let's go simplify this. So here we have the one portion is helm install, second portion is name, third portion is the namespace cube system. The next portion is a long one, which I will expand the screen to help us understand what that next one is. And this is your oops, oops, yeah, oh, okay, hold on. Something is going wrong here. Cert manager. What is going on? I'm not typing that, hold on. Something is wrong. Undo, undo, undo, undo the whole thing, paste again. This is the first portion. Then the namespace portion. Then the set ingress shim action. And the last portion is the actual chart you want to install, which is the cert manager itself. Now what this ingress shim arguments does is it tells this cert manager to go get certificates from let's encrypt production and use the cluster issuer to get certificates. Now we have to define a cluster issuer resource also, that is also written down somewhere here. So first we install the helm chart, and then you will not retrieve correct TLS certificates if you do not provide a valid email address. So here is a cluster issuer that you need to create. The cluster issuer is basically this YAML file. This is a cluster issuer. And that's what we'll also need to install. That's what is expected to be available here in the ingress shim extra arguments segment. And that will advise this cert manager to go to let's encrypt, take your email reference here and request for a certificate from the server, which is this server, let's encrypt directory URL. That will actually be the authority issuing you certificates, and you have to adjust this email address appropriate to your name and your email address. And then that will issue you the certificates as opposed to me. If you use this email address, I will get the certificates. You don't want that. You want to receive your certificates yourself, and so you should use your name. Having said, I will now instantiate a cert manager using help chart. Pretty much like this. And so I'll go here and maybe go back to full screen because you're going to produce a long output again. And so here I am going to paste that one long line about cert manager. And this will also install cert manager on the remote machine on a remote cluster where something failed kind certificate unable to recognize no matches found no matches for kind issuer in the version cert manager alpha one. Maybe we have to do the issuer part first. Let's go fit the issuer here. So the cluster issuer is a YAML file. We have to have the issuer in place here to download that issuer file locally and edit the hello.cloudgenius yourself. I don't have to edit that, but I will show you how to download the thing first. So you first of all, get that thing downloaded. That comes down. This cluster issuer is now available locally right here. And that cluster issuer is what you need to edit. So I will edit that in atom editor and cluster issuer. And I will modify the email address, which I actually don't have to modify because it's my email address. But you have to modify because your email address is going to be different, not this. That's the email address I have. So you change your email address and use that file. Now what we want to do is deploy that particular YAML file in our context. That deployment happens like this. So I'm going to apply my cluster issuer to the cluster. So now I have an issuer, no matches found. I think there is some change. There is some change going on. So something is behaving differently. And so I have to rewrite the YAML file apparently, and there is probably a modification in the version of some settings have changed in the sort manager itself. So what we can do is skip the TLS portion right now and just get to use our cluster services without SSL certificates for now. I will update the exercise to include this cluster issuer business the correct way that they expect today based on the latest version of sort manager. And we'll do these exercises later on. For right now, let's skip the TLS portion because it is going to cause trouble. Not going to work, as is already told me twice. There's something different. So I have to read that later on. I'll read that. Not right now. Now we can debug the TLS generation step, but we want to go forward. So what I want to do now is just to create an ingress. We have created already an ingress controller. We have to create a deployment and a service and an ingress. So three things. Let's just go understand those three things again. We have an ingress controller already ready. Nginx ingress controller that is already functional. And our IP address is connected. Now what we need to do is have an ingress and a service and a deployment. And this deployment will contain WordPress, by the way, we want to install WordPress here in the deployment. We'll have a service that maps to the deployment and ingress route maps to the service. And the service I want to actually create is going to be called www.thecloudseminar.com. That's the domain name I have chosen and maybe I just use xyz. That's the name. .com. So the xyz.cloudseminar.com is the domain name I will use that already maps to the IP address. I will have to have an ingress resource, a service resource, and a deployment resource that creates a WordPress setup in our cluster. So we'll create these things. How do you do that? Well, you create an ingress resource like here. You create a deployment like here. And you create a service like here, the service, deployment, and ingress. So three things, one, two, three, you have to create these three YAML files, apply them to the cluster, and we have a service ready. That's all it takes, a full-fledged service with that name, xyz, the cloud seminar, all that. That's what I will now do, step by step, first with deployment, then a service, and then ingress. So beginning this way, the deployment, then service, then ingress, and then we have the dots connected. So now let's do that pieces. I will now begin with deployment. We'll grab the deployment YAML file. We have it here already in that file. We'll grab it locally, bring it down. So we'll say, you, please come down. So I say, you, please come down. So it comes down. We have the file now. It is called wbdeployment.yml. We'll open it at an atom and see what it has. And so we'll edit it a little bit, just a little bit, because we have a cluster issue is not correctly functional, so we'll ignore that pieces. Those pieces are, okay, it doesn't even have those. That's good. So nothing to change here, right? This is a deployment YAML file. We can deploy this YAML. It will create a container containing this image and it will start that container inside the deployment. The deployment is called tutumwp. That's the name that I have chosen. And that's the metadata name for that deployment. So I can deploy this deployment very easily by saying k apply minus f. And the name is wtwpdeployment. So it goes and deploys the deployment. Currently we don't have any deployment. So see k get deploy, we have probably a cert manager and we did not succeed with cert manager. You have nginx ingress controller working. We don't have any other deployment. K get deployment doesn't show us anything, right? So we want to deploy this new deployment we have, which is called wpdeployment. We have downloaded the file. The file is available. So k apply and dash f and then wpdeployment. So we now have a deployment created. Now we say k get deploy. We have a deployment showing up. It is tutumwp. You can see that it is three second old. It is none of it is available. It is up to date and current and desired is okay, but available is zero. So deployment is getting created. You can see k get no will show you a node. Oh, sorry. No, there are three nodes. K get PO will show you parts. So there are parts creating right now here. The part is getting created by the image that we have in our deployment YAML, which is this one, which is this image is getting downloaded here right now. Image is getting pulled into the cluster. You can see it visually here in this website. You can see that the cluster come on Kubernetes workloads will show you a new workload here tutumwp because we deployed that workload and the currently it is functional. It is running now, which means k get no should show you nodes and k get PO should show you the parts for tutumwp. This one is running. You can see it here also. Same thing. The deployments work. Next, you want to get a service created so that we can connect the dots. What we really want to do is from the user's perspective, say xyz.thecloudseminar.com, go into the IP address, and then we have the nginx ingress controller, and then we get to the ingress. We don't have it yet. Don't have it yet. This needs to map to a service. We don't have the service yet, but we have a deployment that is working, but we cannot get to there. We have to put these two pieces in place. We need to do that service piece next. We'll do that now. The service is the service file. You bring it down locally. How do you bring it? It's a wget. It brings it locally, so the file is now available. We open a notepad here, and we can see that this is the deployment yaml, and the other file we have is the service yaml. The service yaml is a whole lot similar, and you can actually see these two things together side by side, up and down, and here you can match that this service and this deployment has a way, a one-to-one relationship. The service knows how to select for a role called tutum. That match labels. This is how it matches the label, and that's how a service will know how to connect to this deployment, because there is a matching label, role tutum wp. You can write whatever now. You can write whatever colon you like. That will match as long as you have the same thing here, whatever colon you like. It will match the labels correctly, and the service will associate itself with the deployment. That's the matching action. That's the key thing to understand for a service is this selector matching the match labels. If it matches, this service maps to the deployment. This deployment itself runs these containers. You can have more. This is just one. It is running. This is also going to be running as soon as I deploy this yaml file in here. So k apply, and then the name of this file is wp service. So deploy the service. So now we have a service, k get service. We have a new service. The service is tutum wp service ready at this IP address. See it's 94. 1094 is the service address range. Parts have a range of 34, I think, in my subnet. So that's the service created. All the missing piece that we have is this ingress, a route to get to the service. And so we need to bring that file down, like here, and then we examine it. And then we go full screen, and we open this file in Atom called ingress on the right side. And now we see it. And then we use our pen to talk about it. So in the pen, is it functional, pen, functional. So the pen functions. So here the selector role matching, you already saw that. Same scenario here also, except we have to delete certain portions here in this yaml file. And the portions that I need to delete correspond to TLS, because that TLS thing is not ready yet. It's not functional. We did not succeed in that portion. So this TLS thing to get a certificate for this domain needs to be changed. It is not correctly deployed. The certificate manager software did not correctly install. I need to also change the domain name, like this name was tutumwp.cloudgini.whatever. I need to go select that name multiple places, like this, and say, you know what, the name I want to use is not that but xyz.thecloudseminar.com. So that's the name. So I want to use that name, please. Not what you had to begin with. And so I remove that name, put my name, and then I get rid of the TLS section altogether right now because it is not correctly working. It's not even got set up yet. So line number 18, 19, 20, 22, 18, 19, 20, 21, four lines at the bottom, delete. That is a necessary thing. Otherwise you will confuse yourself. What are we doing? TLS or no TLS? No, we are not doing TLS right now. That's why I'm deleting them. So we have got rid of that. And now I save the file, the ingress file. Now we'll read it. Now you see here, after removing the TLS portions, what you see is that this has, by the way, you have to delete this annotation also. This is a TLS annotation. That's how you notify the Connection Certificate Manager to get a TLS certificate. You'll get rid of that line also. And so we'll delete that. We have to delete that. That line needs to also get deleted. Line number eight goes away, save. And now you have a YAML file that represents the service, sorry, ingress here. And it has that kind ingress. It has a metadata name, the annotations is what lets NGINX ingress know that you want to use this ingress with NGINX ingress controller. And you also notify that I'll be using this domain name. And so please map it to the service name that I have here, which is this service. And the selector actually selects the matching label from a deployment. So that's how you notify your NGINX controller. So whenever somebody asks for this, you send them to this path on that service, on this port. That's what I will be doing now. And let us see. You grab this YAML file, the NGINX ingress YAML file, the WP ingress YAML file we just downloaded and then use a K apply action like this. So K get ing first, see how many ingress endpoints we have. We have nothing. So K apply minus F WP ingress. And now we have an ingress. So K get ing, should get us an ing and the ingress is correctly applied to xyzcloudseminer.com. And so we copy that domain name, it is going to port number 80 on the service. This name is Tutum. You can see K get SVC, sorry, not DVC, SVC, K get SVC, oh, break, K get SVC. That shows you the services that we have. And so that's the service we have in question. It maps to the deployment called K get deploy. The deploy we have are, the deployments we have are this deployment, which has by the way, one desired, one current, one up to date and one available service, one available pod running in there. You can see K get pods and we can see the pod is running here. That's one running, which means we can see the fun. Let's go see it. Here we go. And what do you see? That's what I mean to run a service in a cluster. Yeah, it's a lot of work, but it's easy now. You can see the whole thing is running functional and all that good stuff. Okay. That was a marathon, but it worked. It did not work with TLS, so I'll fix it and show it to you next time. It will work. I mean, I have it working and I'll show it to you also. You can also have it working. So that's the idea. The idea will get you a certificate here, and that is what you will see when I update the exercise with the appropriate steps. If you want to watch me figure out how do I fix it, you're welcome to stay along. You can drop off if you like, but I will now stop recording and I will go debug why that thing did not work and I'll update the exercise. You can get that to work, so you can drop off if you like. I'm doing this thing. You can watch me if you want. I'm stopping to record.