Kubernetes 공식 블로그가 Headlamp의 Kueue 플러그인으로 대기 중인 Job을 조사하는 흐름을 소개했습니다. 안내한 0.1.0-alpha 플러그인은 Kueue 자원을 읽는 화면을 제공하며, 자체 생성·수정·삭제 작업 흐름은 추가하지 않습니다. Kubernetes 공식 발표
Kueue는 큐 정책과 자원 할당 조건에 따라 작업을 시작할지 승인합니다. 승인이 나지 않은 Job은 아직 파드 스케줄러가 배치할 파드조차 없을 수 있어요. 이때 노드 상태만 조사하면 원인을 찾기 어렵습니다.
이 글의 목차
큐에서의 승인과 노드 배치는 다른 결정입니다
Kueue는 배치 작업이 공유 자원을 사용할 순서를 조정하는 데 쓰입니다. 자원이 언제나 충분하지 않은 환경에서는 모든 작업을 즉시 실행하기보다 큐 정책과 할당량에 맞춰 시작 여부를 결정해야 합니다. 여기서 Admission은 그 작업의 실행을 허용하는 승인 단계입니다. 승인이 끝난 뒤 실제 파드를 어느 노드에 둘지는 Kubernetes 스케줄러가 다룹니다.
따라서 Job이 멈춰 있고 파드가 없다면 앱이 느리다고 판단하기 전에 어느 단계에서 기다리는지 확인합니다. 아직 승인되지 않았다면 컨테이너 안의 로그가 없는 것도 이상하지 않습니다. 반대로 승인된 작업의 파드가 Pending이면 노드의 자원과 배치 조건을 조사합니다. 시작 단계의 구분만으로도 불필요한 노드 점검을 줄일 수 있습니다.
Workload에서 자원의 합계를 읽습니다
Kueue의 Workload는 Job의 자원 요구와 승인 상태를 나타냅니다. LocalQueue는 네임스페이스 안의 진입점이고, ClusterQueue는 연결된 할당 정책을 다룹니다. ResourceFlavor는 자원의 특성을 구분하는 데 쓰입니다. 이름을 외우기보다 작업이 어느 큐로 들어가 어떤 자원을 요청했는지 순서대로 따라가면 이해하기 쉽습니다.
요청량은 파드 한 개의 값으로 끝나지 않을 수 있습니다. 예를 들어 동시에 실행할 파드가 여러 개라면 작업 전체가 요구하는 CPU와 메모리를 함께 봐야 합니다. 조건 메시지에서 할당량 부족을 가리키는데 파드 하나의 요청량만 비교하면 원인이 보이지 않을 수 있어요. 현재 조건과 최근 이벤트도 구분해서 읽으면 상태가 바뀐 경위를 따라가기 좋습니다.
대기 원인에 따라 조사 화면을 바꿉니다
예를 들어 Job을 제출했는데 파드가 나타나지 않는다면 선택한 네임스페이스와 큐 연결, 조회 권한을 먼저 확인합니다. Workload가 있으면 Admitted 같은 조건을 보고, 승인 전이라면 연결된 큐와 자원 할당을 조사합니다. 이미 승인됐다면 일반 Job·Pod 화면으로 넘어가 스케줄러 이벤트를 확인합니다. 이렇게 분기하면 큐 문제와 노드 배치 문제를 섞지 않을 수 있습니다.
플러그인을 설치했다고 현재 사용자의 조회 권한이 자동으로 생기지는 않습니다. 읽기 화면에 필요한 권한만 먼저 검토하고, Headlamp의 일반 자원 편집 기능과 플러그인 자체 기능을 구분합니다. 공유 클러스터에서는 다른 네임스페이스의 작업 정보가 누구에게 보이는지도 확인해 운영자와 사용자 화면의 범위를 정합니다.
읽기 화면의 권한도 확인
- 선택한 네임스페이스와 Job의 큐 연결을 확인합니다.
- 현재 계정에 관련 Kueue 자원을 읽을 권한이 있는지 봅니다.
- Admission 대기와 노드 배치 실패를 다른 사건으로 기록합니다.
alpha 플러그인의 범위와 Headlamp 자체의 자원 작업 기능을 구분합니다. 조회 화면을 도입하면서 불필요한 쓰기 권한까지 부여하지 않습니다.
발표문 기준일: 2026-10-14 · 확인일: 2026-10-24
