[분석] Kubernetes v1.35 Timbernetes: 6년 만의 GA, AI 스케줄링, 기술 부채 개선

 

 

[ kt cloud Platform엔지니어링팀 이지은 님 ]

📋 요약

이 글에서는 Kubernetes v1.35 Timbernetes의 주요 변화와 AI 워크로드, 리소스 관리, 보안·운영 측면의 개선을 다룹니다.

클러스터 운영 안정성과 비용 효율을 높이기 위한 업그레이드 방향을 정리합니다.

#Kubernetes #Timbernetes #GangScheduling #OCIImageVolume #클라우드네이티브

 

---

Timbernetes: The World Tree Release

2025년 12월 17일, Kubernetes 커뮤니티가 한 해의 마지막 메이저 릴리즈인 v1.35를 공개했습니다. 코드명은 Timbernetes: The World Tree Release — 북유럽 신화 속 우주를 연결하는 세계수 Yggdrasil(이그드라실)에서 영감을 받은 이름입니다. 이전 릴리즈들을 살펴보면 2025년의 여정이 보입니다. v1.33은 "Octarine: The Color of Magic" (마법의 색), v1.34는 "Of Wind & Will" (바람과 의지)로 한 해를 열었고, 이제 세계수를 손에 쥐며 한 해를 마무리합니다. 마치 나무가 해마다 나이테를 더하듯, Kubernetes도 릴리즈를 거듭하며 글로벌 커뮤니티의 손길로 성장해 왔다는 의미입니다.

 

이번 v1.35는 14주(2025.09.15 ~ 12.17)간의 개발 사이클을 거쳐 탄생했습니다. 85개 기업, 419명의 개발자가 핵심 코어에 기여했으며, 클라우드 네이티브 생태계 전체로 넓히면 281개 기업, 총 1,769명의 컨트리뷰터가 이 릴리즈에 참여했습니다.

🎨  릴리즈 로고 이야기  v1.35 로고는 릴리즈 리드인 Drew Hagen이 직접 디자인했습니다. 거대한 나무의 형상이 쿠버네티스의 7각형 로고와 결합되어 있는데, 이는 안정적인 성숙기(Stability)에 접어든 쿠버네티스가 얼마나 견고하게 생태계를 지탱하고 있는지를 보여줍니다. 그는 나무를 중심 이미지로 선택한 이유에 대해 "Kubernetes 커뮤니티의 회복력을 보여주고 싶었다"고 밝혔습니다. 로고 속 세 마리의 다람쥐가 눈길을 끄는데, 각각 어두운 이슈 대기열을 파헤치는 Triager(로그), 코드를 승인하는 Reviewer(마법사), 새 버전 브랜치를 자르는 Release Crew(전사)를 상징합니다. 오픈소스 프로젝트를 묵묵히 지탱하는 기여자들에 대한 유머러스하면서도 따뜻한 헌사입니다.

---

1. 이번 릴리스의 주인공: In-Place Pod Resource Resize (GA)

v1.35에서 가장 혁신적인 변화를 꼽으라면 단연 'In-Place Pod Vertical Scaling'의 정식 버전(GA) 전환입니다. 2019년 KEP-1287로 처음 제안된 이 기능이 무려 6년여의 개발 끝에 완전히 안정화되었습니다. 그동안 우리는 Pod의 CPU나 메모리 사양을 변경하기 위해 Pod를 삭제하고 다시 생성하는 '재시작(Restart)' 과정을 거쳐야만 했습니다. 자바 VM처럼 구동 시간이 긴 애플리케이션의 경우 서비스 가용성에 큰 타격을 주었습니다. 하지만 이제는 서비스 중단 없이 Update 호출 한 번으로 컨테이너의 cgroup 설정을 즉시 변경할 수 있습니다. 즉, 실행 중인 Pod의 리소스를 실시간으로 조정할 수 있습니다. 데이터베이스, AI 학습 워크로드, 스테이트풀 서비스 운영자들에게는 그야말로 게임 체인저입니다.

 

