Spike - Investigate why runners created with the Kubernetes executor may not deregister
Overview
In this issue, support noted that they found a number of customers on GitLab SaaS with runners that had not de-registered. In a follow on comment, there was a mention of this scenario and the Kubernetes executor.
This is customers registering their own runners. Customers are expecting the runners to unregister when they exit (for example, when a Kubernetes pod is migrated to another machine or scaled up or down). The runners are not unregistering, leaving the customer with thousands of runners registered with their namespace which stay there indefinitely.
*Note The pod garbage collector is not going to unregister
the runners on GitLab.com (SaaS or self hosted). Related comment
Scope
Let's investigate if there are scenarios where Pods created by the Kubernetes executor are not de-registering.