26O01b

About this offer

k8s 환경에서의 테스트 추가 고려사항 K8s + Cilium ClusterMesh 조합이면, 지금까지 bare-metal에서 검증한 걸 "그대로 믿으면 안 되는" 항목들이 꽤 생김. 단순히 새 테스트를 추가하는 것보다, 컨테이너화/오버레이 네트워크가 기존 검증 결과를 몰래 깨뜨리지 않는지 재검증하는 항목 과 K8s+ClusterMesh 고유 신규 항목 을 나눠서 보는 게 정확함. A. 가장 먼저 봐야 할 것 — NCCL 재검증 Stage1에서 NCCL All-Reduce로 NVLink 대역폭을 검증했는데, K8s Pod 내부에서 반드시 재검증 필요. 현재 Cilium이 Native Routing을 사용하는 환경이어서 Pod의 eth0는 veth 기반이지만 Cilium eBPF와 Linux native routing을 거쳐 물리 NIC으로 전달됨. Single-node 8-GPU AllReduce에서는 NVLink/NVSwitch 경로가 핵심이므로 Cilium networking 영향은 제한적일 가능성이 높음. 반면 multi-node NCCL에서는 Pod → veth → Cilium → native routing → BGP/ECMP → physical NIC 경로가 실제 성능에 영향을 줄 수 있으므로 별도의 검증이 필요. 따라서 K8s 검증에서는 Bare Metal → hostNetwork Pod → Cilium Pod를 비교하고, NCCL 로그에서 실제 transport/interface 선택을 확인(NCCL_SOCKET_IFNAME이 올바른 물리 NIC을 가리키는지). Multus/SR-IOV는 성능 저하가 확인될 경우 비교 대상으로 추가. MTU 불일치 확인: Native Routing 환경이어도 물리 스위치(Jumbo Frame 9000), 노드 인터페이스, Pod veth 간 MTU가 일치하지 않으면 TCP 패킷 단편화로 NCCL 링 레이턴시가 급증합니다. Socket Buffer Sizing: RDMA가 없는 TCP NCCL 환경에서는 NCCL_BUFFSIZE 및 리눅스 커널의 net.ipv4.tcp_rmem/wmem 파라미터가 Pod 네트워크 네임스페이스에 어떻게 전파되는지(sysctl allowlist) 확인해야 제 성능이 나옵니다. B. Cilium ClusterMesh 자체 RDMA가 없는 상황에서는 TCP 경로에 추가 오버헤드가 조금이라도 붙으면 그대로 성능 손실 로 직결됨. Cilium VXLAN/Geneve 캡슐화 모드 대비 Native Routing(BGP로 Pod CIDR을 직접 광고, 캡슐화 없음) 모드가 오버헤드가 훨씬 적음. 재검증 필요 : Stage2의 iperf3 단일/멀티 스트림, LACP 25G/50G 테스트를 Pod-to-Pod(특히 클러스터 간)로 재실행 해서 bare-metal 대비 손실폭을 측정. ClusterMesh 경유 시 홉이 늘어나는 만큼 지연(RTT)이 늘어나는지도 별도 측정. BGP 라우트 수렴 시간(BGP BFD(Bidirectional Forwarding Detection) 연계 여부에 따른 수렴 시간 검증): 노드 장애/재기동 시 라우트가 얼마나 빨리 갱신되는지(수 초 vs 수십 초) — 이게 느리면 장애 시 트래픽 블랙홀 구간이 생김 Conntrack 테이블 포화: All-Reduce나 분산 추론 시 다수의 TCP 세션이 폭발할 때 eBPF/Linux conntrack 테이블(sysctl net.netfilter.nf_conntrack_max) 한도에 걸리지 않는지 확인해야 함. eBPF Host-Routing 우회 여부: Cilium이 Host-Routing 모드로 동작하여 Pod veth의 TCP 스택을 바이패스(tc BPF)하고 있는지 cilium status --verbose로 체크 리스트에 포함. C. GPU 스케줄링이 NVLink 토폴로지를 깨지 않는지 NVIDIA GPU Operator + Node Feature Discovery + (필요시) Topology Manager가 제대로 구성되어 있는지. TP=8 파드가 8장을 요청했을 때 실제로 이 8장이 물리적으로 같은 NVSwitch 도메인 안에 있는 GPU들인지 (멀티 NVSwitch 보드 구성이면 쪼개질 수 있음) 확인이 필요. MIG를 켰다면 MIG 슬라이스 간 NVLink 특성이 완전히 달라지므로 MIG 미사용/사용 여부를 먼저 확정. NUMA-NIC-GPU Alignment: 8장이 통째로 할당되는 전체 점유 상황 외에도, 부분 할당이나 PCIe/NIC 인터페이스가 특정 NUMA 노드에 바인딩되어 있을 때 GPU와 NIC 간 CPU 소켓 간 트래픽(UPI/QPI traversal)이 발생하는지 Kubelet TopologyManager 정책(single-numa-node 또는 restricted)을 통해 확실히 묶어야 함. 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 (점진적 램프업)와 별개로, 순간적으로 목표 동시성에 도달하는 패턴 전용 스크립트. SYN Queue / Listen Backlog: Spark executor 수백 개가 동시에 vLLM 엔드포인트(혹은 앞단의 Gateway/Envoy)로 TCP 커넥션을 맺을 때 net.core.somaxconn 및 tcp_max_syn_backlog 제한으로 인한 패킷 드롭이 발생하기 쉽습니다. vLLM Continuous Batching 큐잉 지연: 스텝 버스트 인입 시 vLLM의 KV Cache가 포화되어 대기 큐(Waiting Queue)에 머무르는 시간이 길어지며 발생하는 Time-to-First-Token(TTFT)의 P99 스파이크를 측정 지표로 명시하면 좋음. E. MinIO AIStor 접근 경로 변화 기존엔 STORAGE_NODE_IP 고정 IP로 접근했는데, ClusterMesh에서는 Global Service (같은 이름의 서비스가 여러 클러스터에 존재할 때 자동 로드밸런싱/장애조치)로 접근하게 됨. 이 서비스 디스커버리 자체의 지연과, 실제로 "가까운"(같은 클러스터) MinIO 백엔드를 우선 선택하는지(Cilium의 로컬리티 우선순위 설정) 확인 필요. 재검증 필요 : Stage2의 MinIO Cold Load 테스트를 ClusterMesh 경유로 재실행해서 대역폭 손실 여부 확인. Cilium Topology Aware Routing: service.kubernetes.io/topology-mode: Auto 또는 Cilium 서비스 어노테이션을 통해 Compute 파드가 속한 클러스터/존의 MinIO 파드로 트래픽을 강제하는지 검증 필요. 로컬 노드 백엔드가 준비 상태임에도 ClusterMesh 터널을 타고 원격 클러스터 MinIO로 트래픽이 새어나가지 않는지 패킷 경로 확인이 필수. F. 회복탄력성 (K8s라서 새로 생기는 항목) 노드 드레인/코든 : 유지보수 시 GPU 노드를 드레인하면 서빙 중인 vLLM 파드가 얼마나 우아하게 종료되는지(진행 중인 요청 처리 후 종료 vs 강제 킬), PodDisruptionBudget 동작 확인 Readiness Probe 오탐 : DeepSeek-R1처럼 로딩에 수십 분 걸리는 모델은, 기본 HTTP readiness probe가 "포트는 열렸지만 모델 로딩 안 끝남" 상태에서 트래픽을 조기에 흘려보낼 위험 — initialDelaySeconds / startupProbe 설정 검증 필수 ClusterMesh 단절 시뮬레이션 : 클러스터 간 연결이 일시적으로 끊겼을 때 GPU 노드가 로컬 트래픽은 정상 처리하는지, Compute 클러스터 쪽은 재시도/서킷브레이커로 우아하게 실패하는지(캐스케이딩 장애 방지) StartupProbe 분리: Readiness 대신 startupProbe(failureThreshold × periodSeconds를 30분 이상으로 넉넉히 설정)를 적용하여 모델 체크포인트 다운로드 및 메모리 로딩 중 Kubelet이 컨테이너를 OOM/Restart 루프에 빠뜨리지 않도록 구성해야 합니다. preStop Hook 구현: Kubelet 드레인 시 vLLM 프로세스가 SIGTERM을 받기 전 인그레스/엔드포인트 슬라이스에서 먼저 제외되도록 5~10초간 sleep을 주는 preStop 훅 유무를 검증 항목에 추가하세요. 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) 설정 여부에 따라 결과가 크게 갈림. Cilium Bandwidth Manager는 Linux 커널 FQ(Fair Queueing)와 BPF 기반 패킷 스케줄링을 사용하므로, 노드 커널 버전 호환성과 활성화 여부(enable-bandwidth-manager: true)를 사전 확인해야 합니다. CiliumNetworkPolicy 적용 시 eBPF 맵 엔트리가 과도하게 늘어나 데이터 플레인 지연(BPF Map lookup overhead)이 생기지 않는지 부하 상태에서 CPU/지연을 함께 관측하는 것이 좋음. 우선순위 영역 테스트 시나리오 사전 조건 및 필수 설정 핵심 측정 지표 합격 기준 (Pass Criteria) P0 (Critical) 네트워크 기반 Host vs hostNetwork vs Pod veth TCP 성능 및 RTT 비교 MTU 9000 통일(스위치·노드·Pod veth); Cilium Native Routing 및 eBPF Host Routing 활성화 iperf3 단일·멀티 Throughput; ping·sockperf RTT; CPU softirq 점유율 Bare-metal 대비 처리량 손실률 5% 이하; Pod 간 RTT 증가 0.1ms 이하 P0 (Critical) GPU 통신 Pod 환경 NCCL All-Reduce 대역폭 및 인터페이스 바인딩 검증 NCCL_SOCKET_IFNAME 물리 NIC 지정; Pod net.ipv4.tcp_rmem/wmem 튜닝; NVIDIA Operator 및 Topology Manager 구성 Bus Bandwidth (GB/s); NCCL 커널 로그 인터페이스 확인; NUMA 소켓 간 트래픽 여부 단일 노드 8-GPU: Bare-metal 대비 NVLink 98% 이상 유지; 멀티 노드: Bare-metal 대비 TCP 90% 이상 유지 P0 (Critical) 수명주기/안정성 대형 모델(R1 등) Pod 콜드 스타트 및 Startup/Readiness 프로브 오탐 검증 startupProbe 분리(failureThreshold 넉넉히 설정); Ingress/Service 라우팅 연계 모델 가중치 메모리 적재 완료 시간; Probe 실패로 인한 컨테이너 비정상 재시작 횟수 초기 모델 로딩 중 비정상 재시작 0회; 실제 서빙 준비 완료 전 트래픽 유입 0건 P1 (High) 서비스 디스커버리 ClusterMesh Global Service 경유 MinIO Cold Load 및 로컬리티 라우팅 검증 Cilium ClusterMesh 피어링 정상 상태; service.kubernetes.io/topology-mode: Auto 적용 MinIO 읽기·쓰기 Throughput (MB/s); 클러스터 간 Egress/Ingress 트래픽 발생 비율 동일 클러스터 내 백엔드로 100% 로컬 라우팅 유지; 고정 IP 직접 접근 대비 전송 속도 저하 3% 이하 P1 (High) 워크로드 부하 Spark 대규모 동시 요청(스텝 버스트: 0→256) 급증 시 TCP 커넥션 처리 somaxconn 및 tcp_max_syn_backlog 상향; Envoy/LiteLLM 연결 풀 설정 완료 SYN Drop 횟수 (netstat -s); Conntrack 테이블 사용률; TTFT P95/P99 레이턴시 SYN 드롭 및 커넥션 거부 0건; Conntrack 테이블 포화율 70% 이하 P1 (High) 회복탄력성 GPU 워커 노드 유지보수(Drain/Cordon) 시 Graceful Shutdown 및 PDB 동작 preStop 훅(5~10초 sleep); PodDisruptionBudget(minAvailable) 설정 처리 중이던 In-flight 요청 실패율; 엔드포인트 슬라이스 동기화 지연 노드 드레인 시 처리 중인 요청의 502/504 에러 0건; PDB 위반 없는 롤링 퇴거 확인 P2 (Medium) 라우팅 수렴 ClusterMesh 장애·단절 시뮬레이션 및 BGP 라우트 수렴 시간 측정 BGP 라우팅 피어링 및 BFD 연동; 장애 주입 툴 또는 인터페이스 down 스크립트 BGP Route Convergence Time (초); 클러스터 단절 중 로컬 Pod 간 요청 성공률 BGP 라우트 재수렴 3초 이하 (BFD 적용 시 1초 이하); 원격 클러스터 단절 시 로컬 트래픽 영향 0% P2 (Medium) 노이즈 네이버 Spark 대용량 셔플·분산 쿼리와 GPU 통신 간 네트워크 경합 완화 Cilium Bandwidth Manager 활성화; Linux 커널 FQ(Fair Queueing) 스케줄러 적용 백그라운드 셔플 중 vLLM 토큰 생성 속도 저하율; 네트워크 패킷 지연 편차(Jitter) 대역폭 포화 상태에서도 GPU 외부 통신 Throughput 저하 15% 이내 방어 P2 (Medium) 보안/관측성 CiliumNetworkPolicy 적용 및 Hubble 기반 클러스터 간 트래픽 플로우 추적 Hubble Relay 및 UI/CLI 구동; Workload Identity(Namespace/SA) 기반 정책 배포 eBPF 맵 엔트리 크기 및 메모리 점유율; 정책 파싱으로 인한 데이터 플레인 레이턴시 정책 적용 전후 RTT 차이 오차범위(0.05ms 이하) 유지; 비인가 접근 즉각 DROP 및 감사 로그 적재 전체적으로 매우 좋은 구성 입니다. 특히 “bare-metal 테스트를 K8s에서 반복한다”와 “K8s/ClusterMesh에서만 생기는 신규 failure mode를 별도로 검증한다”를 분리한 것이 맞습니다. 다만 실무 관점에서는 몇 군데 중요한 수정/보강이 필요합니다. 특히 B의 ClusterMesh 경로 , E의 Global Service , C의 GPU topology , 그리고 I의 네트워크 경합 은 조금 더 정확하게 정의하는 것이 좋습니다. 제가 보면 현재 문서는 약 85~90% 완성된 상태 이고, 아래처럼 다듬으면 실제 K8s validation plan으로 바로 사용할 수 있습니다. 1. 전체 평가 영역 평가 수정 필요성 A. NCCL 재검증 ★★★★★ 거의 그대로 사용 가능 B. ClusterMesh ★★★★☆ Native routing/ClusterMesh 경로 표현 보강 C. GPU topology ★★★★☆ Topology Manager에 대한 표현 수정 D. 실제 workload ★★★★☆ 일부 workload 특성 재검토 E. AIStor ★★★★☆ Global Service와 AIStor 고정 IP를 분리해서 정의 F. Resilience ★★★★★ 매우 중요 G. Observability ★★★★☆ federation보다 correlation이 더 중요 H. Security ★★★★★ 반드시 포함 I. Resource contention ★★★★★ 매우 중요한 신규 항목 그리고 하나 더 추가하고 싶습니다. J. Kubernetes scheduling / lifecycle / CPU-memory overhead 현재 문서에는 GPU와 network는 잘 들어가 있지만, K8s가 GPU inference 성능에 추가하는 CPU, memory, IRQ, cgroup, NUMA, eviction 등의 영향 이 별도 항목으로 빠져 있습니다. 2. A — NCCL 재검증: 거의 정확함 이 부분은 그대로 가져가도 됩니다. 다만 문장을 하나 수정하는 것을 권합니다. 현재: NCCL_SOCKET_IFNAME이 올바른 물리 NIC을 가리키는지 이렇게 쓰면 Pod 내부에서 물리 NIC 이름을 지정해야 한다 는 의미로 오해할 수 있습니다. 일반 Pod에서는 Pod namespace 안에 물리 NIC이 직접 보이지 않고 보통 eth0 가 보입니다. 따라서: NCCL이 의도한 Pod interface/IP 경로를 선택하는지 확인하고, hostNetwork/일반 Pod에서 실제 물리 NIC으로 연결되는 경로를 검증한다. 가 더 정확합니다. 예를 들어: Pod eth0 │ ▼ veth │ ▼ Cilium eBPF │ ▼ Linux routing │ ▼ Intel E810 Native routing은 encapsulation을 하지 않고 Linux routing을 이용합니다. :chatgpt-content-reference{index="0"} 그리고 ClusterMesh에서도 cross-cluster Pod-to-Pod traffic은 별도의 proxy/gateway를 반드시 거치는 구조가 아닙니다. Cilium 문서도 노드 간, 클러스터 간 Pod traffic이 직접 forwarding된다고 설명합니다. :chatgpt-content-reference{index="1"} 따라서 A는: Bare Metal ↓ hostNetwork Pod ↓ Cilium Pod 비교가 매우 좋습니다. 3. B — ClusterMesh: 방향은 맞지만 중요한 수정 여기서 가장 중요한 것은: "ClusterMesh라서 TCP 경로에 추가 오버헤드가 붙는다" 라고 일반화하면 안 된다는 것입니다. 현재 구성: Cilium routing-mode=native BGP ECMP ClusterMesh 이라면: Pod A ↓ Cilium ↓ native routing ↓ Node NIC ↓ network ↓ Node NIC ↓ native routing ↓ Cilium ↓ Pod B 형태가 될 수 있습니다. Native routing은 기본적으로 encapsulation을 하지 않습니다. :chatgpt-content-reference{index="2"} 따라서 B에서는 "ClusterMesh overhead"를 하나의 숫자로 측정하지 말고 경로별로 분리 하는 것이 좋습니다. 제가 추천하는 비교 Test Source → Destination 목적 B1 Host → Host 물리 네트워크