Pod 스펙 내의 resizePolicy를 통해 자원 변경 시 컨테이너를 재시작할지 말지를 결정할 수 있습니다. 이 동작은 kubectl patch 등을 통해 resources 값을 수정해도 Pod Status가 Running 상태를 유지하며 즉각적으로 할당량이 변합니다. 이는 트래픽이 몰리는 피크 타임에 수동 혹은 자동(VPA)으로 자원을 증설할 때 놀라운 유연성을 제공합니다.

• restartPolicy: NotRequired 재시작 없이 변경 가능
• restartPolicy: RestartContainer 재시작 필요

apiVersion: v1
kind: Pod
metadata:
  name: dynamic-app
spec:
  containers:
  - name: heavy-worker
    image: my-app:latest
    resources:
      limits:
        cpu: "1"
        memory: "1Gi"
      requests:
        cpu: "0.5"
        memory: "512Mi"
    # 리소스 변경 시 재시작하지 않도록 설정
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired

또는 patch로 CPU/메모리 In-Place 변경
kubectl patch pod my-app --type='json' \
  -p='[{
    "op": "replace",
    "path": "/spec/containers/0/resources/requests/cpu",
    "value": "500m"
  },{
    "op": "replace",
    "path": "/spec/containers/0/resources/limits/cpu",
    "value": "1000m"
  }]'

---

2. AI/ML 시대를 위한 'Gang Scheduling' Alpha (AI/ML 워크로드를 위한 새 스케줄링)

최근 쿠버네티스의 가장 큰 화두는 'AI 워크로드 수용'입니다. v1.35에서는 AI/ML 분산 학습 및 HPC 워크로드의 니즈를 반영하기 위한 네이티브 Gang Scheduling 기능이 Alpha 단계로 도입되었습니다.

 

보통 AI 모델 학습을 위해서는 여러 개의 GPU Pod가 동시에 가동되어야 합니다. 이전에는 자원이 부족하면 10개 중 8개만 뜨고 나머지 2개가 대기하면서, 이미 실행된 8개가 GPU 자원을 점유한 채 아무 일도 못 하는 '자원 교착 상태(Deadlock)'가 발생하곤 했습니다. 이 기능은 서로 연관된 Pod 그룹(Gang)을 동시에 스케줄링하거나 아예 하지 않는 방식으로, 일부 Pod만 실행되어 리소스를 낭비하는 문제를 원천 차단합니다.

• 기능 핵심: 이제 PodGroup 개념을 통해 "이 그룹 내의 Pod 10개가 모두 스케줄링 가능할 때만 실행하라"는 All-or-Nothing 로직을 쿠버네티스 코어 레벨에서 지원하기 시작했습니다.
• 효과: 고가의 GPU 자원 낭비를 방지하고, 대규모 클러스터에서의 스케줄링 효율을 극대화합니다.

---

3. 네트워크 최적화: PreferSameNode (GA)

클라우드 비용 절감과 성능 최적화 측면에서 Service의 trafficDistribution 필드에 PreferSameNode가 정식 추가되었습니다. 동일한 노드 안에 요청을 처리할 수 있는 Pod가 있다면, 굳이 네트워크를 타고 다른 노드로 가지 않도록 강제하는 설정입니다. 이 설정은 마이크로서비스 간 통신이 잦은 환경에서 네트워크 지연 시간(Latency)을 획기적으로 줄여주며, 특히 클라우드 환경에서 노드 간 트래픽 비용(Egress Cost)을 아끼는 데 결정적인 역할을 합니다.

apiVersion: v1
kind: Service
spec:
  selector:
    app: my-api
  trafficDistribution: PreferSameNode
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

---

4. 데이터 관리의 혁신: OCI Image Volume (GA)

v1.33에서 Beta로 선보였던 OCI Image Volume이 드디어 이번 v1.35에서 GA(Stable) 단계에 진입했습니다. 이 기능은 “이미지를 볼륨처럼 마운트 하는” 기능으로 특히 대규모 데이터나 AI 모델을 다루는 엔지니어들에게 큰 환영을 받고 있습니다.

 

