서버 구축을 넘어 플랫폼까지 지원하기 위해
인프라에서 플랫폼까지 지원 범위를 넓히기 위해 준비한 사내 실습 환경. 단계별 시작점부터 모델 배포, 요청과 관측, 복원 범위를 살펴봅니다.
인프라를 운영하고 원리를 살펴보고.
그 과정을 남기는 기술 노트.
인프라에서 플랫폼까지 지원 범위를 넓히기 위해 준비한 사내 실습 환경. 단계별 시작점부터 모델 배포, 요청과 관측, 복원 범위를 살펴봅니다.
글 읽기물리 장비의 배치에서 클러스터와 실행 위치로 범위를 좁혀 봅니다.
장비별 실행 경계 · 박스 안은 해당 장비의 구성
각 KVM 호스트가 VM 두 대씩을 실행합니다. GPU 서버는 VM으로 만들지 않고 베어메탈 worker로 참여시켰습니다.
구분할 점KVM 호스트 자체와 그 위의 Kubernetes VM 노드는 서로 다른 관리 대상입니다.
두 KVM 호스트의 VM 네 대와 별도 GPU 서버. 각 KVM 호스트가 VM 두 대씩을 실행합니다. GPU 서버는 VM으로 만들지 않고 베어메탈 worker로 참여시켰습니다.
단계를 선택해 설명을 읽는 도식입니다. 실시간 서버 상태나 패킷 흐름을 표시하지 않습니다.
각 KVM 호스트가 VM 두 대씩을 실행합니다. GPU 서버는 VM으로 만들지 않고 베어메탈 worker로 참여시켰습니다.
장비별 실행 경계 · 박스 안은 해당 장비의 구성 KVM 호스트 A (control-plane VM · CPU worker VM 01) / KVM 호스트 B (CPU worker VM 02 · CPU worker VM 03) / 베어메탈 GPU 서버 (GPU worker · A100 PCIe 80GB × 1)
KVM 호스트 자체와 그 위의 Kubernetes VM 노드는 서로 다른 관리 대상입니다.
논리적으로는 Kubernetes 노드 다섯 대입니다. control-plane은 한 대이며, CPU worker와 GPU worker는 서로 다른 역할의 워크로드를 실행합니다.
Kubernetes 클러스터의 노드 구성 Control-plane × 1 (VM · API server / etcd) / CPU worker × 3 (VM · 플랫폼 서비스) / GPU worker × 1 (베어메탈 · 모델 실행)
단일 control-plane 구성입니다. API 고가용성을 구현한 사례는 아닙니다.
서비스가 실패했을 때 먼저 어느 노드의 워크로드인지 구분합니다. 모델 파일의 로컬 읽기 경로도 GPU 서버에 있습니다.
플랫폼 서비스 실행 위치 CPU worker VM (세 노드에 서비스 배치) → 실행 → 플랫폼 Pod (GitLab · Harbor · 인증 · 관측)
모델 실행 위치 GPU worker (containerd · NVIDIA runtime) → 실행 → vLLM Pod (A100 · GPU 서버의 모델 캐시 사용)
베어메탈 GPU 서버의 OS와 모델 캐시는 KVM VM 스냅샷에 포함되지 않습니다.
22개의 글이 있습니다.
인프라에서 플랫폼까지 지원 범위를 넓히기 위해 준비한 사내 실습 환경. 단계별 시작점부터 모델 배포, 요청과 관측, 복원 범위를 살펴봅니다.
학습할 문제를 고르는 일부터 pass@k, 정답 선택, 평가기의 오류와 회귀까지. 새 모델로 바꿀 근거를 따져봅니다.
문서에서 문제를 만들고 정답을 검수한 뒤, 교사와 학생의 차이·다양성·분리된 평가를 하나의 제작 과정으로 연결합니다.
요청을 나누고 도구와 모델을 고르는 과정. 비용·정확도·p95를 비교하고, 탐색·학습·구성 복원의 조건까지 살펴봅니다.
잔액을 공개하지 않고 가입 조건을 확인할 수 있을까요? API 응답에서 시작해 제출 자료와 서비스의 최종 판단까지 따라갑니다.
ClientHello부터 암호화된 응답까지 흐름을 따라가며, HTTPS가 보호하는 범위와 저장한 JSON만으로는 확인할 수 없는 것을 살펴봅니다.
Server, Prover, Notary, Verifier. 같은 세션에 참여해도 각자가 볼 수 있는 데이터와 맡은 역할은 다릅니다.
Kubespray와 RKE2의 운영 방식을 비교하고, RKE2·Helm·Rancher를 구성하며 다음 실습으로 넘어가기 전에 확인할 상태를 살펴봅니다.
온프레미스 RKE2에서 control-plane VIP와 워크로드 외부 IP를 구분하고, MetalLB와 NGINX Gateway Fabric으로 Gateway API 기반 진입 경로를 구성합니다.
PV·PVC·StorageClass·CSI의 관계를 살펴보고, NFS CSI Driver로 동적 RWX 볼륨을 만들어 여러 파드가 함께 쓰는 과정을 확인합니다.
Keycloak의 핵심 객체와 SSO의 동작 원리를 살펴보고, OIDC Authorization Code Flow with PKCE를 따라가며 SAML과의 선택 기준을 정리합니다.
Keycloak의 그룹 클레임을 Argo CD RBAC와 AppProject에 연결하고, 팀별로 조회와 동기화가 허용되는 범위를 확인합니다.
메트릭·로그·트레이스가 각각 어떤 질문에 답하는지 살펴보고, OpenTelemetry와 주요 백엔드의 역할을 구분하며 관측 가능한 예제 앱을 만듭니다.
kube-prometheus-stack, Loki 커뮤니티 차트, Fluent Bit Collector를 설치하고 ServiceMonitor·PrometheusRule·LogQL로 애플리케이션 메트릭과 로그의 수집 경로를 확인합니다.
GitLab Pipeline의 실행 조건과 실패 차단을 확인하고, 빌드 결과를 Git 변경으로 Argo CD에 넘기는 역할 구분을 설명합니다.
컨테이너 이미지와 Helm Chart의 저장 방식을 구분하고, Harbor와 GitLab 저장소를 Argo CD에 연결해 확인합니다.
앱 소스 변경이 Harbor 이미지와 배포 저장소를 거쳐 실제 웹 응답에 반영되는 과정을 구성하고, 각 단계의 식별자와 결과를 확인합니다.
Argo CD ApplicationSet과 AppProject로 여러 클러스터를 관리하고, 같은 이미지를 dev에서 stg와 prod로 옮길 때 Git 변경과 Merge Request로 승인하는 과정을 살펴봅니다.
MLflow·Ray·KubeRay·KServe·Knative가 각각 어떤 문제를 풀고, 학습부터 모델 서빙까지 어떻게 연결되는지 설명합니다.
PVC·S3/MinIO·MLflow의 역할을 구분하고, 같은 실험을 다시 확인할 수 있도록 데이터·코드·이미지·Python 의존성·모델을 함께 기록하고 고정하는 방법을 설명합니다.
GitLab CI·Harbor·GitLab Chart Repo·Argo CD의 배포 흐름을 RayJob·MLflow·KServe와 연결하며, 각 단계에서 저장하고 확인할 내용을 살펴봅니다.
src/train.py 변경에서 시작해 rootless 이미지 빌드, Harbor push, GitOps RayJob 학습, MLflow 기록, KServe 서빙으로 이어지는 과정을 실습하고 단계별 결과를 확인합니다.
자료 정리 표시는 외부 자료를 바탕으로 정리한 글입니다. 바탕이 된 자료는 각 글에 표시하며, 직접 수행한 실험과 구분해 기록합니다.