“쿠버네티스 1.29 + 가상 GPU 파티셔닝(MIG) 환경에서 vLLM-기반 LLM 서빙(8× H100 GPU/노드)과 REST API 게이트웨이(NGINX Ingress Controller → FastAPI), 그리고 프롬메테우스-그라파나-로키 스택을 한 클러스터 안에 올려 ‘실시간 대화형 RAG 서비스’를 운영하려 합니다.
HorizontalPodAutoscaler(HPA)로 qps ≥ 150일 때 LLM Replica를 동적으로 늘리면서도, GPU 메모리 단편화나 MIG 슬롯 불일치 때문에 nvidia.com/gpu 요청이 충족되지 않아 Pending → CrashLoopBackOff가 잦아지고, 2) Karpenter로 노드 자동-프로비저닝을 켜 두면 GPU 스팟 인스턴스가 예고 없이 회수되어 동접이 급락하며 503이 발생합니다. 또한 3) loki-canary 로그 무결성 지표가 간헐적으로 붉게 변하고, 4) k6 부하테스트(2 분간 3 → 200 VU 스텝)에서 P99 응답 시간이 6 초를 넘으면 Ingress NLB가 자동으로 Health Check Fail로 인스턴스를 제외해 가용성이 추가로 나빠집니다.
이 상황에서
(a) ResourceClaimTemplates와 GPU Shared Device Plugin 조합으로 MIG 슬롯-레벨 할당을 보장하면서 HPA가 정상적으로 스케일-업/다운하도록 만드는 가장 안전한 매니페스트 구조,
(b) karpenter.sh/do-not-disrupt=critical 라벨과 ttlSecondsAfterEmpty 및 우선순위-가중치(spot < ondemand) 설정을 통해 스팟 회수 시 장애를 최소화하는 구체적 노드 플릿 전략,
(c) prometheus-operator-based Alertmanager 규칙으로 P99 latency > 4 s & loki-canary failures > 3 in 5 min 조건이 동시에 발생할 때만 슬랙·팀즈 알람을 묶어서 보내는 다단계 알림 흐름,
(d) Gateway API + HTTPRoute로 전환해 Ingress NLB HC를 --proxy-timeout=10s로 늘리되, 다운스트림 FastAPI에 uvicorn --timeout-keep-alive 15를 함께 맞춰 P99 지연을 흡수하는 엔드-투-엔드 튜닝 절차,
를 단계별 실험-검증하려면 어떤 순서로 매니페스트(Deployment, Provisioner, HPA, PromRule 등)를 수정하고 kubectl-capture-logs, promql, k6 thresholds, loki-tolerations 출력을 어떤 지표로 모니터링·해석하는 것이 좋을까요?”
정리:
각 실험 단계에서 매니페스트(Deployment, Provisioner, HPA, PromRule 등)을 한 번에 바꾸지 말고, 한 단계씩 적용→관찰→지표/로그 분석→문제 발생시 롤백/수정→다음 단계로 진행하는 것이 안정적입니다. 특히 GPU/MIG 할당과 노드 스케줄링, 알림 조건, 엔드-투-엔드 지연 튜닝은 반드시 실시간 모니터링과 로그 캡처를 병행해야 문제 원인을 빠르게 파악할 수 있습니다.
추가적인 YAML 예시나 PromQL 쿼리, k6 스크립트 등이 필요하면 언제든 말씀해 주세요!