• 목록

쿠버네티스 클러스터는 컨테이너를 안정적으로 실행하고 확장하는 AI 인프라의 핵심입니다. 노드와 네트워크 구조부터 LLM 추론 배포와 장애 해결까지 단계별로 살펴봅니다. 특히 GPU를 사용하는 AI 서비스는 일반 웹 애플리케이션과 달리 자원 격리, 모델 적재 시간, 메모리 병목을 함께 관리해야 합니다. 따라서 설치보다 중요한 것은 워크로드 특성에 맞는 설계와 운영 기준을 세우는 일입니다.

AI 생성 삽화 · 쿠버네티스 클러스터 구축과 운영: AI·LLM 인프라 실전 가이드의 내용을 설명하기 위한 이미지입니다.

핵심 정리
쿠버네티스 클러스터는 컨테이너를 안정적으로 실행하고 확장하는 AI 인프라의 핵심입니다.

1. 쿠버네티스 클러스터 구조와 핵심 구성요소

컨트롤 플레인과 워커 노드 이해하기

쿠버네티스는 원하는 상태를 선언하면 실제 상태를 그에 맞게 조정하는 오케스트레이션 시스템입니다. 컨트롤 플레인은 API 서버, 스케줄러, 컨트롤러 매니저, 상태 저장소인 etcd로 구성됩니다. 사용자의 kubectl 요청은 API 서버를 거쳐 처리되며, 스케줄러는 CPU·메모리·GPU 조건에 맞는 노드를 선택합니다.

워커 노드에는 kubelet, 컨테이너 런타임, kube-proxy가 실행됩니다. kubelet은 파드의 실행 상태를 감시하고, 런타임은 실제 컨테이너를 구동합니다. AI 환경에서는 일반 노드와 GPU 노드를 분리하고, taint와 toleration, nodeSelector 또는 노드 어피니티로 모델 서버가 적절한 노드에만 배치되도록 구성하는 편이 안전합니다.

파드·서비스·스토리지의 역할

파드는 쿠버네티스에서 배포 가능한 가장 작은 단위이며, 하나 이상의 컨테이너와 네트워크·스토리지 설정을 묶습니다. 파드는 장애가 나면 교체될 수 있으므로 모델 파일이나 사용자 데이터처럼 지속되어야 하는 정보는 파드 내부에 저장하면 안 됩니다. 대신 오브젝트 스토리지, 네트워크 파일 시스템, 영구 볼륨을 목적에 맞게 선택해야 합니다.

서비스는 파드가 교체되어 IP가 바뀌어도 안정적인 접근 지점을 제공합니다. 외부 노출에는 Ingress 또는 Gateway API를 사용할 수 있고, 내부 통신에는 ClusterIP 서비스를 주로 사용합니다. 배포 객체는 롤링 업데이트와 롤백을 지원하므로 이미지 태그를 고정하고 변경 이력을 남기는 것이 운영의 기본입니다.

---

2. 클러스터 구축 및 노드·네트워크 설정

관리형 서비스와 직접 구축 비교

실습이나 빠른 검증에는 클라우드 관리형 쿠버네티스가 유리합니다. 컨트롤 플레인 운영 부담이 줄고, 오토스케일링·로드밸런서·IAM 연동을 제공하는 경우가 많기 때문입니다. 반면 직접 구축하면 네트워크, 인증서, etcd 백업, 업그레이드 정책까지 직접 결정해야 하므로 학습에는 좋지만 운영 책임이 커집니다.

구축 전에는 리전과 가용 영역, 노드 풀, 서브넷, 라우팅, 보안 그룹을 먼저 설계하세요. 시스템 파드용 노드와 애플리케이션 노드를 분리하면 자원 경합을 줄일 수 있습니다. 초기에는 작은 노드 풀로 시작하되, 실제 트래픽을 확인한 뒤 인스턴스 유형과 수량을 조정하는 방식이 불필요한 비용을 막습니다.

네트워크와 배포 기본 흐름

네트워크 플러그인은 파드 간 통신과 네트워크 정책을 담당합니다. 설치 직후에는 파드 CIDR과 서비스 CIDR이 기존 사내망 또는 VPC 대역과 겹치지 않는지 확인해야 합니다. 겹침은 특정 서비스에만 간헐적인 통신 오류를 만들 수 있어 사후 수정이 어렵습니다. DNS, 로드밸런서, 프라이빗 엔드포인트도 함께 점검하세요.

기본 배포는 네임스페이스 생성, 서비스 계정과 권한 설정, Deployment 작성, Service 연결 순서로 진행합니다. 리소스 요청과 제한을 반드시 지정하면 스케줄러가 배치 기준을 세울 수 있고, 한 파드가 노드 자원을 모두 소비하는 상황도 줄어듭니다. 매니페스트는 Git으로 관리하고 개발·스테이징·운영 환경의 차이는 Kustomize나 Helm 값으로 분리하는 것이 좋습니다.

