 Welcome to this GitLab video. Today, we're going to take a look at creating Kubernetes clusters on GKE from within GitLab. First, let's talk briefly about what I just said. Kubernetes is a container scheduler. It's an open source platform designed to automate the management of your application containers from deploying to scaling to operating. While virtualization technology statically partitions your servers into smaller VMs, Kubernetes allows you to partition as you go, depending on how much or how little resources you need at that time. Scaling up and down is necessary. You can respond quickly and effectively to customer demand while limiting hardware usage and minimizing disruption to feature rollouts. With container schedulers like Kubernetes, the focus shifts from the machine to the service. The machine becomes an ephemeral, disposable element. GKE is a container engine service from Google Cloud Platform that lets you easily spin up one of these powerful Kubernetes clusters with the touch of a button and handles the management and updates of the cluster for you. This can easily accelerate your group's move to cloud native. Next, we're going to jump into GitLab and create a GKE cluster from within GitLab. Install Tiller and Ingress, two services that will help manage the scaling and inbound traffic to our cluster. Set up DNS so the outside world can reach our cluster. Set up AutoDeploy for a project within GitLab and show this entire process for idea to production in less than five minutes. In GitLab, first, I'm going to go to CICD and click on clusters. Then I'm going to go to Add a Cluster. From here, I can click Create on GKE to spin up a brand new Kubernetes cluster. I'll have to do OAuth authentication with my Google account to allow GitLab to create the cluster. I'll select the correct account. Now I can give the cluster a name and the cloud platform ID of the project that I'm going to create the cluster inside of. In this case, GitLab demos. Then I simply click Create Cluster. GitLab has automatically spun up that cluster on GKE. If we go over to Google Cloud Platform, we can see the cluster being created right here. It'll take the cluster about three to four minutes to get spun up, so we'll skip ahead here. Now we can see the cluster is created. And if we go back to GitLab, we can see that successful creation is noted there as well. Now that we have GKE installed and the cluster connected to our project, we can see all those cluster details on the same page right here. From this page, I can also install the Helm tiller. Helm is a streamlining application to help with orchestrating Kubernetes clusters. And Ingress will allow the outside world to get into our cluster. GitLab also allows me to have multiple clusters per project so that I can have one set to the environment of test and one to production, for example. Now I'm going to jump back to Google Cloud Platform to get the Ingress IP address. Here's the public IP address of my cluster. And I'm going to set up my DNS, which I also host in Google Cloud Platform, to point Friday.football, my domain name, to that IP address that was created by the Ingress service. Once that's created, I'm going to jump back to GitLab and set up auto deploy. When I click on set up auto deploy, I can apply a template of Kubernetes for auto deploy directly into my GitLab CI.yaml. I'll replace the cube domain with my Friday.football domain from the previous step. And I'll go ahead and I'll save this default GitLab-CI yaml. I'm going to go ahead and make a merge request into master for this and submit that merge request. And we can see the tests have already passed in the background and I'm going to go ahead and merge that into master. Now let's go look at the pipeline that was created from that new yaml file. Here we can see that it's automatically orchestrated this pipeline with build staging and production. Once the build completes, GitLab will automatically deploy my app into staging on my Kubernetes cluster. We can see that now that that's complete, I can go to environments and click on my staging environment and see my live app at my domain with the staging flag. By default, it's a manual step to get this into production. So I'll go back to GitLab and say deploy to production. And then once that new pipeline that it creates for the production environment completes, we'll see the production app. Here we can see that the production app has been deployed into the environment. And at my domain, I have a production app running. Now let's say I wanted to change something in that app. For instance, wanted to say hello from AutodevOps. I could simply go back to my project, make that change, have it deploy to staging automatically, and then I can deploy it manually to production. Here I'm going to go into the server RB file. Here we can see the messages hello from GitLab. I'll change that to my desired hello from AutodevOps on gitlab.com. I'll commit that file directly in the master. We'll see that the pipeline kicks off automatically to deploy that change into staging after the build. We'll go to environments and take a look at it on staging to make sure it looks okay. Yep, that's exactly what I wanted. Now with one button click in GitLab, I can deploy that directly into my production environment. Thank you for watching this GitLab video. For more information, you can visit about.gitlab.com.