사이드카는 공짜가 아니다

한 줄 요약

사이드카를 하나 붙이면 파드의 요청량이 더해지고, 기동 시간이 늘고, 실패 지점이 하나 생긴다. 그 대가를 넘는 이득이 있을 때만 붙인다.

왜 이게 필요했나

"기능을 하나 더 붙이자" 는 이유로 사이드카를 늘리면 어느 순간 파드가 컨테이너 다섯 개짜리가 된다. 그때 벌어지는 일은 이렇다.

자원이 더해진다. 파드의 요청량은 컨테이너들의 합이다. 사이드카에 requests.cpu: 100m 를 주면 파드 200개에 20코어가 예약된다. 스케줄러는 그 합을 보고 자리를 찾으므로 노드 밀도가 떨어진다. 실제로 쓰지 않아도 예약은 잡힌다.

기동이 느려진다. 정식 사이드카(restartPolicy: Always 인 init 컨테이너)는 본체보다 먼저 뜬다. 프록시가 뜨는 데 3초가 걸리면 모든 파드의 기동이 3초 늘어난다. 롤링 업데이트에서 그게 파드 수만큼 곱해진다.

실패 지점이 는다. 사이드카가 OOM 으로 죽으면 그 컨테이너가 재시작되는 동안 파드는 준비 상태를 잃고, 반복되면 CrashLoopBackOff 로 파드 전체를 못 쓰게 된다. 로그 수집기가 버퍼를 메모리에 쌓는 설정이면 트래픽이 몰릴 때 정확히 그 일이 난다.

어떻게 동작하나

자원을 정할 때의 기준은 단순하다.

| 컨테이너 | requests | limits |
|---|---|---|
| 본체 | 실제 사용량의 p50 | p99 + 여유 |
| 사이드카 | 아주 작게(10~50m) | 넉넉하게 |

사이드카의 limits 를 조이면 본체까지 같이 죽는다. requests 는 작게, limits 는 넉넉하게가 정답이다. 이건 본체와 반대 방향이라 헷갈리기 쉽다.

종료 순서도 중요하다. 본체가 아직 요청을 처리하는 중에 프록시가 먼저 죽으면 그 요청들이 실패한다. 정식 사이드카는 본체가 끝난 뒤 종료되므로 이 문제가 해결됐지만, 그 전에는 preStop 훅으로 몇 초 버티게 하는 우회가 흔했다.

흔한 착각

"사이드카가 죽어도 본체는 산다" — 파드는 하나의 재시작 단위다. restartPolicy 는 파드 수준이고, 컨테이너 하나가 계속 죽으면 파드 전체가 CrashLoopBackOff 로 간다.

"자원을 안 주면 안 쓴다" — requests 를 안 주면 QoS 가 BestEffort 가 되어 메모리 압박 시 가장 먼저 죽는다. 사이드카가 먼저 죽으면 본체도 함께 간다.

실무에서 진짜 중요한 것

사이드카를 넣기 전에 물어야 할 것은 하나다 — DaemonSet 으로 안 되나?

노드마다 하나면 되는 일(로그 수집, 노드 지표)에 파드마다 컨테이너를 붙이면 프로세스 수가 파드 수만큼 늘어난다. 사이드카가 정당한 경우는 세 가지뿐이다.

1. 파드의 네트워크 네임스페이스가 필요하다(프록시, mTLS)
2. 파드의 볼륨이 필요하다(특정 경로의 파일)
3. 테넌트별로 격리해야 한다(설정이 파드마다 다르다)

셋 중 어디에도 안 걸리면 DaemonSet 이 싸다.