GPU 플랫폼을 운영하며 Kubernetes를 보는 관점이 달라졌습니다. 처음에는 애플리케이션을 배포하고 Pod를 안정적으로 실행하는 기반으로 보았습니다. 그러나 GPU·큐·프로젝트·quota가 들어오면 Kubernetes는 단순 실행 환경이 아니라, 자원 배분과 조직의 우선순위가 만나는 곳이 됩니다.
이 변화는 kubectl get pods로 시작한 조사가 왜 자주 막히는지에서 잘 드러난다. Pod 상태는 중요한 출발점이지만, 사용자에게 보이는 문제의 전체 맥락은 아니다. 동일한 Pending 상태도 물리 GPU 부족, 자원 단편화, taint·affinity, 프로젝트 quota, queue의 우선순위, 요청량 변화에서 나올 수 있다. Kubernetes는 이 단서들을 담고 있지만, 운영자는 그 단서를 정책과 사용자 영향까지 연결해 읽어야 한다.
Pod·node·정책의 단서를 별도 콘솔에서 분리하지 않고, 하나의 incident 기록에서 다시 읽는 방식의 예시입니다.
스케줄링은 기술 문제가 아니라 정책의 결과다
Pod가 Pending이면 스케줄러 문제라고 생각하기 쉽습니다. 하지만 GPU 워크로드에서는 요청량, 노드의 가속기 상태, 프로젝트 quota, 우선순위, 큐 정책이 모두 결과에 영향을 줍니다. “왜 배치되지 않았는가”를 알려면 이벤트 한 줄이 아니라 그 정책적 맥락까지 읽어야 합니다.
같은 GPU 한 장도 누구에게, 어떤 우선순위로, 얼마나 오래 배정되는지에 따라 플랫폼 전체의 경험을 바꾼다. 따라서 scheduler가 결정한 결과는 기술 상태이면서 동시에 조직이 정한 자원 배분 정책의 결과다. 이 관점이 없으면 운영자는 queue에서 밀린 workload를 오류로 오해하거나, quota에 막힌 요청을 노드 장애로 조사하게 된다.
요청은 리소스 숫자이면서 제품 약속이다
CPU 환경에서는 request와 limit을 배포의 세부 설정으로 여길 수 있다. GPU 환경에서는 한 장의 요청이 다른 팀의 실험 시작 시각과 비용, 프로젝트의 우선순위 경험에 영향을 준다. 어떤 팀이 과도한 GPU 수를 요청하면 그 Pod 하나의 문제로 끝나지 않고, queue 전체의 대기 시간을 바꿀 수 있다. 반대로 너무 낮게 잡으면 실행은 되더라도 처리량·메모리 부족·재시작으로 이어질 수 있다.
따라서 플랫폼은 사용자에게 단순한 리소스 API가 아니라, 왜 이 요청이 수용·대기·거절되었는지 설명할 수 있어야 한다. Kubernetes event와 scheduler의 판단, node의 가용 상태, Run:ai의 project·queue 정책을 함께 보게 하는 이유다. 운영팀은 “GPU가 없다”라는 응답 대신 어떤 조건이 현재 배치를 막고 있으며, 어떤 변경이 다른 사용자에게 영향을 주는지 말할 수 있어야 한다.
노드 상태만으로 GPU 건강을 판단할 수 없다
Node가 Ready라고 해서 워크로드에 필요한 GPU 경로가 건강하다는 뜻은 아니다. 드라이버와 device plugin이 올바르게 등록됐는지, allocatable GPU 수가 기대와 같은지, GPU memory 오류나 장치 간 통신 문제가 없는지, 특정 카드에만 과도한 작업이 몰렸는지를 별도로 봐야 한다. 반대로 GPU utilization이 낮다고 해서 유휴 자원이 많은 것도 아니다. 기다리는 job, quota, affinity, 분할 방식이 함께 봐야 할 조건이다.
이 때문에 GPU 관측은 단일 dashboard의 그래프를 보는 일보다, 질문에 따라 좁혀지는 탐색이어야 한다. alert에서 Pod와 Job을 열고, 그 Job의 project·queue 정책으로 가고, 같은 시간대의 node·GPU telemetry와 변경 이력을 확인하는 흐름이 필요하다. 화면이 많아도 이 이동 경로가 짧으면 운영자는 조사를 반복하지 않는다.
관측은 계층 사이를 이동할 수 있어야 한다
GPU 지표만 보는 대시보드와 Kubernetes 이벤트만 보는 대시보드를 분리하면, 운영자는 원인을 머릿속에서 이어 붙여야 합니다. 더 좋은 관측 경험은 한 신호에서 관련 workload·노드·프로젝트·변경 이력으로 이동할 수 있게 만드는 것입니다.
운영 화면에서 중요한 것은 모든 그래프를 한 화면에 쌓는 일이 아니다. 하나의 alert에서 “어느 프로젝트의 어떤 job인가”, “해당 job이 기다리는 자원은 무엇인가”, “같은 시각에 node·queue·quota에 어떤 변화가 있었는가”로 이동할 수 있어야 한다. 이 이동 경로가 끊기면 사람이 서로 다른 콘솔의 시간을 맞추느라 조사 시간을 쓴다.
그래서 incident를 중심으로 Kubernetes resource, GPU telemetry, Run:ai 정책, 변경 이력을 묶는 방식이 유효하다. 각 도구의 깊이를 대체하기보다, 어디에서 다음 증거를 찾을지 연결해 주는 역할이다.
운영자의 질문을 자동화하는 방식
자동화의 첫 단계는 “어떤 명령을 실행할까”가 아니라 “어떤 질문을 반복하는가”를 적는 일이다. GPU Job이 기다릴 때 운영자는 보통 어떤 project의 어떤 queue인지, 요청한 GPU가 무엇인지, 후보 node에 어떤 제약이 있는지, quota·우선순위와 최근 변경은 무엇인지 묻는다. 이 질문을 정리하면 수집해야 할 Kubernetes object와 platform API, telemetry가 보인다.
KubeRCA와 Run:AI RCA는 이 지점에서 Kubernetes를 한 개의 정답 소스로 다루지 않는다. alert를 incident 단위로 만들고, 리소스·이벤트·메트릭·로그·정책·변경 이력을 읽기 전용으로 모은 뒤, 출처가 있는 관찰만으로 가설을 구성한다. 자동화가 할 일은 운영자 대신 삭제·재시작하는 것이 아니라, 서로 떨어진 증거를 같은 시간창에 놓고 다음 질문을 줄이는 것이다.
운영 자동화는 안전한 질문부터 시작한다
자동화는 조치를 실행하는 것에서 시작할 필요가 없습니다. 먼저 현재 상태를 읽고, 필요한 증거를 모으고, 사람이 확인할 수 있는 다음 질문을 제시하는 자동화가 더 안전합니다. GPU 플랫폼에서 이 원칙은 특히 중요합니다. 한 번의 무리한 조치가 여러 사용자와 고가의 자원에 영향을 줄 수 있기 때문입니다.
이 관점은 Run:AI RCA의 설계에도 이어집니다. Kubernetes를 정답을 주는 한 계층으로 보지 않고, AI 플랫폼 incident를 설명하는 여러 증거 중 하나로 다루는 이유입니다.
운영자가 자동화에 기대해야 할 것
GPU 환경의 자동화는 “재시작하면 해결된다”는 실행 버튼으로 평가하면 위험하다. 안전한 자동화는 먼저 읽기 전용으로 상태를 수집하고, 어떤 정책과 관찰을 근거로 했는지 보여 주며, 다음 조치의 영향과 롤백을 적는다. 높은 비용의 자원과 여러 팀의 workload가 만나는 플랫폼에서는, 자동화가 확신을 과장하지 않는 능력 자체가 중요한 기능이다.
Kubernetes를 공통 언어로 남기기
GPU 플랫폼에서 Kubernetes는 많은 시스템 중 하나지만, workload·node·event·namespace라는 공통 식별자를 제공한다. 좋은 운영 기록은 이 식별자를 중심으로 사용자 영향, GPU 상태, policy decision, 변경 이력을 연결한다. 그러면 다음 incident에서 다른 담당자가 시작해도 “어디서 무슨 일이 일어났는지”를 같은 객체와 시간 창으로 되짚을 수 있다.
결국 달라진 관점은 단순하다. Kubernetes는 Pod를 띄우는 기반을 넘어, 자원 배분의 결과와 조사에 필요한 사실이 만나는 연결점이다. 이 연결점을 정책·관측·사람의 검토와 함께 설계할 때 GPU 플랫폼의 자동화도 더 안전하고 설명 가능한 방향으로 갈 수 있다.
플랫폼 경험을 SLO로 번역하기
이 관점은 운영 지표도 바꾼다. 노드가 몇 대 healthy한지, GPU 평균 사용률이 얼마나 높은지뿐 아니라, 사용자가 요청한 workload가 합리적인 시간 안에 시작되는지, 왜 기다리는지 설명받는지, 장애가 생겼을 때 어느 팀이 어떤 근거로 대응하는지를 봐야 한다. 기술 상태와 사용자의 체감 사이에 있는 queue time, allocation 실패 사유, 재시작·중단 경험은 플랫폼 품질의 일부다.
따라서 GPU 플랫폼의 SLO는 단일 숫자보다 조사 가능한 약속의 묶음에 가깝다. 요청의 상태를 설명할 수 있어야 하고, 정책에 막혔을 때 다음 행동을 알 수 있어야 하며, incident가 발생했을 때 근거를 잃지 않아야 한다. Kubernetes를 이 경험의 연결점으로 볼 때, 관측과 자동화도 단순한 인프라 지표를 넘어 사용자에게 전달되는 운영 품질을 다루게 된다.
변경은 Kubernetes 밖에서 시작될 수 있다
GPU workload의 상태가 바뀌었다고 해서 원인이 항상 cluster 안에 있는 것은 아니다. Run:ai 프로젝트 정책, queue 우선순위, quota, 이미지 태그, 데이터 위치, 사용자 요청량처럼 Kubernetes object 밖에서 시작된 변화가 Pod의 상태로 드러날 수 있다. 그래서 incident 조사에는 배포와 설정 변경뿐 아니라 플랫폼 정책과 사용자 영향을 같은 시간축에 놓는 변화 이력이 필요하다.
이 관점은 blame을 넓히기 위한 것이 아니다. “어느 컴포넌트가 고장 났는가”를 넘어서 “어떤 변경과 제약이 지금 사용자 경험을 만들었는가”를 보는 방식이다. 원인이 정책이었다면 Kubernetes event만으로는 충분하지 않고, 정책의 적용 범위와 목적, 영향을 받은 project를 함께 읽어야 한다. 이 증거가 있어야 수정도 안전하게 계획할 수 있다.
회복 조치도 플랫폼의 약속 안에 있다
Pending workload를 재시작하거나 queue를 비우는 조치는 빠른 해결책처럼 보일 수 있지만, 다른 사용자와 우선순위에 미치는 영향을 함께 봐야 한다. 운영자는 조치 전에 무엇이 영향을 받는지, 조치 뒤 무엇을 확인할지, 예상과 다르면 어떻게 되돌릴지 남겨야 한다. GPU처럼 비용이 크고 공유되는 자원에서는 복구 절차 자체가 제품 경험의 일부다.
그래서 Kubernetes 관점의 변화는 도구를 더 많이 쓰게 된다는 뜻이 아니다. 상태, 정책, 사용자 영향, 변경 이력을 같은 incident에서 연결하고, 자동화가 제안하는 조치에도 근거·영향·롤백을 요구하는 방식으로 바뀌었다. 이 기준이 있어야 GPU 플랫폼은 빠른 실행 환경을 넘어 신뢰할 수 있는 공동 자원이 된다.
인수인계에도 필요한 incident 경계
GPU 플랫폼의 on-call은 담당자가 바뀌어도 같은 사실을 다시 수집하지 않아야 한다. 따라서 인수인계에는 Pod 상태뿐 아니라 대상 project·queue·quota, 최근 변경, 확인한 가설과 남은 증거를 같은 incident 단위로 남긴다. 이 정보가 있으면 다음 담당자는 이전 작업을 믿으라고 강요받는 대신, 출처와 시간축을 따라가며 스스로 판단을 이어갈 수 있다.
Kubernetes의 리소스와 이벤트는 이 공통 언어의 중심이 된다. GPU telemetry와 policy system이 별도로 있어도 workload·node·namespace라는 연결점을 통해 사용자 영향과 기술 상태를 함께 읽을 수 있다. 이것이 플랫폼 운영에서 Kubernetes를 단순 실행 계층보다 넓게 보게 만든 이유다.
댓글