쿠버네티스 1.36이 가져올 변화 7가지 (Ingress-Nginx 퇴출부터 네이티브 스케일링까지)

2026년 4월 1일|Platform Decision|16분 읽기

쿠버네티스 1.36, 어디가 진짜 바뀌는가

쿠버네티스 릴리스 노트를 볼 때 나는 기능 목록보다 '이게 운영비와 책임 구조를 어떻게 바꾸는가'를 먼저 본다. 새 기능이 멋있어 보여도 결국 클러스터를 굴리는 사람 입장에서 보면 비용, 보안 경계, 장애 대응 절차가 어떻게 달라지느냐가 전부니까.

그런 눈으로 1.36 베타를 훑어봤는데, 이번엔 단순한 안정화 위주 릴리스가 아니다. 지금까지 서드파티로 메워왔던 구멍 몇 개를 코어가 직접 가져가려는 흐름이 보인다. 그동안 KEDA나 Knative 없이는 워크로드를 0으로 못 줄였던 사람, annotation 범벅 Ingress 설정에 질렸던 사람이라면 특히 눈여겨볼 만하다.

4월 22일 정식 출시 예정이라는데, 그 전에 무엇을 미리 정리해둬야 하는지를 중심으로 7가지를 짚어본다.

1. 네이티브 스케일 투 제로

이제 외부 툴 없이도 워크로드를 0까지 줄일 수 있다.

지금까지 스케일 투 제로를 하려면 KEDA나 Knative 같은 솔루션을 얹어야 했다. 문제는 이게 단순히 컴포넌트 하나 추가하는 일이 아니라는 점이다. 운영 입장에선 모니터링 대상이 하나 늘고, 업그레이드 주기를 따로 맞춰야 하고, 장애가 나면 'HPA 문제인지 KEDA 문제인지'부터 가려야 한다. 책임 경계가 흐려진다.

1.36부터는 HPAScaleToZero 기능 게이트가 기본 활성화되면서 네이티브 HPA만으로 0 스케일이 가능해졌다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: scale-to-zero-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-inference-worker
  minReplicas: 0    # 드디어 네이티브 지원!
  maxReplicas: 10
  behavior:
    scaleDown:
      policies:
      - type: Pods
        value: 1
        periodSeconds: 300

이게 왜 중요한가. 개발 환경이나 야간에 노는 워크로드를 떠올려보자. 하루의 상당 시간을 유휴 상태로 보내는데도 최소 한 개 파드는 떠 있어야 했다. 컨설팅하면서 클라우드 비용 명세를 뜯어보면, 이런 '항상 떠 있지만 거의 일 안 하는' 워크로드가 의외로 큰 비중을 차지한다. 진짜 0으로 줄일 수 있다는 건 FinOps 관점에서 단순한 편의 기능이 아니다.

다만 콜드 스타트는 여전히 남는다. 0에서 1로 올라오는 시간 동안 요청을 어디서 버틸지, 큐로 흡수할지는 별개 설계 문제다. 0으로 줄일 수 있다는 것과 0에서 안전하게 깨어난다는 건 다른 얘기다.

2. Ingress-Nginx의 작별

Ingress-Nginx 컨트롤러가 막을 내리는 중이다. 충격적이라기보단 예고된 수순에 가깝다.

당장 사라지는 건 아니다. 다만 프로젝트 차원에서 공식적으로 Gateway API로의 이전을 권장하기 시작했다. Gateway API가 표현력이 더 풍부하고, 무엇보다 역할 기반으로 설계됐다는 점이 핵심이다. 누가 무엇을 설정할 권한을 갖는지가 리소스 단위로 나뉜다. 플랫폼 팀과 서비스 팀의 책임이 섞여 있던 기존 Ingress의 한계를 정확히 건드린다.

아직 이런 식으로 annotation을 쌓아 올리고 있다면,

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    # ... 수많은 annotation들

이 구조의 문제는 컨트롤러 구현체에 종속된 설정이 YAML 안에 녹아든다는 거다. 표준 스펙이 아니라 특정 컨트롤러의 방언이다. 컨트롤러가 사라지면 이 방언도 갈 곳을 잃는다.

