Using Cluster Management Project to Install a Kubernetes Runner

Scenarios: Instructor-Led, Self-Paced

A Kubernetes GitLab Runner Registration does not survive scaling the cluster to zero. If you scale to zero you will need to redeploy the chart to register another runner and you will need to remove orphaned runner registrations in GitLab from each scale to zero event.

This example deploys a new runner in order to be free of runner minute limits on GitLab.com SaaS Runners and to be free on Credit Card registration requirements for participants to use free minutes. You may use a GitLab.com shared runner to configuration Cluster Applications because cluster access is achieved through the installed agent, rather than a traditional Kubernetes control plane API access (like was formerly used by the GitLab Certificate connection method.)

Warning
Since you will have needed to have access to a runner of some type to deploy the cluster managed apps for ingress and

IMPORTANT: This setup is assuming that you wish to setup Auto DevOps for the entire downbound group heirarchy ‘classgroup’ - this can be scoped tighter by paying attention to fully specifying group paths and by creating Group level CI/CD variables at a deeper group level.

This section assumes you have a shared runner attached to your group or project and that it has minutes available for usage.

  1. In ‘classgroup’, Click CI/CD > Runners

  2. Near the top right, Click Register a group runner (button)

  3. Next to the ‘Registration token’, Click [the Clipboard Icon]

  4. In ‘classgroup/cluster-management’ Click Settings > CI/CD

  5. Next to ‘Variables’ Click Expand

  6. Click Add variable once for each table row

    Key Value Protect Mask
    GITLAB_RUNNER_REGISTRATION_TOKEN paste the Runner Registration Token copied earlier No Yes
  7. In ‘classgroup/cluster-management’ Start the Web IDE.

  8. Edit the file ‘helmfile.yaml’ and uncomment the line - path: applications/gitlab-runner/helmfile.yaml

  9. Edit the file ‘applications/gitlab-runner/values.yaml.gotmpl’ and

  10. Uncomment the line runUntagged: true

  11. Click Create commit…

  12. Select Commit to master branch

  13. Click Commit

  14. Monitor the CI job that your commit triggered for successful completion.

Note: GITLAB_RUNNER_REGISTRATION_TOKEN variable could be removed now - but would need to be recreated to reinstall the runner.

Optional Disable Other Runners

If you’d like to see your Kubernetes runner in action, follow this procedure.

Runner Cleanup

If you had deployed a runner there may be one or more Runner Registrations associated with the EKS cluster that is now gone.

  1. In GitLab, within ‘classgroup’ Click Settings => Ci/CD
  2. Under ‘Available runners’ identify the rows that have the IP address of your load balancer and delete them.