[AWS] GitLab Runner를 Amazon EKS Auto Mode로 구성하는 방법 가이드

개요

GitLab Runner를 Kubernetes에 올리면 확장성은 좋지만, 노드 운영/패치/스케일링/보안 연동 같은 운영 부담이 빠르게 커집니다. 이 글에서 다루는 구성은 Amazon EKS Auto Mode를 사용해 클러스터 운영 부담을 줄이고, Spot 인스턴스 기반의 실행 노드 풀로 러너 작업(Job) 비용을 낮추는 방식입니다.

AWS는 EKS Auto Mode가 인프라 자동 프로비저닝, 최적 인스턴스 선택, 동적 스케일링, 비용 최적화, OS 패치, 보안 서비스 연동 등을 자동화합니다.
또한 해당 조합으로 “전통적인 모델 대비 최대 90% 비용 절감” 가능성을 언급합니다(워크로드/스팟 가용성에 크게 좌우됩니다).

아키텍처

[AWS] GitLab Runner를 Amazon EKS Auto Mode로 구성하는 방법 가이드

핵심은 노드 풀을 2개로 분리하는 것입니다.

• 온디맨드 노드 풀: “베이스 러너(상주 러너)”를 안정적으로 띄우는 용도
• Spot 노드 풀: CI Job이 실행될 때 생기는 에페메랄(일시) 러너 파드가 주로 올라가는 용도

그리고 러너가 AWS 리소스(ECR 등)에 접근해야 한다면, 러너 파드에 AWS 권한을 주기 위해 IRSA(OIDC 기반 IAM Roles for Service Accounts) 구성을 사용합니다.

사전 준비

GitLab

• GitLab Runner registration token(러너 토큰) 준비

로컬 도구

다음 버전 이상을 권장합니다.

• AWS CLI v2.25.5+
• eksctl v0.207.0+ (EKS Auto Mode 지원)
• kubectl (EKS 버전 1.32와 호환)
• helm v3.17.3+
• jq, openssl

AWS 권한

• EKS 클러스터 생성, IAM Role/Policy 생성, VPC/EC2 관련 쿼터 여유 필요

---

구성 파일

샘플은 설정을 두 파일로 나눕니다.

• configs/defaults.json: 기본값(의견이 반영된 디폴트)
• configs/custom.json: 선택(커스텀 값). 없으면 설치 스크립트가 최소한 runner_token을 포함해 생성합니다. 이 파일은 토큰 노출 방지를 위해 git에서 제외됩니다.

예시 설정에는 region, cluster_name, version(예: 1.32), namespace, service_account, concurrent_jobs, chart_version(예: 0.55.0), 러너 리소스/헬스체크 값 등이 포함됩니다.

설치 절차

1) 샘플 리포지토리 클론

 

git clone https://github.com/aws-samples/sample-gitlab-runner-on-eks-auto-mode.git
cd sample-gitlab-runner-on-eks-auto-mode/scripts

그리고 end-to-end 설치 스크립트를 실행합니다.

./1-install-eks-auto-mode-cluster.sh

이 스크립트는 문서상으로 다음을 한 번에 처리합니다:

• EKS Auto Mode 클러스터 배포
• IAM 역할과 IRSA(OIDC Provider) 구성
• Spot 인스턴스 설정
• Helm으로 GitLab Runner 설치
• 헬스체크/모니터링 설정

2) 토큰 입력 및 기본 정책 선택

스크립트 실행 중 GitLab runner token을 입력하라는 프롬프트가 나오며, 필요 시 AWS managed policy 목록도 입력 받는 흐름이 예시 출력에 포함돼 있습니다.

3) 노드풀(NodePool) 생성 확인

예시 출력에서 gitlab-main, gitlab-spot 노드풀이 생성되는 로그가 보입니다. 즉, “상주 러너용”과 “스팟 작업용”이 분리되는 구조입니다.

Runner 동작 확인

설치가 끝나면 러너 파드/디플로이먼트가 Running 상태인지 확인합니다. 예시에서는 gitlab-runner 파드가 Running으로 나옵니다.

kubectl get pods -n <runner-namespace>
kubectl get deploy -n <runner-namespace>

추가로, GitLab 프로젝트에서 간단한 파이프라인을 돌려서 Job이 붙는지 확인합니다. 이때 Job 파드가 주로 spot 노드풀에 스케줄링되는지(노드 라벨/노드명 기준)도 같이 보는 편이 안전합니다.

부분 설치 실패 시 복구

설치 도중 문제가 생겼더라도 클러스터가 ACTIVE로 살아 있으면 업데이트 스크립트로 나머지를 진행할 수 있습니다.

eksctl get cluster --name <your-cluster-name>
# ACTIVE면
./2-update-eks-auto-mode-cluster.sh

운영 시 점검 사항

• 권한: 러너가 ECR/EKS/Secrets 등 접근 필요 시, IRSA Role에 정책이 붙었는지 먼저 확인합니다.
• 스팟 중단: Spot은 회수될 수 있으니, “재시도/캐시/빌드 아티팩트 저장”을 파이프라인 설계에 반영하는 편이 안전합니다. (이 부분은 일반적인 Spot 운영 특성입니다.)
• 리소스 제한: 러너 파드 리소스 request/limit이 너무 작으면 빌드 중 OOM이 나고, 너무 크면 스케줄링이 막힙니다. 메모리/CPU/ephemeral storage를 명시해 두는 구성이 도움이 됩니다.