Kubernetes 101 for Python Developers

Speaker 1 [00:04]

Okay, so the idea for today is to go to a couple of learning goals. So the idea is to learn how to structure a modern Python API, sorry, a modern Python application. We want to use Terraform, which is an open source project to manage infrastructure, infrastructure as code. So, we will use different commands, mainly create and destroy. We will learn some basic concepts related to Kubernetes and to GKEY, which is the managed solution from Google for running Kubernetes. And we will try to move our application from your local machine to the cloud inside Kubernetes cluster. So, raise your hand if you have some knowledge about Docker. Raise your hand if today is your first day in which you use Docker. So there are like a couple of concepts related to Docker. One of these is Dockerfile. If you open the folder and you check the Docker file, you should see something like this. And this is a Docker file. So a Docker file is a way to specify the way in which you want to build Docker images. And in this case, if you have Docker on your computer, you can run this command. And the idea is to build your first Docker image in your case, if it's like your first time. So on your computer, it probably will take more time because I had the cache on my computer. the command. And in this case we are specifying that we want to use the local Docker file. We want to create a new image with the dash tag. This is going to be the name of the image, pyBootCamp slash Bazil and then we are going to use a tag 01. And we are also using a new feature of Docker which is the target and with target you can specify which part of your Docker file you want to build and if you go back to the Docker file specification you will see that there is a part where we define something as production and with target we can say to docker okay build the image using only this part of the definition and skip the part related to for example test in this case and this is really handy not just for Python but other for other languages for example a good example is go because you can just have like an image to build your to compile your go program and then after you have the binary file you can just copy the binary file and you can have a very tiny tiny image are you building docker image so you should see something like this inside your console yeah Sure, just in case you have the slides also, you have a folder called slides, the slides are just a markdown file, so in this case it's the docker.md, so you also have a copy of these slides on your computer. So any question related to target? You get an error? Is the only one getting an error? Okay. But the slides, yeah. Is anyone building the image? Okay it's working, no error, okay. Okay, and if you have Docker Compose on your computer, now we can run the Docker image that we just built together with something else. Depending on the terminal that you're using, you probably need to specify this command in a different way. If you're using bash, you can just run the command in this way. And it's a way to inject m variables inside your docker-compose file. And I will tell you more about this in a couple of seconds. So this is the command. We are using docker-compose which is a python application. So in case you don't have docker-compose you can just pp install docker-compose. So we are saying to docker-compose to start all the services to find in the docker-compose file and with dash d we are saying that we want to detach the containers and basically we want to run them as a background services. Like, if you're still fighting with pods, you just forget about this. You can just use the container. It's the same thing. You build the image and you run this command. You should see two containers running on your computer. If you click on this link, if you have this light on your computer, just forget, you should see something empty in your case. And just to be sure, you should see something like this. If you type slash health check, you should see status OK, and you should see the ID of your container. So docker-compose you should see the containers running on your machine. In our case we have the image that we built before and we have the radius which is a dependency of our service. So if for any reason it's like taking too long, really really too long. The thing that you can do is to just do docker pull with this tag. There is already an image available online. are not yet there, yes. So the command is just docker pull and then you need to put the pi bootcamp slash Bazel and the tag. Okay, so if you connect to that URL you should see a list of events. In your case it's empty because we didn't had any events yet. So again if you type docker ps you should see two containers Redis and the other one Bazel and you can also use docker logs to see the logs coming from your application. So you should see a mess like this. So you can try to play with slash health check, your application will receive the request and it will log the request. I will try to do something like this. Okay, does the log format look familiar to you? Because it's not like the usual Python format. Okay, have you ever logged like in this way? Okay, we are just logging using JSON. So it's like using a Python concept, it's like a dictionary, so So we have a key and we have a value, and this is like the format that is also used by Kubernetes. So in the future, like when we'll migrate to the application from your local machine to GCP, the idea is to use logs written in JSON to collect all the information. So we can add more context, we can add more information when we log, and you can see that we have a concept of event. We have the container name, so we can enrich our logs. We have a timestamp, we have other things. And just to give you more context, we are using struct log, which is a Python library. one okay so we have two containers running on our computer one is the Python application the other one is Redis that we use storage as a database do you have questions so far so let's talk about Kubernetes have you used Kubernetes before? Raise your hand. Okay. Okay. So Kubernetes is a big open search project. There is right now, I think it's under the cloud foundation. So there's also a foundation behind this project and other projects related to cloud native infrastructure and so on. So, and in just sentence. Kubernetes is a very big application to manage container and managing container is a big thing. So you can manage like the state, you can put containers together, you can spread your containers across different machines. So it's a way to manage distributed workload across different machines, across different regions, also across different cloud providers depending on the way in which you run kubernetes so basically it's a way to manage containers and you can do pretty much whatever you want with kubernetes so you can create a cluster which is a collection of virtual machine or bare machines in our case we will try to deploy our python application you can also run cron jobs you can define the number of running containers that you want for your application so you can share the workload or you can like load balance them you can easily add and remove nodes to your kubernetes cluster and something really nice is that you have a centralized way to collect logs and metrics and generally speaking you can be happy, especially after the six months after you learn about Kubernetes. So like I said at the beginning, Kubernetes is a fairly really complex project. This is the high level overview of Kubernetes. So we have the infrastructure which can be like a real bare machine or can be just a virtualized resources like um a virtual machine you have the operating system running on your machine you have the container runtime which can be docker or something else and then on each node you have the kubelet the q proxy and other things and these are your container um and also in kubernetes you have different concepts about nodes so you have nodes when they are workers so you can put your application there you can deploy your services there but also you have the concept of master which is the main controller and there you have other services running so kubernetes is not just one thing is a collection of multiple application and like I said before there is some sort of distinction between a node and a master or between a worker and the master but at the end it's not really real because you can also have a master which is running workload and which is running also your application so it's really up to you and it's not really related to you know a proper definition inside the Kubernetes documentation. So like I just said you're free to run any kind of workload on the master although it's not really recommended. In case you're using managed solutions like GKE which is Google Kubernetes Engine, EKS which is the Amazon solution and EKS which is the Microsoft solution from Azure, you don't operate the master node. So you just have an API endpoint to use Kube control and to connect to your master, but you don't see the master inside your collection, inside your cluster. So one of the distinction between a node and the master, like I said, it's pretty artificial, but there are like some components which can be defined like, okay, this component should run on the master and other components should run only on nodes. So on the master node you have the Kube API server, the scheduler, you have the control manager Etsy. Have you ever heard about Etsy? It's a distributed key value database so it's where Kubernetes stores its configuration. And then we have something which is called cloud controller manager which is specific to each cloud provider so Google has its own cloud controller manager which are that object that depends on the implementation of the cloud provider and then as you can see the number of components that you have to run on like on a single node on which is not master they are they are just three which is kubelet, the kube proxy, and the container runtime. Like I said before, Docker is not the only container runtime that you can use. It's definitely the most common one, but you can use other ones, like RKT for example. And so that's the high-level architecture of Kubernetes. And something else which is really important are Kubernetes objects. So Objects are just resources, entities inside your Kubernetes system. A node is an object. Have you ever heard about the concept of a pod? Okay. A pod is another resource. You have the same with secrets, which are secrets. So configuration that you can share across your cluster. Volumes, which is a way to store data and to share a storage system inside your cluster. You have other, like the list is very long. So you have configuration, you have config map, deployments, and apart from the official ones defined by Kubernetes, you can also create your own. So it's quite flexible. And something really important about the philosophy behind Kubernetes is that you can find the desired state of your resource, and then Kubernetes will do its job, which is to keep that state. so if you say that you want to have two containers running inside one node you just need to specify that and kubernetes will try to maintain that condition do you love yaml because if you want to do kubernetes you're going to play with a lot of yaml so every kubernetes object is defined with a yaml file this is fairly easy but it can be really really pretty long so there are like four things which are fundamental which are required by the API which is the API version the kind in this case we are defining a deployment object and then we have spec which is the specification of our object the YAML file I mean the configuration for the object are fairly complex sometimes they are also quite boring, my best advice is to check this link. You can see the documentation for the deployment specification. Like I said before, for any object you need to specify four things, which is the API version, because depending on the Kubernetes version you can try different things. You also have some beta extension or some features which are experimental, so you need to use a different version of the API. The kind is really specific to your object so if you're defining a secret in that case kind will be a secret. If you're specifying a configuration map in that case kind will be the configuration map. And the specification is different between objects because when you want to specify a secret you don't have to specify for example a number of replicas which is a number of container that you want to run in hpod. And then something let's say more common especially if you have experience with docker which is the name of your container, the image and the port. So how do you connect to your kubernetes cluster? There are different ways but the main way is using the kubernetes API. So there is an API specification as part of the official documentation you can check it. And the best way to connect to your Kubernetes cluster from your local machine is using kubectl, which is the CLI to interact with Kubernetes. And there are mainly two ways to manage objects inside a Kubernetes cluster. One is called imperative and And the other one is called declarative. And yeah, we will see the difference later. Is anyone running like a Kubernetes cluster somewhere? Staging, production, or is trying to migrate from, I don't know, a cloud provider to Kubernetes? No one? We're trying, okay. So there are different ways of running Kubernetes. So if you're running on Windows, sorry? Sure. Yes. No, the list is so long that I put like the dots. So it's really up to you, yes. But like, so there are really multiple ways and there are like, so like I said at the beginning, running kubernetes is really like a teamwork if you want to run kubernetes on your machine it's pretty easy because you for example if you're running on osx on windows you can just install docker and you get kubernetes for free like here you can just decide you can just run your kubernetes cluster so it's it's pretty okay if you want to test something but if you want to let's say set up a cluster on AWS, you need to install all the components. So there are like different projects to do this. I think Copes is one of these. Minikube and MicroKubernetes is to run Kubernetes on your machine. There are also managed solutions like Google Container Engine and other like OpenShift and other things related to that. There are also different ways of running Kubernetes. You can have like the manage solution which is run by a provider, you can just think about one of the main cloud provider AWS, Azure, Google, also DigitalOcean is providing Kubernetes as a service and in case of managed solution you only need to worry about the application. So you create your docker file, you ship your docker image somewhere and then you just specify your deployment CML. Or there are like different solutions so you can also have like the custom solution where you take care of everything. And the goal of today is to use GKEY, which is the solution from Google. You can check the link. And it's the official managed offer by Google, which is pretty nice and so far one of the best implementation. So any question? Any question related to Kubernetes, objects, imperative, declarative? We didn't touch yet, that's different. So Google Kubernetes Engine. So the GKEY offer from Google is managed, like I said, so you just need to specify the number of nodes. They will take care of all the rest, like upgrades, managing your master, it's production ready, so it's not like a beta feature coming from GCP, and it's a nice way to run containerized application on Google. So, long story short, you can just go on the user interface, the Google Console, like in this case. If you click here, then you click here on the three bars, there is Kubernetes Engine, You just click here, create a new cluster, you specify the number of clusters, the location, like the region or the zone, you specify the version of the master, specify the number of nodes, and then you click create. And in five minutes you can get the Kubernetes cluster, which is really really interesting and it's really really interesting for many reasons so like I said before managing Kubernetes cluster it's really a teamwork also it's a distributed system yes no no no it just was just a way to show you master and worker nodes are managed directly by Google so you can they will take care of upgrading the version it's also well integrated with the rest of their infrastructure so we with I don't know there's a private network all the other services like databases cloud functions and cloud storage and everything that you might need there is also GPU support, which means you can have nodes with GPU. There is a really nice integration with Stackdriver, which is the Logging and Metrics solution by Google, and it's free in the sense that you don't pay for the service, you just pay for the nodes. So it's the same like running virtual machine, you just select three nodes and you will pay for three nodes. There is no strings attached to that, so you don't pay Google because Google is managing your master. So just to compare the different solutions. So you can run your own cluster. But like I said, it's really complex. So if you don't have like a specific team with the goal of, I don't know, DevOps team or operation teams with the idea, okay, they're going to take care of the Kubernetes cluster. It's not probably a great idea. Running at scale and in production distributed systems is really hard, also because you need to keep the state, which is not easy. And like I said before, providing HAE, which is high availability on a production system, depending on your workload, can be really a full-time job. So why would you run your own cluster? Because there are a couple of companies that are running their own cluster. and like an example is github so they are running kubernetes on bare machine bare metal so they don't use like virtualization they have servers they own servers and they run kubernetes on their servers any idea why github is running kubernetes on bare metal and not in the the cloud. Sorry? No. Any other idea? Yes, related to? It's related to IO speed, so access to the disk. It's much more faster if you're using like real computers and not virtualization. Another thing is that you can create your own cloud provider using Kubernetes. If you want to have full control over the master, things that you don't have with managed solution, you probably need to run Kubernetes on your own. If you don't use cloud solution and you have your own cloud, you probably need to run Kubernetes by yourself. And also, maybe you need to run the last version of Kubernetes, and in that case you need to manage your cluster. Any other idea to run, why you would run Kubernetes by yourself okay so back my suggestion to back to GKE my suggestion is yeah just try GKE is for free like you just need to pay for the virtual nodes you can also specify the the size of the virtual node that you want like for the for the machine so it can be also pretty cheap like and something really interesting have you ever heard about the concept of like printable or if you're coming from AWS you have on spot so you can also use nodes which are printable so you get a really cheap price and I mean this suggestion applies to all the cloud providers so if you're using AWS please check your solution and the same for Azure So and just to recap you get almost the same flexibility that you will get by running Kubernetes by yourself and you don't have to deal with the pain points of running Kubernetes on scale. You can easily like build and run your application without the dealing with really the bad thing about Kubernetes which is a distributed system so you need to run like multiple instance I don't know, Etsy or the master for example. And like I said before, especially if you're migrating towards, I don't know, operational DevOps, GKE is well integrated with Terraform, which is a way to manage your infrastructure. Question? Question related to GKE or cloud providers? Okay, so Terraform, have you ever heard about Terraform? Okay, have you ever heard about AshiCorp? Yes? Okay, so AshiCorp is like an open source based company in the sense that they have open source product and that they have enterprise version. Have you heard about Consul? Consul is another thing from MashiCorp. They also have Vault, which is a way to store and distribute secrets. It's a really nice company, you should check it. Have you ever heard about the concept of infrastructure as code? So before I was doing something like this, right? So I was using the user interface provided by Google to create a cluster. Just think for a second that I need to do this operation 10 times. So I need to remember every time, like the specific sites, and I need to press create. This is really boring, no? And the thing behind infrastructure as code is to have everything as a code. So you will specify the cluster that you want to have, you will specify the number of nodes, you will specify the provider, and then you will just apply this configuration. And and you will put this configuration together with the rest of your code. So this is the concept behind infrastructure as code, and Terraform is one of the solutions that you can use. So ideally you want to have your Terraform configuration, and then you just apply that configuration. So like I said, the pros is that you don't have to fiddle with the user interface anymore, you can also version your infrastructure, so you can have upgrades or downgrades, you can add more nodes and things like this, it is, you can easily destroy and create complex infrastructure just using two commands. And it makes really easy to have the same infrastructure replicated across different environments. So I want to have the same infrastructure but I want to have different names for example. So my cluster in staging should be Kubernetes cluster staging. In production it should have like a different name. The cons is, well, you need to learn the Terraform definitions. And another thing which is specifically related to Terraform is that you have this concept of states. Because when you create something, Terraform has to know the state of the infrastructure. Like, okay, I created this new cluster, I created this new, I don't know, container, and I need to remember this. because the second time that you're going to apply like a change I need to know where to start. So if you look inside your folder inside your local folder there should be a infrastructure directory and you have you should have like mainly five files sorry four files and another folder so you have a cluster which should be a directory, you have a main.tf which is the entry point for the Terraform configuration, you have the Kubernetes folder which is the folder where we define the YAML file for Kubernetes, we have Terraform.tfvars which is a way to define variables inside Terraform and then we have variables.tf which is a way to define the variables which are needed by your Terraform configuration. And if you go down into the cluster folder that's where we define our cluster configuration plus other things. Again, we need to specify always a variables.tf. There is also a concept of roles inside Kubernetes. So basically, you can create new user or groups, which are allowed to perform some sort of operation inside your Kubernetes cluster. Then there is the network.tf, which gets related to VPC and subnetworks inside your cloud provider. We have the ingress, which is something specific to Kubernetes, which is a way to connect like public internet to your Kubernetes cluster and get access to application running inside your Kubernetes cluster. And you have the gke.tf, which is the specification for your Kubernetes cluster. So if you open GKE.tf, you should see a file like this. This is the Terraform syntax. So after sometimes it can get pretty boring, but it's a way to specify what I was doing before inside the user interface. So we have a name, what you see there is the interpolation that you can do with Terraform, so I can change the cluster name with something and the same with the environment. We also need to specify a zone for your Kubernetes cluster, you can also distribute the doc across multiple zones, it's up to you. Like I said before it's well integrated with the other Google resources so I can connect or I can put my Kubernetes cluster inside the private network. You can also specify different login service so in this case we want to use the Kubernetes from Google so we will connect directly to Stackdriver. Then there is like a bunch of other things like HTTP load balancing and we don't want to disable this feature. I will skip this and I will just go through other important things. So another thing is that we can define a maintenance policy for our cluster like Google as manager of your cluster can operate the cluster and do some operation and you can specify when you can start. So before we were defining our cluster and now we need to define the nodes inside our cluster and this is the definition of a node. So again you can specify a name, you have a location, you have your cluster which is the high level object that we created before. Like I said before you can use also printable nodes and you can specify this condition with this variable like printable equals false. So these nodes they are not going to be printable, so Google cannot claim them. And then we can specify the machine type, the disk size, you can write also a different set of disk type, so in this case we're using SSD. We want to disable some legacy endpoint and then we want to authorize our notes to access some Google API. So dev storage, login right, monitoring and service control, service management and trace. This is like the example that you can get from the Terraform documentation, so there is nothing really fancy here. And then other things related to the management like auto repair, yes, auto upgrade through, so Google is going to perform all this operation for you. So back to Terraform we have four commands mainly. So Terraform init, Terraform validate to validate your configuration, Terraform plan to plan the infrastructure that you need to build, it depends on your state, and Terraform apply to apply that configuration to your cloud provider. So if you see the inside your infrastructure folder and you type terraform init, you should see something like this. So terraform is initializing your local folder, downloading all the components that you might need. So for example Google is a component. This is the command that you need to run. So in this case Terraform is downloading all the GCP API definition because with Terraform you can also use different cloud providers. So you can create a cluster of machines on GCP, on Google, but you can also do the same with AWS. Good question. So if you go inside main.ef, that's the entry point for your like terraform files and something that you can do is to define like the required version for terraform and this case is between is the 0.12 version and then we are specifying that we want to use a cluster module and then below this you can see the provider Google sorry yes yes for terraform is just important that they will have a dot EF and then if you load everything nope so we are telling terraform to please download the Google provider okay with this part inside so if you check the for documentation they are like different providers. Google is one of them. You also have AWS, DigitalOcean, Azure and so on. In this case we are using Google and then Google has, I mean the Google provider has a certain set of resources. If you go back to GKEY, the Google container cluster is a resource that you have inside Google as a provider. So if instead of having Google here, I don't know, I will have AWS, and I was running the command, it will probably log like an error saying like, you know, I don't recognize the resource Google container cluster because AWS doesn't know that. So the resources that you can use inside your Terraform files are related to the provider that you're using so just to give you like more context if you go to terraform provider Google there is a really good documentation for every provider so so here you can set you can see all the resources that you have available under the Google provider and you can access all of them but they are specific to the provider so there is not like so the interface is specific to the to the cloud provider I cannot just switch to AWS and keep using the same definitions in my GKE file okay did the terraform it work? Okay. Cool, now the next command is terraform validate. It's just a way to validate your configuration, just formally. It doesn't do any particular check. You can consider it like a linter. So my configuration is valid. and this is one of the most important command that you have inside Terraform we are saying to Terraform to okay Terraform please consider my configuration plan the changes that you have to make considering the state which might be empty like in this case save this the plan in a file called TF plan and don't wait for my input so dash input equal to false and if I run this command I just want to show you this part okay here Okay so refreshing Terraform state in memory prior to plant. So before like doing a plant, Terraform is checking the state, it's trying to update the state if maybe it's a remote state, and then it starts creating the plant, which is this one. So what you see here are all the resources that you need to create, that Terraform needs to create, to create your infrastructure. So using the file that are inside my infrastructure folder this is all the changes that need to be applied to my cloud provider yes there was a question have you run to the G cloud house part yeah you really need to complete the G cloud part did the terraform plan work for someone yes so you see the plan as well does anyone see the plan so the question is if we use terraform are we limited by using only a cloud provider no you can also you have different provider and you also you can also run like bash command so if you want you can create like terraform configuration to run your own cluster okay so we we created the plan the plan is on our computer if you do LS you should see a file called TF plan and now it's time to apply our plant just remember before applying double check that you went through the Google Cloud part. Especially this, gcloud services enable. This is really important because otherwise you will get errors. So before applying your command please enable the compute.googleapis.com and containers.googleapis.com and what we are doing here is just we are just enabling this API for our user. Okay and with some magic Terraform is applying the configuration. Also Terraform is really smart, and it's really smart in a way that it knows the order in which to apply the configuration. So if you want to put your Kubernetes cluster inside a specific sub network, the right way to create this thing is before you create the sub network and then you attach the kubernetes cluster to set this sub network and terraforms know how to perform this thing so you don't need to specify an order in which you want to create your infrastructure but terraform will will get that and it's the same when you want to destroy things right you don't want to destroy the network uh where your kubernetes cluster is running so before you destroy the kubernetes cluster and then you destroy the network So here Terraform is connecting to the Google API and is running all these commands. Yes, so if you go here, you see I'm creating a Kubernetes cluster. So inside the API you can see that Terraform is connected to the API and you see there is this circle spinning and it's creating the Kubernetes cluster. So there is this part of the configuration for the your pools I think and you can specify if you want to have the auto scaling and in case the the number of nodes that you want to have. So the interesting thing is when you try to mix things together. So, for example, you can have, like, non-premtible collection of nodes and premtible nodes, and you can activate auto-scaling on the premtible nodes, so you have really cheap nodes and they can scale, depending on your load. Okay, so the cluster is ready. Now Terraform is doing other things. So, as you can see, Here I have the green check on my cluster, and if you click here, you see all the things that we have configured before. So we have the location of the master, the location of the node, the master node is co-located with, so it's not co-located but it's located in the same region, and it's located in the same node. we have the network which is the network that we create inside our Terraform file and other things. What do you mean, to run Kubernetes or did the things that we just did with Terraform? I think we just did Terraform, but we're just using it at the end, the Google API. So all the things that you're doing with the user interface, you have Google API for this, and there is also feature documentation. So basically you can just authenticate yourself, and if you want, you can just write a Python script connected to the API and doing and you can do exactly the same with Terraform so at the end we are just connecting and there is also like a complex problem to handle like the graph of your infrastructure but at the end we're just using the Google API so Terraform is just an interface I have no idea if internally they're using Terraform for this but I don't think so maybe they haven't like okay like offer by Google I I don't so they are like different things so like other project I think it's one is terraform you can also use chef to like create your infrastructure so there are different solution I think there is also something from Google and the same from AWS but are specific to the cloud provider, right? Yeah, that's the thing. Okay, and now you should see the nodes inside your cluster. So in this case we have the name of our node, we have some specification, like the memory and CPU and so on and I'm done so like I have my apply has completed correctly correctly. Do you see the same? Yes, you can use bold if you want. Something that you can do is, so it depends, if it's related to configuration you can define configuration inside Terraform or inside Kubernetes. If it's about secrets it's a little bit more trickier because, so something that I do for example is I create secrets inside the Kubernetes cluster and then application running inside your Kubernetes cluster can access them but also other services because there is like the Kubernetes API so they can connect to them to the Kubernetes server and get these secrets. The problem is that I'm doing this manually. Yes, that's something that you probably shouldn't do. I don't have like a specific advice for that like it depends on your cloud provider so you can also create secrets inside GCP and then you can connect them to Kubernetes if you want. Specifically to Terraform, something that you can do is when you create like a service which is needed by your Kubernetes cluster, I don't know, like a database, so you can also create RDS instances or Google Cloud SQL instances and using Terraform you can create like a random password and then you can say okay use this random password and save this password inside Kubernetes as a secret. So you really don't touch that password. That's something that we're doing, for example. Sure. Not directly with Kubeflow, but you can have nodes with GPU and then you can use whatever you want so you just need to have the node with the GPU and the docker with the GPU extension and with the NVIDIA drivers for example well it depends on your bank account I guess but yeah it can be pretty expensive I mean the prices are the one that you can find on the GCP documentation for the virtual machines yes yes yes yes yes you can run only one node like in this case So in this case, we are running only one node, so we are paying only for one machine. That's not really related to the containers. like so you can have like multiple containers probably accessing to your gpu but that's then related to the gpu the way in which we you know execute all the uh yeah yeah so okay so we have an ip address which is a public ip address and that's the ip address of our ingress So it's three, so it's five past three, that should be a coffee break, but if you have like four minutes, I want to show you something, so, so if you see the inside Kubernetes, inside Kubernetes folder, you will see that we have three files. We have a service.yml, a job.yml, and a deploy.yml. So if you go back to the Docker Compose file, in the Docker Compose file we have Redis and the Python application. Now if you look into If you look into the service, you should see the deployment configuration for Redis because it's something that we need. So we need to have a Redis service running inside our Kubernetes cluster. And if you check the deploy file, it's the deployment related to our Python application. job application, the job.yaml, it's a cron job just to fill our Redis database with data. So something, yes now we have an empty infrastructure. So, can you read this command? So, there are also different ways to run your workload on Kubernetes. You can use the imperative way, which is using the kubectl CLI to specify what you want to create. like kubectl create this resource the declarative way is when we are using the yaml file so before using kubectl on our cluster we need to download the kubernetes credential and that's the command that you need to type it's probably also inside the slide but it's gcloud container cluster get credential the name that you see afterwards is the name of cluster, it's the same because we use the same terraform definition. The region is the region that finds our inside our terraform file and just because we don't care about getting the logs. So you should see something like this, which as yes should be also inside the slides somewhere yep keep control my mark down you have this comment and now if you type cube control get nodes you should see the nodes running inside your Kubernetes cluster. The next thing that we need to do after we got the credential is to run our configuration, so the service.yaml. The syntax is kubectl apply dash f with dash advanced dash file, and we need to specify the service.yaml, we pray plus, and that's the output that you should get. Kubernetes is creating the deployment.apps-redis-web created and also a service connected to RedisWeb. And if you do kubectl get pods, you see that Redis is running inside your Kubernetes cluster. and now you can do the last thing which is running your deploy i'm running out of time yes and if you get the services so it's get svc you should see three services and two are the one that we just created which is BuzzWeb, the Python application, and the Redis web. So, yes, just two things. If you manage to connect to your cluster, you can just do ctrl-get ingress. And you can wait, because sooner or later you should see the one IP address there, which is the same IP address that I got before this one so as soon as we have the application running Google will activate the the that exact like IP address and then we can connect to the our application last thing important if you care about your credit card is Terraform Destroy. So if you type Terraform Destroy it will check the state and it will ask you to confirm. My advice, okay I will do no, so just wait to see your application. You can do exactly, you can check exactly the same endpoints as if your application were like running locally, so lcheck and events. You can also do kubectl apply-f jobs.yaml and you can start seeing like events inside your application. Yep. You need to wait, you need to wait. It takes like a couple of minutes.