Kubernetes 1.37 Garhwal — 백엔드 개발자가 챙길 핵심 변화

이번 포스팅에서는 2026년 8월 26일 나온 Kubernetes 1.37 “Garhwal” 릴리스를 백엔드 개발자 관점에서 정리하고자 한다. 릴리스 노트를 열면 67개 개선이 쏟아지지만, 클러스터를 직접 운영하지 않고 매니페스트를 쓰고 배포만 하는 입장에서 실제로 손에 와닿는 변화는 그중 몇 개다. 여기서는 매니페스트를 다루는 방식을 바꾸는 KYAML, GPU 같은 장치를 붙이는 방식을 정리한 DRA, 그리고 조용하지만 업그레이드에 영향을 주는 Storage Version Migration을 골라, 무엇이 어떻게 바뀌었고 왜 신경 써야 하는지 짚는다.

Kubernetes 1.37 Garhwal 한눈에 보기

Kubernetes 1.37은 2026년 8월 26일 릴리스됐고, 코드네임은 인도 우타라칸드의 히말라야 지역 이름인 Garhwal이다. 총 67개 개선이 담겼는데 16개가 Stable(GA)로, 23개가 Beta로, 27개가 Alpha로 승격했고 1개가 제거됐다(공식 릴리스 블로그). 정식 릴리스는 대략 4개월 주기라, 1.36 “Haru”(2026-04)에 이은 올해 두 번째 정기 릴리스다.

이번 릴리스에서 개발자에게 특히 의미 있는 GA 승격은 세 가지다. kubectl이 더 안전한 YAML 형식을 출력하는 KYAML, 디바이스 플러그인 없이 GPU 같은 장치를 요청하게 해 주는 DRA Extended Resource, 그리고 etcd에 저장된 오브젝트 버전을 자동으로 옮기는 Storage Version Migration이다. 아래에서 하나씩 실무 관점으로 풀어 본다.

KYAML — kubectl이 ‘덜 위험한 YAML’을 뱉는다

KYAML은 Kubernetes 1.37에서 Stable로 승격한, YAML의 애매한 부분을 걷어낸 안전한 부분집합이다. kubectl get ... -o kyaml로 출력하며, 들여쓰기에 의존하지 않는 flow 스타일을 쓴다. YAML을 대체하는 새 포맷이 아니라, 기존 YAML 파서가 그대로 읽을 수 있는 유효한 YAML이라는 점이 핵심이다.

# 리소스를 KYAML 형식으로 출력
kubectl get pod my-pod -o kyaml

# 리소스를 KYAML 형식으로 출력
kubectl get pod my-pod -o kyaml

출력은 아래처럼 객체를 {}, 배열을 []로 감싸고 문자열 값은 모두 큰따옴표로 두른 모습이다.

---
{
  apiVersion: "v1",
  kind: "Pod",
  metadata: {
    name: "my-pod",
    labels: {
      app: "demo",
    },
  },
  spec: {
    containers: [{
      name: "nginx",
      image: "nginx:1.20",
    }],
  },
}

---
{
  apiVersion: "v1",
  kind: "Pod",
  metadata: {
    name: "my-pod",
    labels: {
      app: "demo",
    },
  },
  spec: {
    containers: [{
      name: "nginx",
      image: "nginx:1.20",
    }],
  },
}

위 KYAML 출력에서 키는 따옴표 없이 두고 문자열 값만 큰따옴표로 감싸며, 마지막 항목 뒤에 트레일링 콤마를 허용한다. 이 방식이 해결하는 건 YAML의 오랜 함정이다. 들여쓰기 한 칸 차이로 구조가 어긋나거나, no가 불리언 false로, 1.20이 숫자로 암묵 변환되던 문제(이른바 노르웨이 문제)가 flow 스타일과 명시적 따옴표로 사라진다. 특히 Helm 차트처럼 문자열을 패치할 때 공백에 민감하지 않아 훨씬 안전하다. 모든 KYAML 파일은 유효한 YAML이므로 입력으로도 그대로 쓸 수 있고, 매니페스트를 굳이 KYAML로 새로 쓸 필요는 없다(KYAML 레퍼런스).

