ARC 0.15, 작업 중인 러너를 삭제하면 어떻게 될까?

러너 리소스 삭제 요청이 곧 Pod 종료는 아니다

ARC가 관리하는 EphemeralRunner와 실제 빌드를 실행하는 Pod는 서로 다른 Kubernetes 리소스다. 0.15.0에서는 러너 삭제 요청을 처리하다가 Actions로부터 작업 실행 중이라는 응답을 받으면, Pod를 바로 없애지 않고 다시 확인할 때까지 남겨 둔다.

0.15.0 태그의 컨트롤러 코드에서 이 동작은 삭제 요청과 정리용 finalizer가 있는 러너를 처리하는 분기에 들어 있다. 살아 있는 Pod의 러너 등록을 해제하려다 JobStillRunningError를 받으면 30초 뒤 재처리한다. 이 30초는 작업 실행 제한 시간이 아니라 재확인 간격이다.

따라서 삭제 요청 뒤 러너가 바로 사라지지 않았다고 해서 모두 정리 실패는 아니다. 해당 작업이 계속 실행 중인지, 컨트롤러가 작업 종료를 기다리는지부터 확인할 수 있다. 반대로 ‘삭제가 지연된다’는 현상만으로 정상 대기라고 단정할 수도 없다.

Pod 직접 삭제는 Kubernetes의 종료 절차를 시작한다

Pod 자체를 삭제하면 컨트롤러가 등록 해제를 기다리는 경로와 달라진다. 같은 코드의 살아 있는 Pod 확인 과정에서도 이미 삭제가 시작됐거나 종료된 Pod는 제외된다.

Kubernetes의 Pod 종료 절차에서는 종료 신호를 보내고, 유예 시간이 지나도 남아 있는 프로세스를 강제로 종료한다. 빌드가 끝날 때까지 무기한 기다리는 절차가 아니다. 노드를 내려 실행 환경 자체를 없애는 상황에도 ARC의 등록 해제 대기를 작업 보장으로 적용할 수 없다.

minRunners와 maxRunners를 모두 0으로 두면 새 Pod 생성을 멈춘다

공식 드레인 예제는 다음 두 값을 사용한다. 새 작업이 배정돼도 새로운 러너 Pod를 만들지 않게 하는 설정이다.

maxRunners: 0
minRunners: 0

새 러너 생성 중단, 기존 작업 완료, 리소스 정리 완료는 같은 상태가 아니다. gha_busy_runners는 현재 작업을 실행하는 등록 러너 수이고, gha_running_jobs에는 실행 대기 중인 작업도 포함된다. busy 값 하나만 보고 제거 절차가 끝났다고 판단할 수는 없다.

유지보수에서는 작업 화면에서 종료 여부를 보고, 이어서 삭제 대상 리소스가 정리됐는지 확인하는 순서가 필요하다. 이는 상태를 확인하는 순서이며, 드레인 설정이 Pod 직접 삭제나 노드 종료를 막아 준다는 뜻은 아니다.

0.14→0.15 전환을 패치 갱신으로 취급하면 안 된다

10월 1일 ARC 0.15.0 발표의 제자리 갱신 개선은 패치 버전 업그레이드를 대상으로 한다. 0.14.2에서 0.15.0으로 넘어가는 전환 전체가 무중단이라는 발표가 아니다.

실제로 10월 6일 공개된 운영자 신고에서 jedi-tal은 Argo CD로 컨트롤러와 차트를 한꺼번에 올린 뒤 이전 스케일 세트가 Terminating에 남았다고 보고했다. 작성자는 이전 finalizer가 새 컨트롤러에서 정리되지 않는 문제를 지목했다. 이 사례는 작업을 기다리는 러너와 이전 버전에서 남은 정리 대상이 다른 문제임을 보여 준다.

GitHub의 일반 업그레이드 절차는 스케일 세트 설치 제거, 리소스 정리 대기, ARC 제거, 버전 사이에 바뀐 CRD 정리, 재설치 순서다. Helm의 CRD 수명 관리 제한도 이 절차의 배경이다.

운영 계획의 첫 항목은 ‘업그레이드’라는 이름이 아니라 실제 삭제·교체할 대상이어야 한다. ARC 0.15.0의 러너 삭제 대기는 확인된 특정 경로다. 컨트롤러 버전 전환, 러너 이미지 교체, 노드 유지보수 전체를 대신하는 무중단 절차로 쓰면 안 된다.