컨테이너 오케스트레이션·런타임: 스케줄링부터 네트워킹까지

Q: 컨테이너 오케스트레이션·런타임, 무엇부터 봐야 할까?

오케스트레이션 선택은 결국 세 레이어에서 나뉜다: **스케줄러 정책이 배치 시간과 노드 효율을 가르고, 런타임(컨테이너 vs WASM)이 콜드스타트와 격리 수준을 결정하며, 네트워킹 구현(CNI·eBPF)이 지연과 CPU 오버헤드를 갈라놓는다**. 이 세 축이 서로 독립적이지 않다는 점이 복잡함의 원인이다.

Q: 컨테이너와 WASM 런타임, 어떤 상황에서 갈라지는가?

런타임 선택은 콜드스타트와 격리 수준의 트레이드오프 구도다. **컨테이너 런타임**(containerd, CRI-O 등)은 OCI 이미지 스펙을 따른다. 이미지 풀(pull)은 보통 500MB~2GB인데, 이를 노드의 로컬 스토리지에 확장(unpack)하는 과정이 지연의 주요 원인이다. 계층화된 이미지라도 모든 레이어를 다운로드한 후 병합해야 하므로, 네트워크 대역폭 20Mbps 환경에서는 3~10초 이상 소요된다. 단, 이미지가 이미 노드에 캐시되어 있으면 이 단계를 스킵하므로, Pod 재배치(rescheduling) 시나리오에서는 빠르다. 런타임이 시작되면, 컨테이너 엔진은 네임스페이스와 cgroup을 설정하는 데 보통 50~200ms를 쓴다. 그 다음 애플리케이션 진입점(entrypoint)이 실행되는데, 이는 런타임 초기화(예: JVM 워밍업, 해석형 언어의 첫 컴파일)에 따라 수백ms~수초까지 변동한다. **WASM 런타임**(wasmtime, wasmer 등)은 구조가 근본적으로 다르다. WASM 바이너리는 보통 1~50MB이고, 스택 머신을 에뮬레이트하므로 애플리케이션 시작은 거의 즉시(< 10ms)다. 단, 격리가 **샌드박스 수준**에 머문다는 뜻이다. 호스트 커널 기능(예: 임의 syscall, GPU 접근)에 접근하려면 명시적 인터페이스(WASI)를 통해야 한다. 또한 WASM 모듈이 멀티프로세싱을 지원하지 않으므로, CPU 병렬성을 원하면 별도 오케스트레이션이 필요하다. 2026년 기준, **컨테이너는 범용 워크로드·높은 격리 요구·기존 라이브러리 의존성이 있을 때 표준**이고, **WASM은 콜드스타트가 절대적 요구사항인 서버리스 함수·가볍고 빠른 마이크로서비스·다중 테넌트 환경**에서 채택이 증가 중이다. 단 WASM 에코시스템(라이브러리 호환성, 디버깅 도구)은 여전히 컨테이너보다 미성숙하다.

Q: 노드 오토스케일이 스케줄러의 대기를 어떻게 증폭하는가?

Pending 상태의 Pod이 나타나면, 오토스케일러는 노드를 추가하기로 결정한다. 이 결정부터 새 노드가 준비될 때까지의 시간이 **스케일-업 지연**이다. 오토스케일러의 작동 주기는 보통 10~15초 간격이다. 즉, Pod이 Pending되더라도 다음 스캔까지 기다린 후 추가 요청이 발동된다. 클라우드 제공자 API 호출(예: AWS EC2 LaunchTemplate)은 또 다른 5~30초 소요된다. 그 다음 인스턴스 부팅(20~60초), kubelet 시작(10~20초), CNI 플러그인 초기화(5~15초)를 거친다. 전체 합산하면 **최악의 경우 2~3분**이 필요하다. 이 지연을 단축하는 전략은 세 가지다: 1. **오버프로비저닝**: 빈 리소스(예: pause Pod)를 미리 할당해둔다. Pod이 Pending되면 pause Pod이 축출되고 실제 Pod이 즉시 배치된다. 비용과 낭비의 트레이드오프. 2. **빠른 스케일러 폴링**: 체크 간격을 5초 이하로 줄인다. etcd 부하 증가. 3. **Spot 인스턴스 풀 관리**: 온디맨드와 함께 저렴한 Spot 인스턴스를 사용하되, 축출 위험에 대비해 Pod disruption budget을 설정한다.

