 Hello, my name is Cesar Saavedra. I'm a Technical Marketing Manager at GitLab. In this video, we're gonna cover the installation, configuration and use of a brand new GitOps capability called GitLab Kubernetes Agent. Let's get started. The GitLab Kubernetes Agent is an active in cluster component for solving GitLab and Kubernetes integration tasks in a secure and cloud native way. It enables the integration of GitLab with a Kubernetes cluster behind a firewall or a network address translation. It implements pull-based CICD GitOps deployments by leveraging the GitOps Engine open source project and it provides real-time access to API endpoints within the cluster. Presently, the GitLab Kubernetes Agent can only be deployed through our Helm chart. So in order to do this, we need to first install GitLab using Helm. So we're gonna follow the instructions and the documentation to install GitLab and we're gonna be using this script right here. So bootstrap script that will install GitLab on GKE and this script has a dependency of another script called common.sh. So I've already downloaded the scripts to my local desktop and we're gonna be running them, giving them specific parameters as indicated by the documentation. These are the parameters. So we're gonna run the script and this will instantiate deploy and run a GitLab instance on GKE. The cluster has been created on GKE and it's running GitLab and we had requested to use a static IP and that's the IP address that has been returned by the installation script. That's the Kubernetes cluster that is already up and running on GKE and what we need to do is we need to set up the static IP to our two domain names that we're gonna be using for this demo. The domain name is glab1.tanuki.host. There you go. And now we're gonna be doing a Helm repo at GitLab and I already added it, so it's already there. And we're gonna do a Helm repo update next and now we're gonna do a Helm upgrade install and this is the step that will be rolling out or installing a pod in the GKE cluster with the actual agent. We passed it some parameters, including the domain and the IP address, the cert manager, is your email as well and the global cast enable, we set that to true and that way we install the agent within this GitLab instance. All right, so the Helm upgrade has taken place. Let's check the running pods. Some are initializing, so let's check again. Okay, good. So the web service, which is the main console, the login console is up and running. So now let's get the password for the root user of this GitLab instance and let's go and log in to GitLab using the root account. Very good, so now we are logged on and the next step is to create two projects. The first one is going to be called the GitOps project. This is going to be the project that will be observed by the agent for updates and changes. Let's initialize it with an empty README file and let's create an empty manifest.yaml file. We'll do this for now and later on we'll populate it with some infrastructure configuration. Let's go back to projects and the next project to create is Kubernetes agent project and this project is going to contain the configuration of the agent which includes information about the other project, the GitOps project that will be observed by the agent, observed for changes and updates. We create a sub directory here under .gitlab agents and agent one will be the name of our agent that we will deploy to the destination cluster. Here we go to the documentation and we are going to copy the sample config.yaml. This is basically the metadata that is going to tell the agent what projects the agent will be observing for changes and updates and it's root GitOps project in our case. Very good. So now we have two projects, Kubernetes agent and GitOps project and the GitLab instance. So now what we need to do is we need to configure and instantiate basically deploy the agent itself to the cluster and one way to do that is through the Rails console but to get to it, we first need to log into the runner pod. So we're now inside the runner pod and then we execute a command to get into the Rails console and from there we can create a project which is pointing to the Kubernetes agent project we defined earlier. We also create an agent called agent one which is going to be the name of our agent and we create a token for it which we'll use in a little bit. So then we create a namespace in the cluster called GitLab agent and we create a secret and we use the token from the Rails console that we created earlier. So now we're going to go to the documentation and make a copy of the resources YAML file, example file and this YAML file is the configuration of the agent that we will be deploying to the Kubernetes cluster. I made a copy of it in my local directory and the agent is going to be communicating with the agent server using secure web sockets. Here is the domain information for the GitLab instance and it's going to be pointing to the Kubernetes agent project. So we apply this resources YAML to the cluster. Now let's see the parts are ready up and running the GitLab agent. As a next step we're going to go to the GitOps project which is the project that is being observed for changes and updates by the agent and we're going to edit the manifest YAML file for it and we're going to go to the documentation and copy the example manifest YAML file and paste it into that file and the repository. And as you can see the name space that this part's going to use is GitLab agent and the name of it is going to be NGINX deployment is going to have two replicas and it's going to talk on port 80. And as soon as we save this file we commit this to the main line the agent will detect this and will update the configuration of the Kubernetes cluster and bring up two instances of the NGINX pod. And as you can see here, the two instances are right there they're already up and running and to show you how fast the modification takes place and how fast the agent detects these modifications like let's increase the number of replicas from two to three save this and let's go back to the cluster and check the pods and we will see a third NGINX deployment pod up and running. So the agent is basically using a pool-based CI CD approach the cluster doesn't have to be exposed to the internet it can be behind the corporate firewall and the agent is actually reaching out to the GitLab agent server and applying the new changes and updates to the cluster locally. Well, let's visit the cluster on GKE and navigate to the logs for the pod that belong to the Kubernetes agent server this is the server side agent that is running within the cluster that is running in GitLab. And here if we look at the log here you can see that it's listening on port 5000 on five and we can click on the different events within the log and see how it is detecting changes to the manifest file that one is actually saying that the manifest file is not found. So it's monitoring the changes in the GitOps project in this case and making sure basically observing the manifest YAML file to see if there are any changes or updates. Now let's check on the agent log files and this is the agent that is actually running on the on the you can think of it as a client side and this just, I just happened to have the same cluster for running GitLab and the actual application agent. You know, in practice, they will likely, you know, most likely be separate clusters one cluster running GitLab and a separate cluster running an application with this agent right here. And as you can see in the log this every so many seconds the agent checks with the agent server and to see if there have been any updates or changes to the project that is being observed. In this case is the project called GitOps project and as changes happen, the agent is communicated of these changes and then the agent applies these changes to the local cluster. You can see in these messages, the first two instances of the NGINX server that were deployed and started as pods and also the last, the third edition of it. So in this demo, you have seen the installation of GitLab and GitLab Kubernetes agent that is our pool-based CI CD for GitOps which allows corporations and organizations to take advantage of our GitOps approach without having to expose their clusters to the internet. I hope you enjoyed this video and until next time.