[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)

 

 

 

👉 컨테이너만 2개, Pod는 1개

 

---

2️⃣ 기존 TFJob Pod랑 “연동”이 아니라

👉 원래부터 같은 Pod다

TFJob YAML에서 이렇게 생김 👇

template:
  spec:
    containers:
    - name: trainer
    - name: uploader   # ← Sidecar

 

 

 

📌 Kubernetes 입장에서는:

• 같은 Pod
• 같은 네트워크
• 같은 Volume
• 생명주기도 묶임

 

 

---

3️⃣ 그럼 둘이 뭘로 소통하냐?

👉 Shared Volume (PVC) 하나로 끝

 

volumeMounts:
- name: output
  mountPath: /output

 

 

 

 

volumes:
- name: output
  persistentVolumeClaim:
    claimName: tf-output-pvc

 

 

 

결과

 

trainer 컨테이너
  /output/model
  /output/checkpoint
  /output/DONE   ← 생성

uploader 컨테이너
  /output/model  ← 바로 보임

 

 

 

 

👉 파일 시스템 공유 = 통신

 

 

---

4️⃣ 실제 동작 흐름 (시간 순서)

⏱ Step 1. Pod 생성

 

tfjob-chief-0 Pod 생성
 ├─ trainer 시작
 └─ uploader 시작

 

 

 

⚠️ 아직 학습 안 끝남

---

⏱ Step 2. uploader는 그냥 대기

 

while true; do
  if [ -f /output/DONE ]; then
    ...
  fi
  sleep 30
done

 

 

 

 

👉 uploader는 아무것도 안 함
👉 GPU도 안 씀

---

⏱ Step 3. trainer가 학습 수행

 

model.fit(...)
model.save("/output/model")

 

 

 

---

⏱ Step 4. 학습 끝 신호

 

open("/output/DONE", "w").close()

 

/output/
 ├─ model/
 ├─ checkpoint/
 └─ DONE   ← 이게 트리거

---

⏱ Step 5. uploader가 감지

 

if [ -f /output/DONE ]; then
  aws s3 sync /output s3://bucket/path
  exit 0
fi

 

 

 

👉 자동 업로드 시작

---

⏱ Step 6. 업로드 완료

• uploader 컨테이너 종료
• trainer도 이미 종료
• Pod 종료

---

5️⃣ 그럼 “기존 Pod”는 뭐가 바뀌냐?

❌ 바뀌는 것 없음

• trainer 코드 거의 동일
• TFJob 구조 동일

✅ 딱 2개만 추가됨

1. output PVC mount
2. DONE 파일 생성 코드

---

6️⃣ 왜 Chief에서만 Sidecar를 쓰냐 (중요)

TFJob 구조 다시 보자

 

Chief  → 모델 저장 (1명)
Worker → 계산만 함 (N명)

 

 

 

만약 Worker에도 Sidecar가 있으면?

 

Worker-0 → 업로드
Worker-1 → 업로드
Worker-2 → 업로드

 

 

🔥 같은 결과를 N번 업로드
🔥 Object Storage 충돌
🔥 비용 + 장애

---

그래서 YAML이 이렇게 분리됨 👇

 

tfReplicaSpecs:

  Chief:
    template:
      spec:
        containers:
        - name: trainer
        - name: uploader   # ✅ 여기만

  Worker:
    template:
      spec:
        containers:
        - name: trainer    # ❌ uploader 없음

 

 

 

👉 의도적으로 Chief만 업로드 책임

 

 

---

7️⃣ “기존 Pod랑 연동”을 한 문장으로 정리하면

❌ Pod ↔ Pod 연동
✅ 같은 Pod 안에서, 같은 PVC를 보는 컨테이너 2개

---

8️⃣ Sidecar 방식이 헷갈리는 이유 (솔직히)

• “Sidecar”라는 이름이 오해를 부름
• 실제로는 멀티 컨테이너 Pod
• Kubernetes 기본 개념을 정확히 알아야 함

---

9️⃣ 이해 체크 (이게 보이면 이해 완료)

이 문장이 자연스럽게 느껴지면 끝이야 👇

“TFJob Chief Pod 하나 안에
TensorFlow 컨테이너랑
업로드 전용 컨테이너가
같은 PVC를 보면서 같이 돈다”