Q: 콜드스타트를 종합적으로 줄이려면?

콜드스타트 총 지연은 다음의 합이다: ``` 총 지연 = 스케줄러 대기 + 노드 할당 + 이미지 풀 + 런타임 시작 + 애플리케이션 초기화 ``` 각 항목을 최소화하는 방법: - **스케줄러 대기**: 우선순위 클래스(PriorityClass)로 중요 Pod을 앞으로 배치. 필터 플러그인을 명시적으로 설정해 불필요한 계산 제거. - **노드 할당**: 로컬 노드 캐시(Image cache locality) 활용. Pod 선호도(pod affinity)로 특정 노드 그룹에 몰아주면 기존 이미지 재사용 비율 증가. - **이미지 풀**: 멀티스테이지 빌드로 최종 이미지 크기 50% 이상 감소 가능. Lazy pulling(예: Stargz, SOCI) 사용 시 필요한 레이어만 다운로드. - **런타임 시작**: 경량 런타임 선택(containerd vs Docker — Docker는 daemon 오버헤드 추가). WASM 검토(콜드스타트가 최우선이면). - **애플리케이션 초기화**: 프로파일링으로 병목 파악. JVM의 경우 GraalVM Native Image 고려(단, 호환성 제약). 실무에서는 이 여섯 항목을 동시에 최적화하기는 어렵고, 워크로드 특성에 따라 우선순위를 결정해야 한다. 예를 들어, 요청 처리 지연이 중요한 API 서버는 스케줄러 + 이미지 풀을 우선 줄이고, 버스트 트래픽 대응이 중요한 서버리스는 오토스케일링 지연을 최우선으로 본다.

Q: 격리 수준과 리소스 경계, 어떻게 선택하는가?

격리의 강도에 따라 세 수준이 있다: **프로세스 격리**(namespace/cgroup 기반): 가장 약하지만 오버헤드가 최소(< 1% CPU). Linux 커널이 네임스페이스 경계를 강제하지만, 호스트 커널 버전에 따라 샌드박스 수준이 변동한다. PID, mount, UTS, IPC 네임스페이스는 거의 완벽하지만, network namespace만으로는 진정한 격리가 아니다. 특히 시스템 콜 수준의 격리가 없으므로, 커널 취약점을 통한 탈출(container escape) 위험이 있다. **가상 머신 기반 런타임**(kata containers, firecracker 기반): 각 Pod을 경량 VM으로 실행한다. 격리는 완전하지만, VM 오버헤드(메모리 50~100MB, 부팅 1~2초)가 크다. 콜드스타트가 중요한 워크로드에서는 비효율적. **WASM 샌드박스**: 프로세스 격리와 VM의 중간. 시스템 콜 접근이 제한되고, 메모리 접근이 WASM 선형 메모리로 한정되므로, 메모리 누수/버퍼 오버플로우 공격에 강하다. 오버헤드는 프로세스 격리와 비슷하지만, 더 좁은 공격 표면을 가진다. **리소스 경계** 설정은 cgroup v2(unified hierarchy)의 도입으로 간단해졌다. CPU 제한은 cpu.max 파일로 직접 설정할 수 있고, 메모리는 memory.max로 하드 리미트를 걸 수 있다. 단, CPU throttling은 지연 변동(jitter)을 야기한다. 진정한 CPU 보장이 필요하면 cgroup cpusets을 써서 특정 CPU 코어를 독점시켜야 한다.

Q: 가장 흔히 간과하는 부분은?