기존에는 애플리케이션에 필요한 대용량 데이터(모델 가중치, 정적 자산 등)를 전달하기 위해 컨테이너 이미지에 포함시키거나, Init Container를 사용해 외부에서 내려받아야 했습니다. 하지만 이제는 OCI 레지스트리에 있는 이미지를 Pod 내부에 읽기 전용 볼륨으로 직접 마운트할 수 있게 되어 컨테이너 로직과 데이터를 분리해 관리할 수 있게 되었습니다. 또한 데이터를 내려받기 위해 별도의 Init Container를 구성하거나 복잡한 부트스트랩 스크립트를 작성할 필요가 없습니다.

spec:
  containers:
  - name: ai-inference-app
    image: my-app:v1.0
    volumeMounts:
    - name: model-weights
      mountPath: /models
  volumes:
  - name: model-weights
    image:
      reference: my-registry/llm-model:v2.0 # OCI 이미지를 볼륨으로 사용

 

이 기능은 앞서 언급한 Gang Scheduling과 결합될 때 시너지가 극대화됩니다. 대규모 GPU 클러스터에서 수십 개의 Pod가 동시에 기동될 때, 각각의 Pod가 무거운 데이터를 개별적으로 다운로드할 필요 없이 OCI 이미지를 즉시 마운트하여 실행할 수 있기 때문입니다.

---

5. 보안 강화: Structured Authentication Config (GA)

클러스터 운영자들에게 가장 고통스러운 작업 중 하나는 kube-apiserver의 인증 설정 변경이었습니다. 기존 쿠버네티스 인증 설정은 명령줄 인자(Flags)를 일일이 수정하고 변경 시마다 API 서버를 재시작해야 했습니다. v1.35에서는 Structured Authentication Config가 GA로 전환되며 보안 관리 방식이 획기적으로 개선되었습니다.

 

이제 여러 개의 OIDC(OpenID Connect) 인증 제공자를 동시에 설정할 수 있으며, 설정 파일만 수정하면 API 서버 재시작 없이도 실시간으로 반영됩니다. 특히 CEL(Common Expression Language)을 활용해 사용자 클레임을 검증하거나 그룹 이름을 동적으로 매핑할 수 있어, 인증 단계에서부터 정교한 필터링이 가능해졌습니다. 이러한 유연성은 RBAC(권한 제어) 정책과 긴밀하게 결합되어 더욱 안전한 권한 할당 체계를 구축하게 해줍니다. 또한 서비스 어카운트 토큰의 유효 기간 제한과 인증서 로테이션 고도화를 통해, 보안 사고 발생 시 즉각 대응할 수 있는 '제로 트러스트' 환경을 실현했습니다.

---

6. 주요 사용 중단(Deprecations) 및 주의사항

이번 버전에서는 향후 큰 변화를 예고하는 경고들이 포함되었습니다.

1. cgroup v1 지원 폐기 예정: 쿠버네티스는 이제 공식적으로 cgroup v2를 권장하며, v1은 곧 지원이 중단됩니다. 최신 커널과 OS(Ubuntu 22.04+, RHEL 9+ 등)를 사용 중인지 반드시 확인해야 합니다.
2. containerd 1.x 지원 종료 준비: v1.35는 containerd 1.x를 지원하는 거의 마지막 버전입니다. 다음 업그레이드 전까지 containerd 2.0 이상으로의 마이그레이션 계획을 세워야 합니다.
3. 오래된 API 버전 제거: flowcontrol.apiserver.k8s.io/v1beta2 등이 제거되었으므로, 관련 리소스를 사용하는 매니페스트를 점검해야 합니다.

---

마무리하며: Timbernetes가 우리에게 주는 의미

