EKS¶

Build Your Own GitLab Runners on EKS

PAGE UNDER CONSTRUCTION

As more and more DevOps teams adopt GitLab for internal development, and furthermore use GitLab CI/CD pipelines, finding ways to manage costs while still delivering highly available, scalable pipelines is crucial.

In this post I will provide an overview of GitLab runners and their role in CI/CD pipelines, as well as how you can configure your own self-managed runners using the Kubernetes executor running in your own EKS cluster.

Overview

At a high level, a GitLab runner is an agent that runs CI jobs in your pipeline. This can be in the form of agents running on Linux, Windows, or Mac hosts, as well as Docker or Kubernetes.

Karpenter and Why You Should Ditch Cluster Autoscaler

PAGE UNDER CONSTRUCTION

If you have used Amazon Elastic Kubernetes Service (EKS) you may have experienced that node groups' autoscaling leaves a bit to be desired. It can be slow, clunky to configure, and making use of mixed instance types can be difficult. My biggest complaint? Nodes launch SLOW!

Enter Karpenter. Karpenter is a node provisioner - which now uses the NodePool terminology, similar to GKE and others - that utilizes the EC2 Fleet API to schedule nodes directly to the cluster, without having to be in a managed node group!

Why would you want to do this? How about nodes that launch and reach Ready state in k8s in 10 seconds!

Read on to see how you can scale faster, more reliably, with greater flexibility, and save money by using Karpenter.