Kubernetes

🧩 실전 시나리오 기반 구성 배경 이 프로젝트는 단순 실습을 넘어서, 실제 발생하는 다음과 같은 문제들을 해결하기 위한 MLOps 인프라 구축을 목표로 설계되었습니다. 여러 모델 실험 결과가 뒤섞여 추적이 어려운 문제 → MLflow Tracking 서버 + PostgreSQL 메타데이터 저장소 구성 모델 파일 및 로그가 로컬에만 저장되어 협업 및 재현성이 떨어지는 문제 → S3 기반 artifact store 구성 + pyfunc 기반 모델 서빙 구조 설계 수작업 DAG 등록, 모델 배포 등의 비효율적 운영 문제 → Airflow + GitSync 연동으로 파이프라인 자동화 및 버전 관리 가능 ...

이 글에서 다루는 것 Airflow DAG에서 조건부 모델 등록 후 FastAPI 핫스왑까지 E2E 자동화 흐름을 실험합니다. 선수지식 MLOps 플랫폼 구축 5단계: FastAPI 서빙 및 핫스왑 구조 구축 — FastAPI 모델 로딩과 /reload API 구조 이 단계에서 해결하려는 문제 개별 컴포넌트(Airflow, MLflow, FastAPI)를 각각 구성했지만, 학습부터 서빙까지의 자동화 흐름을 E2E로 검증해야 실제 운영 가능 여부를 판단할 수 있습니다. 이 단계에서는 Airflow DAG에서 모델 학습 → 성능 기준 분기 → MLflow 등록 → FastAPI 핫스왑까지 전체 파이프라인을 실험합니다. ...

이 글에서 다루는 것 MLflow에 등록된 모델을 FastAPI로 서빙하고, Stage 기반 핫스왑과 모델 정보 조회 API를 구축합니다. 선수지식 MLOps 플랫폼 구축 4단계: Airflow GitSync + Secret 연동 — Helm 배포와 Secret 마운트 패턴 이 단계에서 해결하려는 문제 모델을 수동으로 서빙 서버에 복사하면 배포 실수와 버전 불일치가 발생합니다. MLflow Registry에서 Stage별 모델을 자동 로딩하는 구조를 만들어, 코드 변경 없이 모델을 교체할 수 있도록 합니다. 📐 아키텍처 구성도 🐳 FastAPI 커스텀 이미지 Dockerfile FROM python:3.12 WORKDIR /app COPY app /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"] requirements.txt fastapi==0.110.2 uvicorn==0.29.0 mlflow==2.13.0 pandas==2.1.4 scikit-learn==1.6.1 pydantic==2.7.1 boto3==1.34.113 numpy==1.26.4 packaging==24.2 psutil==7.0.0 scipy==1.15.3 setuptools==69.5.1 빌드 & 푸시 docker build -t ghcr.io/hoizz/fastapi-ml:mlflow-model-info . docker push ghcr.io/hoizz/fastapi-ml:mlflow-model-info 📄 app/main.py (핵심 부분) app = FastAPI() model = None model_info = {} def load_model_from_mlflow(): global model, model_info tracking_uri = os.environ.get("MLFLOW_TRACKING_URI") model_name = os.environ.get("MODEL_NAME") model_stage = os.environ.get("MODEL_STAGE", "Production") mlflow.set_tracking_uri(tracking_uri) model_uri = f"models:/{model_name}/{model_stage}" model = mlflow.pyfunc.load_model(model_uri) client = MlflowClient() latest = client.get_latest_versions(name=model_name, stages=[model_stage])[0] model_info = { "model_name": model_name, "stage": model_stage, "version": latest.version, "run_id": latest.run_id, "model_uri": model_uri, } @app.on_event("startup") def startup_event(): load_model_from_mlflow() @app.get("/model-info") def get_model_info(): return model_info @app.post("/predict") async def predict(request: Request): input_data = await request.json() prediction = model.predict(input_data) return {"prediction": prediction.tolist()} 전체 코드: GitHub (main.py) ...

이 글에서 다루는 것 Airflow를 Helm으로 배포하면서 GitSync DAG 동기화, 외부 PostgreSQL, AWS Secret 마운트를 연동합니다. 선수지식 MLOps 플랫폼 구축 3단계: MLflow Helm 구성 — Helm 기반 배포와 Secret 주입 패턴 이 단계에서 해결하려는 문제 DAG 코드를 수동으로 업로드하면 버전 관리와 협업이 불가능합니다. Git 기반 DAG 관리(GitSync)를 도입하고, SSH Key/AWS 인증을 Secret으로 주입하며, 외부 PostgreSQL을 메타데이터 저장소로 연동하는 GitOps 패턴을 구성합니다. 📐 아키텍처 구성도 🐳 커스텀 Airflow 이미지 구성 GitSync DAG에서 MLflow 연동 또는 AWS SDK 사용을 위한 Python 패키지 설치가 필요합니다. ...