실제로 kubectl 1.37에서 같은 Deployment를 -o yaml과 -o kyaml로 뽑아 나란히 놓으면 차이가 분명하다. 왼쪽 YAML은 들여쓰기로 계층을 표현해 한 칸만 어긋나도 구조가 깨지는 반면, 오른쪽 KYAML은 {}와 []로 계층을 명시하고 문자열을 큰따옴표로 감싸 들여쓰기에 기대지 않는다. 그래서 스크립트나 CI에서 값 하나를 갈아 끼울 때 사고가 줄어든다.

KYAML, 지금 바로 뽑아보기

KYAML은 kubectl 1.37 이상만 있으면 클러스터 없이도 바로 써 볼 수 있다. --dry-run=client를 붙이면 클러스터에 아무것도 만들지 않고 매니페스트만 KYAML로 출력한다.

# 클러스터 없이 — 생성 매니페스트를 KYAML로
kubectl create deployment web --image=nginx:1.27 --replicas=3 --dry-run=client -o kyaml

# 클러스터의 기존 리소스를 KYAML로 내보내기
kubectl get deployment web -o kyaml

# 클러스터 없이 — 생성 매니페스트를 KYAML로
kubectl create deployment web --image=nginx:1.27 --replicas=3 --dry-run=client -o kyaml

# 클러스터의 기존 리소스를 KYAML로 내보내기
kubectl get deployment web -o kyaml

첫 번째 명령은 클러스터 연결 없이 로컬에서 매니페스트를 KYAML로 뽑는 것이라, 손에 익은 YAML 매니페스트를 KYAML로 바꿔 보며 감을 잡기에 좋다. 두 번째처럼 kubectl get으로 실제 리소스를 내보내면 클러스터에 이미 떠 있는 오브젝트를 KYAML로 받아 온다. 뽑은 KYAML은 유효한 YAML이므로 kubectl apply -f의 입력으로도 그대로 들어간다. 참고로 kubectl은 API 서버보다 최대 한두 마이너 버전 차이까지 무난히 붙으니, 클러스터가 아직 1.37이 아니어도 클라이언트만 1.37로 올리면 KYAML 출력은 바로 쓸 수 있다. 로컬에서 설정을 고치고 즉시 확인하는 개발 루프가 익숙하다면, 컨테이너 쪽에서 비슷한 즉시 반영을 주는 Docker Compose Watch와 함께 보면 로컬 이터레이션이 한결 매끄러워진다.

DRA Extended Resource GA — 디바이스 플러그인 없이 GPU를 붙인다

DRA(Dynamic Resource Allocation)는 GPU·가속기·네트워크 장치처럼 복잡한 하드웨어를 파드에 할당하는 메커니즘이고, 1.37에서 Extended Resource 지원이 GA로 승격했다. 기존에는 GPU를 쓰려면 벤더의 디바이스 플러그인을 따로 띄워야 했는데, 이제 DRA 드라이버 하나가 example.com/gpu 같은 익스텐디드 리소스 요청까지 처리한다. Alpha(1.35) → Beta(1.36) → GA(1.37)를 거쳐 안정화됐다(DRA 업데이트 블로그).

실무적으로 중요한 건 점진적 이전이 가능하다는 점이다. 기존 워크로드가 익스텐디드 리소스로 GPU를 요청하는 매니페스트를 그대로 두어도, 백엔드 할당만 DRA로 넘어간다.

디바이스 플러그인 방식과 비교하면 차이가 뚜렷하다.

여기에 Device Taints and Tolerations도 GA가 됐다. 노드 테인트와 똑같은 개념을 장치 단위로 옮긴 것으로, 관리자가 DeviceTaintRule로 특정 GPU를 점검용으로 표시하면 새 파드는 그 장치를 피해 스케줄링되고, 이미 쓰던 파드는 톨러레이션이 없으면 축출된다. 장애 GPU를 격리하거나 유지보수를 돌릴 때 드라이버 설정을 건드리지 않고 처리할 수 있다. 파드가 GPU를 직접 다루는 AI·배치 워크로드를 K8s에 올리는 팀이라면 1.37의 DRA가 가장 크게 와닿는 변화다.

Storage Version Migration GA와 함께 온 것들

Storage Version Migration(SVM)은 etcd에 저장된 오브젝트를 최신 API 버전으로 자동 마이그레이션하는 기능으로, 1.37에서 GA가 됐다. 눈에 잘 안 띄지만 업그레이드 안정성에 직접 영향을 준다. API 버전이 올라가면 기존에 저장된 리소스도 새 스토리지 버전으로 다시 써야 하는데, 그동안은 수동 절차나 별도 컨트롤러에 의존했다. SVM이 GA가 되면서 이 과정이 기본 기능으로 들어와, 오래된 클러스터를 올릴 때 스토리지 버전 불일치로 겪던 문제가 줄어든다.