**네트워크 대역폭이 스케줄러보다 많은 지연을 만든다는 점**이다. 많은 조직이 스케줄링 성능(배치 시간)을 최적화하는 데 집중하지만, 실제로는 이미지 풀 대역폭(1Gbps vs 100Mbps로 5~10배 차이) 또는 CNI의 정책 업데이트 구간(정책 1,000개 추가 시 flannel에서 순간 30~40% CPU 스파이크)이 더 큰 병목이 된다. 또한 **Pod 축출(eviction) 정책이 암묵적으로 스케줄링을 다시 한다**는 점도 간과된다. 노드 메모리가 부족하면 kubelet은 우선순위 기반으로 Pod을 축출하는데, 이는 스케줄러의 배치 결정을 뒤엎는다. 결과적으로 같은 Pod이 여러 노드에서 재시작되고, 각 재시작마다 콜드스타트 지연이 누적된다.

Q: 스케줄러 지연을 측정하려면?

Pod이 생성된 시점부터 노드 할당까지의 시간은 `kubectl describe pod `의 `Conditions` 섹션에서 `PodScheduled` 타임스탬프로 확인할 수 있다. 대규모 클러스터에서는 이 값을 주기적으로 수집해서 P50, P99 분포를 추적하는 것이 권장된다. 스케줄러 로그(`--v=4` 이상)에서도 필터링 및 점수 계산 시간을 추적할 수 있다.

Q: eBPF 네트워킹이 모든 경우에 필요한가?

필요하지 않다. Pod 수 < 500, 네트워크 정책 < 100개인 환경에서는 flannel이나 Calico iptables 모드로도 충분하다. eBPF의 이점은 클러스터 규모가 크거나 정책 변경이 빈번한 경우에 나타난다. 또한 커널 버전(5.8 이상), 호스트 네트워크 구성(BGP 등)에 따라 도입 난이도가 달라진다.

컨테이너 오케스트레이션·런타임, 무엇부터 봐야 할까?

오케스트레이션 선택은 결국 세 레이어에서 나뉜다: 스케줄러 정책이 배치 시간과 노드 효율을 가르고, 런타임(컨테이너 vs WASM)이 콜드스타트와 격리 수준을 결정하며, 네트워킹 구현(CNI·eBPF)이 지연과 CPU 오버헤드를 갈라놓는다. 이 세 축이 서로 독립적이지 않다는 점이 복잡함의 원인이다.

스케줄러는 어떤 정책으로 노드를 선택하는가?

스케줄러의 핵심 작업은 Pod을 노드에 매핑하는 것인데, 이는 단순한 리소스 맞춤(bin packing)이 아니다. 필터링 → 점수 계산 → 바인딩의 세 단계에서 각각 비용이 누적된다.

필터 단계에서는 노드 레이블, 테인트(taint), 친화성(affinity) 규칙을 평가한다. 이 단계에서 후보를 줄이지 못하면 다음 단계의 연산량이 선형으로 증가한다. 대규모 클러스터(노드 수 > 500)에서는 필터링만으로 배치 지연이 100ms를 넘을 수 있다.

점수 계산 단계에서는 기본 플러그인들(LeastAllocated, BalancedAllocation, ImageLocality 등)이 각 후보 노드의 점수를 산출한다. LeastAllocated는 리소스 사용률이 낮은 노드에 우선순위를 주므로 bin packing이 느슨해지지만, 스케일-인할 때 비용 효율이 떨어진다. BalancedAllocation은 CPU와 메모리 사용률을 균형맞게 배분하려 하므로 fragmentation을 줄이되, 핫스팟(hot node)을 만들기 쉽다.

바인딩 단계에서는 etcd 쓰기와 kubelet의 Pod 시작 신호 사이의 시간 간격이 문제다. Admit 플러그인(예: PodPreset, 정책 기반 승인)이 많을수록 이 구간이 길어진다. 또한 비동기 바인딩을 활성화하면 race condition의 가능성이 높아지는 대신 배치 지연이 수십ms 단축된다.