---

3. GPU 기반 AI·LLM 워크로드 배포

GPU 노드 준비와 모델 서버 배치

GPU를 사용하려면 노드의 드라이버, 컨테이너 런타임 연동, GPU 디바이스 플러그인이 모두 정상이어야 합니다. 플러그인이 GPU 자원을 쿠버네티스에 등록하면 파드에서 nvidia.com/gpu 같은 자원 요청을 사용할 수 있습니다. 노드에 GPU가 보인다고 해서 컨테이너에서도 자동으로 사용 가능한 것은 아니므로 실제 추론 테스트가 필요합니다.

LLM 서버는 모델 크기와 양자화 방식에 따라 GPU 메모리 요구량이 크게 달라집니다. 파드에 GPU를 요청하고, GPU 노드에는 전용 라벨과 테인트를 설정하세요. 모델 가중치를 이미지에 포함하면 이미지가 지나치게 커질 수 있으므로 시작 시 오브젝트 스토리지에서 가져오거나 노드 캐시를 사용하는 방식을 비교해야 합니다. 다만 매번 다운로드하면 재시작 시간이 길어지므로 캐시 무효화 기준을 명확히 두어야 합니다.

추론 서비스의 지연과 처리량 관리

LLM 추론은 일반 API와 달리 첫 토큰까지의 시간, 토큰 생성 속도, 동시 요청 수가 함께 중요합니다. 파드 수만 늘리면 모델 메모리와 GPU가 부족해질 수 있으므로 배치 크기, 최대 입력 토큰, 최대 동시성, 스트리밍 설정을 먼저 조정해야 합니다. 긴 프롬프트가 많다면 KV 캐시가 GPU 메모리를 빠르게 소비할 수 있다는 점도 고려해야 합니다.

배포 전에는 대표적인 프롬프트 길이와 동시 요청 조건을 정해 부하 테스트를 수행하세요. 서비스에 readiness probe를 설정할 때 모델 로딩이 끝나기 전에 트래픽이 들어가지 않도록 해야 합니다. 롤링 업데이트는 GPU가 충분하지 않으면 새 파드와 기존 파드가 동시에 떠서 배포가 멈출 수 있으므로, 여유 용량 또는 별도 노드 풀을 확보하고 업데이트 전략을 조정해야 합니다.

---

4. 오토스케일링·관측성·보안 운영

CPU 기준을 넘어선 오토스케일링

HPA는 CPU와 메모리뿐 아니라 사용자 정의 지표를 기준으로 파드 수를 조절할 수 있습니다. LLM 서비스에서는 요청 대기열, 활성 요청 수, 토큰 처리량, GPU 사용률이 더 직접적인 신호가 될 수 있습니다. 다만 GPU 사용률만 높다고 무조건 파드를 늘리면 노드가 부족해질 수 있으므로 HPA와 노드 오토스케일러의 동작 순서를 함께 검증해야 합니다.

스케일아웃은 즉시 일어나도 모델 로딩은 오래 걸릴 수 있습니다. 따라서 예측 가능한 시간대에는 사전 확장하고, 최소 파드 수를 유지하는 전략이 효과적입니다. 반대로 개발 환경은 자동 중지나 야간 축소 정책을 적용해 비용을 줄일 수 있습니다. 오토스케일링 설정에는 최대치와 축소 안정화 시간을 넣어 급격한 반복 확장을 막으세요.

로그·메트릭·트레이싱과 접근 제어

운영 상태는 로그 하나만으로 판단하기 어렵습니다. 노드와 파드의 CPU·메모리·GPU 사용량, 재시작 횟수, API 지연, 오류율, 큐 대기 시간을 메트릭으로 수집해야 합니다. 로그에는 요청 ID를 남기고, 분산 트레이싱을 적용하면 게이트웨이부터 모델 서버까지 지연 구간을 연결할 수 있습니다. 프롬프트와 개인정보는 기본적으로 마스킹하거나 수집하지 않는 정책이 필요합니다.

보안은 최소 권한에서 시작합니다. 네임스페이스별 서비스 계정과 RBAC 권한을 나누고, 시크릿을 이미지나 Git 저장소에 넣지 마세요. 네트워크 정책으로 필요한 통신만 허용하고, 컨테이너는 가능하면 비루트 사용자로 실행합니다. 이미지 취약점 검사, 서명 검증, 파드 보안 기준 적용, 감사 로그 보관도 배포 파이프라인에 포함해야 합니다.

---

5. 장애 해결과 비용 최적화 전략

증상별 점검 순서

