릴리즈 정보
•
릴리즈 버전: v1.37.0
•
릴리즈 일자: 2026년 8월 26일
•
릴리즈 이름: Garhwal
•
릴리즈 주기: 정규(Minor) 릴리즈
•
Maintenance Mode 시작: 2027년 8월 28일
•
지원 종료(EOL): 2027년 10월 28일
•
포함된 개선사항: 총 67개 — Stable 16개, Beta 23개, Alpha 27개, Deprecation/Removal 1개
한눈에 보기
Kubernetes v1.37은 API 서버와 저장 계층의 안정성을 높이는 한편, 오토스케일링과 메모리 관리, AI/ML 워크로드 스케줄링 기능을 실제 운영에 한 걸음 더 가깝게 만든 릴리즈입니다.
StorageVersionMigration API와 KYAML 출력, metrics.k8s.io/v1, Node declared features, Pod Certificates가 Stable 단계에 도달했습니다. HPA(HorizontalPodAutoscaler)의 scale to zero와 MemoryQoS, Workload-Aware Scheduling은 Beta로 승격됐습니다.
새 기능만큼 업그레이드 영향도 중요합니다. SELinux 볼륨 처리 방식이 기본 동작으로 바뀌었고, scheduling.k8s.io/v1alpha2 API가 제거됐습니다. kubelet의 eventRecordQPS: 0은 이제 이벤트 전송량을 제한하지 않는다는 뜻으로 처리됩니다.
주요 변화 요약•
KYAML 출력(Stable): YAML의 모호한 표현을 줄인 Kubernetes용 출력 형식을 kubectl -o kyaml로 사용할 수 있습니다.
•
Resource Metrics API v1(Stable): kubectl top과 HPA가 사용하는 CPU·메모리 메트릭 API가 정식 버전으로 승격됐습니다.
•
Storage Version Migrator(Stable): etcd에 남은 이전 저장 버전의 오브젝트를 현재 저장 버전으로 다시 기록할 수 있습니다.
•
Node declared features(Stable): 버전이 다른 노드가 함께 있는 업그레이드 구간에서, 각 노드가 사용할 수 있는 신규 기능을 스케줄러와 어드미션 계층에 알립니다.
•
HPA scale to zero·MemoryQoS(Beta): 유휴 워크로드를 파드 0개까지 줄이고, cgroup v2의 메모리 보호·스로틀링 기능을 더 정교하게 활용할 수 있습니다.
•
Gang Scheduling·Workload-aware preemption(Beta): 여러 파드가 함께 실행돼야 하는 AI/ML·고성능 컴퓨팅(HPC) 작업을 그룹 단위로 배치하고 선점하는 기반이 마련됐습니다.
•
DRA 기능 성숙: GPU·네트워크 디바이스의 상태, 네트워크 정보, NUMA 위치, 테인트와 톨러레이션을 다루는 기능들이 Stable로 승격됐습니다.
즉시 확인 필요 사항
변경사항 | 영향 범위 | 대응 방법 | 긴급도 |
SELinuxMount Stable 승격·기본 활성화 | SELinux 노드, CSI 공유 볼륨 | CSIDriver.spec.seLinuxMount 지원과 서로 다른 SELinux 레이블을 쓰는 공유 볼륨을 시험합니다. 문제가 있는 워크로드는 seLinuxChangePolicy: Recursive 적용을 검토합니다. | High |
Workload-Aware Scheduling API 변경 | Gang Scheduling, 사용자 정의 스케줄러·컨트롤러 | scheduling.k8s.io/v1alpha2 오브젝트를 찾아 제거하거나 v1alpha3로 변환합니다. | High |
eventRecordQPS: 0 의미 변경 | kubelet, API 서버, 이벤트 수집 | 기존 동작을 유지하려면 50처럼 0이 아닌 값을 명시하고 이벤트 전송량을 관찰합니다. | High |
cAdvisor 플래그·메트릭 정리 | kubelet, Prometheus, 대시보드·알림 | 제거된 플래그와 container_application_*, container_cpu_load_average_10s 등의 메트릭 참조를 확인합니다. | High |
스태틱 파드의 API 오브젝트 참조 제한 고정 | 컨트롤 플레인·스태틱 파드 | Secret·ConfigMap 의존 구성을 파일 기반 설정이나 일반 파드·DaemonSet 구조로 바꿉니다. | High |
cgroup v1 지원 종료 준비 | 구형 Linux 노드 | 모든 노드를 cgroup v2로 전환하고 컨테이너 런타임과 모니터링 도구의 호환성을 확인합니다. | High |
kube-dns·kube-proxy IPVS 사용 중단 계획 | DNS·서비스 네트워크 | CoreDNS와 nftables 모드로 이전할 계획을 세우고 성능과 네트워크 정책을 검증합니다. | Medium |
kubectl run -f/--filename 사용 중단 예정 | 배포 스크립트·운영 절차 | 파일로 리소스를 생성할 때는 kubectl create -f 또는 kubectl apply -f를 사용합니다. | Medium |
eventRecordQPS는 애플리케이션 로그가 아니라 kubelet이 파드 시작 실패, 이미지 가져오기 실패, 볼륨 마운트 문제 등을 Kubernetes 이벤트로 기록하는 초당 최대 건수입니다. v1.37에서 0은 제한 없음이므로, 반복 오류가 발생하면 API 서버로 이벤트가 급증할 수 있습니다.
주요 추가 기능 & 개선사항
애플리케이션 개발 및 운영
KYAML 출력(Stable) • KEP-5295
요약: YAML은 따옴표와 들여쓰기 방식에 따라 문자열이 다른 자료형으로 해석될 수 있습니다. KYAML은 이런 모호한 표현을 제한한 Kubernetes용 YAML 하위 형식입니다.
왜 중요한가요?
•
가독성과 예측 가능성: 사람이 읽은 값과 파서가 해석한 값이 달라지는 문제를 줄입니다.
•
기존 도구와의 호환성: 모든 KYAML은 유효한 YAML이므로 기존 YAML 파서에서도 처리할 수 있습니다.
•
주의 사항: 출력 문자열에 의존하는 스크립트는 일반 YAML과의 차이를 먼저 비교해야 합니다.
어떻게 사용하나요?
kubectl get deployment my-app -o kyaml
Bash
복사
타겟 유저: 애플리케이션 개발자, 플랫폼 엔지니어, GitOps 운영자
Resource Metrics API v1(Stable) • KEP-5207
요약: metrics.k8s.io는 노드와 파드의 CPU·메모리 사용량을 제공하며 kubectl top과 HPA가 사용하는 표준 API입니다. v1.37에서 metrics.k8s.io/v1이 Stable로 승격됐습니다.
왜 중요한가요?
•
안정된 API 계약: 메트릭 소비자가 정식 API 버전을 기준으로 통합할 수 있습니다.
•
전환 기간 제공: 기존 v1beta1도 당분간 계속 사용할 수 있습니다.
•
구현체 확인 필요: API 정의가 Stable이 됐다고 metrics-server나 벤더 어댑터가 곧바로 v1을 제공하는 것은 아닙니다.
타겟 유저: 플랫폼 엔지니어, SRE, 오토스케일링·모니터링 운영자
컨트롤 플레인 & 저장 데이터
Resilient watch cache initialization(Stable) • KEP-4568
요약: kube-apiserver의 watch 캐시는 API 조회와 변경 알림을 빠르게 처리하기 위해 etcd 오브젝트의 사본을 메모리에 유지합니다. API 서버 시작·복구 중 캐시 초기화와 대량 요청이 겹쳐 etcd와 API 처리 용량을 소진하는 문제를 줄이는 기능입니다.
왜 중요한가요?
•
복구 안정성: 처리 가능한 요청만 실행하고 나머지는 HTTP 429 Too Many Requests로 돌려 API 서버가 과부하에 빠지는 것을 방지합니다.
•
클라이언트 동작: 직접 만든 컨트롤러와 API 클라이언트는 Retry-After를 따르고 실패가 이어질수록 대기 시간을 늘리는 지수 백오프를 적용해야 합니다.
•
대규모 클러스터 효과: 시작과 장애 복구 구간에서 일시적인 429를 실패가 아닌 정상적인 재시도 신호로 다뤄야 합니다.
타겟 유저: 대규모 클러스터 운영자, 컨트롤러 개발자, SRE
Storage Version Migrator(Stable) • KEP-4192
요약: Kubernetes API 버전을 올려도 etcd에 이미 저장된 오브젝트는 자동으로 새 저장 버전으로 다시 기록되지 않습니다. v1.37에서는 컨트롤 플레인에 내장된 마이그레이터가 지정한 리소스를 현재 저장 버전으로 다시 기록할 수 있습니다.
왜 중요한가요?
•
API 업그레이드 정리: 더 이상 제공하지 않는 이전 저장 버전을 체계적으로 제거할 수 있습니다.
•
암호화 키 교체 지원: 저장 데이터 암호화 설정을 바꾼 뒤 기존 데이터를 새 설정으로 다시 기록할 수 있습니다.
•
운영 주의: 실행 전 etcd 백업, 대상 오브젝트 수, API 서버와 etcd의 부하를 확인해야 합니다.
어떻게 사용하나요?
apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
name: migrate-deployments
spec:
resource:
group: apps
resource: deployments
YAML
복사
타겟 유저: 클러스터 관리자, 컨트롤 플레인 운영자, 보안 엔지니어
노드·보안·워크로드 인증
SELinux volume handling(Stable) • KEP-1710
요약: CSIDriver.spec.seLinuxMount: true인 CSI 볼륨은 파일 전체를 재귀적으로 다시 레이블링하지 않고, 마운트 옵션으로 SELinux 컨텍스트를 적용할 수 있습니다. 큰 볼륨의 파드 시작 시간을 줄일 수 있지만 공유 방식에 따라 호환성 문제가 생길 수 있습니다.
왜 중요한가요?
•
시작 시간 단축: 파일 수가 많은 볼륨에서 재귀적 레이블 변경 비용을 줄입니다.
•
공유 볼륨 주의: 한 마운트에는 SELinux 컨텍스트 하나만 적용할 수 있으므로, 같은 노드에서 서로 다른 레이블의 파드가 볼륨을 공유하면 시작에 실패할 수 있습니다.
•
드라이버별 검증: Stable 기능이라도 CSI 드라이버가 관련 동작을 지원하는지 실제 워크로드로 확인해야 합니다.
타겟 유저: 보안 엔지니어, 스토리지 관리자, RHEL 계열 클러스터 운영자
Node declared features(Stable) • KEP-5328
요약: 롤링 업그레이드 중에는 서로 다른 버전의 kubelet이 함께 실행됩니다. Node declared features는 각 노드가 현재 사용할 수 있는 신규 기능을 .status.declaredFeatures에 기록해, 호환되지 않는 노드에 파드가 배치되는 문제를 줄입니다.
왜 중요한가요?
•
안전한 버전 혼용: 스케줄러와 어드미션 컨트롤러가 필요한 기능이 없는 노드로 파드를 보내지 않도록 판단할 수 있습니다.
•
수동 레이블 감소: 운영자가 기능 차이를 표현하기 위해 노드 레이블과 테인트를 별도로 관리하던 부담을 줄입니다.
•
오해하기 쉬운 점: GPU 종류나 CPU 아키텍처 같은 영구 하드웨어 목록이 아닙니다. 기능의 Alpha→Beta→Stable 전환기에만 사용하므로 배열이 비어 있어도 정상일 수 있습니다.
확인 방법
kubectl get node <node-name> -o jsonpath='{.status.declaredFeatures}'
Bash
복사
타겟 유저: 클러스터 관리자, 스케줄러·어드미션 개발자, 플랫폼 엔지니어
Pod Certificates와 ClusterTrustBundle(Stable) • KEP-4317, KEP-3257
요약: 파드가 통신 양쪽의 신원을 확인하는 상호 TLS(mTLS)를 사용할 수 있도록, kubelet이 개인 키와 인증서 요청을 관리하고 인증서와 신뢰 번들을 파드 수명에 맞춰 제공합니다.
왜 중요한가요?
•
장기 Secret 감소: 인증서를 장기간 Secret에 넣어 배포하는 대신 파드 수명에 맞춘 인증서 전달 경로를 사용할 수 있습니다.
•
자동 갱신 기반: kubelet이 PodCertificateRequest를 만들고 발급된 인증서를 프로젝티드 볼륨으로 제공합니다.
•
서명자 필요: Kubernetes가 인증서를 자동으로 서명하지는 않습니다. signerName을 처리하는 서명자 컨트롤러가 별도로 필요합니다.
타겟 유저: 보안 엔지니어, 서비스 메시·워크로드 ID 운영자, 플랫폼 엔지니어
오토스케일링 & 메모리 관리
HPA scale to zero(Beta) • KEP-2021
요약: 외부 메트릭이나 오브젝트 메트릭을 사용하면 HPA의 minReplicas를 0으로 지정할 수 있습니다. 요청이 없는 큐 소비자, 배치 작업, GPU 서비스를 완전히 줄였다가 수요가 생기면 다시 늘릴 수 있습니다.
왜 중요한가요?
•
유휴 비용 절감: 사용하지 않는 워크로드의 파드를 0개까지 줄일 수 있습니다.
•
메트릭 경로가 핵심: CPU·메모리 메트릭은 실행 중인 파드가 있어야 하므로 scale to zero에 사용할 수 없습니다. 파드가 없어도 관찰 가능한 큐 길이 같은 외부 메트릭이 필요합니다.
•
운영 주의: 외부 메트릭 공급이 중단되면 HPA가 확장 시점을 알 수 없으므로 메트릭 경로를 별도로 모니터링해야 합니다.
타겟 유저: 플랫폼 엔지니어, 비용 최적화 담당자, 배치·이벤트 기반 워크로드 운영자
MemoryQoS(Beta) • KEP-2570
요약: MemoryQoS는 Linux cgroup v2의 memory.min, memory.low, memory.high를 이용해 메모리 요청량을 보호하고, 최종 한도에 닿기 전에 사용량 증가를 늦출 수 있게 합니다.
왜 중요한가요?
•
중요 워크로드 보호: TieredReservation을 사용하면 Guaranteed 파드는 memory.min, Burstable 파드는 memory.low를 이용해 요청량을 우선 보호할 수 있습니다.
•
조기 압력 적용: memoryThrottlingFactor로 memory.max에 도달하기 전 memory.high에서 회수 압력을 높일 수 있습니다.
•
기본 활성화의 의미: 기능 게이트는 기본으로 켜지지만 memoryReservationPolicy 기본값은 None이고 memoryThrottlingFactor도 미설정입니다. 업그레이드만으로 새 보호 정책이 자동 적용되지는 않습니다.
타겟 유저: 노드 운영자, 성능 엔지니어, 메모리 집약 워크로드 운영자
AI/ML·HPC 스케줄링
기본 스케줄러는 파드를 하나씩 판단합니다. 여러 파드가 모두 실행돼야 진행되는 분산 학습, 다중 호스트 추론, MPI 작업은 일부 파드만 배치되면 GPU와 네트워크 자원을 점유한 채 대기할 수 있습니다. v1.37의 Workload-Aware Scheduling은 Workload와 PodGroup API를 바탕으로 이런 작업을 그룹 단위로 다룰 수 있게 합니다.
Gang Scheduling(Beta) • KEP-4671
요약: PodGroup에 속한 파드가 최소 수(minCount)만큼 함께 배치될 수 있을 때만 스케줄링을 완료합니다. 제한 시간 안에 그룹 전체를 배치하지 못하면 예약한 리소스를 풀어 다른 워크로드가 사용할 수 있게 합니다.
왜 중요한가요?
•
All-or-Nothing 배치: 작업이 진행되지 못하는데 일부 파드만 GPU를 점유하는 상황을 줄입니다.
•
분산 작업 효율: 학습·추론·MPI처럼 파드가 함께 움직여야 하는 작업의 대기와 자원 낭비를 줄입니다.
•
기능 경계: 큐 간 공정성이나 Cluster Autoscaler 연동까지 모두 해결하지는 않습니다. Kueue나 Volcano와 함께 사용할 때 각 구성 요소의 역할을 구분해야 합니다.
타겟 유저: AI/ML 플랫폼 엔지니어, HPC 운영자, 배치 스케줄러 개발자
Workload-aware preemption(Beta) • KEP-5710
요약: 높은 우선순위 작업을 배치하기 위해 낮은 우선순위 파드를 내보내는 선점을 파드 하나가 아니라 워크로드 그룹 관점에서 판단합니다.
왜 중요한가요?
•
그룹 전체의 진행 가능성 고려: 낮은 우선순위 분산 작업에서 파드 하나만 내보내 나머지 파드까지 멈추는 상황을 줄입니다.
•
불필요한 선점 감소: 높은 우선순위 그룹 전체가 실행될 만큼의 공간을 만들지 못하는 선점을 피합니다.
•
초기 Beta의 한계: 복잡한 토폴로지와 재스케줄링 정책까지 최적화된 완성형 알고리즘은 아니므로 실제 워크로드로 검증해야 합니다.
타겟 유저: 스케줄러 개발자, AI/ML·HPC 플랫폼 운영자
DRA 관련 Stable 기능
동적 리소스 할당(Dynamic Resource Allocation, DRA)은 GPU나 네트워크 인터페이스 같은 특수 디바이스를 ResourceClaim으로 요청하고, 조건에 맞는 디바이스를 동적으로 선택·준비하는 체계입니다.
•
확장 리소스와 DRA 연계 • KEP-5004: 기존 확장 리소스 요청을 DRA 드라이버가 처리할 수 있어 점진적으로 전환할 수 있습니다.
•
파드 상태의 디바이스 상태 보고 • KEP-4680: 할당된 GPU·가속기의 정상 여부를 파드 상태에서 확인할 수 있습니다.
•
ResourceClaim 상태 정보 • KEP-4817: ResourceClaim.status.devices를 통해 디바이스별 상태와 네트워크 인터페이스 정보를 워크로드에 전달합니다.
•
디바이스 테인트와 톨러레이션 • KEP-5055: 고장이나 점검 중인 디바이스만 선택 대상에서 제외해 노드 전체를 차단하지 않고 제어합니다.
•
표준 NUMA 속성 • KEP-6072: CPU·메모리·GPU의 물리적 거리를 고려할 수 있도록 드라이버 간 공통 위치 정보를 제공합니다.
타겟 유저: GPU·가속기 플랫폼 운영자, 디바이스 드라이버 개발자, AI/ML 인프라 엔지니어
그 밖에 살펴볼 Beta·Alpha 기능
Beta
•
Native Histogram • KEP-5808: 요청 지연 같은 값의 분포를 동적 버킷으로 기록해 정확도와 시계열 저장 비용의 균형을 개선합니다. Prometheus와 저장소의 지원 여부를 확인해야 합니다.
•
PVC 미사용 시작 시각 • KEP-5541: 마지막 파드가 영구 스토리지 요청인 PVC 사용을 끝낸 시점을 Unused 조건으로 남겨 방치된 스토리지 후보를 찾기 쉽게 합니다. 자동 삭제 기능은 아닙니다.
•
CSI 볼륨 한도와 Cluster Autoscaler • KEP-5030: 새 노드의 볼륨 연결 한도를 확장 시뮬레이션에 반영해 노드를 늘리고도 파드가 계속 대기하는 상황을 줄입니다.
•
Manifest-based admission control • KEP-5793: 핵심 웹훅과 CEL 정책을 디스크에서 읽어 API 서버 시작 시점이나 etcd 장애 중에도 적용할 수 있습니다.
•
etcd RangeStream • KEP-5966: 대량 목록 응답을 청크 단위로 전달해 API 서버와 etcd의 메모리 급증을 줄입니다. etcd 3.7 이상에서 사용합니다.
Alpha
•
StatefulSet Recreate strategy • KEP-3541: 이전 버전과 새 버전을 함께 실행할 수 없는 애플리케이션을 위해 기존 파드를 모두 삭제한 뒤 새 파드를 생성합니다.
•
In-place resize 선점 • KEP-5836: 실행 중인 파드의 증설이 자원 부족으로 지연될 때 낮은 우선순위 파드를 선점해 같은 노드에서 증설할 수 있게 합니다.
•
메모리 기반 볼륨 동적 크기 조정 • KEP-6030: 파드를 재시작하지 않고 emptyDir의 sizeLimit과 tmpfs 크기를 조정합니다.
•
Pod checkpoint/restore • KEP-5823: 컨테이너 런타임 인터페이스에 파드 실행 상태 저장·복원 호출을 추가합니다.
•
DRA 디바이스 호환 그룹 • KEP-5963: MIG와 vGPU처럼 같은 물리 디바이스에서 함께 쓸 수 없는 구성을 스케줄링 단계에서 피하도록 합니다.
운영 관점에서의 변화
업그레이드·노드 운영
•
SELinux를 사용하는 클러스터는 공유 볼륨과 레이블 조합을 업그레이드 전에 시험해야 합니다.
•
eventRecordQPS: 0이 설정된 노드는 의도적으로 무제한을 사용하려는 것인지 확인해야 합니다.
•
cgroup v1 노드, 제거된 cAdvisor 플래그와 메트릭, nodes/logs RBAC를 함께 점검해야 합니다.
애플리케이션·플랫폼 운영
•
KYAML은 새 출력 선택지이며 기존 매니페스트를 모두 바꿔야 하는 기능은 아닙니다.
•
Metrics API v1은 API의 안정화를 뜻합니다. 실제 메트릭 공급자가 v1을 제공하는지는 별도 확인이 필요합니다.
•
HPA scale to zero는 외부 메트릭 가용성이 곧 확장 경로의 가용성이므로 메트릭 장애를 별도로 감시해야 합니다.
대규모 클러스터 운영
•
API 서버 시작·복구 중 발생하는 HTTP 429를 클라이언트가 올바르게 재시도하는지 확인해야 합니다.
•
Storage Version Migration은 etcd 백업과 부하 관찰을 전제로 작은 리소스 종류부터 적용하는 것이 안전합니다.
•
etcd RangeStream은 대규모 LIST의 메모리 사용량을 줄이지만 etcd 3.7 호환성 확인이 먼저입니다.
AI/ML·특수 하드웨어 운영
•
Workload-Aware Scheduling은 Workload·PodGroup API를 지원하는 스케줄러와 컨트롤러 조합이 필요합니다.
•
DRA Stable 기능은 Kubernetes API의 성숙도를 뜻하며 GPU·가속기 드라이버가 해당 API와 서비스를 구현했는지는 별도 확인해야 합니다.
•
Gang Scheduling과 Workload-aware preemption은 실제 큐 정책, 토폴로지, 재시도 동작을 격리된 환경에서 먼저 검증해야 합니다.
맺음말
Kubernetes v1.37 ‘Garhwal’은 클러스터 운영의 안정성을 높이고, 워크로드 특성에 맞춰 자원을 더 세밀하게 관리하도록 개선한 릴리즈입니다. 운영자에게는 장애 복구와 자원 관리의 부담을 줄이고, 개발자에게는 설정과 메트릭을 다루는 기반을 정돈했다는 의미가 있습니다.
특히 주목할 변화는 다음과 같습니다.
•
API 서버 복구와 저장 데이터 관리 개선: API 서버가 시작되거나 복구되는 동안 요청이 몰려 과부하에 빠지는 문제를 줄였습니다. Stable로 승격된 Storage Version Migrator는 기존 오브젝트를 현재 저장 버전으로 다시 기록해, API 버전 전환과 저장 데이터 암호화 키 교체에 활용할 수 있습니다.
•
유휴 자원 절감과 메모리 관리 강화: Beta로 승격된 HPA scale to zero는 큐 길이 같은 외부 지표를 바탕으로 일이 없을 때 파드를 0개로 줄이고, 수요가 생기면 다시 늘립니다. 함께 Beta로 승격된 MemoryQoS는 워크로드에 필요한 메모리를 보호하고 사용량 증가를 조절할 수 있게 합니다.
•
여러 파드와 GPU를 사용하는 작업의 배치 개선: Gang Scheduling과 워크로드 단위 선점이 Beta로 진전하면서, 함께 실행돼야 하는 파드들을 작업 단위로 배치하고 자리를 확보할 수 있게 됐습니다. GPU 같은 특수 장치를 할당하는 DRA 기능도 성숙해, 분산 학습이나 추론 작업에서 일부 파드만 자원을 점유한 채 대기하는 문제를 줄일 기반이 넓어졌습니다.
•
설정과 메트릭을 다루는 방식의 안정화: Stable로 승격된 KYAML은 문자열이 다른 자료형으로 해석되는 등 YAML의 모호함을 줄인 출력 형식입니다. CPU·메모리 사용량을 제공하는 Metrics API도 v1으로 안정화돼, 개발자는 메트릭을 사용하는 도구를 정식 API 버전에 맞춰 구성할 수 있습니다.
이러한 개선은 현재 워크로드의 비효율을 줄이는 데 활용할 수 있습니다. 유휴 시간이 긴 서비스는 파드 수와 재확장 시간을, 메모리 사용량이 큰 애플리케이션은 메모리 압박과 응답 지연을 비교해 보면 좋겠습니다. 분산 작업은 배치 대기 시간과 GPU 활용률을 살펴보면 개선 효과를 파악하는 데 도움이 됩니다.
이번 릴리즈에서는 대규모 클러스터의 안정성과 작업 특성에 맞는 자원 배분에 집중하는 흐름이 보입니다. 앞으로도 AI/ML과 분산 작업의 요구를 반영하면서 운영 안정성과 자원 효율을 함께 높이는 방향으로 발전할 것으로 보입니다.
관련 자료
이번 릴리즈 주요 KEP
Stable — 프로덕션 도입 검토 대상
•
KEP-1710: SELinux volume handling
•
KEP-5295: KYAML 출력
•
KEP-5207: Resource Metrics API v1
•
KEP-4192: Storage Version Migrator
•
KEP-5328: Node declared features
•
KEP-4317: Pod Certificates
Beta — 운영 환경 사전 검증 대상
•
KEP-2021: HPA scale to zero
•
KEP-2570: MemoryQoS
•
KEP-4671: Gang Scheduling
•
KEP-5710: Workload-aware preemption
•
KEP-5729: DRA ResourceClaim support for workloads
•
KEP-5966: etcd RangeStream
Alpha — 격리 환경 실험 대상
•
KEP-3541: StatefulSet Recreate strategy
•
KEP-5836: In-place Pod resize를 위한 선점
•
KEP-6030: 메모리 기반 볼륨 동적 크기 조정
•
KEP-5823: Pod checkpoint/restore
이현승 프로
클라우드와 오픈소스 SW 관련 연구 개발 프로젝트들을 진행해왔고, 지금은 OSS 기술서비스와 아키텍처를 담당하고 있어요 