1.36 Pod-level in-place resize, 사이드카 많은 Pod일수록 의미가 크다

1.36 Pod-level in-place resize, 사이드카 많은 Pod일수록 의미가 크다

지난달 Kubernetes 1.36이 나오면서 In-Place Pod Resize에 한 가지 작은 게이트가 추가됐다. InPlacePodLevelResourcesVerticalScaling. 1.35에서 컨테이너 단위 in-place resize가 GA 된 직후라 잘 안 보이지만, 사이드카가 덕지덕지 붙은 Pod를 운영하는 입장에선 이게 더 반갑다. 오늘은 그 얘기를 짧게.

뭐가 달라졌나

기존 in-place resize는 컨테이너 하나하나의 resources.requests/limits를 따로 바꿔야 했다. Pod에 컨테이너가 3개면 patch도 3번. 그것도 모자라서, 사이드카가 자기 limit에 먼저 걸려 throttle되면 옆의 메인 컨테이너가 여유가 있어도 Pod 전체 응답이 느려지는 패턴이 그대로 남아 있었다.

1.36 베타 게이트가 켜지면 Pod 전체의 .spec.resources를 한 번에 갱신할 수 있다. 컨테이너 단위 요청도 그대로 두고, Pod 차원의 총량을 늘리면 컨테이너들이 그 안에서 알아서 나눠 쓴다.

kubectl patch pod my-pod --subresource resize --patch '
spec:
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"
'

--subresource resize가 핵심이다. 일반 patch로 spec.resources를 건드리면 immutable 에러가 난다.

우리 팀에서 가장 와닿은 케이스

Istio sidecar가 붙은 결제 API. 트래픽 스파이크가 와도 메인 컨테이너 CPU는 50%대인데, envoy 사이드카만 throttle 걸려서 P99 레이턴시가 튀는 일이 분기마다 한 번씩 있었다. 그렇다고 envoy limit을 항상 넉넉히 잡자니 비용 측면에선 낭비.

Pod-level resource를 쓰면 Pod 총량으로 budget을 잡고, envoy가 잠깐 더 먹어도 메인 컨테이너 여유 분에서 가져다 쓰는 그림이 된다. 트래픽 패턴이 시간대별로 갈리는 워크로드일수록 효과가 크다.

쓸 때 주의할 점

• 1.34에서 Pod-level resources가 Beta로 들어왔지만 그건 Pod 만들 때만 적용됐다. 1.36 게이트는 그걸 런타임에 바꿀 수 있게 한 거다. 두 게이트가 다른 거라 둘 다 켜야 의미가 있다.
• 모든 워크로드에 좋은 건 아니다. 컨테이너 간 격리가 중요한 멀티 테넌트 Pod엔 오히려 독이 된다. 한 컨테이너가 Pod 전체 CPU를 먹어버리는 시나리오가 가능해진다.
• VPA가 이 필드를 어떻게 다루는지는 아직 좀 애매하다. 우리 팀에서도 VPA는 컨테이너 단위로 두고, Pod-level은 운영자가 수동으로만 손대는 쪽으로 일단 정리해뒀다.

근데 솔직히 가장 큰 효과는 "사이드카 limit 튜닝 안건"이 회의에서 사라지는 거다. 한 분기에 두세 번씩 누가 envoy 메모리 늘려야 한다고 PR 올리던 패턴이 줄었다. 그것만 해도 충분하다.