 So let's see, for those who are new, this is my special video for the next lesson, this is session 5. What did we do so far in this, I guess, and this is part 1, who was getting started with the project from ground up to the petition which I am using for this talk. Part 2 was about using Dr. Tampos, which is proof in worded by Dr. Tosthich the multiple containers together. And today we will be looking at the container orchestration using Kubernetes. We will be using Minikube, which is a version of Kubernetes, which gives you a flexibility to work with same set of objects that Kubernetes has on a single node first. So on your personal laptop, you can install this proof, and you will be able to do everything that you could do in a cluster locally on your laptop. I suggest this approach because it gives you a lot more confidence before going directly to cloud or even to physical cluster, and then trying to figure out if something goes wrong, what will happen. So this is how I started Kubernetes, learning Kubernetes, and then I went towards it. So this is the approach I suggest to others to start learning about Kubernetes. And then there are many, three parts will be doing deployment of AK service, which is the managed Kubernetes service in Azure in part four. We will extend today's stuff into more scalable features in part four. And then part five, which is where people are monitoring. And in part six, we will be doing SCI screening. So this is what the application we have so far. It's a small tech talks application. And this shows that tech talks has a VA screen. We're using ASD.NET MEC code as a front-end code, as a back-end API, and it's supposed to work in the on-demand, all on-demand. So this is what I mentioned just now. What we did in part one was basically Docker getting started. Part two was the composer. And we started with Kubernetes. So let's understand what is the need for our distribution. Why do we need something like Kubernetes? The first thing is to deploy a lot of container apps. Nowadays, we've heard a lot about microservices, doing modular applications, deploying to servers. And this is where a tool which helps you to deploy these kind of container daily apps. And that's where tools like Kubernetes, Docker's Form, your Mezos, they really shine in this area. The next one is to scale the containerized apps. So you have the ability where you can dynamically scale based on the load. You can define different thresholds on the resource usage, on the number of extended containers. So you can start with, let's say, two instances, and when the load increases, you can make it five, when the load decreases, again, you can scale it down. You can have new rollouts of the versions without having downtime. So you can do like a rolling update. If you have, let's say, five instances of container running, you can have a policy in place which says update two at a time. Why do you deploy version two? And then, when all the five instances are updated, the older version will be decided. It also gives you multiple things that are just storing and storage the different things, storing this and this, you know. And we also have the flexibility of managing multiple resources across multiple containers. So what this means is I can define things like resource commit. So let's say I have a cluster of three nodes. Let's say I have a particular container. Let's say I have this container. It needs a 2GV of RAM to start with. So I can put this kind of constraint saying in order to schedule this container, I need 2GV of available RAM or memory on a particular node. So if you want it this or the container of the station tool will figure out which node has this capacity. And if there is no capacity, we will not be able to schedule this. So it has this kind of intelligence and also self-filling. So we can again define in terms of policies what should happen. Let's say your container dies due to some reason out of memory or some sort of crash happens. It can restart itself. So we have resilience printed into the applications and all this comes in with us and for the station tool. So in the market right now Kubernetes is the most popular one almost every cloud vendor has support for Kubernetes. It was a project which came out of Google. So Google was already using this for a long, long time and they open source at some time back. There is one provided by Docker itself, Docker's form and there is Mezos as well. So you can pick and choose which one you want. In my opinion Kubernetes has the advantage and it is supported by almost every cloud and it is quite used extensively in the market as well. So let's start with Minikube and see what will be Minikube. As I said Minikube is scaled down version. It gives you same set of capabilities of a full-time Kubernetes cluster but on a single mode. So we can see which version of Minikube I'm running. I shared in the meetup how to install Kubernetes CLI, Kubernetes as well as Minikube. So I have 0.28 version of Minikube for Kubernetes which is the command line code for Kubernetes. I have 1.9 version. So Minikube is also its own cluster. It creates a VM and it creates inside that VM over cluster. I have already started this because it takes some time to get started. So I have started the Minikube cluster but it's as simple as saying Minikube and start. I can check the status. It's already running. If it's not running I can do a Minikube start and I could start the cluster. I can delete the old VM if I need to delete it. Minikube has support for multiple versions of Kubernetes. So I can go and check which are the versions in the current version of Minikube supported. So you can see here it's like about 15 to 20 different versions of Kubernetes which it supports. So by default it can start with version 1.10 which is the latest one but if I want to experiment or if I want to work with the older version of Kubernetes I can still go back and work with these versions. Then when it comes to kubectl or Kubernetes itself this is the command line tool which is used to work with Kubernetes and I can check which are the configurations. So Kubernetes needs a context to work with. I can work with multiple clusters at the same time. So if I do kubectl I can get all the context that I have on my machine. Here I've got six different contexts but the one with the start kubectl is the current context that I've been using for this session. So what is Kubernetes? Kubernetes in general is like a control system for automating deployment, scaling and management of containerized applications across the cluster of nodes. The point node here is it's the management of containerized application. It's not managing the cluster as such. It's really a tool which helps you to manage the application which run on the cluster. You would still need the regular management tools of the cluster but to manage the applications on that cluster, you would use Kubernetes. So it's like a deployment tool. It's not for managing the cluster itself but what gets deployed on top of the Kubernetes system. It has a set of basic objects so we have things like namespaces, bots, volumes, services. So namespace is like in Java or in .NET or any language you have a logical location. So we can build namespaces within a physical cluster. We can have a namespace for development. We can have a namespace for QA. We can have a namespace for UAT. So it allows you to create these virtual kind of segregation of objects. So on the same cluster, Kubernetes physical cluster, you can have multiple namespaces and you can deploy the same version of the application into different namespaces. Port, it's the simplest unit of deployment. So port ideally maps to your container. In general, as a best practice, you have one container per port but it does support multiple containers in the same port as well. What is the way in which you manage the state of the data for your files. If you want to manage let's say database objects or database files if it's a batch process that you're running which creates a set of CSV files inside the container and you want it to be accessed outside once the container is stopped or once you want to upgrade the container. If you need some state food processing and you need to purchase those files you use wallet. So it's like a map, right? That's how you map between container and your physical volumes. Service, we will see service in action shortly. And these are basic objects, low-level objects. On top of this, it provides controllers which are like higher-level APF. So this is what helps you in creating a set where you want to have more than one replica of the containers. Deployment which helps you to define a template for deploying your applications. Stateful set is when you want to deal with stateful data. So this comes handy when you want to deploy container and mainly database containers. And you want that database containers have a stateful persistence. Demonset, it's like on your let's say, Unix boxes. So if you want to collect, let's say, metrics from each of these containers which are running, you can define a demo set and that will be used for collecting additional information about the container. So it's like a demo running on your physical box but the demo set is running inside the container. So port, it's the simplest object of deployment in the set. It has various things associated with it. First one is IP. So when you deploy a container inside the container, it creates its own IP for each and every port. It can be a group of containers but in general it will be one container for port. It contains specification how to run container along with its resources. So in this example here, we've got four different variants of port. One, which is just the first one, port one, it's just a container. Port two has container as well as a test suite. Third one is multiple containers and volume and fourth one is combination of this thing. Next one is the deployment. So deployment is like a template find. So in the deployment you define what is the desired state that you want to have for your application. You can define things like how many replicas you want to have, which version of your container you want to deploy, what is the update strategy. Or do you want to update one at a time or multiple instances of the container at a time and various metadata associated with that. So if you can highlight it here, we are defining how many replicas. So one replica here there is a metadata which says what is the selector and the match table. We have the image information that is offered with which should be used, which version. It also has the environment variables in this image. So it's basically a template so if you are using something like chef or puppet it's like those recipes or things that you create in these tools. So this is how we want the target application state to look like. Let's have a quick demo of these features. So if you want to learn multiple containers how do you isolate them with each other like they don't share the same same space memory or something like that. Within the same pod they share that. That's what they have the same which are like this. So the IP is for the pod complete pod. So you can't do like a micro segmentation inside the pod for each another app. Let's start with creating a namespace. And create a namespace we will be using the command line to fix it here. I use this start with help to see what are the options which are available. So here you can see it provides to easy commands for a very beginner level intermediate environment commands for rollout, trolling updates, scale. You also have the cluster management commands which is to get the certificate cluster info you also have provisional commands describing the services just having the options which are available. And you do other commands. So let's start with the namespace which is quite simple. So I say and for this I will use the create command. Create again to go to the next level of commands. You can use help here to see what are the options you have. So I can create cluster mode, cluster running, config map, environment, namespace and all this set of options. So let's do create namespace and I will create namespace with termination space. So now the namespace is created for that information. I can get the description of this at the convenient space here and then I can say it gives me additional information about this namespace. I can also create this only if so as well as I can create command. So that's using command line. But command line is not the most suitable option and Kubernetes definitely provides us better options like most modern day tools. So we can use what is called as the manifest files which are like YAML files which describe the same thing using YAML syntax. So if you look here, here I'm creating a namespace called AKS Part 3 using API version 1 I need to define what is the kind of object I'm creating and a metadata associated with that and then I can go back to the command line and I can say kubectl create instead of creating object using the object syntax, I'll say use the file. I'll give the file name and it will create the same object for me. Later on in the demo, we'll see that instead of using single file, I can give a complete folder structure and whatever files are defined in that particular structure it will create all the objects. So kubectl is intelligent enough smart enough to work with single file as well as a whole set of files, folders. So if you have like in my case, I have here three folders under the Minicube. So I have API, the definition of manifest files for that, DB the web and the namespace. So I can go right at the top at the Minicube level and say apply or create and I give the whole structure. Just say file. It will create everything in one go. I don't have to go to each folder and do create or apply. These values, you usually find that when you start new space here, maybe one here or a typo and these things will not work together. So it's very important that the key values they match when you define them in these labels and wherever we are having these key values. Then we define the template and within the template again we have a spec we can start with the containers that we want to deploy. Since it's a collection for deployment, I can have the containers collection but in this case I'm having only one container which is the TechTops web which we built in the first part. I define some of the environment variables like this is my development environment and a spinet core environment value for that. I define what is the port, container port that I want to expose out of this image. What is the image pool policy? So here I'm specifying if not present. That means where this container is going to be deployed by Kubernetes, it will check if the same version of the image already exists. If it exists it will not pull the image from the container registry. So this is more for the optimization purpose. You can also specify always saying no matter what I want to deploy the specific version and pull this version of the image always from the container registry. Restart policy is if something goes wrong with this particular container what should happen? Should the container restart or Kubernetes restart this container or we want to deal with it ourselves. So I say always if something bad happens I want the container to restart. Then there is termination grace period which is like how much time there should be between the restart of the containers. I'm giving 30 seconds here. So just in case there is some cleanup work to be done I can use these 30 seconds for that. So let's see how to deploy this particular web app using the CLI. So here I have the namespace, techtox, api db and web as the folders I will create the namespace first. So kubectl create and I can say file file name oops okay it's already created. So this is the problem we have with create. So create purely tries to create the object. It's not like a absurd kind of operation in database. If the object already exists it will throw an error but we can use apply in this case. So instead of creating I can say kubectl apply and then I give the same file name. So in this case if it doesn't exist it will create if it exists it will just skip. I used the wrong file name here sorry. So we have the namespace let's go into techtox web I have the deployment and the web service definitions here. So I can use the same command here kubectl apply file name and web deployment. So this is already deployed so it remains unchanged in this case but if it was not deployed it would go and start that container on this single node cluster. I can get the description of this using kubectl describe so I have the deployment and techtox web okay. The reason it's not giving me any information because I have a namespace associated with this. So when there is a namespace associated I need to give the namespace as well. And the namespace I am using here is a case part 3. So now you can see all the information about this deployment what is the namespace it's using when it was created. What are the labels, what are the annotations, what's the selector, how many replicas does it need. Desired is 1, updated is 1, total is 1. So let's say we said we have a real cluster and we wanted 5 replicas and if there is 4 replicas running when we describe we would say we would get information saying desired was 5 and we have 4 running. So this is the kind of information we can get from the description of this. So once this is deployed how do I access this. So it's like deployment is done you have the web site running it's available. To access this I need to expose a service. So for the service you can go back and look at the service definition. So service the kind is service here metadata again. Each Kubernetes object will have its own metadata and that's how we link the namespace to it. Then the spec like for deployment for the service also we have a spec. There is a type in this case I am using node port. There are other types like we can use load balancer which will provision a public IP if you are running on a cloud or we can use there are 4 different options when it comes to the type of service. The node port that I am using is it assigns a node or a port to the service on each and every node of the cluster. So it's like even if the service is not deployed on one particular node let's say you have got 4 nodes in your cluster the replica is running. So 2 nodes will have your service deployed. You are hitting the node node 3 which does not have this particular service deployed because of node port it would still be able to service your request because it knows that the same node is node port or port is exposed on each and every node of the cluster. So this is one of the feature where you can use node port. Port is internal port that we are using from the container. So I am mapping what the container is exposing. So if you go back to the deployment you see here the container port is 80 which is exposed I am exposing the same port via the service and then the selector. Selector is a web front deployment. So this is what I can use to query this particular service definition from outside and this is actually what ties into the definition here. So you see here run web front. So this is how the service links itself to the deployment. So the deployment is like physical deployment and if you are using let's say IIS you physically go and deploy the files but you still need a way of exposing that as a URL. So that work in Kubernetes is done by service. So let's see how we can get the information about this particular deployment or the service. Because the port will be dynamically assigned I can use this command to get the URL of the web. So it is dynamically assigning the port number here as 32595 if I do the deployment again maybe the port number would be different here but you can see that this is how it is exposing the container application which is running inside the container. Then let's go and look at the API part. So for the API deployment initial part is similar we have the kind as deployment we have the metadata we have the replica selector but in case of deployment specification I am using a concept called as init containers here and this is one example where we could have multiple containers within the same port. So what the init container does is it make sure that before your actual container which is web API starts it needs some sort of dependency. So in case of my application I have the web API communicating with SQL Server 2017 and I need to initialize the database before the API can start communicating. So I can do that initialization as part of the init container and if you remember from the first and second talk I was saying just wait for the SQL client we will use it later this image we were still building it that time but it was not used anywhere so this is where I am using that particular image which has a SQL client installed and I am installing the initialize database script there. So last time you saw me running this manually whereas here what I am doing is as part of the initialization process I run a init container which make sure that this runs first before anything gets deployed as part of this deployment. So by running init container I am making sure that my database is ready before the application can start communicating with that and then rest of the part is same when it comes to the actual container it is running the API, Tectox API version I am passing some parameters like the database connection string I am exposing a different port here and the rest of the part is same restart policy termination. In terms of exposing this there is no change so it is exactly same to the web so only difference is the label the selector that it is using which is Tectox API here and let us look at the database part so this is where I am using a different kind of object which is state full set so as I mentioned initially this is helpful when you want to have a state full processing when you want to persist data and your container should have a stable state associated with that so I am using object called state full set and it has a special service name associated with that and the remaining part is similar I am not doing any changes so in this full set I am going to instantiate the MS SQL server Linux version which will run so what basically happening here is we start three containers one for database one for API one for the web and your API container has the init container which initializes a database inside this container and then the application uses that I also have the security part here where we can define a password for the assay account that I am using we can put it inside a manifest file so this is helpful when we have a clear separation in terms of who owns the deployment part and in many organizations you have a ops team which manages the production passwords and dev team does the deployment and we just use the secret we do not know where the file is located or we know where the file is located but we do not know the content of that so in this case we can use you know a dev team can work with these passwords we can still say that my state full set is going to use this secret from a file using this assay password but I do not know how that is generated so ops team can generate it and store it in the format here so this is another good practice we can follow but to keep things simple here I am using just plain text password this is the same password I am storing inside that file ok so let us go back to the presentation so we talked about we looked at namespaces we looked at deployment little bit about the service so service is like the stable endpoint what do we get from a service is it provides load balancing capabilities so if in this example I have got let us say two instances of my api running I have a replica factor of two and it is running on node one node two my front end web application can talk to it using the service discovery mechanism of Kubernetes and it gives this tech talks api as the service so I do not have to really point to node one or I do not have to point to node two it is like the load balancer that we have in normal web servers but this is the software load balancer it also provides a stable ip so let us say you have four or five different machines physical nodes in your cluster and because of the restart or because of your upgrade of the version of application initially these two were running on node one node two and version two of the application starts running on node three so you do not again have to go and change the front end application because it is using service discovery it is referring to this using the services it can still work no matter where the container is scheduled by the orchestrator so we had a look at the state full sets so as I was saying it is really useful when you are dealing with databases and you want to have state full persistence a good part about state full set is even if your pod crashes or even if your cluster goes down and you have to restart the cluster it would still be able to work with the original set of data ok so let us look at the control plane so this is like the management portal of Kubernetes and the way I can access that is using minicube dashboard so this gives me information about the cluster state so I have cluster what are the namespaces inside that so by default Kubernetes creates three namespaces default cube public and cube system if you do not specify the namespace all the objects that we create would be under the default namespace we have the list of nodes in our case since it is a minicube cluster there is only one node called minicube persistent volume I will talk about this when we start deploying to cloud in the next version roles Kubernetes has support for role-based security so we can have a very fine gain control over who has access to what resources we can define that here storage classes again I would come to this in the next one we can filter on the namespace using namespaces here then we can look at the workload complete overview of also what is deployed so how many deployments happened how many pods are there how many replicas are running how many stateful sets I can get the information about each and every deployment each and every pod so all the objects that are shown if something is happening in the cluster I can get the information about that cluster here I can drill down into each one of these objects and find more information about what events occurred what time did they happen and so and so forth so all this is available this is the same portal we will get when we run a full-fledged cluster using Kubernetes so this is another area where I find it really useful that you can do exactly the same thing in a cluster or in a single node cluster no this is about what is as I said right Kubernetes is your deployment of the containerized application so it tells you what is the state of the Kubernetes cluster not what is running inside that particular container this one no this is what I defined in my manifest file so this is that additional metadata that I can use I can filter based on these labels so let's say I have different namespaces and I want to filter on particular namespace that's what I did here when I chose AKS part 3 as the namespace so it's showing me only the objects related to this namespace I can use this the labels for other scenarios where I have things like production cluster or UAT cluster or dev cluster I can use this kind of metadata and then I can filter those objects based on that metadata so it's basically a label and here when it comes to pod and as well as states full set and the replica set you can also see the desired and the actual count so one of one means I requested one and I have one running if it is not matching I would be able to see it here yes yes you can have that this is what I was saying about the cluster IP or the node IP so if you look at the services each of the service has its own internal IP which can be accessed only via the Kubernetes resources this is not exposed outside so I can't access this outside of the cluster so since one example here is the database database is running you can see from the application here where I was using that if I go back and if I hit this this data is coming from the database the initialization script that I ran but I can't use a tool like SQL management studio to access that database because it is not exposed outside of the cluster only these resources the API and the web frontend can talk to it it's not accessible from outside if I have and in the next session I will show you how we can expose this using the public IPs and we can have these secrets as I said so that's another good practice where you can register secrets within the cluster and these resources can use those secrets so this is the cluster IP and then we have those nodes that we are exposing or the ports that we are exposing so if you look at the web front I was exposing 80 which is the container port which is the node port because I said I want the node port to be exposed so it's exposing this dynamic port here I can also make it static if I want I can say every time the container is created I want to expose port 80 only that's also possible so we looked at these kubectl commands various of them here are some references so the code demo it's available the complete source code on GitHub like Docker if you remember last time I shared with you play.docker.com or some site which allows you to run Docker within the browser you can do the same thing with Kubernetes you have Kubernetes playground labs.playwithk8.com I found this particular pdf very helpful it gives a sample application with various objects that I described here there are two other links which I really recommend that you spend some time reading the Kubernetes theme park analogy and the illustrated children's guide so this explains you Kubernetes in the most layman terms so this is the it's like telling to a kid, small kid what Kubernetes is and this is really illustrated that way it's like a story you might have seen this but I find it really helpful you know when you are trying to link stuff like what is a container what is a pod what is a service why do you need this why do you need replicas these kind of stuff for a non-technical person this is really really helpful similarly you have another one which is slightly better I would say you are not at a kid level more at a college level let's say which is explaining Kubernetes on a theme park analogy there is another analogy which I came across in one of the articles it was about the air traffic controller or airplanes and so the author he was equating docker containers, individual docker containers as airplanes which are flying everywhere and then you need somebody to control those planes so that's where something like an orchestration engine like Kubernetes comes in who can say okay which way you need to go and land if there is a change in the schedule so that's like version changes how do you inform the customers who are going to come and land that plane so that was another analogy which was used so I really recommend that you go through these two links and that will really help you to understand the concepts behind Kubernetes they really explain it very very nicely and then there are other links which I have there is also the links for YouTube videos that we recorded for I will share these slides if you want I can put it on the meetup as well no problem which one yes this is the one okay there is another thing which I usually do how many of you know that PowerShell runs on almost cross platform nowadays yeah so I am using PowerShell script so instead of running you know individually all these I have a small PowerShell script which I can share with you so I run the same set of commands here but using PowerShell so this deploys the complete application for me and it also destroys it so I can show it to you quickly let me go and do a tear down of this so this will go in the reverse order so if I deploy web first then the database and then the API it would delete those instances in the reverse order here down with the modules first yes so done I can then deploy the same one oops some problem okay it is still getting terminated so that is why it is giving that error but if I run it after some time should be fine and now if I go back to the cluster state I should see what is happening so you would see a difference you can see in real time what is getting deployed what is the state of each and every object and you can almost follow it so thank you any questions if you can help with the feedback that would be really good it is like 3 or 4 questions it would be helpful for me as well as the organizers of this meetup to improve yeah I am happy to take any questions if you have the could be in a case this do load load balancing want to deploy different instances different instances at the node level or at the application level application level what do you mean by load balancing can you explain little bit more something like I want to scale up my application if rows of my users yes how do you do the load balancing load balancing you can define the number of replicas you saw in the manifest file so I can say how many replicas do I start and then there is in the advanced features you have like monitoring of the load so you can check what is the load on that particular application service and then you can scale so you can monitor let's say the memory usage or the processor based on the kind of applications whether it's memory intensive or processor intensive and then you can set thresholds saying you can monitor application matrix saying in let's say one minute you are receiving more than thousand request let's say you can service up to thousand request with three or four replicas but the moment it goes beyond thousand and if that happens for continuously two minutes or three minutes you know that your application will not be able to handle that so you can scale there is limited monitoring within Kubernetes to do this but there are other tools which are built on top of Kubernetes which allows you to do that multiple virtual machines I can show it to you next time that's the next session what if we have native commands of Kubernetes instead of apply we have to just see what it happens dry run it's there you can do dry run actually similar what's happening like anything it is failing any dependency it's possible I haven't tried it but I think it's there any other question I have some t-shirts from senta mill so one can you catch if it fits you yes if not you have to contact senta mill somebody had a question at the back yes yes Istio is like next level so when I look at these different services right Docker is like level 0 level 1 Docker compose may be level 2 Kubernetes Docker swarm these deployments I would put them level 5 level 6 and then on top of this you still need something that is Istio when you want to run production at scale you need a tool like Istio Istio Istio Istio Istio Istio it's a service mesh so it works on top of Kubernetes so it gives you the ability to define rules it gives you the ability to define uh faults you can inject faults into your services you can really do things which is not possible using current technologies but I can use cloud foundry or something like that to do a lot of stuff on top of Kubernetes correct but what Istio provides you is a concept called a side guard container so it creates a container in the same node as your own application container and then you can just with some minor configurations without changing your application code have metrics which can go into things like Prometheus you can have uh which is the tracing distributed tracing all these really production grade services right which you would otherwise spend a lot of time configuring and monitoring it comes built in into Istio so you just by means of configuration can get this working normally production people either use concrete with Kubernetes Prometheus is one thing