Kubernetes v1.36: ハル (Haru) 릴리즈 소식
릴리즈 정보
•
릴리즈 일자: 2026년 4월 22일
•
릴리즈 주기: 정규(Minor) 릴리즈
•
지원 기간: 2027년 6월 28일까지 (약 14개월)
•
호환성: v1.34 ~ v1.38 호환
•
다음 릴리즈: v1.37 (예정: 2026년 8월 26일)
한눈에 보기
Kubernetes v1.36은 보안, 스토리지, DRA(Dynamic Resource Allocation), 컨트롤 플레인 확장성 기능을 성숙 단계로 끌어올린 릴리즈입니다. 이번 릴리즈에는 총 70개의 enhancement가 포함되었고, 18개가 Stable, 25개가 Beta, 25개가 Alpha 단계로 정리되었습니다.
v1.35에서 이미 안정화된 In-place Pod Resize 같은 리소스 관리 흐름은 v1.36에서 Pod-level resource까지 확장되고, User Namespaces와 kubelet API 권한 분리는 보안 운영의 기본 선택지에 가까워졌습니다.
반면 Service.spec.externalIPs deprecation, gitRepo volume plugin 비활성화, DRA RBAC 변경처럼 업그레이드 전 점검해야 할 항목도 분명합니다.
•
Fine-grained kubelet API authorization (Stable): kubelet API 접근을 nodes/proxy 대신 nodes/metrics, nodes/stats, nodes/pods 등 세분화된 subresource로 나눠 최소 권한 RBAC를 설계할 수 있습니다.
•
User Namespaces (Stable): Pod 내부 root를 호스트의 비권한 사용자로 매핑해 컨테이너 탈출 시 피해 범위를 줄입니다.
•
MutatingAdmissionPolicies (Stable): CEL 기반 mutation 정책이 v1 API로 승격되어, 많은 기본값 주입/라벨 보정 작업을 webhook 없이 처리할 수 있습니다.
•
VolumeGroupSnapshot (Stable): 여러 PVC를 하나의 crash-consistent 복구 지점으로 묶어 snapshot할 수 있습니다.
•
DRA 기능 성숙: AdminAccess와 Prioritized Alternatives는 Stable, Resource health status와 여러 device 관리 기능은 Beta/Alpha로 확장되었습니다.
•
Workload Aware Scheduling (Alpha): PodGroup과 Workload API를 기반으로 AI/ML, HPC, batch workload의 그룹 단위 스케줄링 기반이 확장되었습니다.
즉시 확인 필요 사항
변경사항 | 영향 범위 | 대응 방법 | 긴급도 |
Service.spec.externalIPs Deprecated | Service, 네트워크, 보안 | externalIPs 사용 Service를 식별하고 LoadBalancer, NodePort, Gateway API 등으로 전환 계획 수립 | High |
gitRepo volume plugin 영구 비활성화 | gitRepo volume 사용 Pod | initContainer, git-sync 등 지원되는 방식으로 마이그레이션. v1.36부터 다시 켤 수 없음 | High |
DRA ResourceClaim status granular RBAC | DRA driver, scheduler, controller | resourceclaims/binding, resourceclaims/driver subresource에 필요한 update/patch 권한 부여 | High |
kubeadm flex-volume 통합 지원 제거 | kubeadm + flex-volume | flex-volume 사용 중이면 CSI로 이전. 계속 사용해야 하면 KCM custom image, --flex-volume-plugin-dir, extraVolumes 직접 구성 | Medium |
metric rename | 모니터링, 알림 | volume_operation_total_errors → volume_operation_errors_total, etcd_bookmark_counts → etcd_bookmark_total로 rule 수정 | Medium |
Scheduler PreBind plugin 인터페이스 변경 | custom scheduler plugin | PreBindPreFlight 반환 타입을 PreBindPreFlightResult로 갱신 | Medium |
주요 추가 기능 & 개선사항
보안 & 거버넌스
Fine-grained kubelet API authorization (Stable) • KEP-2862
요약: kubelet HTTPS API 접근 권한을 더 세밀하게 분리하는 기능이 GA가 되었습니다. 기존에는 모니터링 agent가 kubelet /metrics만 읽고 싶어도 nodes/proxy 권한을 받는 경우가 많았습니다. 문제는 nodes/proxy 권한이 단순 조회를 넘어 WebSocket 기반 exec 같은 위험한 경로와 같은 권한으로 묶일 수 있다는 점입니다.
v1.36의 세분화된 권한은 kubelet endpoint별로 nodes/metrics, nodes/stats, nodes/log, nodes/pods, nodes/healthz, nodes/configz 같은 subresource를 사용할 수 있게 합니다. 기존 nodes/proxy 권한은 호환성을 위해 계속 동작하지만, 새 배포나 Helm chart는 세분화된 권한으로 바꾸는 것이 안전합니다.
어떻게 사용하나요?
모니터링 agent가 kubelet metrics/stats만 읽도록 권한을 줄이는 예시입니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kubelet-metrics-reader
rules:
- apiGroups: [""]
resources: ["nodes/metrics", "nodes/stats"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubelet-metrics-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: kubelet-metrics-reader
subjects:
- kind: ServiceAccount
name: metrics-agent
namespace: monitoring
YAML
복사
타겟 유저: 보안 엔지니어, 플랫폼 엔지니어, 관찰가능성 도구 운영자
Support User Namespaces in Pods (Stable) • KEP-127
요약: Pod의 Linux user namespace 지원이 Stable로 승격되었습니다. hostUsers: false를 설정하면 컨테이너 내부의 root 사용자가 호스트에서는 비권한 사용자 ID로 매핑됩니다.
이 방식은 컨테이너 내부에서 root 권한이 필요한 애플리케이션을 실행하더라도, 호스트 커널과 파일시스템 관점에서는 root가 아니도록 만들어 방어 계층을 추가합니다. 특히 privileged에 가까운 기능을 쓰는 workload나 보안 격리가 중요한 multi-tenant 환경에서 의미가 큽니다.
다만 runtime, kernel, volume 종류에 따라 동작 조건이 달라질 수 있으므로 운영 도입 전 파일 권한, volume mount, CSI driver 호환성을 확인해야 합니다. 단순히 runAsNonRoot를 대체하는 기능이 아니라, 컨테이너와 호스트 사이의 UID/GID 매핑 모델을 바꾸는 기능으로 이해해야 합니다.
어떻게 사용하나요?
Pod spec에서 host user namespace 사용을 명시적으로 끕니다.
apiVersion: v1
kind: Pod
metadata:
name: userns-demo
spec:
hostUsers: false
containers:
- name: app
image: registry.k8s.io/e2e-test-images/agnhost:2.53
command: ["/bin/sh", "-c", "id && sleep 3600"]
YAML
복사
타겟 유저: 보안 엔지니어, 클러스터 관리자, multi-tenant 플랫폼 운영자
MutatingAdmissionPolicies (Stable) • KEP-3962
요약: MutatingAdmissionPolicy가 v1 API로 GA가 되면서 CEL 기반의 선언형 mutation 정책을 사용할 수 있게 되었습니다. 기존 mutating webhook은 별도 서버, TLS 인증서, 네트워크 경로, 실패 정책을 운영해야 했습니다. 반면 MutatingAdmissionPolicy는 API 서버 안에서 CEL expression으로 mutation을 계산하므로, 간단한 label 주입이나 기본값 보정에는 훨씬 가볍습니다.
정책은 MutatingAdmissionPolicy와 이를 활성화하는 MutatingAdmissionPolicyBinding으로 구성됩니다. 복잡한 외부 조회나 비즈니스 로직이 필요한 경우 webhook이 여전히 필요하지만, 클러스터 표준 라벨/annotation 보정 같은 작업은 이 기능으로 대체할 수 있습니다. 정책이 admission 단계에서 동작하므로 잘못된 expression은 리소스 생성 흐름에 직접 영향을 줄 수 있어, namespace selector나 matchConstraints로 범위를 좁혀 시작하는 것이 좋습니다.
어떻게 사용하나요?
Pod 생성 시 team=platform 라벨을 적용하는 간단한 예시입니다.
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: add-team-label
spec:
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
mutations:
- patchType: ApplyConfiguration
applyConfiguration:
expression: 'Object{metadata: Object.metadata{labels: {"team": "platform"}}}'
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
name: add-team-label
spec:
policyName: add-team-label
YAML
복사
타겟 유저: 플랫폼 엔지니어, 정책 관리자, 보안 엔지니어
External ServiceAccount Token Signer (Stable) • KEP-740
요약: ServiceAccount token 서명 기능을 API server 내부 키 파일이 아니라 외부 JWT signer로 위임할 수 있습니다. 이 기능은 키를 API server 노드에 직접 보관하기 어려운 환경, HSM이나 Cloud KMS를 사용하는 환경, 여러 클러스터에서 키 관리 체계를 통합하려는 환경에 유용합니다. v1.36에서는 이 기능이 Stable로 승격되어 장기 운영 대상으로 볼 수 있습니다.
kube-apiserver는 외부 signer가 노출하는 Unix domain socket을 통해 서명 요청과 key management를 처리합니다. 기존 projected ServiceAccount token 사용 방식 자체가 바뀌는 것은 아니며, 주로 control plane의 키 관리 책임이 바뀌는 기능입니다. HA API server 환경에서는 모든 API server가 동일한 signer endpoint와 issuer 설정을 일관되게 사용하도록 구성해야 합니다.
어떻게 사용하나요?
외부 signer socket을 사용하는 kube-apiserver 플래그 예시입니다.
kube-apiserver \
--service-account-issuer=https://kubernetes.default.svc \
--service-account-signing-endpoint=unix:///var/run/k8s-sa-signer/socket.sock
Bash
복사
타겟 유저: 보안 엔지니어, 플랫폼 엔지니어, control plane 운영자
스토리지 & 데이터 보호
VolumeGroupSnapshot (Stable) • KEP-3476
요약: VolumeGroupSnapshot은 여러 PVC를 하나의 crash-consistent snapshot 단위로 묶는 기능입니다. 단일 PVC snapshot은 이미 널리 쓰이지만, 데이터베이스나 메시지 브로커처럼 여러 볼륨이 하나의 애플리케이션 상태를 구성하는 경우에는 개별 snapshot만으로 복구 일관성을 보장하기 어렵습니다. v1.36에서 VolumeGroupSnapshot, VolumeGroupSnapshotContent, VolumeGroupSnapshotClass API가 groupsnapshot.storage.k8s.io/v1로 GA가 되었습니다.
사용자는 label selector로 함께 snapshot할 PVC를 선택하고, 스토리지 관리자는 CSI driver와 snapshot class를 준비합니다. 복구할 때는 group snapshot 안의 각 VolumeSnapshot을 새 PVC의 data source로 사용해 볼륨들을 다시 구성합니다.
CSI driver가 group snapshot RPC를 지원해야 하므로, 기능 사용 전 driver 문서를 반드시 확인해야 합니다.
어떻게 사용하나요?
같은 label을 가진 PVC들을 하나의 group snapshot으로 요청하는 예시입니다.
apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
name: mysql-group-snapshot
namespace: database
spec:
volumeGroupSnapshotClassName: csi-group-snapclass
source:
selector:
matchLabels:
app: mysql
snapshot-group: primary
---
apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshotClass
metadata:
name: csi-group-snapclass
driver: example.csi.k8s.io
deletionPolicy: Delete
YAML
복사
타겟 유저: 스토리지 관리자, 플랫폼 엔지니어, 상태 저장 워크로드 운영자
Mutable CSINode Allocatable Property (Stable) • KEP-4876
요약: Mutable CSINode Allocatable은 CSI driver가 노드별 attach 가능 volume 수를 동적으로 갱신할 수 있게 하는 기능입니다. 기존에는 attach limit이 한 번 계산된 뒤 실제 클라우드/스토리지 백엔드 상태와 어긋나도 스케줄러가 오래된 값을 기준으로 판단할 수 있었습니다. 그 결과 Pod는 스케줄링되었지만 volume attach 단계에서 실패하거나, 반대로 실제로는 여유가 있는데 스케줄링이 보수적으로 막히는 문제가 생길 수 있었습니다.
v1.36에서는 이 기능이 Stable이 되었고 MutableCSINodeAllocatableCount feature gate가 enabled로 고정되었습니다. 사용자는 보통 직접 YAML을 작성하지 않고, CSI driver가 CSINode의 allocatable 정보를 갱신하는지 확인합니다.
어떻게 사용하나요?
운영자는 아래처럼 CSINode의 driver별 allocatable count와 이벤트를 확인합니다.
kubectl get csinode <node-name> -o yaml
kubectl describe node <node-name> | grep -i attach -A3
kubectl get events -A --field-selector involvedObject.kind=Pod | grep -i attach
Bash
복사
타겟 유저: 스토리지 관리자, CSI driver 운영자, 클러스터 관리자
Faster SELinux labelling for volumes (Stable) • KEP-1710
요약: SELinux volume label 개선은 큰 볼륨을 사용하는 Pod의 시작 지연을 줄이는 기능입니다. 과거에는 volume 안의 파일을 재귀적으로 relabel해야 하는 경우가 있어, 파일 수가 많은 볼륨에서는 Pod 시작 시간이 길어질 수 있었습니다.
v1.36에서는 mount 시점의 SELinux context 적용을 활용하는 개선이 GA가 되었고, seLinuxChangePolicy와 CSI driver의 seLinuxMount 지원 여부가 중요한 판단 요소가 되었습니다. 이 기능은 성능 측면에서는 매력적이지만, 같은 볼륨을 서로 다른 SELinux label의 Pod가 공유하는 경우에는 충돌 가능성을 검토해야 합니다. 특히 privileged workload와 non-privileged workload가 같은 RWOP 볼륨을 공유하는 환경은 사전 테스트가 필요합니다.
운영자는 기능 적용 전 PodTemplate의 SELinux 설정과 CSIDriver 설정을 함께 감사해야 합니다.
어떻게 사용하나요?
Pod securityContext와 CSIDriver의 SELinux mount 지원 여부를 함께 점검합니다.
apiVersion: v1
kind: Pod
metadata:
name: selinux-volume-demo
spec:
securityContext:
seLinuxOptions:
level: s0:c123,c456
seLinuxChangePolicy: MountOption
containers:
- name: app
image: registry.k8s.io/e2e-test-images/agnhost:2.53
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
persistentVolumeClaim:
claimName: data-pvc
YAML
복사
타겟 유저: 보안 엔지니어, 스토리지 관리자, RHEL 계열 노드 운영자
플랫폼 & 리소스 관리
DRA AdminAccess & Prioritized Alternatives (Stable) • KEP-5018 / KEP-4816
요약: DRA는 GPU, accelerator, 네트워크 장치처럼 단순 CPU/메모리로 표현하기 어려운 리소스를 Kubernetes가 더 구조적으로 다룰 수 있게 하는 프레임워크입니다. v1.36에서는 AdminAccess와 Prioritized Alternatives가 Stable이 되면서 운영자와 스케줄러가 특수 장치를 더 유연하게 다룰 수 있게 되었습니다.
AdminAccess는 이미 사용 중인 장치에 대해 관리자 작업, 상태 점검, 유지보수 목적 접근을 가능하게 하는 흐름입니다. Prioritized Alternatives는 ResourceClaim이 단일 장치 조건에만 묶이지 않고, 우선순위가 있는 대안 목록을 표현할 수 있게 합니다. 이 기능들은 사용자가 독립적으로 쓰기보다 DRA driver, scheduler, controller가 함께 지원해야 효과가 있습니다. 따라서 실제 적용 전에는 driver 문서, ResourceClaim API 버전, RBAC 변경을 같이 확인해야 합니다.
어떻게 사용하나요?
DRA는 driver별 API 지원이 중요하므로, 먼저 ResourceClaim과 Pod 연결 상태를 점검합니다.
kubectl get resourceclaims -A
kubectl describe resourceclaim -n <namespace> <claim-name>
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.resourceClaims}{"\n"}{end}'
Bash
복사
타겟 유저: AI/ML 플랫폼 엔지니어, DRA driver 운영자, 클러스터 관리자
Resource health status (Beta) • KEP-4680
요약: Resource health status는 Pod에 할당된 장치 리소스의 상태를 Pod status에서 확인할 수 있게 하는 기능입니다. GPU나 특수 장치를 쓰는 workload에서 Pod가 실패했을 때, 원인이 애플리케이션인지 장치 장애인지 빠르게 구분하는 데 도움이 됩니다.
v1.31의 Device Plugin 중심 Alpha에서 시작했고, v1.36에서는 DRA까지 범위가 확장되며 Beta로 올라왔습니다. 상태는 사용자가 spec에 쓰는 값이 아니라 kubelet과 device/DRA driver가 보고하는 status입니다.
운영자는 kubectl describe pod 또는 kubectl get pod -o yaml로 allocatedResourcesStatus를 확인해 장애 대응에 활용할 수 있습니다. 이 기능은 장애 원인 분석, GPU drain, 장치 교체 자동화와 연결하기 좋습니다.
어떻게 사용하나요?
Pod status에서 할당 리소스의 health 정보를 확인합니다.
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A20 allocatedResourcesStatus
Bash
복사
예상되는 status 형태는 다음과 같습니다.
status:
containerStatuses:
- name: trainer
allocatedResourcesStatus:
- name: example.com/gpu
resources:
- resourceID: gpu-0
health: Healthy
YAML
복사
타겟 유저: AI/ML 플랫폼 엔지니어, SRE, 하드웨어 리소스 운영자
Memory QoS with cgroups v2 (Alpha) • KEP-2570
요약: Memory QoS는 cgroup v2 memory controller를 사용해 kubelet이 컨테이너 메모리를 더 정교하게 보호하고 제한하는 기능입니다. v1.36에서는 opt-in memory reservation, QoS class별 tiered protection, kubelet metrics, kernel version warning이 추가되었습니다.
memoryReservationPolicy: TieredReservation을 사용하면 Guaranteed Pod는 memory.min으로 hard protection을 받고, Burstable Pod는 memory.low로 soft protection을 받을 수 있습니다. 이 방식은 Burstable Pod의 요청량 전체를 hard reservation으로 잠가 노드 전체 OOM 위험을 키우는 문제를 줄입니다.
다만 MemoryQoS는 여전히 Alpha이므로 운영 클러스터 전체에 바로 적용하기보다는 특정 노드 풀에서 관찰 지표와 OOM 이벤트를 보며 실험해야 합니다. kernel 5.9 이상이 권장되며, cgroup v2 기반 노드에서만 의미가 있습니다.
어떻게 사용하나요?
kubelet configuration에서 feature gate와 reservation policy를 설정합니다.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
MemoryQoS: true
memoryReservationPolicy: TieredReservation
YAML
복사
적용 후 kubelet metrics에서 reservation 상태를 확인합니다.
curl -sk https://localhost:10250/metrics | grep memory_qos
Bash
복사
타겟 유저: 플랫폼 엔지니어, 노드 운영자, 성능 튜닝 담당자
In-place Vertical Scaling for Pod-level Resources (Beta) • KEP-2837
요약: v1.35에서 컨테이너 단위 In-place Pod Resize가 Stable로 올라간 뒤, v1.36에서는 Pod-level resource에 대한 in-place resize가 Beta로 확장되었습니다. Pod-level resources는 multi-container Pod가 하나의 공유 리소스 예산을 갖도록 설계된 기능입니다.
이 기능이 있으면 sidecar와 main container가 함께 있는 Pod에서 컨테이너별 요청을 세밀하게 조정하지 않고도 Pod 전체 CPU/메모리 예산을 변경할 수 있습니다. 예를 들어 VPA가 Pod 전체 메모리 예산을 늘리거나, batch 처리 구간에 CPU 예산을 일시적으로 늘리는 자동화를 만들 수 있습니다. 다만 runtime, kubelet, feature gate, resize 정책이 모두 맞아야 하고, 메모리를 낮출 때는 애플리케이션 OOM 위험을 고려해야 합니다.
v1.36에서는 Beta이자 기본 활성화이지만, production 적용 전 workload별 리사이즈 이벤트와 rollback 흐름을 확인해야 합니다.
어떻게 사용하나요?
Pod-level resource를 가진 Pod 예시입니다.
apiVersion: v1
kind: Pod
metadata:
name: shared-pool-app
spec:
resources:
requests:
cpu: "2"
memory: 2Gi
limits:
cpu: "4"
memory: 4Gi
containers:
- name: app
image: registry.k8s.io/e2e-test-images/agnhost:2.53
- name: sidecar
image: registry.k8s.io/e2e-test-images/agnhost:2.53
YAML
복사
실행 중 resize는 resize subresource로 요청합니다.
kubectl patch pod shared-pool-app --subresource resize --patch '{"spec":{"resources":{"requests":{"cpu":"3","memory":"3Gi"},"limits":{"cpu":"5","memory":"5Gi"}}}}'
Bash
복사
타겟 유저: 플랫폼 엔지니어, DevOps, VPA/리소스 자동화 담당자
컨트롤 플레인 & 관찰가능성
Mixed Version Proxy (Beta) • KEP-4020
요약: Mixed Version Proxy는 여러 kube-apiserver가 서로 다른 minor version으로 동작하는 업그레이드 구간에서 API 요청을 더 안전하게 처리하기 위한 기능입니다. 어떤 API server가 요청된 group/version/resource를 로컬에서 제공하지 못하면, peer discovery 정보를 기반으로 해당 리소스를 제공할 수 있는 다른 API server로 요청을 프록시할 수 있습니다. 이 기능은 HA control plane에서 단계적 업그레이드를 할 때 404나 version skew로 인한 실패를 줄이는 데 도움이 됩니다.
v1.36에서 Beta로 승격되고 기본 활성화되었지만, peer 간 통신을 위해 --peer-ca-file 등 인증 구성이 필요합니다. 운영자는 기능이 켜졌는지만 볼 것이 아니라 peer discovery sync 오류, rerouted request, proxy error 지표를 함께 봐야 합니다. 네트워크 정책이나 방화벽 때문에 API server 간 통신이 막힌 환경에서는 기대한 효과가 나지 않을 수 있습니다.
어떻게 사용하나요?
kube-apiserver peer 인증과 지표 확인 예시입니다.
kube-apiserver \
--peer-ca-file=/etc/kubernetes/pki/peer-ca.crt \
--proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt \
--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key \
--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
Bash
복사
kubectl get --raw /metrics | grep -E 'apiserver_rerouted_request_total|apiserver_peer_proxy_errors_total|apiserver_peer_discovery_sync_errors_total'
Bash
복사
타겟 유저: 클러스터 관리자, control plane 운영자, 업그레이드 담당자
PSI metrics based on cgroup v2 (Stable)
요약: kubelet의 PSI(Pressure Stall Information) metrics 노출이 GA가 되었습니다. CPU, Memory, I/O 사용량은 “얼마나 사용했는가”를 보여주지만, PSI는 “리소스 부족 때문에 얼마나 기다렸는가”를 보여줍니다. 이 지표는 노드가 사용률만 보면 괜찮아 보이지만 실제 애플리케이션 latency가 나빠지는 상황을 설명하는 데 유용합니다.
v1.36에서는 kubelet Summary API를 통해 system과 Pod 수준의 pressure metrics를 사용할 수 있습니다. OS와 kernel이 PSI를 지원하지 않으면 값이 의미 없거나 노출되지 않을 수 있으므로 노드 OS 조건도 확인해야 합니다. Memory QoS와 함께 보면 메모리 보호 정책이 실제 리소스 압박에 어떤 영향을 주는지 더 잘 이해할 수 있습니다.
어떻게 사용하나요?
kubelet summary API 또는 metrics 수집기를 통해 PSI 관련 값을 확인합니다.
kubectl get --raw /api/v1/nodes/<node-name>/proxy/stats/summary | grep -i psi
Bash
복사
노드에서 직접 확인할 때는 kernel PSI 파일도 함께 봅니다.
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io
Bash
복사
타겟 유저: SRE, 성능 튜닝 담당자, 플랫폼 엔지니어
Node log query (Stable) • KEP-2258
요약: Node log query는 노드 진단을 Kubernetes API 흐름 안으로 가져오는 기능입니다. 노드 장애 조사에서는 kubelet, container runtime, OS service 로그가 필요한 경우가 많지만, 모든 운영자에게 SSH 권한을 주는 것은 보안상 부담이 큽니다. 이 기능은 표준화된 API/RBAC 기반 접근을 통해 노드 로그 조회를 운영 자동화와 감사 체계 안에 넣는 방향을 제공합니다.
v1.36에서 Stable이 되었고, Windows와 Linux 노드 운영 모두에서 진단 흐름을 통일하는 데 도움이 됩니다. 다만 로그는 민감 정보를 포함할 수 있으므로 RBAC, 감사 로그, 보존 정책을 함께 설계해야 합니다. 실제 운영에서는 모든 사용자에게 열기보다 SRE 그룹 또는 break-glass 역할에 제한하는 것이 안전합니다.
어떻게 사용하나요?
노드 로그 조회 권한은 좁은 RBAC로 시작하고, 실제 조회는 운영 도구나 kubectl 지원 경로를 통해 수행합니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-log-reader
rules:
- apiGroups: [""]
resources: ["nodes/log"]
verbs: ["get"]
YAML
복사
kubectl auth can-i get nodes/log --as=system:serviceaccount:ops:node-log-reader
Bash
복사
타겟 유저: SRE, 클러스터 관리자, 운영 자동화 담당자
Alpha 기능
Workload Aware Scheduling / PodGroup scheduling cycle (Alpha) • KEP-4671 등
요약: Workload Aware Scheduling은 Pod를 개별 단위가 아니라 Workload와 PodGroup 단위로 다루는 스케줄링 방향입니다. AI/ML 학습, HPC, 대규모 batch job은 전체 Pod 집합이 함께 준비되어야 의미가 있는 경우가 많습니다. 일부 Pod만 먼저 배치되면 리소스가 잠긴 채 작업은 시작하지 못하고, 다른 작업의 스케줄링까지 방해할 수 있습니다.
v1.36에서는 PodGroup scheduling cycle, scheduling constraints, topology-aware placement, workload-aware preemption 같은 기능들이 Alpha로 확장되었습니다. 이 기능은 아직 실험 단계이므로 production 기본 스케줄러 정책으로 바로 적용하기보다는 별도 테스트 클러스터에서 queueing, preemption, autoscaler 영향까지 확인해야 합니다. 특히 custom scheduler plugin이나 batch platform과 결합할 때 API 버전 변경 가능성을 감수해야 합니다.
어떻게 사용하나요?
Alpha feature gate를 별도 테스트 클러스터에서 켜고 PodGroup/Workload API를 검증합니다.
kube-scheduler \
--feature-gates=WorkloadAwareScheduling=true,TopologyAwareWorkloadScheduling=true
Bash
복사
PodGroup/Workload 리소스는 v1.36 Alpha API와 scheduler 설정에 맞춰 실험 환경에서만 적용합니다.
타겟 유저: AI/ML 플랫폼 엔지니어, batch platform 운영자, scheduler 확장 개발자
HPA scale to zero for custom metrics (Alpha) • KEP-2021
요약: HPA scale to zero는 Object 또는 External metric 기반 workload가 replica 0까지 내려갈 수 있도록 하는 Alpha 기능입니다. 기존 HPA는 Pod가 있어야 CPU/Memory metric을 계산할 수 있기 때문에 최소 1 replica가 필요했습니다. 그러나 queue length, 외부 이벤트 수, 메시지 backlog 같은 metric은 Pod가 없어도 계산할 수 있습니다. 이 경우 유휴 시간에는 replica를 0으로 줄이고, metric이 다시 증가하면 workload를 재기동할 수 있습니다.
v1.36의 개선은 scale to zero와 zero에서 scale up되는 흐름을 더 다듬는 방향입니다. CPU/Memory metric 기반 workload에는 적합하지 않고, custom/external metrics adapter의 신뢰성이 핵심 전제입니다.
어떻게 사용하나요?
External metric 기반 HPA에서 minReplicas: 0을 사용합니다.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: queue-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 0
maxReplicas: 20
metrics:
- type: External
external:
metric:
name: queue_messages_ready
target:
type: AverageValue
averageValue: "10"
YAML
복사
타겟 유저: 플랫폼 엔지니어, 비용 최적화 담당자, autoscaling 운영자
Manifest based admission control config (Alpha) • KEP-5793
요약: Manifest based admission control config는 admission webhook과 CEL 기반 정책을 API 객체가 아니라 디스크의 static manifest에서 로드할 수 있게 하는 Alpha 기능입니다. 일반적으로 admission policy는 API 객체로 관리되지만, API 객체는 etcd 상태와 API 접근 권한에 영향을 받습니다.
이 기능은 API server 시작 시점부터 정책을 로드하고, etcd 장애 상황에서도 bootstrap-time 보호 정책을 유지할 수 있는 방향을 제공합니다. 특히 admission 정책 자체를 사용자가 삭제하거나 변경하지 못하게 해야 하는 고보안 환경에서 의미가 있습니다. 반대로 잘못된 manifest는 API server 시작이나 admission 흐름에 영향을 줄 수 있으므로, change management와 rollback 파일 경로를 명확히 두어야 합니다.
어떻게 사용하나요?
API server admission configuration에 static manifest directory를 지정하는 방식으로 접근합니다.
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
staticManifestsDir: /etc/kubernetes/admission-static
YAML
복사
kube-apiserver \
--feature-gates=ManifestBasedAdmissionControlConfig=true \
--admission-control-config-file=/etc/kubernetes/admission-config.yaml
Bash
복사
타겟 유저: 보안 엔지니어, 클러스터 관리자, 플랫폼 거버넌스 담당자
Native histogram support for Kubernetes metrics (Alpha)
요약: v1.36에서는 kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy, kubelet 등 여러 컴포넌트에서 Prometheus native histogram을 Alpha feature gate로 노출할 수 있게 되었습니다. 기존 classic histogram은 미리 정의한 bucket에 관측값을 넣기 때문에 bucket 설계가 맞지 않으면 해상도와 비용 사이에서 타협해야 합니다. native histogram은 sparse bucket 표현을 사용해 더 유연한 latency 관찰을 가능하게 합니다.
이 기능은 특히 API server latency, scheduler latency, controller workqueue latency처럼 분포가 중요한 지표에 유용합니다. 다만 Prometheus 서버, remote write, 장기 저장소, 대시보드가 native histogram을 제대로 처리할 수 있어야 의미가 있습니다. 운영 적용 전에는 동일 지표가 classic/native 양쪽으로 어떻게 노출되는지 확인하고 저장 비용을 점검해야 합니다.
어떻게 사용하나요?
컴포넌트별 feature gate를 켜고 metrics endpoint에서 native histogram 관련 지표를 확인합니다.
kube-apiserver \
--feature-gates=ComponentSLIs=true,PrometheusNativeHistograms=true
Bash
복사
kubectl get --raw /metrics | grep -E 'native|histogram|apiserver_request_duration_seconds'
Bash
복사
타겟 유저: SRE, 관찰가능성 플랫폼 운영자, 성능 분석 담당자
DRA list-type attributes (Alpha) • KEP-5491
요약: DRA list-type attributes는 ResourceSlice의 device attribute가 단일 값뿐 아니라 list 값을 가질 수 있도록 확장하는 기능입니다. 특수 장치는 모델, capability, topology, supported version처럼 여러 속성을 동시에 가질 수 있는데, scalar attribute만으로는 이런 정보를 표현하기 어렵습니다.
이 기능은 bools, ints, strings, versions 같은 list-type field와 CEL .includes() 함수를 통해 ResourceClaim 제약을 더 유연하게 만들 수 있습니다. 또한 matchAttribute, distinctAttribute 제약이 scalar와 list 모두에서 동작하도록 확장됩니다. driver가 attribute 표현을 scalar에서 list로 바꾸는 마이그레이션에도 도움이 됩니다. 다만 feature gate가 기본 비활성화이고, device attribute 수 제한과 scheduler 동작을 driver 구현과 함께 검증해야 합니다.
어떻게 사용하나요?
DRA driver가 ResourceSlice에 list-type attribute를 게시하고, ResourceClaim에서 CEL selector로 사용합니다.
apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaim
metadata:
name: gpu-with-codecs
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
selectors:
- cel:
expression: 'device.attributes["gpu.example.com"].codecs.includes("h264")'
YAML
복사
타겟 유저: DRA driver 개발자, AI/ML 플랫폼 엔지니어, 특수 하드웨어 운영자
운영 관점에서의 변화
보안 운영
•
nodes/proxy는 관찰가능성 도구에 흔히 부여되던 권한이지만, v1.36 이후에는 세분화된 kubelet subresource로 줄이는 것이 더 안전합니다.
•
User Namespaces는 Pod 보안의 강한 방어 계층이지만, runtime과 volume 호환성 때문에 먼저 노드 풀 단위 검증이 필요합니다.
•
MutatingAdmissionPolicies와 Manifest based admission control config는 정책 운영을 API 서버 쪽으로 끌어오지만, 잘못된 정책이 admission 흐름을 막을 수 있으므로 rollback 절차가 중요합니다.
•
External ServiceAccount Token Signer는 키 보관 위치를 바꾸는 기능이므로, signer socket 보안과 HA 구성을 함께 설계해야 합니다.
스토리지 운영
•
gitRepo volume plugin은 v1.36에서 더 이상 되살릴 수 없으므로, 남아 있는 manifest는 initContainer나 git-sync로 바꿔야 합니다.
•
VolumeGroupSnapshot은 여러 PVC를 가진 Stateful workload의 복구 전략을 개선할 수 있지만, CSI driver의 group snapshot 지원이 전제입니다.
•
SELinux volume label 개선은 Pod 시작 시간을 줄일 수 있지만, 공유 볼륨과 서로 다른 SELinux label 조합은 반드시 사전 테스트해야 합니다.
•
Mutable CSINode allocatable은 사용자가 직접 API를 고치는 기능이 아니라, CSI driver가 최신 attach limit을 반영하는지 확인하는 운영 기능입니다.
AI/ML & 특수 하드웨어 운영
•
DRA는 v1.36에서 Stable, Beta, Alpha 기능이 동시에 늘었으므로 driver 버전, ResourceClaim API, scheduler 동작, RBAC를 한꺼번에 검증해야 합니다.
•
Resource health status는 GPU 장애 진단을 Pod status로 끌어오는 기능이므로, 장애 대응 runbook에 allocatedResourcesStatus 확인 단계를 추가할 수 있습니다.
•
Workload Aware Scheduling은 AI/ML과 batch workload에 매력적이지만 Alpha이므로, production scheduler 기본 정책으로 쓰기 전 별도 클러스터 검증이 필요합니다.
•
DRA list-type attributes는 driver 개발자에게 유용하지만, 일반 애플리케이션 개발자가 직접 바로 쓰기보다는 driver 생태계 성숙이 먼저입니다.
관찰가능성 & 성능
•
PSI metric GA와 Memory QoS Alpha는 노드 리소스 압박을 더 구체적으로 설명할 수 있게 합니다.
•
native histogram Alpha는 latency 분포 분석 품질을 높일 수 있지만, Prometheus와 장기 저장소 호환성이 먼저입니다.
•
metric rename 항목은 업그레이드 당일 alert 누락을 만들 수 있으므로 사전 점검 목록에 넣어야 합니다.
•
Mixed Version Proxy Beta는 HA control plane 업그레이드 안정성에 도움이 되지만, peer 인증과 지표 모니터링이 함께 준비되어야 합니다.
알려진 주요 이슈 / 주의사항
이슈 | 영향도 | 확인 방법 | 대응 |
externalIPs 사용 Service | High | kubectl get svc -A -o jsonpath='{range .items[?(@.spec.externalIPs)]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.externalIPs}{"\n"}{end}' | LoadBalancer, NodePort, Gateway API 등으로 이전 계획 수립 |
gitRepo volume 사용 Pod | High | manifest에서 volumes[].gitRepo 검색 | initContainer 또는 git-sync 방식으로 변경 |
DRA RBAC 부족 | High | DRA driver/controller 로그와 ResourceClaim status update 실패 확인 | v1.36 CHANGELOG의 subresource 권한 기준으로 ClusterRole 갱신 |
flex-volume 의존 kubeadm 클러스터 | Medium | KCM static pod, kubeadm config, flex-volume plugin dir 확인 | CSI 이전 또는 custom KCM image/extraVolumes 직접 구성 |
metric rename에 따른 alert 누락 | Medium | Prometheus rule, Grafana dashboard에서 이전 metric 검색 | 새 metric 이름으로 수정 후 업그레이드 |
SELinux mount 최적화와 공유 볼륨 충돌 | Medium | SELinux enforcing 노드에서 공유 볼륨 workload 테스트 | seLinuxChangePolicy와 CSIDriver seLinuxMount 정책 검토 |
추가 학습 자료
맺음말
Kubernetes v1.36 Haru 릴리즈는 클러스터 운영의 기본기를 더 세밀하게 다듬고, 보안·스토리지·특수 리소스 관리 영역을 한 단계 성숙시키는 릴리즈입니다. 이번 업데이트에서 특히 주목할 만한 효과는 다음과 같습니다.
•
보안 경계와 권한 관리의 정교화: 기존에 넓게 부여되던 nodes/proxy 권한을 줄이고, Pod 내부 root와 호스트 root의 경계를 분리할 수 있다는 점은 보안 감사와 multi-tenant 운영에서 실질적인 개선입니다.
•
상태 저장 워크로드와 스토리지 운영 안정성 강화: VolumeGroupSnapshot은 여러 PVC를 하나의 복구 지점으로 묶어 상태 저장 애플리케이션의 백업/복구 전략을 개선합니다.
•
AI/ML 및 특수 하드웨어 플랫폼을 위한 기반 확장: GPU·accelerator·특수 장치 운영을 Kubernetes API 안에서 더 구조적으로 다룰 수 있게 합니다. 아직 실험 단계지만, 대규모 batch, AI/ML 학습, 비용 최적화 워크로드가 앞으로 어떤 방향으로 발전할지 보여주는 중요한 신호입니다.
정리하면, Kubernetes v1.36은 즉시 모든 기능을 켜야 하는 릴리즈라기보다 “권한을 줄일 수 있는 영역”, “스토리지/리소스 운영을 안정화할 수 있는 영역”, “다음 세대 워크로드를 실험할 영역”을 구분해 점진적으로 적용해야 하는 릴리즈입니다. 운영팀은 이 문서를 업그레이드 체크리스트로 활용해 위험 항목을 먼저 제거하고, Stable 기능부터 단계적으로 검증하는 접근을 권장합니다.
이현승 프로
클라우드와 오픈소스 SW 관련 연구 개발 프로젝트들을 진행해왔고, 지금은 OSS 기술서비스와 아키텍처를 담당하고 있어요 


