 Let's get started. So for some software developers, based on the interviews, environments are a little bit like a myth. App developers are often used to be at a container, type commit, and then move on to the next issue. Now, this is great in many ways as it allows them to focus on writing the apps for the business. At the same time, as we see more and more DevOps requirements appearing in the Dev side, Dev teams decide they need some level of understanding of the environment. Even if developers' responsibility with respect to an issue stops once the container got the build and pushed, currently, many teams own the applications that they actually develop. And this ownership is like a long-term relationship that requires a level of understanding of the ops landscape. We think that environments should be at the heart of DevOps and it describes really well this entry point for the application engineers to think about the applications that they own. Environments are stateful, long-lived entities by nature, unlike the issues that the shorter the better. There are various processes around environments. Some teams say that they deploy to production, what others say actually they promote from staging to production. And this promotion verb itself shows that deployments are not one of events. They have a history both in terms of the pipeline and in terms of the target infrastructure itself. Environments should incorporate all of these information. With respect to environment, there are natural questions that developers might want to know about like the resources that they are responsible for. Infrastructure people today need to provide tooling and access to information so Devs can actually own the applications. A typical setup is to have a shared profile instance, for example, and provide access there, but developers spend a lot of time in GitLab already so they are familiar with the UI. As a result, we had this question, like could we have them there within GitLab? What information would be the most important to show? And this led us to the design that you can see here and that you will be able to see live later during the talk that quickly shows the health status of the given environment, the most important resources that are typically the workload type resources in Kubernetes, error and alert highlights, and it can provide as an anti-point towards getting into more information to start the troubleshooting section and of course other actions that might be possible around here. Now I will stop sharing my screen and give it over to Anna to share with you the technical details. Thank you, Victor. Oh, sorry, it's the wrong screen. Hello everyone and I'm happy to continue from here. In order to enable a seamless connection and management of Kubernetes clusters within GitLab, we have developed a range of tools and solutions. One of the core components of the system is the GitLab agent for Kubernetes. This powerful tool provides a secure bi-directional connection between a GitLab instance and the Kubernetes cluster. So how does the GitLab agent for Kubernetes work? Essentially, it is composed of two components, Agent K and CAS, short for GitLab. Agent K is a slim and lightweight cluster site component. It is responsible for establishing a connection to a CAS instance and waiting for requests to process. It is proxying requests from CAS to Kube API. It may also actively set information about cluster events to CAS. While Agent K is actively communicating with the cluster, CAS, on the other hand, represents a GitLab server-side component. It is responsible for accepting requests from Agent K, authenticating Agent K requests by querying GitLab backend, fetching the agent's configuration from a corresponding Git repository using Gitaly, and pulling manifest repositories for GitOps support. By using the GitLab agent for Kubernetes, we can ensure that the communication between the GitLab instance and secure and reliable. One of the key features of the GitLab agent for Kubernetes is the ability to configure agent access rights. This allows the agent administrator to define a specific list of projects or groups that are available for users to gain direct access to the Kubernetes API through the GitLab UI, while maintaining the overall security of the system. The full proxy flow from the front-end to a cluster starts with the user browsing to the desired GitLab project and accessing the cluster agent's page. Once the user selects an agent, a browser cookie is generated and forwarded as a separate header to CAS, along with the correct CSRF token and GitLab agent ID. Upon receiving the request, CAS checks the user's authorization by calling the authorized proxy user GitLab endpoint with the provided user credentials and agent ID. If the credentials are valid and the user has the necessary access, which is at least developer rights for the project, the request is enriched with information from the authorization response and forwarded to agent K. Agent K, in turn, makes an actual request to the Kube API, applying the appropriate impersonation configuration. Then the Kube API response goes all the way back from the agent K to CAS and finally to the GitLab client. By providing a secure and efficient mechanism for accessing the Kubernetes API, the GitLab agent for Kubernetes opens up a wide range of possibilities for cluster management and visualization. In order to utilize the GitLab agent connection to Kubernetes from the front-end, the client of any kind is required. Initially, we were looking into the official Kubernetes client JavaScript library, but unfortunately, it is not currently supported on web browsers, which created a challenge. This is due to the fact that the Kubernetes client library is intended to be used within a server-side environment. And as a result, it relies on certain features that are not available in the browsers, such as network sockets and file system access. Therefore, to interact with Kubernetes APIs from the front-end, alternative libraries might be used that are specifically designed to work in a browser environment. These libraries can be based on the official Kubernetes client library applied and adjusted to function properly in the browser. To solve this problem, we developed our own library that can be used to interact with the Kubernetes API through the GitLab UI. It uses an open API generator in a similar way to Kubernetes client, but without the dependency on Node Fetch, which makes it compatible with the browsers. We have explored several JavaScript and TypeScript generators and settled on using the TypeScript access generator, which produces clean code that can be reshaken and is already compatible with access, a library we use in the front-end. The GitLab cluster client library simplifies the process of retrieving information from the Kubernetes API endpoints and executing commands. We are currently working on integrating it with the Watch API, which will allow the client to receive updates on cluster changes as they occur, eliminating the need for frequent endpoint polling. This will significantly improve the performance and efficiency of the cluster client library, resulting in a better environment integration experience. Integrating the GitLab cluster client library on the front-end is straightforward. It contains an API object and a configuration object that can be used to set the correct API URL and the proper header to ensure authentication works as expected. The development of the cluster client library has allowed us to overcome the limitations of the official Kubernetes client library and provide a smooth and efficient integration experience with GitLab and Kubernetes. With this library and our ongoing efforts to improve it, we are committed to providing the best possible experience for our users in managing their Kubernetes clusters through the GitLab UI. What have we built so far? The environment's page integration provides a comprehensive overview of the health and stability of the cluster. By querying several Kubernetes API endpoints, users can easily monitor the status of running applications, including information on ports, services, deployments, diamond sets, stateful sets, replicas, set jobs, scrunch jobs, and other resources. This allows users to quickly identify any issues or bottlenecks and take appropriate action. By tracking their resource usage and health of the applications, the environment page integration can ensure that the cluster is operating optimally and efficiently and take proactive steps to address any potential issues before they close the downtime or other problems. Now that we've touched on the GitLab agent for Kubernetes and cluster client library that created a base for the environment's page integration, let's take a look at a quick demo to see the action. In this demo, we'll check the agent cluster connection and we'll use the environment's page to view the status of our running application, including ports, services, and deployments. I've already created an agent for our demo. The agent call demo agent is available from the infrastructure Kubernetes clusters page. I've already installed it into my local cluster and you can see that it is shown as connected. The agent has a configuration file. For our demo, the main focus of this file is the manifest projects list. That contains a list of projects that the agent should watch and apply changes to the Kubernetes cluster any time a developer performs changes. The other very important part here is the user access. It specifies the access as required field which can have one of two values. Agent, that means connecting using the agent service account and user designed as a premium feature that impersonates the authenticated user. For our current demo, I will use the agent service account. So the access as is set to be an agent. We also specify a list of projects the users of which with developers of higher role can get the access. In this example, it is set to the current project. Let's return to the agent page. We'll obtain the GitLab CAS cookie from here and it is an essential part for the client cluster connection. You can see from the activity stream list that the agent was created and successfully connected 99 hours ago. It should be good by now. I created an MR to add a basic app. It has a deployment, a service, and an ingress. It should get created under the demo Kubernetes app namespace. As a result, I'd expect to see one running port, one deployment, one replica set, and a service. Let's make, merge it and check the situation in the cluster. See it? That is exactly what we expected. It means that the agent successfully pulled the changes and applied them to the connected cluster. And now let's go to the... I already created one environment, production. There are no deployments here because I didn't set up any first demo. But we can see the Kubernetes overview section. It shows the same information that we've already seen in your QPSTL. It defines the cluster as healthy as we don't have any failed resources. It shows the agent that is used for the GitLab to cluster connection. We are already familiar with this one. We can see ports, deployments, and replica sets here, as well as the service we've created recently with some basic information about it. Let's take a quick look at the network tab. We can catch one of the QPAP requests and verify that we have a GitLab class cookie set here as well as the GitLab agent ID. Now let's try to update this information. Sorry Anna, as you share your screen, we can't see the terminal when you want to show that to us. Oh, I'm so sorry about it. But the terminal just... Same information as the environment page. Thanks for letting me know. I have no plans for sharing the terminal, so it should be good. So I'm going to change the number of replicas to see if it's reflected on the front end. So it's still being merged. And we need some time for the agent to pick up those changes. And now we see that we have nine more pending ports that are turned to be running once. So it's basically the Chipsetel watch visualization. I'll now change it back. Let's see how that's reflected on the front end. We need to give it a second. Now we can see that the number is set to just a single port. I really like how the cluster looks healthy and happy. But for the experiment, let's also try to mess things up a little. I've prepared a configuration that is most definitely fail. It contains a failed deployment and a failed port. Let's merge it and see what happens. Did it merge it? Yeah, was too quick. So we can observe that there's a failed port now. And this failure has also updated the environment's health status to unhealthy. And we see a new label for the deployments indicating that there's a failed one. I'll remove those two failed resources for now. As I'd always like to see my cluster is healthy. And now the agent should pick up the updated configuration and apply it to the cluster at the moment. Yeah, and now we have a healthy cluster once again, with one successful deployment that generates a single port. In conclusion, the integration between GitLab and Kubernetes offers developers an intuitive and streamlined workflow for deploying and managing applications. By leveraging the GitLab UI, developers can monitor the status of their applications and quickly respond to any failures without having to switch between multiple tools. This integration not only streamlines the development process but also helps teams deliver code faster and with greater confidence. While the integration is currently in development, I'm hanging over to Victor, who will be happy to guide anyone interested in getting started with the environment's integration. Thank you. This was just amazing. And I'm very excited to see users trying it out. So if you would like to get started with the agent itself, behind the QR code, you can find the link to the documentation. If you are interested in the UI integration for Kubernetes, we already linked to the GitLab cluster client repo. Please use it. If there's anything you would like to contribute, we welcome contributions as well. And please provide feedback on the design that you have seen in the environment's integration or check out ongoing work on the Kubernetes dashboard design that we plan to shift later. And last but definitely not least, if you are interested in what we just demoed here, feel free to sign up to the closed beta. You can reach us through any of these main mains here and provide us feedback even live if you want through that calendar link.