Kubernetes 1.35, containerd 1.x 지원 종료 버전: 2026년 업그레이드 가이드

(dev.to)

Kubernetes 1.35를 마지막으로 containerd 1.x 지원이 종료됨에 따라, 2026년까지 컨테이너 런타임 구성 방식의 근본적인 변화를 포함한 업그레이드 계획을 수립해야 한다는 경고입니다.

이 글의 핵심 포인트

1Kubernetes 1.35는 containerd 1.x를 지원하는 마지막 릴리스임
2Kubernetes 1.36 버전부터는 containerd 2.0이 최소 요구사항으로 적용됨
3containerd 2.0에서는 CRI 플러그인 식별자 경로가 변경됨 (io.containerd.grpc.v1.cri → io.containerd.cri.v1.images)
4기존의 registry mirrors 및 configs 방식이 폐기되고 config_path 기반의 hosts.toml 방식으로 변경됨
5잘못된 설정 적용 시 노드에서 이미지를 가져오지 못하는 ImagePullBackoff 장애가 발생할 수 있음

이 글에 대한 공공지능 분석

왜 중요한가?

Kubernetes 1.35 이후부터는 containerd 2.0이 필수 요구사항이 되며, 이는 기존에 사용하던 컨테이너 런타임 설정이 작동하지 않을 수 있음을 의미합니다. 특히 CRI 플러그인 경로와 레지스트리 구성 방식의 변경은 단순한 패치가 아닌 인프라 재설계 수준의 주의를 요하는 파괴적 변경입니다.

어떤 배경과 맥락이 있나?

Kubernetes 프로젝트는 주기적으로 오래된 런타임을 제거하며, containerd 1.6 및 1.7은 이미 1.34 버전부터 Deprecated 상태로 지정되었습니다. 이는 클라우드 네이티브 생태계의 표준을 최신화하고 보안 및 성능을 개선하기 위한 정기적인 기술 부채 청산 과정의 일환입니다.

업계에 어떤 영향을 주나?

인프라 운영팀은 단순한 컨트롤 플레인 업데이트를 넘어, 노드의 컨테이너 런타임 설정을 검증해야 하는 추가적인 작업 부담을 안게 됩니다. 잘못된 설정 적용 시 이미지를 불러오지 못하는 ImagePullBackOff와 같은 치명적인 서비스 장애로 이어질 수 있어, 자동화된 테스트 환경 구축이 더욱 중요해집니다.

한국 시장에 어떤 시사점이 있나?

클라우드 네이티브 전환을 서두르는 국내 스타트업들은 인프라 관리 비용과 운영 리스크를 고려하여, Managed Kubernetes(ESS, GKE 등)의 지원 주기와 업그레이드 전략을 사전에 수립해야 합니다. 특히 레지스트리 미러링 설정을 사용하는 기업은 설정 파일 구조 변경에 따른 장애 가능성을 반드시 점검해야 합니다.

이 글에 대한 큐레이터 의견

이번 업데이트는 단순한 버전 숫자의 변화가 아니라, 컨테이너 생태계의 핵심 구성 요소인 containerd의 아키텍처적 변화를 Kubernetes가 강제하는 중요한 전환점입니다. 인프라 운영자 입장에서는 기존에 잘 작동하던 config.toml 설정이 무용지물이 될 수 있다는 점에서 상당한 기술적 부채와 운영 리스크를 마주하게 됩니다.

특히, 모든 것을 최신 버전으로 빠르게 올리는 것이 항상 정답은 아닙니다. containerd 2.0의 새로운 설정을 적용하는 과정에서 발생할 수 있는 호환성 문제나 레지스트리 설정 오류는 서비스 중단이라는 막대한 비용을 초래할 수 있습니다. 따라서 무조건적인 업그레이드보다는, 현재 운영 중인 클러스터의 안정성을 최우선으로 하여 단계적인 테스트와 롤백 전략을 포함한 '점진적 마이그레이션' 계획을 세우는 것이 스타트업에게 가장 현명한 접근입니다.

원문 보기 →