<p>I have deployed my own small private Kubernetes cluster and in it I have deployed a GitLab agent with (currently) a single pod with a runner inside that handles my playground CICD pipeline (learning about cloud tech and CICD at the same time). Since I am currently running my cluster in a VM on my laptop I do shut down my cluster whenever I've finished working for the day.</p>
<p>After shutdown once started, the cluster automatically deploys a new pod with the GitLab runner. The agent picks it up and sends that information to the GitLab instance, which respectively offers it to the respective project(s).</p>
<p>Below you can see an example for this situation:</p>
<p><a href="https://i.stack.imgur.com/fIjpQ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/fIjpQ.png" alt="GitLab runners provided by K8s pods" /></a></p>
<p>The bottom runner is no longer available (pod was destroyed). The one on top is the new pod that was launched automatically by the cluster.</p>
<p>While currently this is manageable, I am thinking about the future. If I kill the pod 10 times for some reason (or it gets redeployed due to e.g. a crash), I will get 10 inactive runners in the list and one active (the latest one). 10 runners that will never ever be again (unless by some coincidence the cluster creates a runner with the exact same ID).</p>
<p>I was unable to find any information in the GitLab documentation and the menus in the Web UI. I am also aware that my approach is probably very crude and can be optimized (suggestions are welcomed!).</p>

rbaleksandar
<p>You could do one of a few things.</p>
<h2>Preserve the runner token</h2>
<p>When you register the runner, you use the registration token (static) to obtain a runner token (unique to each runner). This token is written to the <code>/etc/gitlab-runner/config.toml</code> file. This is also the part of the process that creates a new runner entry in your runner list. It appears you are registering new runners every time you 'redeploy' your runners.</p>
<p>If you preserve your <code>/etc/gitlab-runner/config.toml</code> file (e.g., by mounting the <code>/etc/gitlab-runner</code> directory as a volume for each runner container) then you will reuse the same runner token whenever you shutdown and bring up your runner and therefore will reuse the same runner/ID upon redeployment.</p>
<h2>Cleanup offline runners</h2>
<p>If a runner does not make contact with the GitLab server for some time, it will be marked as &quot;Offline&quot;. You can <a href="https://docs.gitlab.com/ee/api/runners.html#list-groups-runners" rel="nofollow noreferrer">list the runners for your group</a> using the API (you can also filter on <code>status=offline</code>) and then use the API to <a href="https://docs.gitlab.com/ee/api/runners.html#delete-a-runner" rel="nofollow noreferrer">delete a runner</a> using the ID(s) returned by your first query.</p>
<p>You can extract this logic into a script and run it periodically (or, perhaps, even from a scheduled GitLab pipeline).</p>
<hr />
<p>Be aware, GitLab plans to <a href="https://docs.gitlab.com/ee/security/token_overview.html#runner-registration-tokens-deprecated" rel="nofollow noreferrer">deprecate registration tokens</a> in favor of 'runner authentication tokens' starting in GitLab version 16.0 (not yet released) and plans to remove registration tokens in version 17.0 -- so this advice may become stale within the next couple years.</p>