이 분석이 중요한 이유는 배치 지연이 곧 콜드스타트 총 지연의 일부이기 때문이다. 스케줄러가 100ms 걸리면, 런타임이 200ms를 단축해도 효과가 제한된다.

컨테이너와 WASM 런타임, 어떤 상황에서 갈라지는가?

런타임 선택은 콜드스타트와 격리 수준의 트레이드오프 구도다.

컨테이너 런타임(containerd, CRI-O 등)은 OCI 이미지 스펙을 따른다. 이미지 풀(pull)은 보통 500MB2GB인데, 이를 노드의 로컬 스토리지에 확장(unpack)하는 과정이 지연의 주요 원인이다. 계층화된 이미지라도 모든 레이어를 다운로드한 후 병합해야 하므로, 네트워크 대역폭 20Mbps 환경에서는 310초 이상 소요된다. 단, 이미지가 이미 노드에 캐시되어 있으면 이 단계를 스킵하므로, Pod 재배치(rescheduling) 시나리오에서는 빠르다.

런타임이 시작되면, 컨테이너 엔진은 네임스페이스와 cgroup을 설정하는 데 보통 50200ms를 쓴다. 그 다음 애플리케이션 진입점(entrypoint)이 실행되는데, 이는 런타임 초기화(예: JVM 워밍업, 해석형 언어의 첫 컴파일)에 따라 수백ms수초까지 변동한다.

WASM 런타임(wasmtime, wasmer 등)은 구조가 근본적으로 다르다. WASM 바이너리는 보통 1~50MB이고, 스택 머신을 에뮬레이트하므로 애플리케이션 시작은 거의 즉시(< 10ms)다. 단, 격리가 샌드박스 수준에 머문다는 뜻이다. 호스트 커널 기능(예: 임의 syscall, GPU 접근)에 접근하려면 명시적 인터페이스(WASI)를 통해야 한다. 또한 WASM 모듈이 멀티프로세싱을 지원하지 않으므로, CPU 병렬성을 원하면 별도 오케스트레이션이 필요하다.

2026년 기준, 컨테이너는 범용 워크로드·높은 격리 요구·기존 라이브러리 의존성이 있을 때 표준이고, WASM은 콜드스타트가 절대적 요구사항인 서버리스 함수·가볍고 빠른 마이크로서비스·다중 테넌트 환경에서 채택이 증가 중이다. 단 WASM 에코시스템(라이브러리 호환성, 디버깅 도구)은 여전히 컨테이너보다 미성숙하다.

네트워킹 구현이 지연과 CPU를 어떻게 좌우하는가?

CNI(Container Network Interface)는 Pod 간 통신을 구현하는데, 이 구현의 선택이 P99 지연과 CPU 오버헤드를 가른다.

정통 CNI 플러그인(flannel, calico 등)은 각 노드에서 에이전트(daemon)를 실행하고, 정책(policy)을 커널 netfilter 규칙(iptables/nftables)으로 번역한다. 이 접근의 문제는 정책 규칙의 수가 늘어나면 커널 연산량이 지수적으로 증가한다는 점이다. 예를 들어, Pod 수가 5,000개를 넘으면 각 패킷이 수십 개의 iptables 규칙을 순회해야 하므로, P99 지연이 수ms 증가할 수 있다. CPU 오버헤드도 무시할 수 없는데, 규칙 업데이트(Pod 추가/삭제)가 전체 규칙 세트를 다시 커널에 로드해야 하므로 순간적인 CPU 스파이크가 발생한다.

eBPF 기반 네트워킹(Cilium 등)은 이를 근본적으로 다르게 푼다. eBPF 프로그램은 커널 내 JIT 컴파일되므로, 정책 수에 관계없이 O(1) 시간에 패킷을 처리할 수 있다. 또한 정책 변경 시 커널을 재로드할 필요 없이 맵(map)만 업데이트하므로, 배치 업데이트의 지연이 거의 없다. 성능 벤치마크(Cilium 공식 문서, 2024년)에서 1,000개 네트워크 정책이 적용된 클러스터에서:

