쿠버네티스에서 파드의 CPU나 메모리를 바꾸려면 파드를 다시 띄워야 했다. 요청량이 늘어 메모리를 올리고 싶으면 재시작을 감수해야 했고, 그래서 처음부터 넉넉하게 잡아두는 것이 관행이 됐다. 2025년 12월 17일에 나온 쿠버네티스 1.35에서 In-Place Pod Resize가 정식(stable)이 됐다. 파드를 죽이지 않고 자원을 조정할 수 있다는 뜻이다. 이 글은 그 변화가 실제로 무엇을 바꾸는지와, 함께 들어온 기능들을 정리한다.
1.35에 무엇이 들어왔나
이번 릴리스는 60개의 개선을 담았고, 성숙도별로 나뉜다.
릴리스 이름은 "Timbernetes"다. 쿠버네티스는 릴리스마다 이름을 붙이는데, 이번은 세계수(World Tree)를 모티프로 했다.
자원을 바꾸려고 파드를 죽이지 않아도 된다
기존 동작을 짚고 가자. 파드 스펙의 resources는 불변 필드였다. 값을 바꾸면 새 파드가 만들어지고 기존 파드는 종료된다. 디플로이먼트라면 롤링 업데이트가 돌고, 스테이트풀셋이라면 순서대로 교체된다.
이 제약이 만든 관행이 과다 할당이다. 트래픽이 몰릴 때 OOM으로 죽는 것보다는 낫다고 판단해서, 평소에 필요한 것보다 훨씬 큰 값을 요청한다. 클러스터 전체로 보면 노드의 상당 부분이 쓰이지 않은 채 예약만 되어 있는 상태가 된다.
In-Place Resize가 정식이 되면서 이 전제가 바뀐다. 실행 중인 파드의 CPU와 메모리를 재시작 없이 조정할 수 있다.
다만 한계도 알아둬야 한다. 메모리를 줄이는 방향은 운영체제 수준에서 까다롭고, 컨테이너 런타임과 커널 지원에 따라 동작이 갈린다. 늘리는 쪽이 훨씬 안전하다. 또 애플리케이션이 시작할 때 읽은 값(예: JVM 힙 크기)을 나중에 바꿔주지는 않는다. 컨테이너에 자원이 더 생겨도 프로세스가 그걸 쓰도록 설정돼 있어야 의미가 있다.
함께 들어온 나머지 변화들
OCI Image Volume이 정식이 됐다. 레지스트리에서 OCI 이미지를 받아 그 내용을 파드 안에 읽기 전용 볼륨으로 붙인다. 모델 가중치, 설정 묶음, 정적 자산처럼 "컨테이너 이미지에 넣기는 크고 외부 스토리지를 쓰기는 번거로운" 데이터를 다루는 방법이 하나 늘었다. 버전 관리가 이미지 태그로 되므로 배포 추적이 명확하다.
Gang Scheduling이 알파로 들어왔다. 서로 연관된 파드 묶음을 전부 함께 스케줄하거나 아예 하지 않는 방식이다. AI·ML 학습 작업이 대표적인 대상이다. 여덟 개 중 여섯 개만 뜬 채로 나머지를 기다리면 GPU가 놀면서 자원만 잡는다. 전부 아니면 전무로 처리하면 이 낭비가 사라진다.
파드 전체 재시작도 알파로 추가됐다. 개별 컨테이너가 아니라 파드 안 모든 컨테이너를 제자리에서 다시 시작한다.
HPA의 허용 오차(tolerance) 설정이 베타가 되면서 기본 활성화됐다. 지금까지 HPA는 목표치에서 10% 이내면 움직이지 않도록 고정돼 있었는데, 이 값을 워크로드마다 조정할 수 있게 됐다. 진동이 잦은 서비스는 허용 오차를 넓히고, 민감한 서비스는 좁힌다.
올릴 때 확인할 것
쿠버네티스는 마이너 버전이 1년에 세 번 나오고 각 버전의 지원 기간이 길지 않다. 그래서 올리는 것 자체가 상시 과제다. 1.35로 갈 때 볼 것을 정리하면 이렇다.
먼저 매니지드 서비스의 지원 시점이다. EKS나 GKE, AKS를 쓴다면 클라우드가 해당 버전을 제공해야 한다. 1.35는 EKS와 EKS Distro에서 2026년 1월에 지원이 시작됐다.
다음으로 제거된 API를 본다. 쿠버네티스는 버전마다 베타 API를 정리한다. kubectl convert나 정적 분석 도구로 매니페스트를 훑어 폐기 예정 API를 먼저 잡아야 한다. 이걸 놓치면 업그레이드 후 배포가 실패한다.
마지막으로 알파 기능에 기대지 않는 것이다. Gang Scheduling이나 파드 전체 재시작은 매력적이지만 알파다. 기본으로 꺼져 있고, 다음 버전에서 형태가 바뀌거나 없어질 수 있다. 프로덕션 설계를 알파 기능 위에 올리면 나중에 되돌리기 어렵다.
자원 관리 방식이 바뀔 수 있다
In-Place Resize가 정식이 된 것의 진짜 의미는 기능 하나가 늘었다는 게 아니라, 자원을 정적으로 잡아두는 관행을 재검토할 근거가 생겼다는 데 있다.
지금까지 수직 확장(VPA, Vertical Pod Autoscaler)은 널리 쓰이지 않았다. 추천값을 계산해 줘도 적용하려면 파드를 재시작해야 했기 때문이다. 재시작이 필요 없다면 이야기가 달라진다. 실제 사용량을 보고 조금씩 조정하는 운영이 가능해진다.
물론 바로 그렇게 되지는 않는다. 자동 조정은 잘못 동작하면 서비스를 흔든다. 사람이 판단해서 조정하는 단계를 거쳐, 신뢰가 쌓인 뒤에 자동화로 가는 순서가 맞다. 그래도 방향은 분명하다. 넉넉하게 잡아두고 잊는 방식에서, 필요한 만큼 쓰고 조정하는 방식으로 옮겨 갈 여지가 생겼다. 클러스터 비용을 들여다보는 팀이라면 이 변화를 눈여겨볼 만하다.
파드가 재시작되지 않는다는 것의 부작용
In-Place Resize에는 덜 논의되는 측면이 있다. 재시작이 사라지면 재시작이 우연히 해주던 일도 사라진다.
쿠버네티스 환경에서 오래 돌아가는 프로세스는 여러 이유로 상태가 나빠진다. 메모리 누수가 조금씩 쌓이고, 연결 풀이 망가진 커넥션을 물고 있고, 캐시가 오래된 값을 들고 있다. 지금까지는 배포나 자원 변경 때마다 파드가 교체되면서 이런 것들이 자연스럽게 초기화됐다.
수직 조정이 흔해지고 배포 주기가 길어지면 파드의 수명이 길어진다. 그러면 그동안 드러나지 않던 누수가 문제로 올라온다. "재시작하면 괜찮아지는" 버그를 오래 방치해 온 서비스일수록 영향이 크다.
대응은 두 가지다. 하나는 의도적인 순환이다. 일정 주기로 파드를 교체하도록 정책을 두면 된다. 다른 하나는 제대로 고치는 것이다. 메모리 사용량 추이를 모니터링에 올려두고, 우상향하는 그래프가 보이면 원인을 찾는다.
새 기능이 편의를 주면서 기존의 암묵적 안전망을 걷어내는 경우가 종종 있다. 무엇에 기대고 있었는지 아는 것이 중요하다.
참고 자료
- Kubernetes v1.35: Timbernetes (The World Tree Release) — Kubernetes Blog — 릴리스 일자와 전체 개선 항목 요약
- Kubernetes v1.35: New level of efficiency with in-place Pod restart — Kubernetes Blog — 파드 재시작 기능의 설계와 제약
- Kubernetes 1.35 Released with In-Place Pod Resize and AI-Optimized Scheduling — InfoQ — 성숙도별 항목 수와 Gang Scheduling 배경
- Kubernetes Releases — 버전별 지원 기간 확인
'IT' 카테고리의 다른 글
| Node vs Deno vs Bun, 2026년 런타임 선택 기준 (0) | 2026.10.07 |
|---|---|
| PostgreSQL 19 REPACK, 새벽 점검이 줄어든다 (0) | 2026.10.06 |
| React 20이 없는 이유와 React Compiler (0) | 2026.10.04 |
| 자바 버전 지금 뭘 써야 하나, LTS와 Valhalla (0) | 2026.10.03 |
| Node.js 26의 Temporal, Date를 대체할까 (0) | 2026.10.02 |