파드가 Pending이면 kubectl describe pod에서 스케줄링 이벤트를 확인하세요. GPU 부족, 노드 테인트, 리소스 요청 초과, PVC 연결 실패가 흔한 원인입니다. CrashLoopBackOff는 컨테이너 로그와 종료 코드, 환경 변수, 시크릿, 프로브 설정을 순서대로 확인하는 것이 좋습니다. 모델 로딩 실패는 파일 경로와 권한, 디스크 용량, GPU 메모리를 함께 살펴야 합니다.

서비스 접근 오류는 파드가 정상인지, 엔드포인트에 파드가 등록됐는지, 서비스 포트와 대상 포트가 일치하는지 확인합니다. 그다음 네트워크 정책, DNS, 로드밸런서, 외부 게이트웨이 순으로 범위를 넓히세요. 장애 조치 전에 현재 상태와 이벤트를 저장하면 원인 분석에 도움이 됩니다. 운영 환경에서는 임의로 파드를 삭제하기보다 롤백과 트래픽 차단 절차를 먼저 실행해야 합니다.

GPU 비용과 운영 비용 줄이기

GPU 비용 최적화의 핵심은 사용률이 아니라 유효한 처리량 대비 비용입니다. 작은 모델에는 더 작은 GPU를 사용하고, 양자화·배치 처리·모델 캐시를 조합해 메모리와 대기 시간을 함께 측정하세요. 개발용 GPU 노드는 스케줄 기반으로 중지하고, 운영용은 예약 할인이나 약정 상품을 검토할 수 있지만 실제 사용 패턴을 확인한 뒤 결정해야 합니다.

노드가 여러 종류라면 워크로드별 노드 풀을 나누고, 중단 가능한 인스턴스는 재시작을 감수할 수 있는 배치 작업에 제한적으로 사용합니다. 로그 보관 기간과 이미지 저장소의 오래된 태그, 사용하지 않는 PVC도 정기적으로 정리하세요. 비용 대시보드에는 팀·네임스페이스·서비스별 라벨을 연결해 누가 어떤 자원을 사용하는지 보이게 만드는 것이 중요합니다.

---

6. 자주 묻는 질문 (FAQ)

Q1. 쿠버네티스는 LLM 서비스에 꼭 필요한가요?

반드시 필요한 것은 아닙니다. 단일 모델과 소규모 트래픽이라면 가상 머신이나 단순 컨테이너 실행 환경이 더 경제적일 수 있습니다. 다만 여러 모델, GPU 노드, 자동 배포, 장애 복구, 팀 단위 자원 격리가 필요해지면 쿠버네티스의 이점이 커집니다. 운영 인력과 복잡성까지 비용에 포함해 선택하세요.

Q2. GPU가 있는데도 추론 속도가 느린 이유는 무엇인가요?

GPU 사용률만으로 성능을 판단하기 어렵습니다. 모델 로딩, CPU 전처리, 네트워크 지연, 작은 배치, GPU 메모리 부족에 따른 오프로딩이 원인일 수 있습니다. 첫 토큰 지연과 토큰 생성 속도를 분리해 측정하고, 입력 길이와 동시성 조건을 고정한 부하 테스트로 병목 구간을 찾아야 합니다.

Q3. HPA가 GPU 파드를 제대로 늘리지 못하면 어떻게 하나요?

기본 HPA는 GPU 지표를 자동으로 이해하지 못할 수 있습니다. Prometheus Adapter 등으로 사용자 정의 지표를 연결하고, GPU 파드를 수용할 노드가 실제로 늘어나는지도 확인해야 합니다. 파드 확장과 노드 확장의 시간 차이, 모델 로딩 시간, 최대 노드 수를 함께 설정하지 않으면 지연만 커질 수 있습니다.

Q4. 운영 전 반드시 준비해야 할 것은 무엇인가요?

배포 매니페스트와 이미지 버전 고정, 롤백 절차, 모니터링 대시보드, 알림 기준, 백업 정책을 먼저 준비해야 합니다. 특히 etcd나 관리형 제어 영역의 백업 범위와 모델·설정 파일의 복구 방법을 구분하세요. 장애 상황에서 누가 어떤 순서로 대응할지 런북으로 문서화하면 복구 시간을 줄일 수 있습니다.

---

7. 마무리

쿠버네티스 클러스터 운영은 설치 명령보다 자원 배치, 네트워크, 모델 수명 주기, 관측성과 보안을 함께 설계하는 작업입니다. 처음에는 관리형 환경에서 작은 GPU 노드 풀과 단순한 추론 서비스를 구성하고, 부하 테스트로 병목과 비용을 확인해 보세요. 이후 사용자 정의 지표 기반 오토스케일링, 장애 훈련, 비용 라벨링을 단계적으로 추가하면 안정성과 효율을 함께 높일 수 있습니다.

태그: #쿠버네티스 #클라우드인프라 #AI인프라 #LLM배포 #GPU클러스터

---

참고 자료

• Kubernetes GPU 스케줄링 공식 문서