26S25a

K8s + Cilium ClusterMesh 조합이면, 지금까지 bare-metal에서 검증한 걸 "그대로 믿으면 안 되는" 항목들이 꽤 생깁니다. 단순히 새 테스트를 추가하는 것보다, 컨테이너화/오버레이 네트워크가 기존 검증 결과를 몰래 깨뜨리지 않는지 재검증하는 항목과 K8s+ClusterMesh 고유 신규 항목을 나눠서 보는 게 정확합니다.

A. 가장 먼저 봐야 할 것 — NCCL이 오버레이를 타고 있진 않은지

이게 실무에서 가장 흔히 놓치는 부분입니다. Stage1에서 NCCL All-Reduce로 NVLink 대역폭을 검증했는데, K8s 파드 안에서 NCCL이 물리 NIC이 아니라 Cilium의 오버레이 인터페이스(veth/overlay)를 잡아버리면 대역폭이 크게 떨어집니다.

• 단일 노드 NVLink는 GPU 간 직결이라 파드 네트워킹과 무관하게 영향이 적지만, 향후 멀티노드로 확장할 계획이 있다면 NCCL_SOCKET_IFNAME이 올바른 물리 NIC을 가리키는지, Multus 같은 세컨더리 CNI로 GPU 노드에 물리 NIC을 직접 노출해야 하는 건 아닌지 반드시 확인이 필요합니다.
• 재검증 필요: Stage1의 all_reduce_perf를 bare-metal이 아니라 K8s 파드 내부에서 재실행해서 수치가 그대로인지 확인.

B. Cilium ClusterMesh 자체 — 네이티브 라우팅 vs 오버레이

RDMA가 없는 상황에서는 TCP 경로에 추가 오버헤드가 조금이라도 붙으면 그대로 성능 손실로 직결됩니다.

• Cilium이 VXLAN/Geneve 캡슐화 모드인지, Native Routing(BGP로 Pod CIDR을 직접 광고, 캡슐화 없음) 모드인지부터 확인해야 합니다 — 후자가 오버헤드가 훨씬 적습니다. 앞서 언급하신 BGP 환경이면 아마 Native Routing일 가능성이 높은데, 실제로 그렇게 동작하는지 패킷 캡처로 확인 필요.
• 재검증 필요: Stage2의 iperf3 단일/멀티 스트림, LACP 25G/50G 테스트를 파드-투-파드(Pod-to-Pod, 특히 클러스터 간)로 재실행해서 bare-metal 대비 손실폭을 측정. ClusterMesh 경유 시 홉이 늘어나는 만큼 지연(RTT)이 늘어나는지도 별도 측정.
• BGP 라우트 수렴 시간: 노드 장애/재기동 시 라우트가 얼마나 빨리 갱신되는지(수 초 vs 수십 초) — 이게 느리면 장애 시 트래픽 블랙홀 구간이 생깁니다.

C. GPU 스케줄링이 NVLink 토폴로지를 깨지 않는지

• NVIDIA GPU Operator + Node Feature Discovery + (필요시) Topology Manager가 제대로 구성되어 있는지. TP=8 파드가 8장을 요청했을 때 실제로 이 8장이 물리적으로 같은 NVSwitch 도메인 안에 있는 GPU들인지(멀티 NVSwitch 보드 구성이면 쪼개질 수 있음) 확인이 필요합니다.
• MIG를 켰다면 MIG 슬라이스 간 NVLink 특성이 완전히 달라지므로 MIG 미사용/사용 여부를 먼저 확정.

D. 기존 Compute 클러스터(Spark/StarRocks/Trino/JupyterLab) 특화 부하 패턴

지금까지의 stage3a6(포화점), stage5b(부하테스트)는 "점진적으로 동시성을 올리는" 패턴이었는데, 실제 이 엔진들의 트래픽은 성격이 다릅니다.

