GitLab Updates Kubernetes Agent for Experts, Compliance, Edge Use
Three years after the company first began offering a Kubernetes integration, GitLab has released the GitLab Kubernetes Agent (GKA), an active in-cluster component for solving integration tasks between GitLab and Kubernetes integration tasks, one that will take a different approach from the previous software, according to the company.
“While the current GitLab Managed Clusters and cluster creation from within GitLab might serve many use cases, it’s primarily aimed at simple cluster setup and is not flexible enough to be the basis for production clusters. We want to change this approach, and are focusing on the needs of expert Kubernetes engineers first,” a GitLab blog post explained.
Beyond the additional use cases, the company also saw some weaknesses with the current integration, which it wanted to address with the new agent. The existing integration used a push-based operation model, required admin rights to the cluster, and needed to be open to the internet, which posed challenges for some users.
“I think the biggest concern is compliance. We have a lot of customers who come to us and want to self-host GitLab because they don’t want their code in the cloud, and they have large compliance concerns. Then there are other folks that want to host on GitLab.com but have a lot of edge requirements,” said GitLab developer evangelist Brendan O’Leary.
The new integration addresses these concerns by operating as an agent that lives on the cluster, checking back in periodically with a GitLab instance for configuration changes. When a change occurs, the agent pulls the new configuration-as-code and hits the Kubernetes API from within the cluster, rather than from outside, to make the changes.
“For folks who have their cluster that’s in a completely disconnected network, or in a network that has complex security requirements, it’s going to really help those folks out a lot,” said O’Leary.
Written primarily in Go, and with its deployment machinery built on the gitops-engine, the GKA has been released under the MIT license. The current version, however, is a very early version and offers limited functionality, with more on the way. O’Leary explained that the agent will serve as “a bridge between the Kubernetes API and GitLab API,” bringing with it a variety of features, such as GitLab Managed Apps, which allows GitLab to easily install applications like Prometheus and Knative, among others. Some more concrete next steps outlined by GitLab include shipping the GitLab Kubernetes Agent as part of the Official Linux Package and supporting the deployment of private repositories.
On this final point, O’Leary said that “you have to deploy today with Helm, which is fine, but we want to be able to have it available for anyone and just in the Linux package that ships with GitLab.”
Some plans for further down the road include cluster-side dynamic container scanning, using GitLab as an authentication and authorization provider for Kubernetes clusters, offering linters and checks for Kubernetes best practices on deployed resources, and providing proxy cluster services, all of which can be found in the GitLab Kubernetes Agent epic.
GitLab is a sponsor of The New Stack.
Feature image by Arek Socha from Pixabay.
