Microsoft Azure Kubernetes Service | Amr Gamil | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Microsoft Azure Kubernetes Service

teacher avatar Amr Gamil

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

21 Lessons (1h 57m)
    • 1. K8s intro

      3:44
    • 2. Azure signup

      3:53
    • 3. Quick k8s HL

      2:17
    • 4. Creating aks part1

      4:43
    • 5. Creating aks part2

      8:15
    • 6. Testing namespace

      5:31
    • 7. Db

      5:48
    • 8. Secret creation

      2:22
    • 9. Build acr

      5:35
    • 10. Middle tier yaml file

      7:18
    • 11. Middle tier deploy

      6:00
    • 12. Service api

      4:31
    • 13. Rating web

      5:56
    • 14. Front end service

      2:51
    • 15. Ingress part1

      7:05
    • 16. Ingress part2

      8:29
    • 17. Scaling hpa part1

      5:14
    • 18. Scaling part 2 loadtesting

      7:55
    • 19. Cluster scaling

      6:30
    • 20. Monitoring

      9:00
    • 21. Conclusion

      3:50
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

11

Students

--

Projects

About This Class

This is a hand’s on workshop for implementing state of the art end-to-end microservice docker based architecture using k8s on top of Azure Kubernetes Service [AKS]. The workshop will takes you through the steps of creating a Kubernetes cluster, deploying a Mongo DB & microservices-based application, load balancing and securing inbound traffic, scaling option in aks and how can you monitor your cluster in production environment.

At the end of this workshop you will understand AKS inside out, and will be able to design and implement production ready Kubernetes clusters.

The K8s cluster will be hosted on AKS and integrated with azure container register for hosting the container images. AKS RBAC and Azure Active directory will be used to authenticate and authorize access to the AKS cluster and Azure monitor will be used to monitor the cluster.

Any application can be hosted on this cluster, but for the sake of this workshop, we will be using a ready-made sample application from github. A rating website.

Meet Your Teacher

Teacher Profile Image

Amr Gamil