마이그레이션은 빠를수록 좋다. 기술 부채는 이자가 붙는다. Ingress-Nginx가 살아 있는 동안 매핑 작업을 끝내두는 것과, 지원이 끊긴 뒤 떠밀려서 옮기는 것은 난이도가 완전히 다르다.

3. AI 시대를 위한 동적 자원 할당 (DRA)

GPU, TPU, NPU 스케줄링이 바뀐다.

기존 Device Plugin API는 단순한 가속기에는 그럭저럭 맞았지만, 복잡한 하드웨어를 다룰 땐 표현력이 부족했다. 1.36에서는 **DRA(Dynamic Resource Allocation)**가 AI 워크로드 쪽으로 크게 개선됐다.

개인적으로 가장 눈에 띈 건 DRA Taints와 Tolerations다. 멀티 GPU 노드에서 GPU 한 장이 ECC 오류를 내기 시작했다고 해보자. 기존엔 노드 단위가 격리의 최소 단위였다. GPU 한 장이 문제인데 그 노드에 붙은 멀쩡한 GPU와 CPU 작업까지 같이 빼야 했다. 자원을 통째로 비워두는 셈이다.

이제는 문제 있는 GPU 한 장만 taint로 격리할 수 있다. 나머지 가속기와 CPU 작업은 그대로 돌아간다. 장애 격리의 단위가 노드에서 디바이스로 내려온 것이다. AI 인프라를 굴려본 사람이라면 이 한 칸의 차이가 운영에서 얼마나 큰지 안다.

4. 재시작 없는 수직 스케일링

Java 애플리케이션 메모리 늘리려다 서비스가 잠깐 죽은 경험, 다들 한 번쯤 있을 거다.

나도 그랬다. 메모리 limit을 살짝 올리려던 것뿐인데 파드가 재시작되면서 순간적으로 서비스가 끊겼다. 변경 자체는 사소한데 그 사소함이 다운타임으로 이어지니, 결국 '리소스 조정은 점검 시간에'라는 식으로 운영 절차가 보수적으로 굳어진다.

1.36에서는 In-Place Vertical Pod Scaling이 안정화돼, 실행 중인 파드를 재시작하지 않고 리소스 할당량을 조정할 수 있게 됐다. 특히 정적 CPU 관리자 정책이 켜진 환경에서도 지원된다는 점이 의미 있다.

VPA를 쓰는 입장에선 반가운 변화다. 무중단 리소스 조정이 실제로 가능해지면서, CPU 코어 고정이 필요한 고성능 워크로드도 콜드 스타트 없이 스케일링할 수 있다. 변경의 위험 비용이 내려가면 운영 절차도 그만큼 유연해진다.

5. 보안이 강화된 이미지 풀링

정적 imagePullSecret의 시대가 끝나간다.

기존엔 ECR, ACR, Harbor 같은 프라이빗 레지스트리에서 이미지를 가져올 때 고정된 시크릿을 썼다. 문제는 이게 한번 유출되면, 누군가 수동으로 교체할 때까지 계속 악용된다는 점이다. 정적 크리덴셜은 본질적으로 '언제 새는지 모르고, 새도 한참 뒤에야 안다'는 리스크를 안고 있다.

1.36에서는 **임시 서비스 계정 토큰(Ephemeral Service Account Tokens)**이 안정화되면서, 수명이 짧고 자동으로 로테이션되는 토큰을 쓸 수 있게 됐다.

제로 트러스트가 이미지 풀 레벨까지 내려온 셈이다. 토큰이 특정 파드의 수명주기에 맞춰 발급되고 만료되니, 유출돼도 악용 가능한 창이 짧다. 금융권 IT에서 크리덴셜 관리로 고생해본 입장에선, '시크릿을 잘 숨기는' 접근에서 '시크릿의 수명을 짧게 가져가는' 접근으로 넘어가는 이 방향이 맞다고 본다.

6. 더 똑똑해진 노드 모니터링 (PSI)

"메모리 사용률 95%"라는 알람이 떴다고 정말 위험한 상황일까?

