what is the difference between a gitlab runner and a gitlab agent? - kubernetes

Question

I'm new to Gitlab and Kubernetes and I'm wondering what the difference between a Gitlab runner and a Gitlab agent is.
On gitlab it says an agent is used to connect to the cluster, run pipelines, and deploy applications.
But with a regular runner you could just have a pipeline that invokes kubectl to interact with the cluster.
What is possible with an agent that isn't with a runner using kubectl?

Answer 1

The GitLab Agent (for Kubernetes) is the way GitLab interacts with the Kubernetes cluster (https://docs.gitlab.com/ee/user/clusters/agent/) and is used to allow GitLab to generate GitLab runners which are like Jenkins agents (https://docs.gitlab.com/runner/install/). Consider it like a broker or manager in this case. The agent would spawn the runners inside the cluster with the configuration you have setup.
For example, in my case, I have a node-pool dedicated specifically for gitlab runners. These nodes are more expensive to run, since they're higher-spec than the standard nodes used by the rest of the cluster, so I want to make sure only the GitLab runners spawn on there. I configure the Runner to have a node selector and toleration pointing at that specific node pool so the cluster scales up that node pool to put the runner on it.
The agent itself provides way more functionality than just spawning runners, but your question only asks about the GitLab agent and Runner. You can review the pages I've linked if you would like to find out more.

Answer 2

from docs
GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.
you should install GitLab Runner on a machine that’s separate from the one that hosts the GitLab instance for security and performance reasons.
so GitLab runner is designed to be installed on a different machine to solve security issues and performance impact on a hosted machine
The GitLab Agent for Kubernetes (“Agent”, for short) is an active in-cluster component for connecting Kubernetes clusters to GitLab safely to support cloud-native deployment, management, and monitoring.
The Agent is installed into the cluster through code, providing you with a fast, safe, stable, and scalable solution.

Answer 3

The GitLab Agent (for Kubernetes) is the way GitLab interacts with the Kubernetes cluster
But that means it needs to be compatible with your GitLab instance.
Fortunately, with GitLab 14.9 (March 2022):
View GitLab agent for Kubernetes version in the UI
If you use the GitLab agent for Kubernetes, you must ensure that the agentk version installed in your cluster is compatible with the GitLab version.
While the compatibility between the GitLab installation and agentk versions is documented, until now it was not very intuitive to figure out compatibility issues.
To support you in your upgrades, GitLab now shows the agentk version installed on the agent listing page and highlights if an agentk upgrade is recommended.
See Documentation and Issue.
Plus, with GitLab 15.2 (July 2022)
API to retrieve agent server (KAS) metadata
After we released the agent for Kubernetes, one of the first requests we got was for an automated way to set it up.
In the past months, Timo implemented a REST API and extended the GitLab Terraform Provider to support managing agents in an automated way.
The current release further improves management of the agent specifically, and of GitLab in general, by introducing a /metadata REST endpoint that is the superset of the /version endpoint.
The /metadata endpoint contains information about the current GitLab version, whether the agent server (KAS) is enabled, and where it can be accessed. This change improves upon the previous functionality, where you had to put the KAS address in your automation scripts manually.
See Documentation and Issue.