Kubernetes v1.35: 세계수 (The World Tree) 업데이트 핵심

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

Kubernetes v1.35 세계수

2025년 12월 17일 배포된 Kubernetes v1.35 "Timbernetes"는 단순한 기능 추가를 넘어, 실제 운영 환경에서의 비효율을 제거하는 데 큰 방점을 두었다.

 

공식 릴리스 노트 중에서 "주요 업데이트 조명(Spotlight on Key Updates)"과 "안정화된 기능(Features Graduating to Stable)" 섹션을 주된 내용으로 포스팅한다.

이번 릴리스의 하이라이트는 "중단 없는 운영"과 "네트워크 최적화", 그리고 "배치 작업의 유연성" 세 가지로 중점이다.

운영자는 반드시 스테이징 환경에서 테스트 후 프로덕션에 적용해야 하며, 특히 알파/베타 기능 도입 시에는 세심한 주의가 필요함.

( 공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다. 이는 정확한 정보가 아닐 수 있음을 알려드립니다. )

---

공식 사이트

광고 클릭은 큰 힘이 됩니다!

Kubernetes v1.35: Timbernetes (The World Tree Release)

728x90

---

주요 업데이트 - Spotlight on key updates

1. 파드 리소스의 인플레이스 (KEP #1287) - State: GA

VPA(Vertical Pod Autoscaler)의 실용화: 파드 재시작 리스크 때문에 VPA 도입을 꺼렸던 운영자들도 이제 트래픽에 따라 실시간으로 리소스를 늘리고 줄이는 오토스케일링을 안전하게 적용할 수 있다.

기존 문제

과거에는 파드의 CPU나 메모리 할당량을 변경하려면, 파드를 삭제하고 더 큰 스펙으로 재생성(Recreate)해야 했다.

이는 데이터베이스나 AI 모델 로딩처럼 초기화 비용이 큰 애플리케이션에 치명적인 서비스 중단을 야기했다.

v1.35 개선

이제 파드를 재시작(Restart)하지 않고도 resources.requests와 resources.limits 필드를 수정할 수 있다.

API 서버에 변경 요청을 보내면, Kubelet이 컨테이너 런타임(CRI)을 통해 리눅스 cgroup 설정을 즉시 변경한다.

 

YAML 변경점: 파드 스펙 내 containers[].resources 필드가 이제 변경 가능(Mutable)해졌다.

resizePolicy:
- resourceName: cpu
  restartPolicy: NotRequired  # 핵심: 재시작 불필요
- resourceName: memory
  restartPolicy: NotRequired

작동 메커니즘:

1. 사용자가 kubectl patch로 리소스를 변경한다.
2. API 서버: 변경 요청을 접수하고, resizePolicy를 확인한다.
3. 스케줄러: 노드에 남은 가용 자원(Allocatable)이 충분한지 계산한다. (부족하면 거절됨)
4. Kubelet: CRI(Container Runtime Interface)를 통해 리눅스 커널의 cgroup limit 값을 실시간으로 수정한다. 

메모리를 줄일 때(Shrink), 현재 사용량보다 낮게 설정하면 OOMKilled가 발생할 수 있다.

Java 힙 메모리처럼 애플리케이션 레벨에서 리소스를 고정하는 경우, 앱 내부 설정도 동적으로 바뀌는지 확인해야 한다.

재시작 없이 파드의 리소스 제어가 가능해지니 다운타임이 줄고 VPA 활성화가 더 가속 될 듯 하다.

---

2. 워크로드 ID 및 보안을 위한 Pod 인증서 (KEP #4317) - State: Beta

이제 kubeletPodCertificateRequest를 통해 키를 생성하고 인증서를 요청하며 자격 증명 번들을 Pod의 파일 시스템에 직접 기록한다. 또한 kube-apiserver, 접근 시 노드 제한을 적용하여 제3자 서명자가 흔히 저지르는 실수, 즉 노드 격리 경계를 실수로 위반하는 문제를 방지한다. 

기존 문제

이전에는 파드에 인증서를 배포하려면 외부 컨트롤러(cert-manager, SPIFFE/SPIRE), CRD 오케스트레이션 및 시크릿 관리가 필요했으며, 인증서 순환은 사이드카 또는 초기화 컨테이너에서 처리했다.

v1.35 개선

Kubernetes v1.35는 자동화된 인증서 순환을 통해 네이티브 워크로드 ID를 지원하여 서비스 메시 및 제로 트러스트 아키텍처를 획기적으로 간소한다. 

cert-manager, SPIFFE/SPIRE의 기능을 쿠버네티스 내장으로 끌고 들어왔는데, 보안 관련 기능이라 GA까지 기다렸다 사용 사례를 한번 살펴봐야겠다.

---

3. 노드 기능 선언 (KEP #5328) - State: Alpha

노드가 자신의 기능을 명시적으로 선언하여 스케줄링 불일치를 방지한다.

기존 문제

컨트롤 플레인은 최신 버전이지만 노드(Worker)가 구버전인 경우, 스케줄러가 해당 기능을 지원하지 않는 노드에 파드를 배치하는 문제가 발생할 수 있었다.

v1.35 개선

노드가 지원하는 기능을 .status.declaredFeatures 필드를 통해 API 서버에 직접 게시한다. 스케줄러는 이 정보를 바탕으로 파드가 호환되는 노드에서만 실행되도록 보장한다.

하드웨어 파편화가 심한 클러스터나 업그레이드 과도기에 매우 유용한 안전장치가 될 것이다.

---

안정화된 기능 - Features Graduating to Stable

1. 트래픽 분산: PreferSameNode (KEP #3015)

서비스 트래픽을 효율적으로 라우팅하여 레이턴시와 비용을 줄인다.

기존 문제

기존 정책은 노드 내부 트래픽만 허용하거나(Local), 구역(Zone) 단위 제어만 가능해 유연성이 부족했다. 특히 파드가 없는 노드에서의 트래픽 드롭 위험이 존재했다.

v1.35 개선

PreferSameNode 옵션이 도입되어 "가능하면 내 노드 내부로, 없으면 외부로" 라우팅이 가능해졌다. 기존 PreferClose는 PreferSameZone으로 명칭이 변경되어 명확성을 더했다.

 

YAML 변경점: Service 리소스에 새로운 필드가 추가되었다.

apiVersion: v1
kind: Service
spec:
  trafficDistribution: PreferSameNode  # 신규 옵션

 

기존 internalTrafficPolicy: Local과의 차이:

1. Local: 내 노드에 파드가 없으면 트래픽을 드롭(Drop)해버린다. (위험도가 있음)
2. PreferSameNode: 내 노드에 파드가 있으면 거기로 보내고, 없으면 다른 노드로 보낸다. (안전함)

동일 노드 통신은 CNI(Container Network Interface) 브리지나 VXLAN 캡슐화를 거치지 않고 메모리 버스 속도로 통신하므로 레이턴시가 획기적으로 낮아진다.

네트워크 홉(Hop)을 줄여 성능을 극대화하는 기능이다.  내부 루프백 통신을 우선시하므로 클라우드 전송 비용 절감에 직접적인 효과가 있을 것이다.

---

2. Job 관리 위임 (KEP #4368)

배치 작업(Job)의 제어권을 외부 시스템에 넘길 수 있다.

기존 문제

MultiKueue 같은 외부 디스패처가 Job을 관리할 때, 기본 Job 컨트롤러와 충돌하거나 상태 동기화가 매끄럽지 않았다.

v1.35 개선

.spec.managedBy 필드를 설정하면 기본 컨트롤러는 해당 Job의 동기화를 건너뛰고, 지정된 외부 컨트롤러가 전적으로 관리하도록 위임한다.

 

YAML 변경점: Job 스펙에 제어 주체를 명시한다.

apiVersion: batch/v1
kind: Job
spec:
  managedBy: kueue.x-k8s.io/multi-kueue  # 외부 컨트롤러 지정

 

작동 메커니즘:

1. 기본 kube-controller-manager 내의 Job Controller는 managedBy 필드가 있는 Job을 무시(Skip)한다.
2. 대신 지정된 외부 컨트롤러(예: Kueue)가 파드 생성, 상태 업데이트(.status), 재시도 로직을 전담한다.

배치 작업의 제어권을 분리하는 업데이트이다.
멀티 클러스터 환경에서 대규모 배치 작업을 돌리는 기업들에게는 아주 좋은 기능으로 보여진다.

 

---

3. 파드 세대(Generation) 추적 (KEP #5067)

인플레이스 리소스 업데이트의 성공 여부를 확실하게 검증한다.

기존 문제

파드 스펙을 변경해도 이것이 실제로 노드에 반영되었는지, 아니면 아직 처리 중인지 메타데이터만으로는 확인이 불가능했다. 리소스를 2Gi에서 4Gi로 올렸을 때, 현재 4Gi인지 2Gi인지 Kubelet의 상태 보고만으로는 시점을 맞추기 어려웠다.

v1.35 개선

파드에 .metadata.generation과 .status.observedGeneration 필드가 추가되었다. 이제 Deployment처럼 파드도 변경 이력을 명확히 추적할 수 있다.

 

내용:

1. .metadata.generation: 사용자가 스펙을 변경할 때마다 1씩 증가 (Sequence).
2. .status.containerStatuses[].userFaces.resources: 현재 컨테이너에 실제 적용된 리소스 값.

Kubelet은 이 두 값을 비교하여 "변경 적용 중(Resizing)"인지 "완료(Resized)"인지 보고한다.

인플레이스 업데이트의 신뢰성을 보장하기 위한 메타데이터 강화 업데이트이다.
운영자 입장에서 '내 명령이 진짜 반영된 건가?' 하는 의심을 해소해 주는 중요한 업데이트다.

---

주요 베타 및 알파 기능 - New Beta & Alpha Features

1. Downward API 토폴로지 노출 (KEP #4742) - State: Beta

기존 문제

애플리케이션이 자신이 위치한 Zone/Region을 알기 위해서는 API 서버에 권한을 가지고 쿼리를 날려야 했다.

v1.35 개선

Downward API를 통해 파드 내부 환경 변수로 topology.kubernetes.io/zone 정보를 바로 주입받을 수 있다.

불필요한 RBAC 권한 부여를 줄이고, 앱이 위치 인식을 더 쉽게 할 수 있게 되었다.

---

2. 스토리지 버전 마이그레이션 (KEP #4192) - State: Beta

 

기존 문제

데이터 스키마가 변경되면 관리자가 수동으로 데이터를 읽고 쓰는 복잡한 마이그레이션 작업을 수행해야 했다.

v1.35 개선

컨트롤러가 내장되어 스토리지 버전 마이그레이션을 자동으로 처리한다. 이제 "인트리(In-tree)" 기능으로 기본 활성화된다.

---

3. 갱 스케줄링 (Gang Scheduling) (KEP #4671) - State: Alpha

 

기존 문제

AI 분산 학습 시, 파드들이 낱개로 스케줄링되다가 자원이 부족하면 서로 자원을 점유한 채 멈추는 교착 상태(Deadlock)가 발생했다.

v1.35 개선

"모두 아니면 전무(All-or-Nothing)". 연관된 파드 그룹이 동시에 실행될 자원이 있을 때만 스케줄링을 시작한다.

AI/ML 워크로드를 위한 스케줄링 효율성이 비약적으로 상승할 것으로 기대된다.

---

중단 및 제거 - Deprecations & Removals

1. cgroup v1 지원 완전 제거

-   내용: v1.35부터 Kubelet은 cgroup v1 노드에서 실행되지 않는다.

-   대응: CentOS 7 등 구형 OS 사용자는 커널 업그레이드 및 cgroup v2 활성화를 서둘러야 한다.

2. Ingress NGINX 프로젝트 은퇴 예고

-   내용: 가장 널리 쓰이던 Ingress NGINX가 2026년 3월까지만 패치를 제공한다.

-   대응: Gateway API를 지원하는 Envoy Gateway, Cilium 등으로 마이그레이션 계획을 세워야 한다.

3. kube-proxy IPVS 모드 중단 (Deprecated)

-   내용: IPVS 모드가 유지보수 문제로 중단(Deprecated) 되었다.

-   대응: 성능과 호환성이 더 좋은 nftables 모드로 전환을 권장한다.

4. containerd v1.x 마지막 지원

-   내용: v1.35는 containerd 1.x 버전을 지원하는 마지막 릴리스다. 다음 버전부터는 2.0 이상이 필요하다.

---

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.