flannel: Pod-to-Pod 평균 지연 ~2ms, CPU 사용률 ~15% (정책 업데이트 중 순간 40%)
Cilium(eBPF): Pod-to-Pod 평균 지연 ~0.3ms, CPU 사용률 ~3% (정책 업데이트 중도 ~4%)

단, eBPF의 진입장벽은 높다. 커널 버전 요구사항(5.8 이상 권장), BPF 프로그램 복잡도, 디버깅의 어려움이 있다. 또한 일부 하이퍼바이저(예: AWS EC2 극초기 세대)에서 eBPF 기능이 제한되는 경우도 있다.

오버레이 vs 언더레이 선택도 중요하다. Flannel VXLAN(오버레이)은 모든 노드에서 동작하지만, 패킷 캡슐화로 인해 MTU 처리가 복잡하고 CPU 오버헤드가 5~10% 증가한다. 언더레이 방식(예: Calico BGP 모드, AWS VPC CNI)은 호스트 라우팅을 쓰므로 지연이 낮지만, 네트워크 인프라에 깊게 의존한다.

노드 오토스케일이 스케줄러의 대기를 어떻게 증폭하는가?

Pending 상태의 Pod이 나타나면, 오토스케일러는 노드를 추가하기로 결정한다. 이 결정부터 새 노드가 준비될 때까지의 시간이 스케일-업 지연이다.

오토스케일러의 작동 주기는 보통 1015초 간격이다. 즉, Pod이 Pending되더라도 다음 스캔까지 기다린 후 추가 요청이 발동된다. 클라우드 제공자 API 호출(예: AWS EC2 LaunchTemplate)은 또 다른 530초 소요된다. 그 다음 인스턴스 부팅(2060초), kubelet 시작(1020초), CNI 플러그인 초기화(515초)를 거친다. 전체 합산하면 **최악의 경우 23분**이 필요하다.

이 지연을 단축하는 전략은 세 가지다:

오버프로비저닝: 빈 리소스(예: pause Pod)를 미리 할당해둔다. Pod이 Pending되면 pause Pod이 축출되고 실제 Pod이 즉시 배치된다. 비용과 낭비의 트레이드오프.
빠른 스케일러 폴링: 체크 간격을 5초 이하로 줄인다. etcd 부하 증가.
Spot 인스턴스 풀 관리: 온디맨드와 함께 저렴한 Spot 인스턴스를 사용하되, 축출 위험에 대비해 Pod disruption budget을 설정한다.

콜드스타트를 종합적으로 줄이려면?

콜드스타트 총 지연은 다음의 합이다:

총 지연 = 스케줄러 대기 + 노드 할당 + 이미지 풀 + 런타임 시작 + 애플리케이션 초기화

각 항목을 최소화하는 방법:

스케줄러 대기: 우선순위 클래스(PriorityClass)로 중요 Pod을 앞으로 배치. 필터 플러그인을 명시적으로 설정해 불필요한 계산 제거.
노드 할당: 로컬 노드 캐시(Image cache locality) 활용. Pod 선호도(pod affinity)로 특정 노드 그룹에 몰아주면 기존 이미지 재사용 비율 증가.
이미지 풀: 멀티스테이지 빌드로 최종 이미지 크기 50% 이상 감소 가능. Lazy pulling(예: Stargz, SOCI) 사용 시 필요한 레이어만 다운로드.
런타임 시작: 경량 런타임 선택(containerd vs Docker — Docker는 daemon 오버헤드 추가). WASM 검토(콜드스타트가 최우선이면).
애플리케이션 초기화: 프로파일링으로 병목 파악. JVM의 경우 GraalVM Native Image 고려(단, 호환성 제약).

실무에서는 이 여섯 항목을 동시에 최적화하기는 어렵고, 워크로드 특성에 따라 우선순위를 결정해야 한다. 예를 들어, 요청 처리 지연이 중요한 API 서버는 스케줄러 + 이미지 풀을 우선 줄이고, 버스트 트래픽 대응이 중요한 서버리스는 오토스케일링 지연을 최우선으로 본다.