Kubernetes v1.35 Timbernetes는 이름 그대로 거대한 나무처럼 우리에게 안정적인 쉼터와 강력한 도구를 동시에 제공합니다. 단순히 기능이 많아진 것을 넘어, 6년 만의 In-Place Pod Resize GA, cgroup v1 제거, IPVS Deprecated처럼 기술 부채를 정리하고 기반을 강화하는 성숙한 프로젝트의 자기 혁신을 보여줍니다. 릴리즈 리드 Drew Hagen이 말했듯 "프로젝트는 계속 가지를 뻗으며, AI와 엣지 컴퓨팅의 미래를 위한 성숙한 토대로 뿌리를 내리고 있다"는 표현이 이번 릴리즈를 완벽하게 요약합니다.

 

이 모든 것이 가능한 배경에는 글로벌 기여자들의 헌신이 있습니다. 직장을 다니고 가정을 돌보면서도 세계에서 가장 큰 오픈소스 프로젝트를 위해 시간을 내는 1,769명의 컨트리뷰터들 — 그들이야말로 이 세계수를 지탱하는 뿌리입니다.

 

2026년의 Kubernetes가 어떤 나이테를 새길지, 벌써 기대가 됩니다.

 

---

❓ 자주 묻는 질문 (FAQ)

Q. In-Place Pod Resize 기능을 사용하면 기존에 설정한 HPA(Horizontal Pod Autoscaler)와 충돌하지 않나요?

A. 아니요, 충돌하지 않습니다. In-Place Resize는 개별 Pod의 '사양'을 키우는 수직적 확장(VPA 방식)이며, HPA는 Pod의 '개수'를 늘리는 수평적 확장입니다. v1.35부터는 부하 발생 시 Pod를 새로 띄우기 전, 기존 실행 중인 Pod의 여유 자원을 먼저 확장하는 방식으로 상호 보완하여 운영 효율을 높일 수 있습니다.

Q. In-Place Pod Resize를 실제로 쓰려면 무엇이 필요한가요?

A. 별도의 Feature Gate 설정 없이 v1.35 클러스터에서 바로 사용할 수 있습니다. kubectl patch 또는 kubectl edit으로 실행 중인 Pod의 resources 필드를 수정하면 됩니다. 다만 메모리는 기본적으로 컨테이너 재시작이 필요하고, CPU는 재시작 없이 변경됩니다. resizePolicy 필드로 리소스별 재시작 정책을 명시적으로 제어할 수 있습니다.

Q. Gang Scheduling은 일반적인 웹 서비스 운영에도 도움이 되나요?

A. 일반적인 웹 서비스보다는 분산 처리 워크로드에 특화되어 있습니다. 예를 들어, 5개의 Pod가 유기적으로 연결되어 동작해야 하는 배치 작업이나 AI 모델 학습 시, 자원 부족으로 일부만 실행되어 전체 작업이 멈추는 '자원 데드락' 현상을 방지하는 데 결정적인 역할을 합니다.

Q. IPVS 모드를 쓰고 있는데 지금 당장 nftables로 바꿔야 하나요?

A. v1.35에서 Deprecated 선언이 됐을 뿐, 아직 동작은 합니다. 단, 향후 1~2개 릴리즈 사이클 내에 제거될 가능성이 높으므로 지금부터 마이그레이션 계획을 세우는 것이 안전합니다. kubectl get configmap kube-proxy -n kube-system으로 현재 모드를 확인하고, 테스트 환경에서 nftables 모드를 먼저 검증해 보길 권장합니다.

Q. containerd 1.x 지원 종료 예고에 대해 어떻게 대응해야 하나요?

A. v1.35는 containerd 1.x를 안정적으로 지원하는 마지막 릴리스 중 하나입니다. 향후 v1.36 이상의 버전으로 업그레이드하기 전에, 사용 중인 노드의 런타임을 containerd v2.0 이상으로 업데이트해야 합니다. 특히 cgroup v2 기반에서 동작하므로 OS 커널 버전(Ubuntu 22.04+ 등)도 함께 점검하는 것이 좋습니다.

---

📚 관련/출처

https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/