Kubernetes v1.36 하루 (Haru)
들어가기 전
많이 늦은 글입니다.
보통은 새로운 버전이 나오고 하루 내지 이틀 사이에는 포스팅을 하는데, 새로운 회사로 이직하고 적응기에 놓여있어 빠르게 글을 작성하지 못 했습니다.
아무쪼록 이번 쿠버네티스 하루는 재미있는 기능이 많이들 스테이블로 올라왔더군요, 다들 이번 이름처럼 좋은 하루 보내시길 바라겠습니다.
Kubernetes v1.36 하루 (Haru)
2026년 4월 22일 배포된 Kubernetes v1.36 "하루(Haru)"는 단순한 기능 추가를 넘어, 실제 운영 환경에서의 비효율을 제거하고 관리의 정밀도를 높이는 데 큰 방점을 두었다.
공식 릴리스 노트 중에서 "주요 업데이트 조명"과 "안정화된 기능" 섹션을 주된 내용으로 포스팅한다.
이번 릴리스의 하이라이트는 "워크로드 인식 스케줄링(WAS)"과 "하드웨어 리소스 상태 모니터링", 그리고 "보안 격리 및 편의성 강화" 세 가지로 중점이다.
운영자는 반드시 스테이징 환경에서 테스트 후 프로덕션에 적용해야 하며, 특히 알파/베타 기능 도입 시에는 세심한 주의가 필요함.
공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다.
이는 정확한 정보가 아닐 수 있음을 알려드립니다.
공식 사이트
광고 클릭은 큰 힘이 됩니다.
Kubernetes v1.36: ハル (Haru)
Editors: Chad M. Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Utkarsh Umre Similar to previous releases, the release of Kubernetes v1.36 introduces new stable, beta, and alpha features. The consistent delivery of high-quality releases underscores th
kubernetes.io
주요 업데이트
리소스 상태 모니터링 (KEP #4680) - State: Beta
디바이스 오류 파악의 일원화: 파드 크래시 원인이 하드웨어인지 앱인지 진단하는 과정이 대폭 간소화된다.
기존 문제
이전에는 쿠버네티스에 할당된 기기(GPU 등 특수 하드웨어)의 상태를 보고하는 기본 방법이 없어, 하드웨어 결함으로 인한 파드(Pod) 크래시 루프를 진단하기가 매우 까다로웠다.
v1.36 개선
각 파드의 .status 내에 allocatedResourcesStatus 필드가 추가되며 베타로 승격되었다. 하드웨어가 기존 디바이스 플러그인을 통해 프로비저닝되었든 최신 DRA(동적 리소스 할당) 프레임워크를 통해 프로비저닝되었든 관계없이 통합된 상태 보고를 제공한다.
이제 kubectl describe pod 명령어를 통해 파드의 크래시가 기기 상태 이상(Unhealthy 또는 Unknown) 때문인지 즉각적으로 확인할 수 있다.
장애 원인 파악(Triage) 속도를 비약적으로 높일 수 있다. 결함이 있는 하드웨어를 신속하게 격리(Cordon/Drain)하는 운영 자동화 구성이 용이해질 것이다.
워크로드 인식 스케줄링(WAS) 기능 (KEP #4671) - State: Alpha
개별 파드 스케줄링의 한계 극복: 연관된 파드들을 하나의 그룹으로 묶어 효율적으로 스케줄링한다.
기존 문제
쿠버네티스 스케줄러와 작업(Job) 컨트롤러는 파드를 독립적인 단위로만 관리했다. AI 분산 학습이나 복잡한 배치 워크로드의 경우, 일부 파드만 스케줄링되고 나머지는 자원 부족으로 멈춰버리는 교착 상태(Deadlock)에 빠지거나 리소스가 낭비되는 파편화 현상이 자주 발생했다.
v1.36 개선
관련 파드를 단일 논리 엔티티로 처리하기 위해 Workload API 및 새롭게 분리된 PodGroup API가 네이티브로 통합되었다.
그룹 내 모든 파드가 "함께 바인딩되거나 아예 바인딩되지 않도록 보장(All-or-Nothing)"하는 새로운 PodGroup 스케줄링 주기가 도입되어 전체 그룹을 원자적으로 평가한다.
AI/ML 분산 워크로드를 운영하는 플랫폼 엔지니어들에게는 가뭄의 단비 같은 기능이다. 부분 배치가 만드는 리소스 점유 낭비를 예방해 클러스터 전체의 효율이 극대화될 것이다.
안정화된 기능
포드의 사용자 네임스페이스 지원 (KEP #127)
컨테이너의 탈옥(Breakout) 피해를 최소화하는 강력한 보안 격리 기능.
기존 문제
컨테이너 내에서 권한을 탈취당할 경우, 해당 악성 프로세스가 기본 호스트 노드에 대한 루트(Root, UID 0) 관리 권한까지 그대로 얻어버리는 심각한 보안 취약성(탈옥)이 존재했다.
v1.36 개선
Linux 커널의 사용자 네임스페이스(User Namespace) 기능을 활용해, 컨테이너의 루트 사용자를 호스트 노드의 "권한 없는 사용자(Unprivileged user)"로 매핑한다.
pod.spec.hostUsers: false 설정을 통해 파드가 이 격리 기능을 활성화할 수 있습니다. 이를 통해 컨테이너를 탈출하는 프로세스라도 호스트 환경에서는 어떠한 관리 권한도 갖지 못하게 된다. (※ containerd 2.0 이상 등 호환 가능한 런타임 필요)
다중 테넌트(Multi-tenant) 클러스터와 민감한 인프라를 보호하기 위한 심층 방어(Defense in Depth)의 핵심이다.
시스템 관리 권한(CAP_SYS_ADMIN 등)이 필요한 워크로드라도 호스트 격리 하에 더 안전하게 실행할 수 있다.
서비스 어카운트 토큰 외부 서명 API (KEP #740)
외부 HSM(하드웨어 보안 모듈) 및 KMS(키 관리 시스템)와의 완벽한 통합.
기존 문제
이전에는 ServiceAccount JWT 서명 키가 디스크 파일로 저장되었으며 API 서버 시작 시에만 로드되었다.
이는 키 순환(Key Rotation) 시마다 API 서버 프로세스를 재시작해야 하는 치명적인 운영상의 불편함과 가용성 저하를 유발했다.
v1.36 개선
kube-apiserver가 ServiceAccount 토큰 서명을 외부 시스템(KMS 등)에 위임(Delegate)할 수 있다.
--service-account-signing-endpoint 플래그를 통해 외부 서명자의 Unix Domain Socket(UDS)을 지정하면, API 서버는 외부 서명자의 공개 키를 동적으로 검색 및 캐시하고 토큰의 유효성을 검사한다.
API 서버 재시작 없이도 안전하게 키를 순환할 수 있다. 금융, 공공 등 PCI-DSS나 SOC 2와 같은 엄격한 컴플라이언스(Compliance)가 요구되는 엔터프라이즈 환경에서 매우 환영받을 기능이다.
재귀적 SELinux 라벨 변경 속도 향상 (KEP #1710)
대규모 스토리지 볼륨의 파드 시작 지연(Startup delay) 문제 해결.
기존 문제
SELinux가 Enforcing 모드로 실행되는 환경에서는, 파드가 볼륨을 마운트하기 전에 컨테이너 런타임이 볼륨 내의 모든 파일과 디렉토리에 대해 재귀적으로 SELinux 라벨을 다시 쓰는(Relabeling) 작업을 수행해야 했다. 파일이 수백만 개인 볼륨의 경우 파드 시작에 엄청난 시간이 소요되었다.
v1.36 개선
파일 시스템을 순회하며 일일이 라벨을 수정하는 대신, 운영체제의 볼륨 마운트 옵션(-o context=XYZ)을 활용하여 마운트 수준에서 즉시 올바른 SELinux 컨텍스트를 부여한다.
seLinuxChangePolicy: MountOption을 지원하는 환경에서는 파일 개수에 상관없이(Constant time) 즉각적으로 볼륨을 마운트한다.
파일이 많은 볼륨을 다루는 AI/ML 데이터셋 파드나 대규모 데이터베이스의 재시작/롤아웃 속도가 비약적으로 향상된다.
Tail latency(긴 꼬리 지연)를 극적으로 줄일 수 있다.
개인적인 생각입니다만, 개선이 되었다 하더라도 SELinux를 사용하면 운영 복잡도는 상승 할 수 밖에 없을것 같습니다.
세분화된 Kubelet API 권한 부여 (KEP #2862)
모니터링 에이전트의 보안 리스크 원천 차단.
기존 문제
Prometheus, Datadog과 같은 모니터링/로깅 도구들이 Kubelet API(예: /metrics)를 조회하려면 불가피하게 nodes/proxy라는 포괄적인(Catch-all) RBAC 권한을 부여받아야 했다.
이 권한은 임의의 컨테이너 명령 실행(/exec)까지 허용하므로, 모니터링 도구가 해킹될 경우 클러스터 전체가 장악될 수 있는 거대한 보안 홀이었다.
v1.36 개선
nodes/proxy를 nodes/metrics, nodes/stats, nodes/log, nodes/pods 등 세분화된 하위 리소스(Subresource) 권한으로 분리했다.
이제 모니터링 툴에는 딱 필요한 /metrics 읽기 권한만 최소 권한(Least Privilege) 원칙에 따라 부여할 수 있다.
"모니터링 툴 취약점이 클러스터 전체 장악으로 이어지던" 악명 높은 공격 벡터(Attack Vector)가 마침내 차단되었다.
모든 클러스터 관리자는 즉시 RBAC 설정을 감사하고 세분화된 권한으로 마이그레이션해야 한다.
세분화 마이그레이션시 초도 설정에 대한 운영 인력 비용이 발생 할 수 있을듯 합니다.
변형 어드미션 정책 (KEP #3962)
무겁고 복잡한 외부 웹훅(Webhook) 운영 부담 해소.
기존 문제
들어오는 API 요청의 값을 선언적으로 수정(Mutating)하려면, 클러스터 외부에 별도의 어드미션 웹훅 서버를 구축하고 TLS 인증서를 관리해야 했다.
웹훅 장애나 네트워크 지연은 클러스터의 생성/변경 작업을 통째로 마비시키는 원인이 되었다.
v1.36 개선
공통 표현식 언어(CEL)를 사용하여 kube-apiserver 내부에서 직접 변형 논리를 평가하고 실행한다. MutatingAdmissionPolicy 및 MutatingAdmissionPolicyBinding 리소스를 통해 외부 통신 없이 즉각적이고 안전하게 리소스 값을 변경(패치)한다.
사이드카 주입이나 기본 라벨/어노테이션 설정을 위해 더 이상 외부 웹훅 서버를 띄울 필요가 없다. 클러스터 아키텍처가 단순해지고 API 안정성이 대폭 상승한다.
노드 로그 쿼리 (KEP #2258)
SSH 접속 없는 안전한 노드 레벨 트러블슈팅.
기존 문제
파드 로그와 달리, kubelet이나 containerd 등 시스템 컴포넌트 로그를 보려면 클러스터 관리자가 개별 노드에 SSH나 RDP로 직접 접속해야만 했다.
v1.36 개선
Kubelet의 /logs/ HTTP 엔드포인트를 통해 OS의 네이티브 로깅 인프라(journald 또는 /var/log)에 직접 쿼리할 수 있다.kubectl get --raw "/api/v1/nodes/<node-name>/proxy/logs/?query=kubelet" 와 같은 명령어로 손쉽게 서비스 로그를 조회하거나 에러 패턴을 검색할 수 있다. (※ enableSystemLogQuery 활성화 필요)
노드 디버깅을 위해 더 이상 위험하게 SSH 포트를 열어둘 필요가 없어집니다. 보안성과 편의성 두 마리 토끼를 모두 잡았다.
추가적인 툴 없이 엔드포인트로 노드 로그를 볼 수 있다니... 그저 빛
가변 CSINode 할당 가능 속성 (KEP #4876)
스토리지 연결 한도의 동적 관리.
기존 문제
노드가 처리할 수 있는 최대 CSI 볼륨 수는 드라이버 시작 시 정적으로 보고되었다.
이로 인해 실제 용량과 스케줄러의 정보가 불일치하여, 파드가 용량이 없는 노드에 배치되었다가 ContainerCreating 상태에 갇히는 현상이 빈번했다.
v1.36 개선
CSI 드라이버가 노드의 최대 볼륨 처리 수량(CSINode.spec.drivers[*].allocatable.count)을 런타임에 동적으로 업데이트할 수 있다. ResourceExhausted 오류 발생 시 Kubelet이 즉각적으로 한도를 재조정하여 스케줄러가 정확한 가용성을 파악하게 돕는다.
고밀도 스토리지 환경에서 "원인 불명의 파드 생성 지연"이 크게 감소할 것이다.
볼륨 소스: OCI 아티팩트 및 이미지 (KEP #4639)
정적 데이터 배포의 패러다임 전환.
기존 문제
앱 코드가 아닌 정적 에셋, AI/ML 모델, 설정 파일 등을 파드에 주입하려면 Init 컨테이너를 사용해 데이터를 복사하거나 NFS 등 외부 스토리지를 연결해야 하는 번거로움이 있었다.
v1.36 개선
파드 스펙의 volumes 섹션에 OCI 호환 레지스트리의 image 참조를 직접 정의할 수 있다. Kubelet이 해당 OCI 아티팩트를 가져와 파드 내에 읽기 전용 볼륨으로 즉시 마운트한다.
무거운 머신러닝 모델이나 정적 자산을 앱 이미지에서 분리해 OCI 아티팩트로 관리할 수 있다. "뚱뚱한(Fat) 이미지" 문제를 해결하고 CI/CD 파이프라인이 한결 가벼워진다.
cgroups v2를 사용한 메모리 QoS 및 PSI 지원 (KEP #4205, KEP #2570)
리소스 병목(Contention)의 현미경 관찰.
기존 문제
CPU/메모리 "사용률(Utilization)" 메트릭만으로는 시스템이 단순히 활발하게 일하는 중인지, 아니면 자원이 부족해 스레드들이 서로 멈춰서 기다리는(Stall) 중인지 정확히 구분하기 불가능했다.
v1.36 개선
Linux 커널의 PSI(Pressure Stall Information) 메트릭을 cgroup v2를 통해 네이티브로 수집한다. CPU, 메모리, I/O에 대해 "Some(일부 지연)"과 "Full(완전 멈춤)" 압력 정보를 Kubelet Summary API와 Prometheus /metrics/cadvisor 엔드포인트로 노출한다.
노드 스래싱(Thrashing)과 "시끄러운 이웃(Noisy Neighbor)" 현상을 뼈저리게 겪어본 운영자에게는 구세주 같은 지표이다.
오토스케일링 로직을 훨씬 더 정교하게 다듬을 수 있다.
볼륨 그룹 스냅샷 (KEP #3476)
다중 볼륨 애플리케이션의 크래시 정합성(Crash-consistent) 보장.
기존 문제
분산 DB나 여러 개의 PVC를 사용하는 애플리케이션의 경우, 각 볼륨을 백업할 때 스냅샷 타이밍이 미세하게 엇갈려 복원 시 데이터 무결성이 깨지는 대참사가 일어날 수 있었다.
v1.36 개선
VolumeGroupSnapshot API를 통해 지정된 여러 개의 PVC 세트에 대해 정확히 멈춘 상태의 동일 시점 스냅샷을 동시에 찍을 수 있다.
엔터프라이즈급 재해 복구(DR) 파이프라인을 구축할 때 없어서는 안 될 가장 중요한 기반 기술이다.
동적 리소스 할당(DRA)의 완전한 성숙 (KEP #5018, KEP #4816)
GPU 등 특수 하드웨어 운영의 고도화.
v1.36 개선
AdminAccess (KEP-5018): resource.k8s.io/admin-access: "true" 라벨이 지정된 네임스페이스에서는, 클러스터 관리자가 이미 다른 워크로드가 사용 중인 하드웨어 리소스(Claim)에 접근하여 헬스체크 및 진단 작업을 수행할 수 있다.
우선순위 대안 (KEP-4816): ResourceClaim 내에 firstAvailable 필드를 도입하여, 1순위 하드웨어가 없을 경우 차순위 하드웨어(Fallback)를 스케줄러가 자동으로 탐색하고 할당하도록 지정할 수 있다.
특정 GPU 모델이 부족할 때 "아쉬운 대로" 하위 모델 GPU라도 할당받아 서비스를 유지하는 유연한 스케줄링이 가능해진다.
가장 뜨거웠던 기능입니다. 쿠버네티스의 GPU 활용을 끌어 올리기 위한 기능이죠
그 외 눈여겨볼 안정화 기능
gogo protobuf 의존성 제거 (KEP #5589): 유지보수가 중단된 gogoprotobuf 라이브러리 의존성을 K8s 코드베이스에서 완전히 걷어내어 장기적인 보안 취약성 리스크를 제거했다.
CSI 드라이버 Secret 토큰 옵트인: 서비스 어카운트 토큰을 일반 volume_context 대신 더 안전한 secrets 필드로 전달하도록 설정(serviceAccountTokenInSecrets: true)하여, gRPC 로그 등에 토큰이 노출되는 사고를 방지한다.
주요 베타 및 알파 기능
컨트롤러 최신성 유지 (Staleness mitigation) - State: Beta
기존 문제
컨트롤러가 캐싱된 "오래된(Stale)" 상태 정보를 바탕으로 조정을 수행하다가 충돌 업데이트나 치명적인 데이터 손상을 일으키는 문제가 종종 발생했다.
v1.36 개선
컨트롤러가 오래된 클러스터 상태 뷰에 기반해 동작하는 것을 차단하고, 컨트롤러 동작의 관찰 가능성을 높여 유해한 파괴적 동작을 사전에 방지한다.
cgroups v2를 사용한 메모리 QoS (KEP #2570) - State: Beta
단일 노드에 여러 파드가 실행될 때 발생하는 메모리 병목 현상을 방지하기 위해, cgroup v2를 기반으로 컨테이너 간의 간섭과 스래싱(Thrashing)을 억제하는 스마트한 메모리 보호 기능이 도입되었다.
작업(Job) 일시 중지 시 가변 컨테이너 리소스 (KEP #5440) - State: Beta
작업(Job)이 Suspend(일시 중지) 상태일 때 한정으로 컨테이너의 CPU, 메모리, GPU 요청 및 제한을 동적으로 변경할 수 있다. 대기열 기반의 큐잉 컨트롤러가 클러스터 여유 상황에 맞춰 배치 작업 리소스를 유연하게 조율할 수 있다.
중단 및 제거 - Deprecations & Removals
Ingress NGINX 프로젝트 은퇴
내용: 가장 널리 쓰이던 Ingress NGINX가 2026년 3월 24일부로 공식 은퇴(Retire)했다. 해당 일자 이후로는 추가 릴리스, 버그 수정, 그리고 보안 취약점 해결 패치가 일절 제공되지 않는다.
대응: 당장 작동이 멈추는 것은 아니지만, 보안 사고를 예방하기 위해 Gateway API를 지원하는 최신 솔루션(예: Envoy Gateway, Cilium 등)으로 마이그레이션 계획을 반드시 세워야 한다.
Service .spec.externalIPs 지원 중단
내용: 서비스 사양의 externalIPs 필드는 중간자 공격(MITM, CVE-2020-8554) 등 심각한 보안 이슈를 야기할 수 있어 v1.36부터 공식적으로 지원 중단(Deprecated)되며, v1.43 릴리스에서 완전히 제거된다.
대응: 외부 트래픽 노출 아키텍처를 LoadBalancer 타입 서비스, NodePort, 또는 Gateway API를 사용하는 방식으로 전면 개편해야 한다.
gitRepo 볼륨 플러그인 완전 제거
내용: 보안상의 치명적 위험(노드에서 root로 코드 실행 가능) 때문에 수년간 지원 중단 상태였던 gitRepo가 v1.36부터 완전히 경로가 닫히고 비활성화된다.
대응: gitRepo 볼륨에 의존하는 워크로드는 초기화(Init) 컨테이너에서 git clone을 명시적으로 수행하는 방식으로 변경해야만 파드를 정상적으로 띄울 수 있다.
중요
잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.
'Kubernetes > Kubernetes 버전별 변경 이력' 카테고리의 다른 글
| Kubernetes v1.35: 세계수 (The World Tree) 업데이트 핵심 (2) | 2025.12.22 |
|---|---|
| Kubernetes v1.35 업데이트 미리보기 (1) | 2025.11.26 |
| Kubernetes v1.34: 바람과 의지 (Of Wind & Will) 업데이트 핵심 (0) | 2025.10.07 |
| Kubernetes 1.33 “Octarine” 업데이트 핵심 (1) | 2025.10.01 |
| KUBERNETES 1.28 변경이력 [ 번역본 ] (1) | 2024.08.07 |