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

쿠버네티스 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, DRA, PSI 모두 그렇습니다.

여기서 달라지는 건 분명합니다. 운영하던 외부 컴포넌트 중 일부는 역할이 줄거나 사라지고, 그만큼 책임이 코어 쪽으로 옮겨갑니다. 컴포넌트가 줄면 운영 부담이 주는 건 맞지만, 그렇다고 공짜는 아닙니다. 코어 버전에 더 강하게 묶이고, 업그레이드를 미룰 여유가 줄어듭니다.

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

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