메모리 대부분이 파일 캐시로 쓰이고 있다면 멀쩡할 수도 있다. 기존 쿠버네티스는 단순 사용률만 보고 판단했다. 그래서 캐시까지 점유율로 잡혀 NodeNotReady 오탐이 나거나, 멀쩡한 파드가 eviction되는 일이 생겼다. 숫자는 높은데 실제로는 아무도 자원을 기다리며 멈춰 있지 않은, 가짜 부하 상황 말이다.

1.36에서는 **PSI(Pressure Stall Information)**로 노드 상태를 더 정확히 파악한다. PSI는 리눅스 커널 기능으로, 태스크들이 실제로 리소스를 기다리며 정체돼 있는지를 알려준다. 사용률이라는 표면 지표 대신, 정체라는 구조적 신호를 본다는 게 핵심이다.

운영 관점에서 기대되는 건 이런 것들이다.

더 지능적인 파드 eviction
NodeNotReady 오탐 감소
진짜 부하와 가짜 부하를 구분하는 관찰 가능성

장애 대응에서 가장 피곤한 게 오탐이다. 진짜 신호와 노이즈를 가려주는 지표가 코어에 들어온다는 건, 새벽에 깨는 횟수가 줄어든다는 뜻이기도 하다.

7. Containerd 2.x와 OCI 아티팩트 지원

런타임 업그레이드를 미뤄온 사람에게는 마감 알림이다.

쿠버네티스 1.36은 containerd 1.6.x를 지원하는 마지막 버전이 될 가능성이 크다. containerd 2.x로의 이전을 준비해야 한다는 얘기다.

여기에 OCI 아티팩트 마운팅도 안정화됐다. Helm 차트, WASM 모듈, 설정 파일 같은 것들을 OCI 레지스트리에서 파드로 직접 마운트할 수 있다. 이미지에 모든 걸 욱여넣거나 별도 볼륨으로 끌어오던 패턴이 정리될 여지가 생긴다.

런타임 교체는 화려한 작업이 아니라 그냥 귀찮은 작업이다. 그래서 자꾸 뒤로 밀린다. 미리 확인해둘 것들만 정리하면,

현재 쓰는 AMI나 프로비저닝 스크립트
containerd 버전 호환성
노드 이미지 업데이트 계획

플랫폼 팀이 지금 손대야 할 일

위 7가지를 운영 작업 단위로 쪼개보면 대략 이렇게 정리된다.

1. 자동 스케일링 정리

야간에 유휴 상태인 워크로드 식별
minReplicas: 0 적용 가능한 서비스 선별
네이티브 HPA 마이그레이션 계획, 그리고 콜드 스타트 대응 방안

2. Ingress 마이그레이션 준비

복잡한 Nginx annotation 의존도 분석
Gateway API 학습 및 POC
기존 Ingress → Gateway 매핑 작업

3. 인프라 업그레이드

containerd 2.x 호환성 확인
CONFIG_PSI=y가 켜진 커널 이미지 준비
노드 OS 이미지 업데이트 계획

정식 출시 전에 정리해둘 것

정식 출시까지 20일 남짓 남았다. 이번 릴리스를 보면 한 가지 흐름이 분명하다. 그동안 서드파티로 메워온 구멍들을 코어가 직접 흡수하는 방향이다. 스케일 투 제로, Gateway API, DRic, PSI 모두 그렇다.

이게 의미하는 바는 단순하다. 우리가 운영하던 외부 컴포넌트 중 일부는 역할이 줄거나 사라지고, 그만큼 책임이 코어 쪽으로 옮겨간다. 컴포넌트가 줄면 운영 부담이 주는 건 맞지만, 그렇다고 공짜는 아니다. 코어 버전에 더 강하게 묶이고, 업그레이드를 미룰 여유가 줄어든다.

나라면 스케일 투 제로와 Gateway API 마이그레이션 두 가지부터 손대겠다. 하나는 당장 비용에 닿아 있고, 하나는 미루면 미룰수록 이전 비용이 커지는 일이라서다. 나머지는 인프라 업그레이드 주기에 자연스럽게 묶어 가면 된다.

결국 새 기능을 언제 켜느냐보다, 지금 쓰는 외부 의존성 중 무엇을 정리하고 무엇을 남길지를 먼저 그려두는 게 이번 릴리스를 맞는 더 나은 자세다.

#쿠버네티스#K8s#컨테이너#클라우드네이티브#데브옵스