격리 수준과 리소스 경계, 어떻게 선택하는가?

격리의 강도에 따라 세 수준이 있다:

프로세스 격리(namespace/cgroup 기반): 가장 약하지만 오버헤드가 최소(< 1% CPU). Linux 커널이 네임스페이스 경계를 강제하지만, 호스트 커널 버전에 따라 샌드박스 수준이 변동한다. PID, mount, UTS, IPC 네임스페이스는 거의 완벽하지만, network namespace만으로는 진정한 격리가 아니다. 특히 시스템 콜 수준의 격리가 없으므로, 커널 취약점을 통한 탈출(container escape) 위험이 있다.

가상 머신 기반 런타임(kata containers, firecracker 기반): 각 Pod을 경량 VM으로 실행한다. 격리는 완전하지만, VM 오버헤드(메모리 50100MB, 부팅 12초)가 크다. 콜드스타트가 중요한 워크로드에서는 비효율적.

WASM 샌드박스: 프로세스 격리와 VM의 중간. 시스템 콜 접근이 제한되고, 메모리 접근이 WASM 선형 메모리로 한정되므로, 메모리 누수/버퍼 오버플로우 공격에 강하다. 오버헤드는 프로세스 격리와 비슷하지만, 더 좁은 공격 표면을 가진다.

리소스 경계 설정은 cgroup v2(unified hierarchy)의 도입으로 간단해졌다. CPU 제한은 cpu.max 파일로 직접 설정할 수 있고, 메모리는 memory.max로 하드 리미트를 걸 수 있다. 단, CPU throttling은 지연 변동(jitter)을 야기한다. 진정한 CPU 보장이 필요하면 cgroup cpusets을 써서 특정 CPU 코어를 독점시켜야 한다.

가장 흔히 간과하는 부분은?

네트워크 대역폭이 스케줄러보다 많은 지연을 만든다는 점이다. 많은 조직이 스케줄링 성능(배치 시간)을 최적화하는 데 집중하지만, 실제로는 이미지 풀 대역폭(1Gbps vs 100Mbps로 510배 차이) 또는 CNI의 정책 업데이트 구간(정책 1,000개 추가 시 flannel에서 순간 3040% CPU 스파이크)이 더 큰 병목이 된다.

또한 Pod 축출(eviction) 정책이 암묵적으로 스케줄링을 다시 한다는 점도 간과된다. 노드 메모리가 부족하면 kubelet은 우선순위 기반으로 Pod을 축출하는데, 이는 스케줄러의 배치 결정을 뒤엎는다. 결과적으로 같은 Pod이 여러 노드에서 재시작되고, 각 재시작마다 콜드스타트 지연이 누적된다.

핵심 정리

오케스트레이션은 스케줄러·런타임·네트워킹 세 레이어로 나뉘며, 각 선택이 지연과 격리를 독립적으로 좌우한다.
스케줄러 지연은 필터링 단계에서 대부분 발생하므로, 노드 수 > 500일 때는 필터 규칙을 명시적으로 제한하는 것이 중요하다.
컨테이너는 높은 격리와 호환성을 제공하지만 이미지 풀(3~10초)이 콜드스타트의 주요 원인이고, WASM은 즉시 시작(< 10ms)되지만 샌드박스 수준 격리만 제공한다.
eBPF 기반 네트워킹(Cilium)은 정책 규모가 클수록 이점이 크지만, 커널 버전 요구사항과 디버깅 복잡도가 높다.
노드 오토스케일링 지연(2~3분)은 스케줄러 최적화보다 더 큰 문제일 수 있으므로, 우선순위와 오버프로비저닝을 함께 고려해야 한다.
콜드스타트 최소화는 이미지 크기(Lazy pulling), Pod 친화도(노드 캐시 재사용), 경량 런타임 선택을 함께 진행해야 효과적이다.
네트워크 대역폭과 CNI 정책 업데이트 오버헤드는 스케줄링 성능보다 자주 간과되지만, 대규모 클러스터에서 더 큰 영향을 미친다.

