Skip to content

Easy bootstrapping of GitLab k8s functionality

Release notes

https://docs.gitlab.com/ee/user/clusters/agent/install/#installation-steps

GitLab offers flexible, reliable and secure GitOps support with the agent for Kubernetes and its FluxCD integrations. Still, until now, bootstrapping FluxCD with GitLab and setting up the agent for Kubernetes required a lot of documentation reading and switching between the GitLab UI and the terminal. The GitLab CLI now offers the glab cluster agent bootstrap command to simplify the agent setup on top of an existing FluxCD installation. This way FluxCD and the agent can be set up in just two, simple commands.

Problem to solve

As an unexperienced Kubernetes user, I want a simple way to start with the GitLab - Kubernetes integration, so I can focus on my job of building applications, and benefit from the GitLab integration for deploying what I built.

A VERY SMOOTH getting started experience for agentk and Flux and built-in GitLab best practices. aka: we do the heavy lifting on the user's behalf.

The end result should be a GitLab and cluster configuration that

  • works for gitops
  • works for the UI integration
  • works for local access
  • Flux manages all the app upgrades in the cluster

Proposal

Approach 1: Extend the glab CLI

  • Extending the glab CLI by introducing a bootstrap command which would setup the agent and flux.

Approach 2: Extend the flux CLI

  • Extending the flux CLI by implementing new options to the flux bootstrap gitlab command which would setup the agent in addition to flux.

Approach 3: Two commands with flux and glab

A the flux bootstrap gitlab works great already, we leave it as is, and extend the glab CLI to register an agent, add the HelmRelease to the pointed directory and store the secret in the cluster. Similarly to the bootstrap command, we can make it idempotent, always generating a new registration token, and always applying it to the cluster. This would allow an easy upgrade and key rotation from a scheduled job that just runs both commands in sequence. If already two tokens are active, the command would remove the one that was used the longest ago and create a new one.

glab should not provide or pull in the dependencies required, like kubectl or maybe helm - instead it should assert that it's available in $PATH and err otherwise.

Intended users

Feature Usage Metrics

Instrument Flux usage in clusters with agentk i... (#465454)

Does this feature require an audit event?

No.

Implementation Proposal

@timofurrer created a prototype at feat: cluster agent bootstrap command (cli!1645 - merged). What's missing:

  • error handling
  • beautify command line output
  • add some more configuration possibilities via flags
  • add tests
  • maybe refactor some parts, like flux and kubectl commands
Edited by Viktor Nagy (GitLab)