Kubernetes 1.36 변경점을 보다가 이 글을 적게 된 이유는 단순하다. 회사에서 Kubernetes 도입을 다시 생각하고 있고, 이미 여러 프로젝트가 MSA 형태로 나뉘어 있다 보니 “새 버전 기능이 좋다”보다 “지금 우리 운영 기준을 무엇부터 정리해야 하나”가 더 중요했다.
공식 CHANGELOG 기준으로 Kubernetes 1.36.0은 2026년 4월 22일 공개됐고, 현재 Kubernetes 공식 릴리스 페이지는 1.36, 1.35, 1.34를 지원 중인 최근 3개 minor release로 안내한다. 그래서 이번 글은 기능 홍보가 아니라, MSA 운영팀이 Kubernetes 1.36을 보기 전에 체크해야 할 항목 중심으로 정리했다.
연관 글
요약
Kubernetes 1.36에서 회사 MSA 도입 관점으로 먼저 볼 것은 DRA, 스케줄링, admission, 관측 지표, 오래된 볼륨 기능 정리다. 특히 GPU·특수 장비 자원을 쓸 계획이 있거나, 자체 scheduler plugin·FlexVolume·git-repo volume·Service externalIPs를 사용 중이면 업그레이드 전 확인이 필요하다.
개인적으로는 “쿠버네티스가 좋아졌나?”보다 “우리 회사가 쿠버네티스를 받아들일 준비가 되어 있나?”를 먼저 묻게 됐다.
목차
이 글에서 다루는 내용
왜 Kubernetes 1.36을 보게 됐나
현재 회사 프로젝트는 이미 MSA 형태로 여러 서비스가 나뉘어 있다. 그런데 서비스가 나뉘었다고 곧바로 Kubernetes가 정답이 되지는 않는다. 배포 단위, 로그 수집, 장애 격리, 네트워크 정책, 권한 관리, 롤백 방식이 같이 정리되어야 한다.
그래서 Kubernetes 1.36의 변경점도 “새 기능을 써야 하나?”보다 “도입 전에 우리 운영 기준과 충돌하는 부분이 있나?”로 봐야 한다. 특히 1.36은 DRA(Dynamic Resource Allocation), PodGroup 기반 스케줄링, admission 설정, 오래된 볼륨 기능 정리 쪽 변화가 눈에 띈다.
Kubernetes 1.36 주요 변경점
| 영역 | 변경점 | 실무 영향 |
|---|---|---|
| 업그레이드 주의 | volume_operation_total_errors 메트릭이 volume_operation_errors_total로 변경 |
Prometheus/Grafana 알람과 대시보드 쿼리를 먼저 수정해야 한다. |
| 스케줄러 | PreBind plugin 병렬 실행 지원 | 자체 scheduler plugin을 쓰는 조직은 plugin API 대응 여부를 확인해야 한다. |
| 서비스 네트워크 | Service .spec.externalIPs deprecation warning 추가 |
외부 IP를 Service에 직접 박아 쓰는 방식은 장기 운영 기준에서 재검토가 필요하다. |
| 스토리지 | git-repo volume plugin 기본 비활성화, 되돌리는 옵션 없음 |
아직 git-repo volume에 의존하는 manifest가 있으면 배포가 깨질 수 있다. |
| kubeadm | FlexVolume 통합 지원 제거 | 오래된 스토리지 플러그인은 CSI 전환 계획을 잡아야 한다. |
| etcd/관측 | etcd_bookmark_counts가 etcd_bookmark_total로 변경 |
etcd 관련 커스텀 알람이 있으면 이름 변경을 반영해야 한다. |
| DRA | ResourceClaim status granular RBAC, Device Binding Conditions beta, Device taints/tolerations beta | GPU·AI 가속기·특수 장비 자원을 쓸 계획이면 권한과 드라이버 호환성을 먼저 검토해야 한다. |
| 스케줄링 | Topology-aware workload scheduling, PodGroup, workload-aware preemption 관련 기능 추가 | 배치 작업, 대규모 Pod 그룹, 노드 토폴로지 제약이 있는 환경에서 의미가 있다. 일반 웹 MSA라면 당장 필수는 아니다. |
| 노드/메모리 | cgroup v2 기반 MemoryReservationPolicy 지원 |
노드 메모리 보호 정책을 세밀하게 가져가려면 OS/cgroup v2 기준을 함께 확인해야 한다. |
| Admission | Manifest-based admission control configuration alpha | API 서버 시작 시점부터 admission 정책을 파일 기반으로 로드하는 방향이다. 아직 alpha라 운영 도입은 신중해야 한다. |
MSA 도입 전 변경 체크리스트
| 체크 | 확인할 것 | 판단 기준 |
|---|---|---|
| 버전 | 관리형 Kubernetes가 1.36을 지원하는가 | 지원하지 않으면 1.35 또는 공급자 권장 버전부터 시작한다. |
| Manifest | externalIPs, gitRepo, FlexVolume 사용 여부 |
하나라도 있으면 대체 설계를 먼저 만든다. |
| 관측 | Prometheus rule, Grafana dashboard, Loki label 체계 | 메트릭 이름 변경으로 알람이 조용히 죽지 않는지 확인한다. |
| 스토리지 | PV/PVC, CSI driver, 백업/복구 절차 | DB나 파일 저장소를 Pod 생명주기에 묶지 않는다. |
| 배포 | 서비스별 readiness/liveness/startup probe | MSA는 “떴다”보다 “트래픽을 받아도 된다”가 중요하다. |
| 권한 | Namespace, ServiceAccount, RBAC 분리 | 프로젝트별 계정과 권한 경계를 먼저 만든다. |
| 네트워크 | Ingress, Gateway API, NetworkPolicy, 내부 DNS | 서비스가 많아질수록 네트워크 정책이 문서보다 중요해진다. |
| 리소스 | requests/limits, HPA/KEDA, node pool 분리 | 초기에는 “자동 확장”보다 “예측 가능한 제한”이 먼저다. |
회사 도입 시 현실적인 진행 순서
1단계. 바로 운영 이관하지 말고, 한 서비스만 올린다
처음부터 모든 MSA를 Kubernetes로 옮기면 실패했을 때 원인을 찾기 어렵다. stateless API 하나, 내부 관리자 도구 하나처럼 장애 영향이 작은 서비스부터 올리는 편이 낫다.
2단계. 배포보다 로그와 롤백을 먼저 본다
Kubernetes 도입 초기에 가장 크게 체감되는 문제는 “배포는 됐는데 왜 죽었는지 모르겠다”다. Loki, Prometheus, Grafana, 이벤트 수집, 컨테이너 로그 보존 기준을 먼저 잡아야 한다.
3단계. 1.36 기능은 필요한 것만 켠다
DRA, PodGroup, topology-aware scheduling은 좋아 보이지만 모든 MSA에 필요한 기능은 아니다. 일반 웹/API 서비스라면 먼저 Deployment, Service, Ingress/Gateway, ConfigMap/Secret, HPA, NetworkPolicy부터 안정화하는 것이 낫다.
4단계. 업그레이드 테스트 환경을 따로 둔다
1.36으로 바로 가든, 1.35에서 시작하든 핵심은 업그레이드 리허설이다. 최소한 staging cluster에서 manifest apply, Helm chart 렌더링, 알람 rule, ingress route, DB 연결, PVC mount까지 검증해야 한다.
kubectl get deploy,svc,ingress -A
kubectl get pv,pvc -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl top pod -A
이 명령이 전부 해결책은 아니지만, 도입 초기에 “현재 클러스터가 무슨 상태인지” 빠르게 보는 기본 점검으로는 충분하다.
실제로 막히는 부분
증상 1. 배포는 성공했는데 트래픽이 안 들어온다
대부분 Service selector, Ingress class, health check, readiness probe 중 하나에서 막힌다. MSA에서는 서비스 이름이 많아져서 selector 라벨 하나만 틀려도 배포 성공처럼 보이는 장애가 생긴다.
증상 2. 알람이 멀쩡한데 장애를 놓친다
1.36에서는 스토리지/etcd 쪽 메트릭 이름 변경이 있다. 업그레이드 후 Prometheus rule이 빈 결과를 반환하면 알람은 조용해진다. 대시보드가 예쁘게 뜨는지보다, 실제 rule query가 값을 반환하는지 봐야 한다.
증상 3. “MSA니까 Kubernetes”라고 생각한다
MSA와 Kubernetes는 같은 말이 아니다. 서비스가 여러 개라서 Kubernetes가 편해지는 것은 맞지만, 운영 기준이 없으면 오히려 장애 지점만 늘어난다. 특히 DB, 메시지 브로커, 파일 저장소, 배치 작업은 별도 운영 기준이 필요하다.
결론
Kubernetes 1.36은 DRA와 스케줄링 쪽이 꽤 활발하게 바뀐 릴리스다. 하지만 회사 MSA 도입 관점에서는 새 기능을 켜는 것보다 오래된 manifest, 관측 지표, 스토리지 플러그인, 권한 분리, 롤백 절차를 먼저 확인하는 것이 더 중요하다.
내 기준의 결론은 이렇다. Kubernetes 1.36을 검토하되, 첫 운영 목표는 “최신 기능 사용”이 아니라 “한 서비스를 안정적으로 배포하고, 장애가 났을 때 바로 원인을 찾고, 안전하게 되돌릴 수 있는가”가 되어야 한다.