자주 묻는 질문

스케줄러 지연을 측정하려면?

Pod이 생성된 시점부터 노드 할당까지의 시간은 kubectl describe pod <pod-name>의 Conditions 섹션에서 PodScheduled 타임스탬프로 확인할 수 있다. 대규모 클러스터에서는 이 값을 주기적으로 수집해서 P50, P99 분포를 추적하는 것이 권장된다. 스케줄러 로그(--v=4 이상)에서도 필터링 및 점수 계산 시간을 추적할 수 있다.

컨테이너 이미지 풀 시간을 얼마나 줄일 수 있는가?

멀티스테이지 빌드로 final layer 크기를 50% 감소, 베이스 이미지를 distroless로 바꿔 추가 3040% 감소 가능하다. 그 외 lazy pulling(Stargz, SOCI 형식)은 필요한 레이어만 다운로드하므로 초기 시작을 515초 단축할 수 있지만, 런타임 풀(runtime pull) 오버헤드가 추가된다. 이미지가 노드에 캐시되어 있으면 풀 단계를 완전히 스킵하므로, Pod 재배치 워크로드에서는 캐시 히트율 추적이 중요하다.

eBPF 네트워킹이 모든 경우에 필요한가?

필요하지 않다. Pod 수 < 500, 네트워크 정책 < 100개인 환경에서는 flannel이나 Calico iptables 모드로도 충분하다. eBPF의 이점은 클러스터 규모가 크거나 정책 변경이 빈번한 경우에 나타난다. 또한 커널 버전(5.8 이상), 호스트 네트워크 구성(BGP 등)에 따라 도입 난이도가 달라진다.

WASM 런타임을 지금 도입해야 하는가?

프로덕션 도입은 워크로드 특성에 따라 결정해야 한다. 콜드스타트가 절대적 요구사항인 서버리스 함수 환경, 또는 멀티테넌트 환경에서는 시도할 가치가 있다. 단, WASM 에코시스템(라이브러리 호환성, 디버깅 도구)이 아직 성숙도가 낮으므로, 기존 Go/Rust 스택에서 간단하게 포팅 가능한 워크로드부터 시작하는 것이 현실적이다.

노드 오토스케일링 지연을 2분 이하로 줄릴 수 있는가?

이론적으로 불가능하다. kubelet 부팅 + CNI 초기화만 3040초, 클라우드 API 응답 시간 1030초를 제외할 수 없다. 대신 오버프로비저닝(pause Pod 사전 할당)이나 호스트 풀(warm pool) 관리로 체감 지연을 수초 단위로 줄일 수 있다. 또는 Knative, AWS Lambda 같은 서버리스 플랫폼에 워크로드를 옮겨서 오토스케일링을 완전히 다르게 구현할 수 있다.

리소스 요청/제한(requests/limits)을 어떻게 설정해야 하는가?

requests는 스케줄러가 노드 할당을 결정하는 기준이므로, 실제 사용량의 P95 정도로 설정한다. 너무 크게 설정하면 노드 fragmentation이 증가해 스케일링 비효율이 생긴다. limits는 CPU의 경우 requests보다 약간 높게(예: 1.5배) 설정해서 버스트를 허용하되, 메모리는 requests와 같게 설정하는 것이 권장된다(메모리 한계 초과는 Pod 축출로 이어지므로).

스케줄러 성능과 정책을 모니터링하려면?

kube-scheduler 메트릭(prometheus 수집):

scheduler_schedule_attempts_total (성공/실패)
scheduler_e2e_scheduling_duration_seconds (스케줄링 총 시간)
scheduler_plugin_execution_duration_seconds (플러그인별 수행 시간)

대규모 클러스터에서는 이들을 수집해서 P99를 추적하고, 임계값(예: 100ms)을 초과하면 필터 규칙 최적화나 다중 스케줄러 배포를 검토한다.