Autoscaling Runner GitHub Actions di Kubernetes dengan ARC

Saya menjalankan runner self-hosted GitHub Actions di VM biasa dalam waktu lama, dan dua mode kegagalannya selalu sama. Entah beberapa runner yang selalu menyala menganggur membakar biaya sepanjang malam, atau lonjakan push membuat job antre sepuluh menit karena saya membatasi jumlah mesin. Lebih buruk lagi, runner persisten menumpuk state antar job, sehingga sisa node_modules, cache Docker yang teracuni, atau variabel lingkungan liar dari build sebelumnya bocor ke build berikutnya. Actions Runner Controller memperbaiki kedua masalah sekaligus, dan ini adalah cara resmi yang direkomendasikan GitHub untuk menskalakan runner di Kubernetes.

Tulisan ini membahas arsitektur ARC modern (runner scale sets, bukan CRD RunnerDeployment yang sudah usang), bagaimana penskalaan sebenarnya memutuskan berapa banyak pod dibuat, dua container mode yang harus Anda pilih, dan pengaturan spesifik yang mengontrol biaya. Semua di bawah ini berdasarkan Helm chart gha-runner-scale-set terkini yang diterbitkan GitHub.

Cara ARC benar-benar menskalakan: listener dan runner ephemeral

ARC memiliki dua Helm chart. Chart controller memasang operator dan custom resource sekali per cluster. Chart runner scale set dipasang sekali per kumpulan runner, dan setiap instalasi membuat satu AutoscalingRunnerSet plus satu pod listener ringan. Listener itu menjaga koneksi long-poll ke layanan GitHub Actions. Ketika job yang menargetkan label runner Anda antre, GitHub memberi tahu listener berapa runner yang dibutuhkan, dan listener mem-patch EphemeralRunnerSet sehingga Kubernetes membuat sejumlah pod runner itu. Tidak ada HPA berbasis CPU dan tidak ada polling endpoint metrik di sini — penskalaan didorong langsung oleh antrean job nyata, itulah mengapa cepat sekaligus akurat.

Setiap runner yang dibuat ARC bersifat ephemeral. Ia mendaftar ke GitHub, mengambil tepat satu job, menjalankannya, lalu pod dihapus. Job berikutnya mendapat pod baru dari image yang sama. Jaminan sekali pakai itulah alasan utama memilih ARC dibanding runner persisten: tidak ada state yang terbawa, jadi build tidak bisa disabotase oleh apa pun yang berjalan sebelumnya. Biayanya adalah waktu cold-start — setiap job membayar untuk menarik image runner dan, dalam mode dind, menjalankan daemon Docker — yang Anda mitigasi dengan warm pool lewat minRunners.

Memasang controller dan sebuah scale set

Instalasi berupa dua rilis Helm dari OCI registry GitHub. Peningkatan besar dibanding ARC lama adalah cert-manager tidak lagi menjadi prasyarat, sehingga instalasi controller benar-benar satu perintah. Pasang controller lebih dulu, lalu buat secret Kubernetes berisi kredensial GitHub Anda (PAT untuk mulai cepat, atau GitHub App untuk produksi), kemudian pasang scale set yang menunjuk ke URL repository, org, atau enterprise Anda.

# 1. Install the controller (once per cluster)
helm install arc \
  --namespace arc-systems --create-namespace \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller

# 2. Install a runner scale set (once per runner pool)
helm install arc-runner-set \
  --namespace arc-runners --create-namespace \
  --set githubConfigUrl="https://github.com/MatthewsWongOfficial/my-repo" \
  --set githubConfigSecret.github_token="$GH_PAT" \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set

Nama rilis Helm menjadi label runner. Apa pun nama instalasi scale set itulah string persis yang Anda taruh di runs-on. Jadi rilis di atas dikonsumsi oleh workflow seperti ini:

# .github/workflows/ci.yml
jobs:
  build:
    runs-on: arc-runner-set   # == the Helm release name
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

Tombol yang mengontrol biaya

Dua nilai menentukan tagihan Anda. minRunners adalah jumlah runner idle yang dijaga tetap hangat dan siap; maxRunners adalah batas keras berapa pod yang boleh ada sekaligus. Setel minRunners ke 0 dan Anda menskalakan penuh ke nol — Anda tidak membayar apa pun saat tidak ada job, dengan konsekuensi cold start pada job pertama setelah periode sepi. Setel ke 1 atau 2 dan Anda menukar sedikit biaya idle demi pengambilan hampir instan selama jam kerja. Jumlah yang benar-benar berjalan pada suatu saat kira-kira minRunners ditambah jumlah job aktif, dibatasi oleh maxRunners.

• minRunners: 0 — scale-to-zero sejati. Terbaik untuk build malam hari, repo lalu lintas rendah, dan apa pun yang cold start 30–60 detik masih dapat diterima.
• minRunners: 1–2 — warm pool kecil agar push pertama pagi hari tidak menunggu. Biaya idle-nya satu atau dua pod, bukan armada VM penuh.
• maxRunners — setel untuk melindungi cluster, bukan antrean. Build matriks yang lepas kendali bisa mencoba membuat ratusan pod dan menggusur beban kerja Anda yang lain.
• resources.requests — tepatkan ukuran CPU dan memori per pod runner agar scheduler Kubernetes mengemasnya efisien alih-alih memesan node berlebihan.

Container mode: dind versus kubernetes

Jika workflow Anda hanya menjalankan skrip, tes, dan build secara langsung, Anda tidak butuh apa pun khusus. Namun begitu sebuah job menggunakan container action, service container, atau docker build, runner butuh cara menjalankan container. ARC memberi dua opsi containerMode, dan pilihannya punya implikasi keamanan dan kompleksitas nyata.

Rekomendasi default saya adalah dind untuk kebanyakan tim — paling tidak mengejutkan dan meniru apa yang dilakukan runner biasa. Gunakan mode kubernetes hanya ketika kebijakan cluster Anda melarang pod privileged, dan sediakan waktu untuk konfigurasi storage yang dibutuhkannya, karena sering menjegal orang. Satu jebakan yang patut diketahui: versi chart terbaru pernah memiliki bug di mana init container dind yang disuntikkan berperilaku tak terduga saat containerMode diset ke kubernetes, jadi pin versi chart Anda dan uji mode yang benar-benar Anda pilih sebelum menggulirkannya ke setiap repo.

Apa yang benar-benar akan saya terapkan

Untuk tim kecil hingga menengah, saya akan memasang controller sekali, menjalankan satu scale set per lingkungan (satu pool CI umum dan mungkin pool terpisah untuk deploy), menyetel minRunners ke 1 selama jam kerja dan membiarkannya turun ke nol di luar itu, menyetel maxRunners ke angka yang aman di bawah kapasitas cluster, dan memakai mode dind dengan GitHub App. Konfigurasi itu memberi runner sekali pakai yang bersih, pengambilan di bawah satu menit sepanjang hari, dan tagihan mendekati nol di malam hari. Ini jauh lebih murah daripada armada VM yang selalu menyala dan jauh lebih aman daripada runner persisten, dan karena penskalaan digerakkan antrean, ia tidak pernah tertinggal di belakang lonjakan commit seperti autoscaling berbasis CPU.