이 글에서 다루는 것 MLflow를 PostgreSQL + S3 백엔드로 구성하여 Kubernetes에 Helm 배포하고, 커스텀 이미지와 Ingress를 연동합니다. 선수지식 MLOps 플랫폼 구축 2단계: S3 & PostgreSQL Secret 관리 — Secret/ConfigMap 주입 전략 이 단계에서 해결하려는 문제 한 프로젝트에 여러 버전의 모델이 등장하면, 각 실험의 파라미터/메트릭/아티팩트를 체계적으로 추적할 서버가 필요합니다. 로컬 MLflow UI(SQLite + file 저장)로는 팀 공유와 아티팩트 영속성이 부족합니다. 이 단계에서는 MLflow를 PostgreSQL(메타데이터) + S3(아티팩트) 백엔드로 구성하고 Helm으로 Kubernetes에 배포합니다. ...

이 글에서 다루는 것 Kubernetes Secret과 ConfigMap으로 S3/PostgreSQL 인증 정보를 안전하게 주입하는 전략을 다룹니다. 선수지식 MLOps 플랫폼 구축 1단계: 인프라 설계 및 환경 준비 — NFS/PostgreSQL/S3 환경 구축 이 단계에서 해결하려는 문제 모든 구성 요소(MLflow, Airflow, FastAPI)가 외부 DB, GitHub, S3 등 민감한 리소스와 연동됩니다. API 키와 비밀번호를 YAML이나 코드에 직접 넣으면 보안 위험이 발생합니다. 이 단계에서는 Kubernetes Secret과 ConfigMap을 활용하여 인증 정보를 안전하게 분리하고 주입하는 구조를 설계합니다. 아키텍처 구성도 ...

이 글에서 다루는 것 Kubernetes 기반 MLOps 인프라의 전체 구조를 설계하고, NFS/PostgreSQL/S3 기반 환경을 구축합니다. 선수지식 Airflow 5단계: PythonOperator + MLflow Tracking 연동 — Level 1 완료 후 시작 권장 이 단계에서 해결하려는 문제 ML 모델을 실험하고 추적하려면 단순 Jupyter Notebook으로는 부족합니다. 학습 이력 추적(MLflow), 파이프라인 자동화(Airflow), 모델 서빙(FastAPI)을 하나의 플랫폼에서 운영하려면 Kubernetes 기반 인프라가 필요합니다. 이 단계에서는 그 기반이 되는 NFS, PostgreSQL, S3, Kubernetes 클러스터 환경을 설계하고 구축합니다. ...

이 글에서 다루는 것 Prometheus로 Kubernetes 클러스터 메트릭을 수집하고, Grafana 대시보드로 시각화하는 모니터링 기초를 다룹니다. 선수지식 Kubernetes 4단계: Helm — Helm Chart 설치와 values.yaml 커스터마이징 이 단계에서 해결하려는 문제 Kubernetes 클러스터에서 Pod, Node의 CPU/메모리 사용량을 실시간으로 파악하지 못하면, 장애 대응과 리소스 최적화가 불가능합니다. Prometheus가 메트릭을 수집하고, Grafana가 이를 대시보드로 시각화합니다. 이 구조는 MLOps에서 모델 서빙 지연, 학습 리소스 모니터링의 기반이 됩니다. 실습 코드: GitHub (Monitoring) 🧭 전체 흐름 요약 ① Helm 저장소 추가 ② Prometheus 설치 (메트릭 수집) ③ Grafana 설치 (대시보드 시각화) ④ Web UI 접속 → Prometheus 연결 → 대시보드 불러오기 📂 디렉토리 구성 k8s-monitoring/ ├── values-prometheus.yaml # Prometheus 커스터마이징 설정 ├── values-grafana.yaml # Grafana 설정 + 비밀번호 지정 ├── README.md ⚙️ [1단계] Helm 저장소 추가 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo add grafana https://grafana.github.io/helm-charts helm repo update 📦 [2단계] Prometheus 설치 기본 설치 helm install prometheus prometheus-community/prometheus kubectl port-forward svc/prometheus-server 9090:80 접속: http://localhost:9090 ...

이 글에서 다루는 것 Kubernetes 앱을 패키지화하여 설치·업그레이드·롤백을 관리하는 Helm의 개념과 values.yaml을 통한 커스터마이징 방법을 다룹니다. 선수지식 Kubernetes 1단계: Deployment & Service — 기본 리소스 이해 Kubernetes 3단계: Ingress & Nginx Controller — 서비스 라우팅 개념 이 단계에서 해결하려는 문제 Deployment, Service, ConfigMap 등 여러 YAML 파일을 개별 관리하면, 환경별 설정 변경과 버전 관리가 어렵습니다. Helm은 이 YAML들을 하나의 Chart로 패키징하고, values.yaml로 설정만 바꿔서 재배포할 수 있게 합니다. MLOps에서 MLflow, ArgoCD, Prometheus 등을 설치할 때 사실상 표준 도구입니다. ...

이 글에서 다루는 것 여러 서비스를 하나의 진입점에서 경로(Path) 기반으로 라우팅하는 Ingress 리소스와 Nginx Ingress Controller를 다룹니다. 선수지식 Kubernetes 1단계: Deployment & Service — Pod 배포와 Service 노출 Kubernetes 2단계: ConfigMap & Secret — 설정 분리 개념 이 단계에서 해결하려는 문제 Service마다 NodePort를 열면 포트 관리가 복잡해지고, 도메인 기반 접근이 불가능합니다. Ingress는 단일 진입점에서 HTTP 요청을 경로나 호스트 기반으로 내부 서비스에 라우팅합니다. 실무에서 MLflow, Jupyter, API 서버를 하나의 도메인 아래 경로로 분리할 때 필수적인 구조입니다. ...