반응형 [GPUaaS]/TensorFlow13 [중요3] 운영 표준 - [최종] KServer & NAS & S3 & TFJob.yaml (라벨/MIG/RWO/RWM 적용) 좋아, 이제 “실제 운영에 쓰는 풀버전 TFJob 설계” 단계로 제대로 가보자.아래 설명은 요약 없음, 처음부터 끝까지,👉 왜 이렇게 해야 하는지 → 어디서 실행되는지 → 각 필드의 의미까지 전부 풀어줄게.0️⃣ 먼저 전체 흐름부터 (이걸 머리에 그려야 YAML이 이해됨) (사람/CI) kubectl apply tfjob-train-prod.yaml ↓ [TFJob Controller] ├─ Chief Pod (GPU) │ ├─ NAS: 데이터셋 + 결과 공유 │ └─ 학습 완료 시 DONE 생성 │ ├─ Worker Pod들 (GPU) │ └─ NAS: 데이터셋 읽기 전용 │ └─ Uploader Sidecar (Chief만) └─ NAS 결과 → Object Storage(S3) ↓ [Object .. 2026. 1. 30. [중요2] 운영 표준 - [최종] Train.py & TFJob.yaml (라벨/MIG/RWO 적용) 그럼 지금부터 **“처음부터 끝까지 운영용 TFJob 완전 배포 세트”**를 순번으로, 실제 배포 기준으로 자세히 정리할게요.목표: Chief만 체크포인트 + Sidecar S3 업로드, Worker 계산 전용, MIG + RWO, GPU 라벨 준수🚀 운영용 TFJob 완전 배포 세트 순서1️⃣ Namespace 준비운영 환경에서는 프로젝트별/팀별 Namespace 권장 kubectl create namespace ml 확인: kubectl get ns 2️⃣ PVC 준비 (RWO, Chief 전용)블록스토리지 사용 시 RWOWorker는 PVC 쓰지 않고 계산만 함 # tf-output-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: .. 2026. 1. 30. [중요2] 운영 표준 - TFJob.yaml (라벨/MIG/RWO/S3 적용) “운영 표준 라벨 세트 + TFJob” 기준으로, GPU 전용 노드 Affinity, 최종 운영용 PVC + Sidecar 업로드 포함 (TFJob YAML)아래 YAML은 Chief + Worker 구조, GPU 라벨 기준 스케줄링, 출력 PVC + S3 업로드, GPU MIG 프로필 적용반영한 운영 표준 버전입니다. 📄 tfjob-train-prod.yaml apiVersion: kubeflow.org/v1 kind: TFJob metadata: name: tf-mnist-train namespace: ml spec: runPolicy: cleanPodPolicy: None tfReplicaSpecs: # ========================= # Chi.. 2026. 1. 28. [중요2] 운영 표준 - ☸️ Kubernetes + TensorFlow 구동 원리 ☸️ Kubernetes + TensorFlow“이 코드가 대체 어디서 어떻게 도는 건데?” 완전 정리0️⃣ 전체 그림 먼저 (제일 중요) [로컬 PC] (코드 작성) ↓ docker build [컨테이너 이미지] ↓ [컨테이너 레지스트리] ↓ kubectl apply -f tfjob.yaml ↓ [Kubernetes] ├─ Chief Pod ──▶ python train.py ← 이 코드 실행됨 └─ Worker Pod ─▶ python train.py ← 똑같이 실행됨 👉 당신이 직접 실행하는 게 아님👉 Kubernetes가 Pod 안에서 실행시킴 1️⃣ 이 코드는 “파일 하나”다📄 파일명보통 이렇게 씀: train.py 📌 train.. 2026. 1. 28. [중요2] 운영 표준 - GPU 노드 라벨 세트 🎯 한 줄 결론 먼저라벨은 “계층별로 의미가 하나씩만” 갖게 표준화하고MIG 쓰면 Chief / Worker 노드풀은 분리하는 게 정석이다. 1️⃣ GPU 노드 라벨 “표준 계층” (이게 핵심)라벨은 의미 중복 없이 계층화해야 한다.✅ Level 1 — 하드웨어 식별 (변하지 않음) gpu.vendor: nvidia gpu.model: A100 gpu.mem: 80gb 물리 스펙절대 바뀌지 않음모니터링 / 비용 / 통계용 ✅ Level 2 — GPU 기능 상태 gpu.mig: enabled # or disabled MIG ON / OFF스케줄 정책 분기점 ✅ Level 3 — MIG 구성 정책 (중요) gpu.mig.profile: 1g.10gb # 또는 3g.40gb 노드풀의 “의도”실제.. 2026. 1. 28. [GPU 타입] 운영 무중단 - 라벨 NodePool 등록 ✅ 결론 한 줄이미 운영 중인 NCP 노드풀에는👉 “콘솔(UI) 또는 NCP API”로만 라벨을 붙일 수 있고,👉 Kubernetes YAML로는 절대 못 붙인다.(kubectl label node는 임시 처방 ❌) 1️⃣ 왜 Kubernetes YAML로 안 되나?이유는 구조 차이야 [Kubernetes] └─ Node (결과물) [NCP] └─ NodePool (원본) └─ AutoScaling └─ Node 생성 YAML (Node, Machine)은 이미 만들어진 결과노드풀 라벨은 노드 생성 “이전” 설정👉 그래서❌ kubectl apply -f nodepool.yaml 같은 건 개념적으로 불가능 2️⃣ 이미 운영 중인 NCP 노드풀 → 라벨 추가 방법✅ .. 2026. 1. 27. [GPU 타입] 신규 라벨 NodePool 등록 (라벨 + Taint + Affinity 세트) kubectl label node … 는 “이미 존재하는 노드”에만 수동 적용이라👉 오토스케일링으로 새로 뜨는 노드에는 절대 자동 적용 안 됨 ❌ 1️⃣ 원칙 한 줄 요약GPU 타입 라벨은 Node가 아니라 NodePool / AutoScalingGroup에 붙인다2️⃣ Managed Kubernetes (정답 루트)✅ NCP / EKS / GKE 공통 개념 Node Pool ├─ 인스턴스 타입: A100 ├─ 오토스케일링 └─ 공통 라벨 (nodeLabels) 👉 새 노드가 생길 때 kubelet 시작 시 자동 부착🔹 NCP Kubernetes (GPU 노드풀)콘솔 / API 설정 개념 nodeLabels: gpu.vendor: nvidia gpu.model: A100 gpu... 2026. 1. 26. [GPU] Node Affinity + GPU 타입 분리 (A100 / H100) GPU 클러스터 운영의 핵심 중 핵심👉 라벨링 → Affinity → TFJob 적용 → 운영 팁 순서1️⃣ 왜 GPU 타입 분리가 필수냐?문제 상황 (안 하면 생기는 일)A100 / H100 혼재 노드Worker 일부는 A100, 일부는 H100❌ NCCL 성능 저하❌ 학습 속도 불균형❌ 결과 재현성 깨짐👉 분산 학습은 GPU “동질성”이 생명 2️⃣ GPU 노드 라벨링 (관리자의 1회 작업)🔹 권장 라벨 설계 gpu.vendor=nvidia gpu.model=A100 gpu.model=H100 gpu.mem=80gb gpu.interconnect=nvlink 예시 (A100 노드) (임시용) kubectl label node gpu-node-1 gpu.vendor=nvidia gpu.mod.. 2026. 1. 26. [GPU] requests = limits가 좋은 이유 1️⃣ GPU에서 requests = limits가 좋은 이유🔹 CPU / Memory랑 다름CPU / Memory → overcommit 가능GPU → 절대 불가 (정수 리소스, 독점)즉, requests: 1 limits: 1 은 사실상 GPU 세계의 기본 규칙 2️⃣ 경우별 동작 차이❌ limits만 있는 경우 limits: nvidia.com/gpu: 1 스케줄러는 암묵적으로 requests=1로 처리대부분 동작은 함❗ 하지만:리소스 계산이 명시적이지 않음Quota / Capacity 계산에서 혼란운영 표준 문서화에 불리✅ requests + limits 모두 있는 경우 (권장) requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1.. 2026. 1. 26. [TF 분산학습] 스토리지 관점 + TensorFlow 내부 동작 ✅ 최종 TFJob YAML (GPU 설정 추가) ======================================apiVersion: kubeflow.org/v1 kind: TFJob metadata: name: tf-mnist-train namespace: ml spec: runPolicy: cleanPodPolicy: None tfReplicaSpecs: # ========================= # Chief (결과 저장 + 업로드) # ========================= Chief: replicas: 1 restartPolicy: OnFailure template: spec: .. 2026. 1. 26. [쿠버네티스 워크로드 개념] TFJob / CronJob / Job / Deployment / Pod 쿠버네티스 “워크로드 개념”을 한 번에 정리할 수 있는 포인트라서,TFJob까지 묶어서 역할·수명·재시작·확장 관점으로 설명해줄게.1️⃣ Pod – 모든 것의 출발점✅ 뭐냐면쿠버네티스에서 실제로 실행되는 최소 단위하나 이상의 컨테이너 묶음특징일회성 존재죽으면 끝 (스스로 복구 안 됨)IP, 볼륨, 네임스페이스 공유언제 쓰나테스트디버깅절대 운영용 아님 apiVersion: v1 kind: Pod 📌 운영에서는 Pod를 직접 만들지 않는다 → 항상 상위 컨트롤러 사용 2️⃣ Deployment – “계속 살아 있어야 하는 서비스”✅ 뭐냐면무한히 실행되어야 하는 앱을 관리ReplicaSet을 통해 Pod 유지특징항상 지정한 개수만큼 Pod 유지롤링 업데이트 지원장애 시 자동 복구대표 사용처API 서버웹 서.. 2026. 1. 26. [TensorFlow] 구글이 만든 머신러닝·딥러닝 프레임워크 !! 1️⃣ TensorFlow가 뭐냐면AI 모델(머신러닝 / 딥러닝)을 만들고, 학습시키고, 배포까지 할 수 있는 오픈소스 라이브러리구글이 내부에서 쓰다가 공개함주 언어는 Python (C++ 기반, 속도 빠름)2️⃣ 이름이 왜 TensorFlow?Tensor: 다차원 배열 (0차원~N차원 데이터)Flow: 데이터가 그래프처럼 흘러가며 계산됨👉 “다차원 데이터가 계산 그래프를 따라 흐른다”는 뜻3️⃣ TensorFlow로 뭐 할 수 있어?대표적인 활용 예:✅ 딥러닝 모델이미지 인식 (CNN)음성 인식자연어 처리 (NLP)추천 시스템✅ 실서비스 배포웹 서버모바일 앱 (Android / iOS)엣지 디바이스 (Jetson, IoT)✅ GPU / TPU 활용GPU, 멀티 GPUTPU (구글 전용 가속기)4️⃣ .. 2026. 1. 26. [TFJob] POD Sidecar 자동 업로드 이번엔 개념 → Pod 구조 → 실제 동작 순서 → 왜 Chief만 쓰는지 4단계로 설명 ☸️ Sidecar 자동 업로드“기존 Pod랑 어떻게 연동되냐” 완전 해부0️⃣ 핵심 한 줄 먼저Sidecar는 ‘새 Pod’가 아니라, 기존 TFJob Pod 안에 같이 들어가는 컨테이너다👉 이게 이해의 80% 1️⃣ Kubernetes Pod 구조부터 정확히 잡자❌ 흔한 오해“Sidecar = 옆에서 도는 별도 Pod”“Uploader Pod가 Trainer Pod를 감시” ✅ 실제 구조 [ Pod (tfjob-chief-0) ] ├─ Container 1: trainer (TensorFlow) ├─ Container 2: uploader (Sidecar) └─ Shared Volume (PVC) .. 2026. 1. 25. 이전 1 다음 반응형
