How do you implement GitOps with GitLab and Kubernetes agent?

GitOps means the desired state of a system, especially Kubernetes manifests, lives in a Git repository as the single source of truth, and an automated agent continuously reconciles the live cluster to match what's declared in Git, rather than a CI job pushing changes to the cluster directly.

GitLab supports this pattern through the GitLab agent for Kubernetes, which runs inside the cluster and pulls configuration from a designated repository rather than requiring the cluster to expose credentials outward to GitLab. The typical flow is:

1. Register the GitLab agent and install it in the target cluster with a scoped access token.
2. Define the agent's configuration (which repos/manifests it should watch) in .gitlab/agents/<agent-name>/config.yaml.
3. Commit Kubernetes manifests (or Helm values) to the watched repository.
4. The agent detects the change and reconciles the cluster to match, pulling rather than being pushed to.

The pull-based model is the key security difference from a traditional CI-push deployment: the cluster never needs to expose an externally reachable API endpoint or hand out cluster-admin credentials to the CI pipeline, since the agent inside the cluster initiates the connection outward instead.