이 밖에도 16개 GA 승격 중에는 API 서버의 watch 캐시 초기화 안정화, etcd 대용량 목록 조회의 메모리 사용을 줄이는 최적화 등 대규모 클러스터 운영에 도움이 되는 항목이 있다. 전체 목록과 세부 사양은 공식 릴리스 블로그와 1.37 체인지로그에서 확인할 수 있다. 다만 매니페스트를 쓰고 배포하는 입장에서 당장 코드를 바꿔야 하는 건 앞서 다룬 KYAML·DRA 정도이고, 나머지는 클러스터를 올릴 때 자연히 따라오는 개선으로 보면 된다.

Kubernetes 1.37로 올리기 전에 챙길 것

Kubernetes 1.37 업그레이드를 계획한다면 API 제거·버전 스큐·매니지드 서비스 지원 시점 세 가지를 먼저 확인해야 한다. 이번 릴리스에는 1건의 제거가 포함돼 있으므로, 쓰고 있는 매니페스트가 제거된 API를 참조하는지 사전에 점검하는 게 안전하다.

# 클러스터에서 곧 사라질/제거된 API 사용 여부 점검 (pluto 예시)
pluto detect-files -d ./manifests

# 현재 사용 중인 API 리소스의 스토리지 버전 확인
kubectl api-resources --sort-by=name

# 클러스터에서 곧 사라질/제거된 API 사용 여부 점검 (pluto 예시)
pluto detect-files -d ./manifests

# 현재 사용 중인 API 리소스의 스토리지 버전 확인
kubectl api-resources --sort-by=name

pluto 같은 도구로 deprecated·removed API 참조를 미리 잡아내면, 업그레이드 직후 리소스가 적용되지 않는 사고를 막을 수 있다. 버전 스큐도 유의할 지점이다. kubelet은 API 서버보다 최대 3개 마이너 버전까지 낮아도 되지만 높을 수는 없으므로, 컨트롤 플레인부터 올린 뒤 노드를 순차적으로 올리는 순서를 지킨다. 마지막으로 EKS·GKE·AKS 같은 매니지드 쿠버네티스는 업스트림보다 수 개월 늦게 새 버전을 제공하므로, 1.37을 당장 클러스터에서 만나긴 어렵고 지원 시점을 각 서비스 릴리스 캘린더로 확인해야 한다.

쿠버네티스가 낡은 API를 걷어내는 건 이번이 처음이 아니다. 최근 Ingress-NGINX가 은퇴하고 Gateway API로 넘어간 흐름을 정리한 Ingress-NGINX 은퇴와 Gateway API 마이그레이션 글처럼, 제거·대체는 주기적으로 반복되므로 매니페스트가 참조하는 API를 릴리스마다 점검하는 습관이 필요하다. 지원 기간도 함께 계산해 두면 좋다. 쿠버네티스는 마이너 버전마다 약 14개월간 패치를 제공하므로(최신 3개 릴리스 + 유지보수 기간), 2026년 8월에 나온 Kubernetes 1.37은 대략 2027년 하반기까지 보안·버그 패치를 받는다. 이 창 안에서 다음 업그레이드 시점을 잡는 것이 안전하다.

자주 묻는 질문 (FAQ)

마치며

지금까지 Kubernetes 1.37 Garhwal의 핵심 변화를 살펴봤다. 릴리스 노트 67개를 다 읽고 나면 늘 “그래서 내가 당장 바꿔야 할 게 뭐지?”가 남는데, 이번엔 KYAML이 그 답에 가깝다. 예전에 매니페스트에서 포트 번호를 따옴표 없이 적었다가 문자열이 아니라 숫자로 파싱돼 한참을 헤맨 적이 있는데, KYAML의 명시적 따옴표를 보니 그때 생각이 났다. DRA는 GPU를 직접 다루는 팀이 아니면 아직 먼 얘기일 수 있지만, AI 워크로드를 클러스터에 올리는 흐름을 보면 조만간 대부분이 마주칠 주제다. 릴리스 자체를 급하게 따라갈 필요는 없되, KYAML처럼 지금 워크플로우를 바로 편하게 해 주는 것부터 하나씩 손에 붙여 보길 권한다.