Teacher

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. K8s intro: Congratulations on joining this course. This is the right course for you to learn about infrastructure management and ops consideration of running Kubernetes based micro service architecture. On top of XES. Aes is ASR curated natives service. It's the platform as a service offering from the Azure public cloud of Kubernetes. Hello and welcome to the ASR Kubernetes service workshop. This is a hands-on workshop for implementing state of the art end-to-end microservices architecture using QPR net is on top of HDFS. This workshop will take you through a journey of curiosity, Kubernetes cluster deploying micro service-based application. And this is part of a big series going through monitoring, sitting up CIC d by applying. So at the end of this workshop, you will understand achy S inside out and you will be able to design and implement a production ready Kubernetes clusters. If you're up for the challenge and I invite you to join me on this learning journey. So let's go. Before we get started, let's talk about prerequisite. Knowledge of micro service architecture. Containers and Kubernetes is high-level architecture and technology are welcomed. Nevertheless, don't let this stop you. Since I will be explaining and introducing every concept while implementing it, you will use your Azure subscription to deploy the resources in this workshop. And I will show you how to subscribe for a free account on Azure portal. At the end of this workshop, you'll be able to use APS to deploy Kubernetes cluster. And you will learn all of the best practices to do it. You'll be able to configure an Israeli Container Registry to store the applications container images, deploy microservices rating obligation that we will be using in our workshop, which consists of a database tier, middle tier and front end tier. Deploy is or communities, Ingress and angry. Just, it's just a load balancer. Configure SSL using certain Manager and service management is a module ingroup orientated and don't worry about all of this terminology. You're going to explain everything in this foreshore. Use namespaces and role-based access control. Monitor the health of the Kubernetes cluster, Configure cluster auto scaling. And this is on the clustered LeBron and also for the pods level configure horizontal Auto Square. Lets have a look on the high level of application architecture. We will be starting by creating our Israel Kubernetes cluster and configuring it. And first we will show you how can you deploy a database container inside your cluster? And how can you connect to external database services, whether it's inside or in this case is SQL or is opposed to this, or is it cosmos database? Then we will show you how can you use Active Directory or Active Directory to manage your axis and identities in the cluster. How can you monitor your cluster using monitor? And we will show you how can you load balance your traffic either internal or external inside the cluster? And how can you secure inbound traffic using SSL? This is just one level deeper, just focusing on Ezra Kubernetes Services and the modules inside of it. And all. Here you will see the modules that we will be using and implementing through out the workshop. Don't worry about the details, will be explaining every single module throughout the workshop. 2. Azure signup: In this video, I will show you how can you create a free ASR subscription? You go to portal that is er.com. And then once you go there, you will be asked to sign in. If you have a really an Outlook on a Hotmail account, you can sign in directly. If not, you can create one. In my case, I have already prepared and account for this workshop. So I will go ahead and sign in. I just signed him now to my portal. And I will say maybe litter. And if you can see here, it gives you the option to start with an ASR free trial. You press on a start and it will ask you to sign up. What's important here that you will be asked to enter your credit card information. But don't worry, as we'll just take it to validate your identity, nothing more. So it will be entering your identity information, your phone number, and you would validate it with an SMS. Now, it's loaded. So it will ask you about the country firstName, lastName, email address. And once you enter here you four number, it will validate it. And didn't ask you to enter their credit card information. And then you agree. Now that I subscribe, you will find under subscription that we have added my new subscription free trial. And up to the notification here, you will find that it tells me I have a 170 credit remaining. Now, we will be going to create a resource group. So I will press on this left panel. I will go to resource group and I will create one. What is resource group? It just a container and abstraction layer for all of the resources. Let's go ahead and create a resource group. You'll be asked to choose a subscription. In our case, we only have one subscription, we leave it as is. And we entered the resource group name. And you choose averaging it splitter that you have a region close to where we live. Let's choose Western Europe, then press review. And in Kuwait, it will take seconds to create. Then you go to resource. It could be that you just created. If we go back to our application architecture, we will start by creating an Azure Container Registry. Azure Container Registry allows you to build, store, and manage container images in a private registry. We will use it to store our images. They built image of our application. Go to the search bar and search for container container registries and create a container registry. Again, you'll be asked to choose your subscription. That resource group. In our case, we only have one resource or group that we just created and a registry name. Make sure to choose a registry name which is globally unique because this will be the domain name that we use to connect to your registry. So let's try Kubernetes workshop demo. And we are lucky. It seems like it works. It choose allocation Western Europe in this case. And we're going to leave it as a review and create and seems like everything is okay and pressed on caveat, it will take a couple of seconds. Also too. Created validation is passed. You present you yet, and we will have our vicious three VD. This is the overview screen. Once it's created, we will not be using it for now. But important here to remember is this login server. We're going to use it later and also the name of it. So again, see that it starts with the name of the container registry, that is r dot io. 3. Quick k8s HL : Kubernetes is a portable, extensible, open source platform for automating the deployment, scaling, and management of containerized workloads. It abstracts away complex container management and provides declarative configuration to orchestrate containers indifferent compute environments. Let's have a look at the high level architecture of Kubernetes. A Kubernetes cluster consists of two main resources, node and master. Let's zoom in inside the node. And node is a worker machine in Kubernetes and maybe either revision machine or a physical machine, depending on the cluster. Each node is managed by. The master. Node can have multiple ports. And the Kubernetes master automatically handles scheduling the boats across the node in the cluster. Each small circle here represents upward. Every Coop Unit is node, runs at least cube. This is a process that allows the node to communicate with the master and a Container Runtime Environment. For example, Docker. In this case, Docker is responsible for pulling the container image from a registry, unpacking the container and running the application. Zooming further towards the put. Put is equivalent, is abstraction that represents a group of one or more application containers. When we create a deployment in Kubernetes, that deployment creates multiple bouts with containers inside of them. As opposed to creating containers directly. All containers inside a book share an IP address and port space are always co-located and cost scheduled and run in a shared resource and the same node, that means that they can share the volume and the IP address. So to summarize, Kubernetes architecture consists of two main resources, and master and anode. The master orchestrates and denote run the actual workload in the form of pots that contains containers inside of it, which are the actual applications. 4. Creating aks part1: In this video, we will create an ASR community service cluster. We search for Kubernetes Services. And you will see that no Kubernetes service here to display. And we will create a new service. As your community service is the ASR service to create and manage Kubernetes clusters. As always, we choose our subscription and the resource group reheated, and the cluster name. Let's choose Kubernetes workshop AKs as the name. Leave the region, as is the Kubernetes version, as is at the time of recording this video, it was 1.15, the default version, but it might be different when you are watching it. Regarding the node pools, note pools are just collections of servers. You can choose up to a 100 servers or nodes inside one node pool. And here you can change the size, the size of the node. You can choose it here. But watch out because he cannot change it after the creation of the cluster. We can here choose the size, let say two virtual cores and it giga rams, or maybe keep it as 27 for sake of demo. And as I mentioned, you can also change the size after Euclid, the cluster, but you can add new pool and also new nodes. We're going to talk about the non pools in a second. But here you can have three as a start and then later you can add up to a 100 nodes per pole. Let's go to next. Here we can see the concept of node pools. Note pools can contain up to a 100 servers or note. And you can have up to ten node pool per cluster. That gives you a total of 100 nodes inside your cluster. For this workshop, we don't need more node pools, so we leave it as is virtual nodes also, we don't use it for now. And then you can see the virtual skillset. And it tells you that the virtual skillsets are required for multiple notebooks. But not only this, it is also required for auto-scaling and really speak about it in a second. But in general, in case you're not familiar with version machine skillsets. Vision machining skillsets allows you to create and manage a group of identical load-balanced version machines. The number of virtual machine instance can automatically increase and decrease in response to the demand and the defined scheduled. It seems like the virtual machine skill sets also required for the went support. By default, you have Linux nodes in your cluster, but in case you would like to have when the support, then instead of running individual virtual machines, you will have to have a version machining skill sets. We leave it as enabled and we go to next, which is authentication. So here under the authentication tab, you can create an identity for your cluster. The cluster requires an identity to create additional resources like for example, load balancers and manage disks in ASR. This identity can be either service principle or system assigned managed identity. This identity can also be used to authenticate with Azure Container Registry that we created in previous video. And I will show you how we can do it later. And for the purpose of the workshop, who will use the system assigned manage identity? Because they are more or less the same. So manage identities are essentially a wrapper around service principle and make their management simpler. And we will see that we will be requiring the system assignment identity for the integration part. Here it tells you the system assigned manage identity is required in order to associate is or container registry. So in order for your cluster to go to you, private registry, in this case the Azure Container Registry. It seemed it needs an identity. The identity just a user name of your cluster. And for this, you need the system assigned manage identity and authentication. So I will choose it. If you go back to integration, you will see that he can, uh, choose your container registry. So here you have the RSpec role-based access control. We're going to leave it as enabled because we use it to control user access to the Cluster, as well as what the user may or may not do. Once it's authenticated. We leave it as enabled and we go to the networking tab. 5. Creating aks part2: Now we're going to configure the networking of the cluster. Is it gives you two options, two models for networking. One is the default communities model, and the other one is the container native interfaces. And for us to exoplanets, let's go back to the architecture. You can see here that each spot inside the node and gets its own IP address. And the node here also will have its own IP address, which is different than this one. The basic and default networking model of Kubernetes is called cubed net, not working. Where the node we'll get an IP address from the a's are virtual network subnet. And everybody here will get his IP address from a logically different IP address range. So this IP address ranges will not be visible for the external world. Then in this case, bots will reach the external wall it using network address translation or net. The other network and modern is called C n i, which is Cloud Native Interface, sorry, it's called container native interface. And in this case, let's just clear a bit all of these and have it completely new. So in this model, what you will have is that each put inside your node or get his proper IP address. And this IP address can communicate to the external world. The boat can communicate using this IP address to the external world at the same time, receive information and traffic from the external world. But in this case, each IP address here has to be unique across your whole cluster. And it's part of your subnet. In case you are not that much familiar is as reversion networking, we will touch upon it in just a second. Very highly. Please go back to our networking and choose Advanced. Remember, advanced again is the CNI model I just mentioned. It's the container native interface which gives an IP address to each put inside your network. And here you re-ask it to create a virtual network. We don't have a virtual network within, not curated. Again before. Then, here you will see that you have the option to either create a new one or the system here. Portal will create automatically for you. When I was speaking just before about the subnet. So in general, version network, it just a private network in the cloud. We think about it just like the LAN network in your premises. It has a range, an IP range for the whole network. And it has, inside this range, it is subdivided into sub-networks are subnet for short. We're going to leave everything as default, but it's important to know that here. Well, I think this is a bit too much range, so we can just put it 16. And here we can leave it also will default and put the average range at. So for example, here, this is the complete subnet here, which consists of 65 thousand addresses. And this is the unique address of your virtual network. And the subnet is subset of this. So I can choose to have, for example, a small subnet of 24. He, meaning that you will have, as mentioned here, 256 addresses. For the subnet, which is part of this 65 thousand addresses. This is very high level. What is the virtual network is? Then you go back and you press OK. And here we have an error which is good, is good that we choose it the default cluster to explain to you what is this? So the Kubernetes service address range, you understand that Kubernetes uses a master to orchestrate and manage the whole notes. And for that he needs to run some services. And these services needs an IP address. And here is the range of the IP addresses that you define. And it tells you the address must not overlap with any subnet IP address range. This one is within the range of this one. So this is 10.010016. And if you go here back to the visual network, you will see is that the same range, so it collide. He cannot have these. What we will do is we can just change this 0 to one. Sorry, var here. So we change this 0 to one. It should be ok. And also part of this is the DNS service. It has to be part of this range. So let's put one here and I will explain what is this just here when we speak about the DNS name prefix and finally, the Docker pitch address. Remember from before that the architecture here contains a Docker runtime. And this Docker might be accessed from the APS cluster. And for that it needs an IP address, and that's what you give here, an IP address range to access Docker from the APS cluster. So here we have the DNS name prefix. This is a fully qualified domain name that you will use to connect to your cube unit is API to manage your containers after creating the cluster. The load balancer here we'll leave it as 0s. Private cluster also leave it as is probably cluster just allows the master two nodes communication by a private link. So the master will never go to the internet to communicate back to the networks, will always communicate via a private internal link. For us, we didn't care about it for now we'll leave it disabled. And network policy. Network policy is something important in the communication between pots. So ports can communicate to the external world. But what if boats and said the same note or puts inside different nodes inside one cluster would like to communicate to each other, how can they do this? And if you go back here to the architecture, you can see that here you have bought and here, here, what and what if these boats would like to communicate to each other? And here is the network policy. For now. We will not be doing intercommunication interpret communication. We will leave it as none. And then we go to the integration part. For the integration, the only thing here we need to configure is their connection with the ASR Container Registry, which we created a couple of videos ago. You choose the name of it. And then finally the monitoring. We're gonna speak later on the course about the monitoring. But for now, we can use the ASR monitor, which is a service in Azure to communicate with the cluster. And for that, we need to enable it here and choose our log analytic workspace. Don't worry about this. We can explain it later, but for now, leave it as is. And finally, review and a cure yet it's doing the validation. Now. Once it's done, you press one caveat and you will be having your HES cluster validation past. We go back down and replace onCreate. It will take couple of minutes to create, so we'll pause the video and we'd come back once is done in case you receive an error during validation or your quota is not enough. The easiest way to solve it is to just choose two instead of three, and then you review and then you validate. You can see here the addition past, and go ahead and create a cluster. 6. Testing namespace: In this video, we will be testing the AKs cluster we created in the previous video. For that, you will need some environment prerequisites. You need some tools, so an install in your laptop. The first tool is ASR command line interface to interact with the portal resources and the Kubernetes command line client to interact with the cluster. We go back to the portal and then open a new tab. And for the first one is are CLI NS TO search for this and go to the first link. It's a microsoft documents that tells you how to install it. So go ahead and follow it. Second part is to install Cube CTL. You do the same. You search for Cube CTL and installed. And there is an historian setup Cube CTL on your Windows or Linux, whatever operating system you are using. So go ahead and do that. I already did it in my environment, so I will be directly using it. We don't need this one or this one for now. And first thing you need to do is login. You need to login to your portal. Once you press enter, it will open a browser and ask you to sign in. Here you will enter your email and password, and then you sign in. It will sign in and then reversed you back to the command line interface provides so you're signed in as. And then when you go back to the login, you will have the JSON formatted response. The first command you need to do, I increased a little bit different to be able to see the first command you need to execute to retrieve the credentials of your cluster is, is it good credential? And it has two parameters. First one is the resource group and our case it was Kubernetes workshop. And then M of the resource. And in this case, Cooper natives pork shop a KS. And then I mistyped here or shop eight key and press enter. That command is finished successfully. This command retrieves the credential that you need in order to connect to your cluster. You can view these confidential either by going to your home directory. Underneath there will be a new folder called cube. Underneath of it, you will have your config file or easier, you can use the Cube CTL command config view. And this one will show you all of the details of your cluster here. So you have the cluster name, the version, your certificates, everything you need to communicate to the cluster. We clear our screen. And then you can play around is a Cube CTL. For example, you, if you'd like to know how many nodes or to show the nodes inside your cluster. You can write Cube CTL, get note, and it will get the three or two nodes that you have a new cluster depending on which, how many nodes you have and the status is ready. Next thing, we will be creating a namespace. Before I explain what is namespace is, let me do this. Command. Cube CTL, get name spaces. And you can see that inside the cluster by default, you have a default namespace, which contains all of your resources. And three other namespaces that are used by the master to organize its own resources. Let's say that you want to deploy several applications from different teams or departments in your company to the same cluster. What should you do? Or you have to spin on, create a completely new HES cluster for this. Namespace comes to the rescue, are equivalent. It is namespace is a logical boundary between your resources. So you group all of your resources. It's like resource or grouping. Asr. It's here namespace that groups all of your resources inside the cluster. And every resource inside one namespace must have a unique name, but it doesn't have to be unique across the whole cluster. And like this, you are able to deploy multiple namespace inside one cluster. And at the same time, each namespace can be as if its own cluster, all small cluster that runs inside your notes. So by default here you have a default namespace where if you don't specify if you create a resource in Kibera neatness and you don't specify an empty space, it goes to these default namespace. For the purpose of this workshop, let's create a new namespace by the command Cube CTL. Q here, name space, and then you put the name of it, rating app for example. Then if you, after it's created namespace created, you get namespaces. You will find that you have this written up as a new active namespace. 7. Db : Up until this point, we have created an Azure Container Registry. And we have created our ASR container is or community service. And we added a namespace inside of it. We also do play division network. And this video will be deploying a MongoDB inside the APS cluster. Later will be connecting to an external database. But for the sake of this workshop, for now, we will be deploying a database inside a container in their case cluster. If we go to the detailed Israel community service architecture, we showed at the beginning, this is the scope. Here is inside of the Kubernetes service. And inside here, this is the complete deployment of VR application, Microsoft Office application. It consists of, maybe you can focus on this part is database. And all of this part is the middle tier, and all of this part is the front end. In this video, we'll be focusing on the database, which is, this part, will be deploying a Mongo database. Before when install MongoDB. Let's talk about help. So what is held? Helm is simply a package manager for Kubernetes. So it allows you to get up, rebuild packages or applications and install it into your Kubernetes cluster. If you are coming from Linux background, you are familiar with apt-get install to install packages inside of Linux. You can use the same inside of communities using hell. So we go to dogs. By the way, the website is Hellman dot SH. It's not under ducks, it's undergird started. You go to get started and then down here, you find that and install Helm Go to the installation guide. According to your operating system, you choose your code and you just install it. From experience. I think you can do it. I'm using Windows, but if you use SHOFCO install communities help, sometimes you have administrative or permission errors. So what I usually do, if you go completely down and you press on this experimental Windows, this will download a zip file. And this file you can find the helm inside of it and you just have to put it inside your path. So I downloaded it. You don't even have to put it inside the path. If you don't want to, you can just press SIM D here and you will be able to run. Hell. I just wanted to mention an easier step. If you don't want to install him in your local machine, you can go back to the portal and you press on Cloud Shell. The Cloud Shell instead, the porter already has held many stalled, so we can use it here if you don't want to install it locally. So first thing we need to do is to write this comment. I will also provide all of the comments used in this workshop. This is just to configure the home to go to the right triple, to download the database. So you press Enter. Again, we're using health as a package manager just to uninstall a ready made belt application, which is the MongoDB that we will be using inside our cluster, HDFS cluster. Alright, so this is the command that you will need to install the MongoDB inside your cluster. So hell. And he's told again, I will provide all of the codes in the resources and all of the scripts. Hell, and install rating is the release. Bitnet, Bitnami, MongoDB is just the name of the package. And it's important to, to mention the namespace. I remember that in our in our Kubernetes cluster, we created a new namespace and we call it creating a BLE ratings app. We have to set three main stuff. So the first one is the username of the database and the backward or the database and the name of it itself. So this is the name of the database itself. So it's a rating dp. And let's choose username. For example. We can say Q per user, and let's choose the password that you want. Okay? So let's change password. This is demo so I can show you my password. No problem, 1234. It has to be in a string and press Enter and held. Now we'll install it in your Kubernetes cluster. And you can ask, How can I know which Kubernetes cluster i would be installing this N2. Remember that here we have a cube config. And this config allows you to choose the right EBS cluster to install it in. And here we have an error, I think we miss a spill the namespace, let's verify what is the name of the namespace. So use Cube, CTL, get namespaces. And then we will see here that it's ok. Yes, there is no S here. So if I go back here and all I need to do is to remove this and now everything should be okay. Okay, sounds good. Here, the installation is successful. Now you have your database running on the AKs cluster. What's important now here to note is just this DNS, so noted down. We're gonna use it later. 8. Secret creation: In this video, we'll be creating a Kubernetes is secret to hold. The MongoDB details. Either want your password of the database to be stored in a configuration text file. So we'll be using Kubernetes secret. If you search for community secret, can go to the Kubernetes is official website and it tells you what is it. It's simply let you store and manage sensitive information. Could be a password, could be a token or public-private key combinations. So we are going to be using and creating secrets. In this module. We'll go back to our command line, and this is the command to create secret. So Cube CTL create secured generic. This is comes from the API from the communities. And now you put the name of the secret mango sacred. You choose your namespace, which is always on all of the workshop rating app. And then let's talk about this last part. A Kubernetes is secret, can hold several items and is indexed by key. But in this case, here, we only have the mango connection as a key value pair. What we need to do now is it change the username to the username which shows a case user. And the password was, if I remember correctly, 1234, rating mango database, everything is correct. Then we press enter. So this is the user name we use before the password, the name of the database, and the port. Everything is correct. Then Sacred mango circuit is curated. To validate that it was created. Let's reduce the Cube CTL describe secret. And then you put the name of it, which is mango secret. And finally you put dynamic space, which is rating app. And here, if I don't guess I did not miss anything. So it tells you the name space and it contains 64 bytes of memory. By now we have created our sacred that we will be holding the connection string for our Mongo database. 9. Build acr: Remember that we created a container registry and one of the videos before. But up until now, this container registry has no images. If you go down to repo. So under service, you have repository. If he got the repository, you will find that it's no results is completely empty. So in this video, what we will be doing is we will be building our image using ACR are Azure Container Registry. But for that, let's install, get. All of the code that we will be using is hosted on GitHub. And we will be installing Git. In order to communicate with the GitHub. You search for getting install and you go to get CSM and Eunice tool. I already installed on my machine. So in order to verify the habit or not, you can just write this comment get dash version. And I think it's double dash. And it gives you which version you are installing. Good. First thing you do. Just for the sake of organization. You create a directory and let's call it a work shop demo. And you go to this directory. Then what you need to do is first to start cloning this ripple. All of the links that I will be using will be posted in the resources of this course. You go to clone or download, and you copy this. You go back to your terminal and you enter this comment git clone. And the link will DO note all of the front end files from the GitHub into your local machine. Now, if you list the content, you will see that you have the front end part loaned inside this directory. Now will change to this directory. And what we will be doing now is we will be using the Azure Container Registry not only to host the image but also to build it. We will write is it ACR? Build. And we will provide the registry name. And we will provide the name of the image, the final name of the image that you'd like to produce for the registry imagery. Go back to the portal and we check this is delegate server. What we need is the need just the main name. Copy this one, and go back to your console and put a here. And the name of the image that will be rating, dash whip. This is version number one. We press enter and we now are building the image and we're gonna directly push it towards the ACR are Azure Container Registry. I got an error because I forgot to put the source location. So in addition to the registry and image, you'll have to just provide where should they find the files in order to run and build this application, I will just put dot. That means that in the current directory and I will press Enter. You can see that now it started to build. And it will take some time for the first time to actually build, download, and build all of the images needed for this container. So I will stop the video and come back. Once it's done. It took about four minutes to successfully end. This is only for the first time. Next time it will be faster. We will need also to do the same, but not for the rating Web, which is the front end of the application, but also for the middle tier, we go backwards. And what we need to do is git clone. And we're going to clone the other directory. Again, all of the links will be shared. So git clone and you clone it into the Kubernetes is Workshop demo folder. Now we have it there. What we do again, the same, we're going to do exactly the same. But this time is for the API part. So we go to API, we can even go reuse. Yes, ACR built the same registry name. And here the rating API, version one. And don't forget the source location and press enter. It will take again almost for five minutes. Then I will stop the video and come back. Once it's done. It took actually much less one minute two belt. Last thing we need to verify now is that our edges are successfully uploaded to our ripple. We go back to their container registry. We go back to repos repositories. And we can see here that we have now two images successfully built on variable. 10. Middle tier yaml file: Going back to our Israel community service detailed architecture, we have successfully created all of these components who we created, MongoDB deployed it inside, inside the cluster. And we have created a secret to contain the connection string to this database. This part is not yet done, but we're gonna talk about it later. For this video, we'll be focusing on the middle tier. So the rating API. And this rating API, we build its image and its really on the Azure Container Registry. So let's see how can we deploy this middle tier into our HGS cluster. Just a hint in this file will be also provided to you in the resources section of the course. First thing we need to create is a deployment manifest file. So it described the desired state of the workload in the deployment manifest file. And use Cube CTL to submit the manifest file to the deployment controller. And then afterwards the deployment controller takes care of translating all of this YAML descriptive file into an actual deployment in your cluster. Again, this is descriptive language, YAML, and it describes your deployment. Their whole goal of this workshop is not to go into the details of every item here, but for us it's important to understand what is the component of this manifest file coming back here. So using the.m file, I want to tell it, Yes, please deploy an application called rating API and deploy two pots of it. And this is what is translated here. The deployment name is rating API. And it contains containers with the name of rating API. And the container has an image. And this image is referring to. If we go back to our portal just to show you what is revealing to you, remember our Container Registry. And I told you, remember this last couple of videos ago. I told you you remember and this login server. So if he can see here, it has an API of ASR is ER dot IO. So going back to our deployment that Gmail, you'll find here. Here you will add the name of your container registry and rating EPI vision one. That's already what's existing under repositories. He go to repository. Here we can find that you have already two images. One is the middle tier and one at the front end. We're focusing now. This middle tier. Lamy? Yes, it is no much information here. So again, what do you need to hear to replace? Summing it out a bit? This is the name of your container registry. You need to just put it here. So replace this SCR name with a container registry name. On the coop unit is website. You will find enough details on every single item of this. What I'm trying to give you, the big picture, since this is not a Kubernetes course. So here, what, what, what am I telling in this Yemen fire? I'm saying Deploy. Well, image inside a container called rating API, and expose the container to port three hundred, three hundred and eighty. So here you choose whatever port you want. And here is an interesting part. Let's talk about the environment. Remember that if I would like to connect to this mango DT database, I would like to have the connection string here. What I'm saying is, please give this container axis to an environment variable called mango URI. And the value of this environment value, get it from the mango secret that we created. And the key is mango connections. So this is what we created LAS section, we created a secret. The name of the variable inside the secret is mango connection, and this contains the connection URI to the connection string to the database. So I'm attaching it to an environment variable called Mango DB. So there are two ways of communicating via secret. Inside the coordinate is either you attach just an environment variable, like we do here, or you mount a volume, a complete volume, that contents are vial that has this mango secret. But for now it's, We do it easily just using an environment variable. So finally, the resources part. Each container instance is given a maximum here of 25% of your CPU and 64 megabytes of RAM. The Couperin, It is a schedule face, looks for a node with available capacity and scheduled the Bodoni it. Finally here, the limits it just given the coordinate is telling it this is the maximum resource allocated. Do not give him this container more than 50% of the CPU, and don't give more than 256 megabytes. Just a hand. Here. If the container exceeds this 50%, it will not be killed. Or like process will not be stopped, but if it exceeds memory, it will be stopped and reallocated. Finally, the readiness probe and delivering this probe. So the container exposed a health check into point at health and port 300. If the API is unable to connect to the MongoDB, the health check into point return as a failure. And then you can use these probe to configure Kubernetes and check whether the container is healthy and ready or not. By the way, this is the end point that will be used to also check if the container is up and running or not. And if not, then Kubernetes will be able to kill it and restart a new one. And that's how Kubernetes maintains your platform up and running. And that's it. So again, it's just a YAML file with some syntax syntax. You can always learn it on the documentation side, but it's important to understand the high level. What is this trying to do? Then we save it. And let's save it as rating dash API, dash deployment, yaml. Let's remember where it was. Yes, it was here. It KS workshop demo. And let's save it. And let's go back to the command line. 11. Middle tier deploy: I'm back at the command line. Let me go back to the IKS workshop demo folder. If I listed, I have my YAML file here. What I need to do is use Cube CTL command line to deploy this file into daycare as cluster. The command we will be using this Cube CTL apply. Then you put the namespace, which is rating app. And finally, you put the rating API deployment yaml file and press enter. Document apply is used to update an existing deployment. And if it's the first time to create it, then it also going to create a new instance if it doesn't exist, if it exists, it updates it. But you can also do the same with instead of apply, you can just put create. So here you can see that deployment app's rating API. Let's validate our deployment. So Cube, CTL, get deployment. It gives you the states of all of the deployments in your cluster deployments. And you can see once it's done nor resources found. Yes, so that's very important and we're gonna do it next in the next videos as well. You always have to specify the name space, which in our case. Because if you don't, if It will, only look at the default namespace. So again, remember that we have Cube CTL, get name space. And then you have a default one and rating app. So any command I use, for example, get deployment. It, it will be executed on the default namespace, which we don't have any resources in. But if I specify the namespace, then it will show me that now I have two deployments, rating MongoDB, our database, and rating API, our middle tier. As part is to show you Cube CTL. Get put. Again, you put the namespace that we have, which is written up. And here it gives you the name of the boats itself. And the ports contains a containers inside of it. Re yes, its rating up like this. And it tells you that you have one which is running. Oh, that's actually interesting. So here the status is image, pull back off. So the MongoDB is running no problem with it. But here is a problem with the image Boolean, meaning that the Kubernetes cluster cannot pull the image from the Azure Container Registry. Go back to our application architecture. You see here we have the Azure Container Registry and here is our Kubernetes cluster. Kubernetes cluster needs to go and access the hazard cure. Notice the Azure Container Registry to pull to pull images and it uses Active Directory to authenticate. But we did not give permission to the ears. Are Kurt cluster given his cluster to access the Azure Container Registry. And that's what we're going to be doing now. Let's go back to our portal. Under the Container Registry. There is access control. Press on it. And then here you are able to add rule assignment. Press on this. And what do you do here is you will select the role. The role will be ECR pool. And let's search for cooper newtons. Then you choose Asian pool and you save. And once that's done, we can go back to the terminal and you will see that Cuvier needs has access to pull damages from the container registry. Now if you get the let's first get the deployments that we already have. Dip low moment. And let's delete the original deployment, this rating API. So Cube CTL, delete the employment. And we choose the namespace, the app, and the name of the deployment, which is written dash API. And this will delete the deployment. The lawyer meant missing it n, And it's deleted. Now what I need to do is apply the deployment again. So this is the right command for this. And now if we write Cube CTL, get pods, and we specify the namespace. Think up. We'll see that we have finally the rating API iPod. It's not yet ready to be ready. We can actually do dash watch, and we will be always getting the up-to-date status. Now it will be ready after a second and the status is running. So we have successfully managed to give the right access to the cube or unit is to pull the image from the Azure Container Registry. 12. Service api: So up until this moment, we have our rating application and we have it deployed in our cluster as one put. But how can I access the spot? Up until this moment there is no internal or external IP address assigned to it, so I cannot access it, I cannot talk to it. And here comes the concept of services inside Kubernetes. What is a service? A Kubernetes service is an abstract way to expose an application running on a put. And the purpose of it is to enable communication between disparate and other poets in the node or other boards in different nodes or to the external world. Let's go ahead and create our service. Here. The deployment file will be much simpler. So again, now it should be a little bit more familiar with this Yemen deployment file. Remember the old one? The kind was deployment. Here. I'm telling that the kind is service. So I'm deploying a service. The name of the service is written API and selector of the. Let's talk about this. How can I know which application this service is associated to? I know this via the selector. So I go to the application of the name of rating API. If I go back to my previous deployment and I go to the app here, label app, the rating API. So with this selector, I know which application am I exposing or which container inside of put am I exposing. So next is protocol, TCP, straightforward and port 80 and target port. What is the difference between port and target port? So this is a little bit sometimes confuses people. Port is the external world. In this case, the port. When it's inside the node, all the traffic coming into the node on the port 80 will be directed to the port 3 thousand of the output. This is the mapping. This port reflects the extent and wireless communication. How I see it from outside, from outside is port 80 and from inside its port 30. So this will be routing. I receive all communication on port 80 from outside and I routed to port 303 thousand inside the container. And finally, is the type of the service. There are multiple types for each service. Cluster IP, it just means that gives this pod or disservice just an internal IP. Do not allow external communication to this, but rather allow only communication from the internal network. So we'll save this file. And let's save it in the same directory and call it code rating, API service. All dashes between Dudamel. Again, these files I, along with all of the other files, will be provided to you into resources. Going back to our terminal. What we need to do is to do the same. He remembered the apply command, but in this case, and instead. So the same apply namespace in the same namespace. And whatever be applying now is the code rating in a YAML file. And UC service curated. If we now use Cube CTL get services namespace rating AAA, rating up, then we will get all of the services inside our cluster. You see we have a service for the MongoDB and service rating API that we just deployed. And now we can see the API. There's no external API because it's only a cluster network scope. And it's a TCP protocol on port 80. 13. Rating web: So now that we have created our middle tier, it's time to create the front end. So what we have now is the middle tier is created running inside the put. The MongoDB is running inside a book in our cluster. And the are communicating to each other. And there is a service attached to the middle tier with a cluster IUP, meaning it's an internal only service. You can only access it through the cluster. But now we would like to build our front end part, which will allow traffic, HTTP traffic to reach it from the internet. So let's go ahead and do it. So again, here we come back to our deployment yaml file. It's going to be the same like our first one, which has the kind deployment. That's what we use to deploy our middle tier. Here we will be deploying our rating web. So we have a deployment name, rating whip that will be selecting a rating web application and disrupting web application. You will find it here with this information. So exactly the same things. I'll be providing you this file. What you need to do is to replace this with d Hazor container registry name. We go back to our portal and we go home. Let's try to find the container registry name. And here is the name. We copy the name. And then we go back and replace this with it. And then let's talk about the risks. So nothing new here. Here we don't have to actually define an environment variable like we did, because it doesn't want to communicate directly with the database. It will be communicating through the middle tier rating API to the database. We're just saying that please expose it to port 8080 and also the same resource requests and limits. So nothing else to explain. So let's go back to our causal and deploy this YAML file. So first let's save the file again in the same place. Choose the name you want. I choose rating dash, web, Dutch deployment duty, ammo, and saved. I go back to my console here and we're gonna use the same command. Let's choose the right, not this one. Let's first check what's inside and apply the rating where. Yes. So here maybe a small trick in order that every time we have to identify the namespace attribute and put it to rating app. This is the name of our rating space. Otherwise it will deploy it in the default namespace. But let's first deploy this one. There is a trick that you can find it inside. This is now already created. If you go back to Kubernetes cheat, the cheat sheet, there is a complete set of all of the commands that he can use, mosquito Anytus. So you just have to search for Cube CTL cheat sheet. And then you will find that the first one. What's interesting here is you can find if you search for namespace here. So set I contexts utilizing a specific user. No, not not this one. This one, yes, permanently saved the namespace for all subsequent Cube CTL comments. So let's copy this one. What this means is if I go back to my command line and put rating API, creating app as my namespace and press enter. I no longer need to specify a name space in my comments because my new default namespace will be the rating app. So for example, if I do Cube CTL, get imports, I no longer need to provide namespace. I already get my pots. And here, there is an issue with this one. Let's go ahead and see. Alright. So I went to my portal and they found that the application name is rating version one, rating without s. And here you can find that we have S. So that's why there was a problem of pulling, pulling the image from the container registry. So I'll move this S, also important here that you also remove the S from this rating up in the link. So this is just an environment variable called API. And the application expect to connect to this API. So once this whip front end starts, it needs to connect to the middle tier, right? And this is the environment variable that it will be using to connect to the middle tier. We go back to our console and what we do is delete the deployment. Again. I know the name here. From here, the name of the deployment. Aki didn't I didn't save it. So let me save it. And I go back to the console. And I applied again. And it's created. Then I get pods. And everything is up and running. 14. Front end service: Backdoor architecture. We deploy the rating web inside one, but and nowadays, traffic going between the middle tier and the frontier. What is needed here is to create a service. And the service we're allowed the public traffic to get inside the cluster. And that's why we're going to choose the type load balancer. So what is service of type load balancer? So very simply said, it just creates a public IP address to the front end and allow public traffic to go through the cluster. If you'd like to have a little bit of details under the hood, it creates a load balancer. It creates an ASR, load balancer, and a public IP address, assigned them to each other and allow public traffic to go inside the cluster. Again. So sin phi that we use for the service regarding the middle tier, we will use with changing of names and changing the ports. So the type will be load balancer. The traffic will come at port 80 from the outside world and mapped to port 8080. Inside the pot. We save the file and the same path. I choose the name rating, dash web, Daesh, service, duty, ammo. And I save. I go back to my console and I apply, define what was defined name, rating web service. So rating serves and I apply it. It will take a couple of seconds to create the service is created and I keep my screen. And then what I will do is I Cube CTL get services, which will show me all of the service which were already deployed in the previous videos. You can see here we have the rating API service with a cluster IP type and MongoDB cluster IP typing only internally can reach it only with internal. You can see here you only have a private IP address. And here we only have external IP address only for the rating web front end service of type load balancer. Now it's finally time to actually test our application. You go to the powder of a new tab, HTTP, and you put the IP address. And wallah. Here you'll find your rating application up and running inside your ats cluster. 15. Ingress part1: Very good so far. So finally and last videos you are able to see the outcome of your work and all of the previous sessions. And you're able to access the application which is also donate KS cluster via publicly accessible IP address. So if we go back to the application architecture, we are done with all of this part. So all of this part is already done. And now what we will be focusing on, on deploying something called an ingress. Since as of now, the traffic comes and bypass this Ingress and goes directly to the service of type load balancer that we do deployed in our cluster. So now let's talk about Ingress and why do we need it? Before explaining what is an Ingress, let's talk a little bit about layer four and layer seven load balancing. If you are familiar with the OSI model, you would understand that this consists of seven layers. But if you're not, don't worry. The purpose of this video to just tell you that the service we created before of type load balancing or load balancer is a service of layer for load balancing type. So it's only aware of the transport layer, meaning that it only understands TCP and UDP protocols. And this implicates that it only sees the IP address. It doesn't see the URL on the HTTP level. But don't worry, don't worry about all of these details. What is important to understand that you need a layer seven Nobel answer no to layer four, in order to be able to understand the HTTP protocol. That's what you need to know. That being said, let's talk about the ingress. So simply said as well, the increase, it's just an isotope load balancing layer on top of the surface. So the service itself is load balancing multiple ports. But all of these multiple ports contains one application. But what if you would like to deploy a new service that contains multiple ports behind it, that means that this will have an IP address and the servers will have another IP address. But from the outside water, the incoming request here will have to understand and know this IP address and know also this IP address. But angry IS here, provide an abstraction layer that understand HTTP and HTTPS traffic. And we'll be able to route based on the URL, meaning that it will be rating, for example, slash service one. And this will be routed via the ingress towards the service one. Let's say this is surface one. And then if I get the same URL, but instead servers to, then ingress is smart enough to map it to the service to. You can also use the angry for other stuff like TLS termination, which we'll be talking about it in further videos. And also it can act as a reverse proxy. Now we're back in our terminal, so let's carry it. First an Emmy space. Since we are deploying the ingress outside of our application, let's keep it clean and put it on a new namespace. We call it ingress. Now that we created it, the second step is to actually create the ingress resource itself. We're gonna use hell again here, which is the package manager for Kubernetes to install the Ingress Controller. Second thing we need to do is just to refer hell towards a stable repo to make sure that we are getting the latest stable version of our angry not officially released on. We just use him repo adds table and then delink. Don't worry, all of these links would be shared in the resource files in the course. Just before going and installing the Ingress Controller, we were speaking about ingress here. And now I'm speaking about the Ingress Controller. How come so angry says Just the concept. It's a resource that the Quran, it is itself the original implementation of communities did not provide a one service or an implementation to the ingress controller. But it gives you the idea of having an Ingress, which is a load balancer only Layer seven on top of the services, but you yourself have to implement it. But how can you implement it simply here you can see that controllers, It is a lot of controllers in the market that already supports and also implements the endless controller for you. In this workshop, we will be using engineer. So let's go back to the terminal and see how can we install it. We're back to our terminal. Again. Ingress and Kubernetes is just a concept in GIS. Control is the implementation of this concept. And we're going to use engineers, which is one of the implementation of this concept inside our communities. So now what we're gonna do is use help to install this engineer. I copy pasted directly the comment and we'll be also surely get with you, of course. And it's a little bit too much, but I will just explain it very high level because it's actually simple. It's just too many arguments. We're calling hell here. We're asking him to uninstall engineer, ingress. Nothing fancy here. We're telling it to get it from this table report that we just provided in the previous command. We are giving it a name here, the namespace where I didn't find any misplace which is enriched in this case, which we just created here. And we have multiple arguments here that we can speak about. The first one is D, controller replica count. So what I'm just saying is installed two replicas or two pots of this engine X. So this is just for the sake of availability, installed two instances of it. And here, not selected or not selected here. Lisa, just regarding, I'm telling it pleased the controller. It choose Linux only Linux machines, not Windows machines underneath because up until this moment on ingress can be deployed on HES, on Linux machines. Alright, so we press enter and let our hell do the magic. Again. If this too complex for you, don't worry, I'm going to share it with you and you don't have to really know it because you can always copy pasted, but you just need to understand the concept behind it. Now, the increase is, you can see here the ingress, the engineers ingress controller has been installed and it takes up to five minutes actually to get an IP address. So we gonna wait a bit and come back. 16. Ingress part2: Now I see that I have now an external IP address assigned to the Ingress Controller or engineers controller. So while I check the status just by copy and paste, if he go up, you can see that it may take some couple of minutes, but you can always watch it a status by doing this comment and I just copy here the comment, and I just checked it and give me the outcome here. So nothing else to do here to Ingress are ready to be used. But remember, we go back to our service. This is the rating web service, the front end of obligation. It has a type of load balance. Then what we need to do, because now what happens is that our cluster is exposed to the internet, not only via the Ingress Controller, but also why the service. So we have two endpoints for your services. So what we need to do is just change this to cluster IP type image. Just check if the same. I didn't do it. Let's just copy from this. It's all capital and then put it here, save it. And then I go back to my console. First, I go back to my, I guess workshop, I clean the screen. You cannot, ideally, what we can do, this is just the IP address. Ideally what we can do is just use the command cube, CTN apply, and then the name of the deployment to apply first deployment, the name of the deployment which was writing web, and then dash, and the name of the file, which is rating web service. But the problem here is that you cannot exchange type while the service is running. So what we need to do now is we go back to the terminal and first we have to delete. So we can delete this first. And we deployed. Yes. Now deployment returning NOT_FOUND. Yes. Okay. So sorry, it's not the deployment, it's a service SIR risk. And then again, NOT_FOUND. Maybe ratings. Yes. Okay, so now that I deleted it, let's apply cube CTN and then you apply the new deployment file, which is rating web service one. It should take seconds to be created. Yes, it's creating. If we go back to the high level view of the ingress, you wrote is that you can have multiple services behind one angry. So how can I know which request to map to which service? Remember when I showed you before that you can have backslash S1 and you are, you are L or you can have in your URL, S2 and your path. So I need to configure, for example, ingress to route this request to service one and this request to service to. For this, I need something called Ingress rules. And that's what we'll be doing now. But in order to do English rule, that container of it or like the umbrella is ingress resource. So I need to create ingress resource. And inside English resource you have one or many English rules. So let's go ahead and create our Ingress resources. Again, yes, you guessed right? For any resource you would like to deploy your Kubernetes cluster. You have to have a YAML file and manifests or a deployment fine. Here, that kind of ingress meta data. So this is the name which is rating with Ingress. And here we're just saying which implementation we're using, which is Engineer. And here's, what's important. Here is the rules. So as I mentioned before, this is an ingress resource. And inside this resource you have multiple rules. And here the rule, we only have one rule here, which is based on path. So what it does, it just URL path routing. When you receive a request with this format, you will routed to this back end. This written web service. We created it before you remember this is the web service that we change it from load balancing IP to cluster IP and if expects traffic on port 80. So here what we are saying is when you receive a URL path starting with this DNS name and has a path like the default path. And on port 80, please risk, Please routed to the service. So now what we need to change is, as mentioned here, the comment is that you have to put here the ingress IP address and I will show you how to get it now, here, don't worry about this. This is just a DNS name dot in IP that I, oh, this is a wildly DNS name that you can get it for free. Of course you can put here instead your DNS name, your custom DNS, DNS name. So we go back to the console and we do Q CTL. Sir. This is you want to get actually the service, so we have to put good before. And then then you put the namespace here because it's a different namespace than our default one now which is the rating app. And rating it was I think green N3Cs. So here you will get the name of the IP address. You better copy it. Let me first save the file here. You save it with any name as well. So I save it was written in risk. And you go back to the console. Let's copy this external IP address. Go back and replace the ingress IP address with this one. So we are all set now what we need to do, let's save the file, go here and deploy it. Cube, CTL, apply and backs. We have also here to specify the namespace increase. Now I tell you what, let's leave it in the default namespace and you choose the name of the deployment file, which was in Greece, I think, yes. And you apply once it's done. The only thing which is missing now is that you go to a browser and you test it again. And voila, here is your web application up and running. So to summarize, now we have almost deployed everything here except for this one we're gonna talk about next video. But now we have, we started the video that the traffic is going bypassing the Ingress and going directly to your service. Now, we have managed to deploy an Ingress. And injurious contains Ingress Controller. And this ingress controller contains two pots or are deployed in two parts. And it contains a routing group that routes all of the traffic that comes to the main DNS towards the main back into service here. So with that, let's verify that here we cannot anymore access the service via the internal rating web service. It will die, it will not reach it. And here you can only access it via the Ingress Controller. 17. Scaling hpa part1: As the popularity of your application grows, the application needs to be able to scale up and down to manage the demand change. You have to ensure that the application remains responsive as the number of written increases and decreases. In this video, I will show you two things. First, how can you use the equivalent net is horizontal, scalar, increase the number of pods to meet your demand. And also Moreover, how can you use the Israel community service cluster auto scaler to increase the nodes inside of your cluster. First, let's talk about HPA or horizontal put auto scaler. Remember that the node can contain one or multiple parts. And each of these has a set of resources which is limited according to the deployment file of this deployment. So if you go back to the deployment file that we use to deploy, for example, written API. You remember that we had that resource section and a request. And this is what this needs at minimum two to actually be deployed in this cluster. So you have a CPU and the memory request, and you have a limitation as well. So this one cannot take more than half of the CPU, of the virtual CPU that you have, cannot have more than this memory. But what if I need more than this for my application to respond properly? It's where the HPA comes handy. So HPA allows the EBS cluster to detect when you're deployed, but need more and more resources based on a metrics that you define, such as, for example, CPU or memory. And HPA can then is killed will more puts into the cluster to cope with the demand. So how can you configure it? There are two ways. The first one is via the command line, whichever surely right, right away. And the second one is using the deployment. You remember everything in Kubernetes can be deployed via a manifest file. So let's start by the command line. So first, let's go back to the terminal and check Cube CTL, get deployment just to make sure that we have everything up and running. Yes. So we have the rating API, the rating mongodb, that rating web, and we have only one available here. Good. Then we can use this command, which is Cube CTL, who to scale. And then you put the deployment name and you can choose which metric that can use. So here we get, we can use directly CP percentage. We say it's minimum 50%. And then the minimum amount of ports in my node, it's going to be one. And the maximum will be ten. Actually, it will not be only on one node, it will be across nodes. But let's not do it via the command line here. And I'll show you how can you do it via a manifest file. So here is the YAML file that we used to deploy that horizontal put auto scaler again is the same API version and then they're kind here. In this case it will be horizontal put auto scaler, the name of it. You can choose the name that you want. And N generally, it tells the same message that this command lines does hear those Kubernetes to deploy. Hpa, which is horizontal put auto scaler. When the CPU presented is more than 50. Keep the minimum one and the maximum tin. So play around between 110 to maintain the CP percentage and average of 50. Here what you have here is the same but written in Yemen phi minimum replica, which is the minimum amount, maximum amount or 110 metrics based on the resource. The resource is CPU utilization, and here is 50. But let me be instead of 5030 to trigger the scaling up faster. So we're going to save the file again. Let's name it. Written HEPA that yaml, you save. And we go back now to the terminal. What we can do now it's simple deployments. So Cube CTL, apply deploying. We don't even have to write it which if and rating HP naughty M0. And it will deploy it to the default namespace, which was written whip. And here is created. Let's try to Cube CTL, GET and PUT. And you can see that it still nothing more. Writing web is the same because the requests are not still that much for the HB to be triggered and to deploy new ports. So let's do some trick in order to imitate as if you are receiving too many requests in your application. 18. Scaling part 2 loadtesting: This video is a continuation of Las Vegas and we will be adding extra load on our obligation in order to see in action. There is one simple trick that you can do first, which is simply here, you change the number of the minimum replica to, let's say three. And you save the file. You go back to the command line and you do the same. So you deploy this change. Once it's deployed, the HB will detect that we only have one port, and he will make sure that we have at least three pots. So now when I press again, get deployment, you can see that we have for the rating API, one out of three is ready because it's still ongoing, but we have 33 more pods that are running in our cluster. Let's do again, get more deployments. We have three parts. Let's go get the boards of themselves. And voila, you can see that written API has at least three. So here you can see that HPA completely managed to scaling up. Okay, good. What you can do also is you can manually scale regardless of any metrics, you can manually scale up and down your deployment. Meaning that I can use this manual command, Cube CTL scale replicas. And you provide here the number of points that you'd like to have, let's say five. And you can provide the name of the deployment, which is rating API was S, I think. Yes. So here it will tell you that it's scaled and give it some time. Yes, it's easy skilled Cube CTL to get pods. You will find that here. You have written KPI count of five points now. And you can also use the same common to just deploy, to scale down as well. So let's do it one and do scaling and get pods. It's terminating. Again, is terminating all of them. And after a while it will come only one part of this deployment. Let us go back here and make sure that only have one in order to be able to automatically tested. And here, let's apply this new configuration. And you go up towards that four, okay? Then now we only have one port of the rating API. What do we need to do now is to generate a fake requests to the application to test the auto-scaling capabilities of the ports of the horizontal put auto scaling. How can we do this? Let me show you. If you just Google Kubernetes, which is scaling. You can find here this comment which gives you a sample of how can you do a load testing on your pots or on your cluster. So what I will be doing here, I will just be copy-pasting these two commands. Here. It runs support load generator, which is, this is the image of it. And it does a command Y2, like always ask for this, always call this API here. Almost call it, send it requests, non-stop, non-stop. And this will increase the load and you will be able to see the HPA or like horizontal scaling up the pods to meet your demands. So let's try this. I opened a new command line because we are going to use the other one to actually show you the command how the looks like. I will copy paste here. So nothing to change here. Press enter. This will just deploy this image inside a put and allow us to access this command line, which is just a busy box MJ. I go back here and I copy the rest of this command and paste it here. Actually here what you need to do is to change this to a front end. And so how can I get Front End? This is our website, so I go back here. This is the website. And I copy the link. I go back here, I paste it here. But I'm not going to be, I'm going to be distinct an API, an API existing code already. It's called api slash load test. So let's, once I run this, it will go like nonstop. So what I will be doing, I'll just be adapting a bit the screen. So before hitting Enter, I'd have to divide the screen in order for you to be able to see how it will go. Now done. Yes, it's non-stop now sending, sending requests. And here I can, I'm able in another session to get what. You can see here that actually here you need to leave it a bit more minute-to-minute in order to be able here to see the status. So I will pause the video and come back when it's working. Maybe let's make a small trick for the sake of this demo. Let's make it a little bit smaller. Here. I do it 20 and before it was 30. Now I do it 20% to make it faster, to scale it up and down faster. And what I will do here is I will need to apply. So Cube CTL, apply this configuration. And once it's done, I can already start this 1. First, let me show you a Cube, CTL and you get HB. And here you can see that it's maybe, let me make it a little bit bigger. A rating API, HB, age that age just deployed. Eight, has a target of 20%, many MM, one, maximum thin pods, and currently we have replicas of three. What I will be doing now, I think I already terminated on this one. I really terminated the pod here. Yes. Alright. So what I will be doing is I will, let's apply. Note, let's scale it to one, meaning that it will be only one rating API working. You can see this one is terminating now. So here HPA, I clear the screen a bit. If you get the HPA, we'll see at 16% and you have one replica. Again. All of these watch out because all of this, I still have my load testing working. And now you will find that it's increasing the replicas here. Yes. So here it's three replicas because it went to 46%. And if now I tried to Cube CTL, get boats, I will see that I have now 123 pots rating API 1231, which is 12 days. This is long time ago we did not, we never killed it, but now one is 30-second, another one a 30-second, which weren't just created by the HPA to match these demand. And now, ideally, if you get HP again, you'll find that the demand after awhile it will go down again. And the three ports will be there enough to match detriment. 19. Cluster scaling: As I showed you, horizontal put this auto scaler helps to scale out with new buds as required to meet the demands. But eventually, the cluster will run out of nodes to accommodate this new pots. And you will see skewed, we'll put in a pending state and I will show you now in the demo. And the solution for this would be to use the cluster to scatter, which doesn't touch the wood numbers, but increases the node numbers, the actual resources, servers in your cluster. And back here to my command line. And then what I will do is Cube CTL get what. And I miss the S. Maybe it would work. Okay. So here you have the main pots, the database API, the Web. You can see that also the HPA is stopped since a soak my load testing, then there is no need for extra replicas and we only have one replica for the API layer. So get bots again. What we need to do now is here you can see the status is running. I would like now to show you how if now I would increase amount of puts to a certain extent that the current servers will not be able to handle. Then it will be instead of running state to repeat pending state. But in order to show you this very fast, what we will need to do is to just simply fix it inside the deployment file. Remember here, this is the Yemen manifests deployment file for the rating API. We had resources request of this amount of the 20% of the CPU. So now what I will do, I will just ask more. I will ask 100 like 1 seventh complete CPU power. Also, I will increase the maximum limit. Like this. I can easily use two or three number of iPods. I can really show you how it will end up in a pending state. So I go back to the console and what I will do, I will have to apply this new configuration so its rating API Deployment. Once it's done, then we will see the put is, there is a new BOD containing, again get pots. So you can see that they replace the old one with a new one and everything is working just fine because up until this morning, the servers in the pool, which are two, we have two nodes are enough for these pots to run. So let's, instead of doing again the load testing, let's use the queue CTL scale option. Which replica takes replica as an input. And I think it takes two dashes here. And I will just ask him the Kubernetes cluster to have three replicas of the deployment, which was the name of rating API. So. Like, like this, it's simply, I am telling Kubernetes is polices scale give me three more or two more points to sort of three. Api, running inputs should work. Yes, indeed. So when I'd get pods now you can see or I, that's what I wanted to show you. So here you can see that it starts, it added two more parts to match the three requirement, put three pods requirement. But we don't have enough servers or nodes underneath in the cluster to many or to contain this, to contain this demand. Back to the portal. Here I'll show you how can you scale up your nodes in order to meet this new demand? So if you go back to the node pool setting and you will see that here is your agent pool. Remember we have a Kubernetes cluster can have up to ten pools, note pools, which is just a set of servers. And for each node pool you can have up to a 100. So here and the three dots here I press on it and the press scale. And here it allows you to see two options. There is manual and auto-scaling option. The manual, as the name indicates, you can just put here the number that you want and you can go As you know, up to a 100 note. And you can also configure auto scaling the minimum and maximum node count, which would be updated according to the load coming from the boats. So here we're going to keep it as two. I just wanted to show you here that you can do manual and autoscale, which shows you the minimum and the maximum amount of nodes. Manually specify exactly how many nodes you want and you go down and you press Apply. And that's how you scale up and down your clusters. Of course, if you try now to add three, for example, you will get an error because this is a free subscription. You cannot get more than two nodes of this size. Before we go to the next video, let's make sure that we restore the original configuration. We go back to diameter fire, make sure that we are back at the five hundred and two hundred and fifty for request and limits. And we go back to the command line because you remember that we have, now, if you do Cube CTL get pods, we will have three bonds at least. Yes, three boards, at least for API, rating API. What I need to do now is to restore the original configuration. The simplest way to do it is to just delete that deployment, which is rating, delete deployment, rating API. And then again, you apply their updated one. And this will make sure that we only have one rating KPI running. 20. Monitoring: In this video, we'll be focusing on as your monitor that allows you to give the monitoring data to your cluster. High level as we monitor, allows you to be able to collect and analyze and act on telemetry and data you collect from New York cloud and on-premises environment. So it allows you to get some matrixes like CPU utilization, memory utilization. And I really like on the official page of Microsoft, they have a really nice high-level overview about what is remarkable is very powerful platform. So here it gives you insights, meaning some metrics and data. For me, Fourier lubrication obligation can be hosted on a virtual machine. It doesn't really matter where all of the services and support as a monitor with these data that allows you to visualize it, make some dashboards, and analyze it using log analytics and respond, meaning that you are able to create alerts like send me an email if the CPU utilization is smaller than or bigger than certain amount, 50% for example. And it integrates with business processes. So you can have an API that communicate to your on-premises system, or you can do a workflow using logic apps. So in short, it's a very powerful platform that helps you get all of the information of your cluster, in this case as cluster. And in this video, we're gonna be talking very high level about what is omega can provide to you in the context of achy? Yes. We are back to our portal in order to access as a monitor for your HES cluster, you have two ways. First in the overview screen, you can find here two buttons that talks about either monitor your container or via logs. You can press on it here. Or he can directly go through the monitoring section and press on insights. So let's do that. Once you go to the first screen of your Is, are monitored, you will find already some dashboards are built for you, which is very interesting. It gives you the node level information. So the CPU utilization memory, note counts and pretty much everything that you would like to know on a high level from the node to already built for you. And here you can choose which kind of information you would like to draw. And this dashboard, for now, let's keep it minimal is average and maximum. What's interesting here also, you can allow the life that here he will receive live data, as you can see, with a period of five seconds, he can go down to 1 second. And you can already see the live data inside your container, the application when these higher demand or lower demand. For the sake of the demo. Also, it may go back to my command line here. Remember here we had a load testing before. I'm using the same comment. So just sending multiple information, multiple requests towards, Let me just stop it and show it to you. And just request towards your load test API inside your application and let it run. And if I go now to my portal. I can see here that already the performance is increasing, CPU utilization is increasing. The memory utilization is increasing. It's real-time. And if you go back and stop it, you will also see it going down. But it will take a little bit more than 1 second here to show it. So it's not very accurate. I go back here and it's stupid. And ideally within 1 second is should go, go back. But here you can see, if I go up, you can see it still. Even if it's 1 second, vigor and molarity, it's still going up and after a while it will go down, but kind of ten seconds delay or something. So I will close this for now. And let's see other blades here, other tabs here. I go to the health and here it gives you a lot of information about the Kubernetes infrastructure health and the health. Here it tells you like the current state, it's healthy. Everything is green as you can see here. And here, all the services that are running on the master, the master node, a guess or is or community service is given for free, is part of the offering of the HES from Microsoft. You can also see the nodes. And here it gives you, first of all, the first level is the pool. And we have only one pool and we have two nodes inside of it. Let me make it bigger for you to see the overall view. So here it gives you the overall health indication of the node level. And if we zoom a bit more, you can see here it tells you everything is perfect. And we are now monitoring the CPU utilization, memory utilization, and overall status. And this is three metrics that are monitored by default. Okay, let's see the next tab. Here we have the notes and it gives you a high level view also about the nodes. So we can see that containers, it's running 20 containers so far. Because also it runs some built in Kubernetes containers to monitor and communicate with the master. And you can also see an uptime and a lot of other information. And you can dig deeper to the container's reports that actually running inside. But what's interesting here, I would like to show you this preview feature. By the time you are watching this, maybe it's already in general availability. So let's press on this. It opens your console where you can get live metrics and also events that's happening on the node liver. So here there's no new data on this one because we are selecting this container, but let's select the high level nodes and press again on view data. And here you can see you get leads, high-level details about what's happening from the management point of view on this node. For me personally, the most used tab here is the container tap. And this one, it gives you information about all of the poets that was there existed before your Kubernetes cluster. And it gives you a live data. Here also regarding the actual running ports in your cluster. For example, let's go and find the rating API. This is the written API which is currently working. So I press on it a prison view data. And let me zoom in here to see. So you have, by default you have the Log tab and the events tab. The events, what's happened when actually that was creating. So have here that it's pointing to the image from the ISR Container Registry. It was successfully built, is created and started. And the logs here by default, that gives you the high-level view. It doesn't give you what is the application is doing itself while running, but what's happening on top of the container or the pot itself? If I go back here and rerun my load test, and I go back to the console. It gives you live data about what's happening here. It's have a get request on the API load test. Stop. This one. Go back here and you can see that the only requests which is happening now is the health prop. If we go back to the cluster level, here we have some metrics which is ready made for you, as I showed before. But what if you would like to know a certain metrics that doesn't exist here, that you can configure under metrics. If you press on it, you will get a nice dashboard here that tells you what is the scope, which is, in this case the Kubernetes cluster? What is the metric namespace could be a standard one or custom, which is based on logs that you collect. Let's keep it for now, a standard, and you can select the metrics. And this is very limited, as you can see, matrixes. And if you select custom, you can even increase those. But for now, let's just see, for example, the disk Basie percentage. And it shows you the nice graph about the disk visit percentage on average level. You can see the minimum, the maximum level, and you can plot it all. 21. Conclusion: Congratulations, we have reached the end of this course. You have done great following this course til the end. I salute you, I congratulate you. It takes commitment and perseverance to go through the course. Let me wrap up what we have been doing through this course. So first, we have our application and everything is up and running inside. As a community service was started by designing and setting up our cluster, setting up our Azure Container Registry, getting the code from GitHub, code GitHub and building it and storing the images inside here of the Azure Container Registry. We also use our cluster to deploy a database, mango database. And I showed you a high level. What can he do is as a monitor and how can you authenticate using Azure Active Directory between the cluster, the Kubernetes cluster and the Azure Container Registry to pull the images into the containers and the ports inside the cluster. We also looked at how can we allow external traffic to enter to our cluster. First by looking into a load balancing service that is exposed by the cluster. And second is by using ingress, ingress controller. And we also looked at how can we secure all of the traffic coming into the cluster here with using TLS. So all of the basic components you need to set up as a community services and run an application on top of it and be able to collect monitoring data out of it. So this is a very, very good step. Nevertheless, there are some next step that you need to do in order to pull it up to a real production ready application. If I go back to the architecture again, you still have to understand how can I set up a CIC d by applying meaning that I have my developer here writing his code in his preferred IDE or code editor like Visual Studio or Visual Studio code. And then he push it to the git hub in this code, this, in this case, this is the source control and it's linked to a devops, in this case it's Jenkins. And how can Jenkins get the code and understand that this new push in your GitHub code, get it and deploy it to your curfew pernicious service. How can you do this and how can he access it in a secure way using our Beck and Azure Active Directory. This CID CD, by applying, it's something that missing. Stay tuned and look at our profile for new courses coming on this, it might be already there by the time you are listening to these video, what else is needed? You can see here we have our database is internal in the Kubernetes cluster. In a production ready environment, you need a separate database that can be accessed from the cluster. In this case, for example, you have the Azure SQL, which is a managed service from Microsoft. And it also allows you not only to have SQL, have MySQL and Postgres and multiple other SQL, a database databases. And you also have Cosmos DB, which is a new SQL, and you can also attach it to your cluster. And how can you set up this link here? And finally, how can you put all of your secrets of the cluster inside is her key vault, which is a safe and secure way to store your keys and secrets. A big thank you for watching this video, and I will see you soon in new courses.