엔진	실제 패턴	추가로 봐야 할 것
Spark	수백 개 executor가 동시에 폭발적으로 추론 요청을 쏨(스텝 함수형 버스트)	점진적 동시성 램프업이 아니라 즉각적 스파이크(예: 0→256 동시성이 수 초 내) 테스트, LiteLLM/Envoy 레벨 커넥션 풀 고갈 여부
Trino/StarRocks	쿼리 페더레이션 중 GPU 노드로의 소수의 긴 요청(UDF 스타일)	쿼리 타임아웃과 vLLM 응답시간 불일치 시 커넥션 누수 여부
JupyterLab	사람이 쓰는 인터랙티브 — 낮은 동시성, 매우 불규칙, 장시간 유휴 후 갑작스런 요청	Stage1에서 짚었던 "유휴 후 첫 요청 지연(warm-up latency)"이 K8s 파드 레벨에서도 재현되는지 — 특히 GPU가 아니라 파드 자체가 스케일다운되어 있다가 콜드 스타트하는 경우(오토스케일링 쓴다면) 지연이 수십 초까지 갈 수 있음

• 신규 필요: Spark 스타일 "스텝 버스트" 부하 생성기 — 기존 stage3a6(점진적 램프업)와 별개로, 순간적으로 목표 동시성에 도달하는 패턴 전용 스크립트.

E. MinIO AIStor 접근 경로 변화

• 기존엔 STORAGE_NODE_IP 고정 IP로 접근했는데, ClusterMesh에서는 Global Service(같은 이름의 서비스가 여러 클러스터에 존재할 때 자동 로드밸런싱/장애조치)로 접근하게 됩니다. 이 서비스 디스커버리 자체의 지연과, 실제로 "가까운"(같은 클러스터) MinIO 백엔드를 우선 선택하는지(Cilium의 로컬리티 우선순위 설정) 확인 필요.
• 재검증 필요: Stage2의 MinIO Cold Load 테스트를 ClusterMesh 경유로 재실행해서 대역폭 손실 여부 확인.

F. 회복탄력성 (K8s라서 새로 생기는 항목)

• 노드 드레인/코든: 유지보수 시 GPU 노드를 드레인하면 서빙 중인 vLLM 파드가 얼마나 우아하게 종료되는지(진행 중인 요청 처리 후 종료 vs 강제 킬), PodDisruptionBudget 동작 확인
• Readiness Probe 오탐: DeepSeek-R1처럼 로딩에 수십 분 걸리는 모델은, 기본 HTTP readiness probe가 "포트는 열렸지만 모델 로딩 안 끝남" 상태에서 트래픽을 조기에 흘려보낼 위험 — initialDelaySeconds/startupProbe 설정 검증 필수
• ClusterMesh 단절 시뮬레이션: 클러스터 간 연결이 일시적으로 끊겼을 때 GPU 노드가 로컬 트래픽은 정상 처리하는지, Compute 클러스터 쪽은 재시도/서킷브레이커로 우아하게 실패하는지(캐스케이딩 장애 방지)

G. 관측성 통합

• Stage5e에서 독립적으로 띄운 Prometheus/Grafana를, 기존 클러스터에 이미 있는 모니터링 스택과 federation할지 별도로 유지할지 결정 필요
• Cilium Hubble로 클러스터 간 트래픽 플로우/정책 드롭을 시각화 — 특히 네트워크 정책으로 막힌 트래픽을 조기에 발견하는 용도로 유용

H. 보안/네트워크 정책

• 기존엔 firewalld 규칙이었는데, K8s에서는 CiliumNetworkPolicy/CiliumClusterwideNetworkPolicy로 전환 — Compute 클러스터의 어떤 워크로드 아이덴티티(namespace/서비스어카운트)만 GPU 서비스에 접근 가능한지를 IP 기반이 아니라 아이덴티티 기반으로 재설계·검증

I. 리소스 경합 (노이즈 네이버)

• ClusterMesh로 물리 네트워크 팹릭을 공유하게 되므로, Spark의 대용량 셔플/StarRocks 쿼리가 네트워크를 점유할 때 GPU 노드의 외부 통신(모델 다운로드, KV 티어 트래픽)이 밀리는지 — Cilium Bandwidth Manager(대역폭 제한/QoS) 설정 여부에 따라 결과가 크게 갈립니다.

---

==