Skip to content
Latchkey

O Que É o Actions Runner Controller (ARC)? Runners no Kubernetes

O Actions Runner Controller (ARC) é um operador Kubernetes open-source que executa e faz autoscaling de runners self-hosted do GitHub Actions como pods no seu próprio cluster.

O ARC é a forma popular de fazer self-host de runners em escala no Kubernetes. Ele transforma a capacidade de runners em pods que escalam conforme a demanda - poderoso, mas faz do seu fleet de CI uma carga de trabalho Kubernetes que agora você precisa operar.

O que o ARC faz

O ARC observa o GitHub em busca de jobs na fila e cria pods efêmeros de runner para atendê-los, escalando para cima sob carga e para zero quando ocioso. Cada runner é um pod agendado nos nós do seu cluster.

Por que as equipes o adotam

  • Runners efêmeros com autoscaling, sem preço por minuto de hospedagem.
  • Runners que vivem dentro da sua rede e fronteira de segurança.
  • Reaproveitamento do investimento já existente na plataforma Kubernetes.

A realidade operacional

O ARC herda todo o ops do Kubernetes: upgrades de cluster, autoscaling de nós, atualizações do controller, manutenção de imagens, ajuste de scaling e depuração de agendamento de pods. Os runners são "gratuitos" em relação ao preço de hospedagem, mas caros em tempo de engenharia de plataforma.

ARC vs runners gerenciados

O ARC e uma plataforma gerenciada miram o mesmo objetivo - runners baratos, efêmeros e com autoscaling - mas o ARC é do-it-yourself no Kubernetes, enquanto uma plataforma gerenciada é operada por você. A escolha é se você quer operar o fleet.

A alternativa zero-ops

A Latchkey entrega runners efêmeros, com autoscaling e warm pool, sem cluster para operar - o resultado do ARC sem as operações de Kubernetes, tipicamente cerca de 70% mais barato que os runners hospedados pelo GitHub.

Principais conclusões

  • O ARC é um operador Kubernetes que faz autoscaling de runners self-hosted do GitHub.
  • Ele fornece runners efêmeros com autoscaling dentro do seu próprio cluster.
  • Ele carrega todo o overhead operacional do Kubernetes.
  • Runners gerenciados atingem o mesmo resultado com zero ops.

Guias relacionados