2026 개발 트렌드: Kubernetes v1.37 Memory QoS Beta, OOM 직전의 메모리를 운영 계약으로 바꾸다
Kubernetes v1.37에서 Beta가 된 Memory QoS를 계기로, memory.high·memory.min·memory.low를 OOM 회피 옵션이 아니라 워크로드 분리·관측·rollback이 필요한 node-level 운영 계약으로 해석합니다.
아카이브 글
2026 개발 트렌드: Kubernetes v1.37 In-Place Resize Preemption, 무중단 확장보다 퇴출 예산을 먼저 설계하자
Kubernetes v1.37의 in-place Pod resize scheduler preemption Alpha를 계기로, restart 없는 scale-up을 목표로 삼지 않고 어떤 workload를 언제 퇴출해도 되는지 priority·PDB·capacity·rollback 예산으로 설계하는 기준을 정리합니다.
2026 개발 트렌드: Node.js 26의 Temporal 기본 활성화, Date 교체보다 시간 모델·호환성 경계를 먼저 정하자
Node.js 26에서 Temporal API가 기본 활성화된 흐름을 계기로, Date 치환을 목표로 삼지 않고 instant·local date·time zone·직렬화·구버전 runtime을 분리해 이행하는 실무 기준을 정리합니다.
2026 개발 트렌드: OTel 환경변수 Context Propagation RC, CI·CLI의 끊긴 Trace를 운영 계약으로 잇는다
OpenTelemetry 환경변수 context propagation release candidate를 계기로, HTTP 밖에서 시작되는 CI·빌드·CLI·배치 프로세스의 trace를 안전하게 연결하는 도입 경계와 운영 기준을 정리합니다.
2026 개발 트렌드: Kubernetes v1.37 Node Lifecycle Conditions, 노드 정비를 자동화 전에 계약으로 만들기
Kubernetes v1.37의 Node Lifecycle Conditions를 계기로 drain·maintenance·graceful shutdown 상태를 공통 계약으로 다루는 방법과, Alpha 신호를 자동 eviction 정책으로 오해하지 않는 운영 기준을 정리합니다.
2026 개발 트렌드: OTel OTTL Lambda, Collector 변환이 설정을 넘어 검증 가능한 데이터 계약이 된다
OpenTelemetry Collector Contrib v0.157.0의 OTTL lambda 기능을 계기로, telemetry 변환을 편리한 YAML 조각이 아니라 입력·출력·비용·실패 모드를 검증하는 데이터 계약으로 운영하는 기준을 정리합니다.
2026 개발 트렌드: Kubernetes v1.37 Rootless Node Components, 노드 권한을 워크로드 격리 밖에서 다시 설계하다
Kubernetes v1.37에서 Beta가 된 KubeletInUserNamespace를 계기로, Pod user namespace와 node component rootless mode를 구분하고 CNI·CSI 호환성, 스케줄링 격리, 운영 canary 기준으로 검토하는 글입니다.
2026 개발 트렌드: Kubernetes v1.37 Manifest 기반 Admission Control, 정책 보호선을 API 밖으로 옮기다
Kubernetes v1.37에서 Beta가 된 manifest 기반 admission control을 계기로, API 안의 정책을 보호하려면 bootstrap 신뢰 경로·파일 권한·검증·rollback을 어떻게 다시 설계해야 하는지 정리합니다.
2026 개발 트렌드: Kubernetes v1.37 etcd RangeStream, 대량 List의 메모리 피크를 용량 계약으로 바꾸다
Kubernetes v1.37과 etcd v3.7의 RangeStream Beta를 계기로, control plane의 대형 List 요청을 단순히 빠르게 만드는 문제가 아니라 object 크기·동시성·fallback·메모리 피크를 함께 관리하는 용량 계약으로 다룹니다.
2026 개발 트렌드: npm Trusted Publishing은 한 개 OIDC 설정이 아니라 Release Path별 권한 모델이 된다
npm의 다중 trusted publisher와 staged publishing 변경을 바탕으로, 장기 publish token을 없애는 데서 그치지 않고 stable·prerelease·긴급 경로를 서로 다른 OIDC 권한과 승인 증거로 운영하는 기준을 정리합니다.