🔭곧 릴리즈 예정인 Kubernetes v1.34 미리 살펴보기

안녕하세요, Aiden’s Lab 뉴스레터입니다.

2025년 8월 말 Kubernetes 1.34 버전이 릴리즈된다는 공식 발표가 최근 공개되었습니다. 이번 릴리즈에선 기존 기능이 제거되거나 Deprecated(더 이상 사용되지 않고 앞으로 사라질 예정)되기보다는, 기존 기능 개선이 주를 이룬다고 하는데요.

하드웨어 장치 리소스 관리와 Service Account 토큰 활용 개선, Deployment의 Pod 재생성 시점 설정과 같이, 세세하지만 Kubernetes의 방향성을 보여주는 업데이트들이 돋보였습니다.

이번 공식 발표의 중요한 부분은 조금 더 풀어 설명해서 쉽게 이해할 수 있도록 도와드리겠습니다.

Pod에 GPU 등 하드웨어 장치를 더욱 유연하게 할당하고 관리할 수 있는 DRA(Dynamic Resource Allocation) 기능 안정화

먼저 DRA(Dynamic Resource Allocation) 기능의 Stable 단계 진입 예정 소식입니다. Kubernetes 1.30 버전부터 소개된 기능이기 때문에 DRA가 낯설 수도 있는데요.

DRA는 하드웨어 장치 리소스를 하나 혹은 여러 Pod에 할당할 수 있게 해주는 기능입니다. 하드웨어 장치에 대한 DeviceClass를 정의 후, ResourceClaim이란 오브젝트를 생성해서 Kubernetes 워크로드(Deployment, Statefulset 등)가 해당 장치 리소스를 유연하게 사용하는 방식인데요.

좀 더 쉽게 이해하려면 Dynamic Volume Provisioning을 떠올려보세요. 스토리지를 StorageClass로 정의한 다음, PersistentVolumeClaim을 통해 Kubernetes 워크로드가 사용하는 기능인데, 할당 대상을 Class로 정의해서 Claim 오브젝트를 통해 사용하는 게 똑같죠?

다만 차이점은, DRA의 할당 대상이 하드웨어 장치 리소스라는 것입니다.

DRA은 ResourceClaim으로 여러 Pod가 하나의 장치 리소스를 공유해서 유연하게 활용할 수 있고, 장치마다 DeviceClass로 알맞은 카테고리를 부여해서 체계적으로 사용할 수 있다는 장점이 있습니다.

해당 기능은 이번 1.34 버전에서 Stable 단계로 진입하는 걸 목표로 하고 있다는데요. 만약 테스트를 거쳐 Stable 단계가 된다면, DRA는 Kubernetes 1.34 버전의 클러스터에서 기본적으로 사용할 수 있게 됩니다.

특히 DRA는 GPU 리소스를 Kubernetes 워크로드에 유연하게 할당할 수 있어 AI 개발에 중요한 역할을 수행할 수 있기 때문에, 개발 팀이 Stable 진입을 서두를 것으로 보입니다.

kubelet이 컨테이너 이미지를 가져올 때의 보안성 향상

Kubernetes 1.33 버전부터 Credential Provider 플러그인을 통해 kubelet이 ServiceAccount의 토큰을 사용해서 컨테이너 이미지 저장소에 접근할 수 있는 기능을 선보였습니다.

Pod가 실행되면서 컨테이너 이미지를 가져올(Pull) 때, kubelet이 해당 Pod와 연결된 ServiceAccount의 토큰을 사용하는 기능인데요. 해당 기능은 현재 알파 단계이기 때문에 추가 설정을 통해 사용이 가능합니다.

이미지를 가져올 때 필요한 인증정보를 노드(예: .docker/config.json)에 저장하지 않아도 되기에 보안성을 더욱 높인 업데이트였습니다.

1.34 버전부터 위 기능이 베타로 승격되면서 별도 설정 없이도 사용 가능할 예정인데요. 각 클러스터 노드에 Credential Provider 플러그인을 설치해야 하는 과정이 필요하긴 하지만, 컨테이너 이미지 저장소와의 통신 과정에서 발생할 수 있는 보안 위험을 줄여주는 업데이트로 기대됩니다.

Deployment의 Pod 재실행 시점을 설정하는 옵션 추가

Deployment가 변경될 경우, Pod가 다시 실행하는 데에는 일정한 시간이 걸리고 리소스도 추가로 소모됩니다. 이런 문제점을 해결하기 위해 1.34 버전부터 Pod 재생성 정책 설정이 추가됩니다.

해당 기능은 1.34 버전부터 알파 상태로 선보이는데요. Kubernetes API 서버와 kube-controller-manager의 설정에서 아래 두 가지 필드의 값을 enable로 명시하면 사용 가능합니다.

• DeploymentPodReplacementPolicy

• DeploymentReplicaSetTerminatingReplicas

이후 Deployment의 .spec.podReplacementPolicy 필드에 Pod가 재생성되는 방식을 아래와 같이 정의할 수 있게 됩니다.

• TerminationStarted:

  • 기존 Pod가 Terminate되기 시작될 때 새로운 Pod 생성. Rollout을 보다 빠르게 수행할 수 있지만 리소스가 많이 소모될 위험 있음

  • 종료까지 오래 걸리는 Pod의 Deployment 수정 시, 새로운 Pod가 바로 재생성되지 않는 문제 해결 가능

• TerminationComplete:

  • 기존 Pod가 완전히 Terminate되고 나서 새로운 Pod 생성. Rollout은 상대적으로 느리지만 리소스 소모를 제어할 수 있음

  • 리소스 소모량이 많은 Pod의 Deployment 수정 시, 기존 Pod가 종료되지 않은 상태에서 또다른 Pod가 재생성되면서 갑자기 리소스 사용량이 폭증하는 문제 해결 가능

Deployment는 Kubernetes에서 가장 많이 사용되는 워크로드 중 하나인 만큼, 더욱 효율적으로 Deployment를 사용할 수 있는 정밀한 정책이 추가된 것으로 보입니다.

클러스터에서 발생하는 이벤트의 전체 라이프사이클을 추적 기능 안정화

Kubernetes 클러스터 노드에서 발생한 이슈를 디버깅하는 것은 쉽지 않았습니다. 오류가 발생했다는 로그만으로는 어디서 문제가 있었는지 파악하는 데에 시간이 걸릴 수밖에 없었는데요.

그래서 지난 1.22 및 1.25 버전에서 kubelet과 Kubernetes API 서버에서 컨테이너 런타임으로 보내는 요청을 트레이스로 기록하는 기능이 처음 선보였습니다. 기록은 OpenTelemetry 표준을 따르기 때문에 다양한 모니터링 툴에서 시각화할 수 있는 범용성도 노렸고요.

kubelet과 Kubernetes API 서버가 트레이스를 기록하면서 지연 시간과 오류의 원인을 짚어낼 수 있고, Kubernetes 이벤트(예: Pod 시작)의 전체 라이프사이클을 확인할 수 있게 된 것인데요. 트레이스에는 고유한 ID도 부여되어 컨테이너 런타임이 수행한 작업들 중 연관된 것들이 묶일 수 있고, 문제의 원인을 분석할 때 유용하게 사용 가능합니다.

이번 1.34 버전에선 해당 기능이 Stable 단계로 진입하는 걸 목표로 한다고 하는데요. 이미 여러 마이너 버전을 거쳐온 기능이기 때문에 무리 없이 Stable 상태가 될 것으로 보입니다.

KYAML(Kubernetes + YAML) 양식 지원

KYAML은 YAML과 JSON의 문제점을 해결하기 위한 Kubernetes를 위한 YAML 양식으로, Kubernetes 1.34 버전부터 Alpha 단계로 선보일 예정입니다.

KYAML이 고치려 한 문제점은 아래와 같습니다.

• YAML에서 공백만으로 들여쓰기하면서 가독성이 떨어짐

• YAML에서 String 타입 값에 따옴표로 감싸는 것에 대한 정책이 없음

• JSON에서 주석을 제대로 지원하지 않음

• JSON에서 Map의 Key를 항상 따옴표로 감싸야 해서 사용성이 떨어짐

위 문제점을 KYAML은 아래와 같은 규칙으로 개선한다고 합니다.

• String 타입의 값은 항상 큰따옴표("")로 감싼다.

• Key는 특정 상황을 제외하면 따옴표로 감싸지 않는다.

• Mapping에는 항상 중괄호({})를 사용한다.

• List에는 항상 대괄호([])를 사용한다.

KYAML은 k8s 매니페스트나 Helm chart를 작성할 때 사용 가능하며, 모든 kubectl 버전에서 Input으로 사용 가능할 예정이라고 합니다. kubectl v1.34부터 KYAML을 새로운 Output 양식으로 지원(예: kubectl get -o kyaml ...)할 예정이라고 하네요.

그리고 개발 팀에 의하면, KYAML은 YAML의 하위 개념이므로 Kubernetes에서 YAML 대신 KYAML만 사용할 것을 요구하는 일은 앞으로도 없을 거라고 합니다. KYAML은 어디까지나 YAML과 JSON의 문제점을 개선하려는 하나의 노력으로 등장한 것이기 때문에, KYAML을 YAML의 대체재가 아닌 또다른 선택지로 설정한 것은 합리적이라고 생각합니다.

마무리

Kubernetes 1.34 버전에는 어떤 큰 변화가 있다기보단, 세세하지만 Kubernetes의 방향성이 드러나는 업데이트들이 많았습니다.

AI 개발에 중요한 GPU 리소스 관리부터 더욱 개선된 Credential 관리, 클러스터 노드 레벨의 트레이스 기록까지 Kubernetes는 시대의 흐름에 맞추며 내부 구성요소를 견고히 하는 움직임을 보이고 있는데요. 앞으로 Kubernetes는 또 어떻게 발전해나갈지 기대해봅니다.

그럼 다음 아티클에서도 흥미로운 주제로 돌아오겠습니다.

감사합니다.

참고 자료

• https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek

• https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation

• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/dra-intro-install.html

• https://kubernetes.io/docs/tasks/administer-cluster/kubelet-credential-provider

✨이번 아티클은 어떠셨나요?

이번 글의 주제에 대해 어떻게 생각하는지 알려주세요! 더 나은 아티클을 전달해드리기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab에 큰 힘이 됩니다!

✨이번 뉴스레터는 어떠셨나요?

이번 글에서 다룬 주제에 대해 어떻게 생각하는지 알려주세요! 뉴스레터를 더 나은 방향으로 개선하기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab 뉴스레터에게 큰 힘이 됩니다!

🔭Aiden’s Lab에서 더 많은 아티클을 만나보세요

발행된 뉴스레터를 아카이빙하고 다양한 정보를 공유하는 기술 블로그를 운영 중입니다.

👉 Aiden’s Lab 기술 블로그 둘러보기