CNCF graduated·incubating 프로젝트 릴리즈 노트의 AI 분석.
Lima v2.1.4는 몇 가지 버그 수정과 nerdctl 업데이트, CLI 및 템플릿 소소한 개선을 담은 통상적인 패치 릴리스입니다. 주요 변경이나 보안 수정, 지원 중단 항목은 없습니다.
CRI-O v1.34.10은 두 가지 버그를 고친 일반 패치입니다. gomaxprocs CPU 주입 로직 수정과 재시작 후 컨테이너 상태 ImageRef 형식이 달라지던 문제를 처리했으며, 보안·API·설정 변경은 없습니다.
etcd v3.6.13은 --listen-client-http-urls를 설정한 클러스터에서 gRPC 리스너의 CRL 검사가 우회되던 HIGH 등급 취약점(GHSA-3wh4-j44w-pg92)을 수정한 보안 패치입니다. WebSocket bearer 토큰 인증 버그 수정과 v2-deprecation 플래그 옵션 추가도 포함됩니다.
--listen-client-http-urls를 설정한 클러스터에서는 gRPC 리스너가 CRL(인증서 폐기 목록) 검사를 수행하지 않아, 폐기된 클라이언트 인증서로도 인증이 통과될 수 있었습니다. 해당 플래그를 사용하는 환경이라면 v3.6.13으로 업그레이드하세요.
etcd v3.5.32는 --listen-client-http-urls를 설정했을 때 gRPC 리스너에서 CRL 검증이 우회되던 HIGH 등급 취약점(GHSA-3wh4-j44w-pg92)을 수정한 보안 릴리스입니다. v2-deprecation 우회 옵션 추가와 버그 수정도 함께 포함되었습니다.
--listen-client-http-urls 플래그를 설정한 경우 gRPC 리스너에서 CRL 검증이 작동하지 않아 폐기된 인증서가 허용되었습니다. 해당 플래그와 mTLS, CRL을 함께 사용 중이라면 v3.5.32로 업그레이드하세요.
Helm v3.21.2는 Kubernetes v1.36 클라이언트 라이브러리를 업데이트합니다. Kubernetes v1.36 클러스터와의 호환성을 유지하기 위한 정기 패치이므로 업그레이드하세요.
Helm v3.21.2는 Kubernetes 클라이언트 라이브러리(client-go)를 v1.36 API에 맞춰 업데이트했습니다. 이미 Kubernetes v1.36 클러스터를 운영한다면 Helm을 v3.21.2로 업그레이드해 완전한 호환성을 확보하고 클라이언트-서버 버전 차이로 인한 문제를 피하세요. 이전 Kubernetes 버전을 사용 중인 팀은 즉시 업그레이드할 필요는 없지만, 일관성 유지 차원에서 권장합니다.
Lima v2.1.3은 보안 패치 중심 릴리스입니다. QEMU VM 내 권한 상승(CVE-2026-53657)과 containerd 다수 CVE를 수정했으니 즉시 업그레이드해야 합니다.
QEMU 기반 Lima VM에서 비특권 사용자가 게스트 에이전트 소켓을 통해 VM 내 root를 획득할 수 있는 취약점입니다. 여러 사용자가 VM을 공유하거나 신뢰할 수 없는 워크로드를 실행 중이라면 우선순위가 높습니다. v2.1.3으로 업그레이드하고 영향받는 VM을 재시작하세요.
containerd v2.3.2에서 CVE 5건이 수정됐고, 이번 Lima 릴리스에 nerdctl v2.3.3으로 번들됩니다. Lima VM에서 컨테이너 워크로드를 실행 중이라면 기존 버전의 containerd가 노출된 상태입니다. Lima를 업그레이드한 뒤 VM을 재시작하거나 재생성해 새 nerdctl 바이너리가 반영되도록 하세요.
macOS, Windows 게스트에서 containerd.user=true가 더 이상 자동으로 설정되지 않습니다. 명시적 설정 없이 rootless containerd를 사용하던 환경이라면 업그레이드 후 VM 설정을 확인하고, 필요하면 containerd.user=true를 명시적으로 지정하세요.
containerd v2.1.9은 CVE 5건을 수정한 보안 패치 릴리스입니다. containerd 2.1.x를 운영 중이라면 즉시 업그레이드 계획을 세우세요.
이번 릴리스에서 containerd 자체 CVE 5건을 수정했습니다. 어드바이저리가 아직 공개되지 않아 심각도를 확인할 수 없지만, 패치 릴리스 하나에 CVE가 5건이면 빠르게 대응해야 합니다. Kubernetes 노드 이미지, 관리형 노드 그룹, bare-metal CRI 환경 모두 이번 주 안에 업그레이드 일정을 잡으세요.
이번 릴리스에 포함된 runc 바이너리는 v1.3.6입니다. runc를 containerd와 별도로 관리하는 환경(Kubernetes 노드에서 흔한 구성)이라면, containerd를 올려도 runc는 그대로입니다. 별도 설치된 runc가 v1.3.6 이상인지 직접 확인하세요.
CRI 체크포인트/복원과 관련해 세 가지가 바뀌었습니다. 예상치 못한 아카이브 내용을 거부하고, 복원된 체크포인트의 재태깅을 건너뛰며, CDI 어노테이션을 필터링합니다. CRIU 기반 라이브 마이그레이션을 쓰는 팀은 업그레이드 후 복원 워크플로우를 반드시 테스트해 기존 동작에 영향이 없는지 확인하세요.
containerd 1.7.33은 containerd 자체 CVE 2건과 go-jose CVE 1건을 패치하고, runc를 v1.3.6으로, Go 런타임을 업데이트했습니다. 업그레이드 이유는 보안 패치가 전부입니다.
containerd 본체에서 CVE-2026-53488과 CVE-2026-47262, go-jose에서 CVE-2026-34986이 수정됐습니다. 세부 내용은 GitHub 보안 어드바이저리를 확인하세요. containerd 1.7.x를 운영 중이라면 이전 패치 버전에 머물 이유가 없으므로 즉시 업그레이드하는 것이 좋습니다.
이미지 config에 포함된 reserved label이 외부로 전파되지 않도록 수정됐습니다. 레이블 기반 접근 제어나 정책 적용을 운영 중이라면 업그레이드 후 동작을 검증하고, CVE-2026-47262 어드바이저리에서 영향 범위를 확인하세요.
containerd에 번들된 runc가 v1.3.6으로 올라갔습니다. runc를 별도로 관리하는 환경이라면 설치된 버전이 v1.3.6 이상인지 확인해 containerd와 버전을 맞추세요.
containerd v2.0.10은 CVE-2026-53488, CVE-2026-47262 두 건의 취약점을 수정하고 runc를 v1.3.6으로 올렸습니다. 2.0.x를 운영 중이라면 즉시 업그레이드하세요.
CVE-2026-53488과 CVE-2026-47262가 이번 릴리스에서 함께 수정됐습니다. 각 어드바이저리(GHSA-xhf5-7wjv-pqxp, GHSA-jpcc-p29g-p8mq)에서 영향 범위를 확인하세요. containerd 2.0.x를 운영 중인 노드는 노출 여부를 따지기 전에 v2.0.10으로 먼저 올리는 것이 맞습니다. 런타임 레벨 취약점이라 영향 범위가 넓을 수 있습니다.
containerd에 포함된 runc 바이너리가 v1.3.6으로 올라갔습니다. v1.3.4, v1.3.5의 수정 사항도 포함됩니다. runc를 패키지 매니저 등으로 별도 관리하는 경우, containerd 업그레이드와 별개로 runc 버전도 v1.3.6에 맞춰 확인하세요.
컨테이너 실행 시 containerd의 reserved 레이블이 이미지 config에서 더 이상 전파되지 않습니다. 실행 중인 컨테이너의 레이블을 읽는 자동화 도구를 운영 중이라면, 업그레이드 후 동작을 확인하세요. 조용한 동작 변경이라 레이블 기반 로직에 영향을 줄 수 있습니다.
containerd 2.3.2는 CVE 5건을 포함한 보안 패치와 런타임 안정성 수정이 핵심입니다. 2.3.x를 운영 중이라면 즉시 업그레이드하세요.
이번 릴리스에서 containerd 코어 관련 CVE가 한 번에 5건 패치됐습니다. 어드바이저리가 아직 전부 공개되지 않았지만, 한 패치 릴리스에 5건이 몰린 만큼 노출 범위가 작지 않습니다. 2.3.x를 운영 중인 팀은 다음 정기 점검을 기다리지 말고 containerd 바이너리를 2.3.2로, runc는 v1.4.3으로 함께 업그레이드하세요. 노드 프로비저닝 파이프라인도 버전을 맞춰 업데이트하세요.
마지막으로 설정된 레지스트리 호스트에서 일시적 네트워크 오류가 발생할 때 자동으로 재시도하도록 resolver가 수정됐습니다. 별도 설정 변경 없이 적용되며, 네트워크 불안정 환경에서 간헐적 이미지 풀 실패를 겪었다면 이 패치로 개선될 수 있습니다.
runc shim이 runc create 호출 전체를 서비스 락을 잡은 채로 실행하면서, 컨테이너 생성이 느릴 때 동시 RPC 타임아웃이 발생해 시작에 실패하는 문제가 있었습니다. 부하가 걸린 상태에서 컨테이너가 시작되지 않거나 멈추는 증상을 겪었다면 이번 패치로 해결될 가능성이 높습니다.
containerd 2.2.5는 5개의 CVE를 수정하고 runc를 v1.3.6, Go를 1.26.4/1.25.11로 올린 보안 중심 패치 릴리스입니다. 2.2.x를 운영 중이라면 빠른 업그레이드가 필요합니다.
이번 릴리스는 containerd 자체에서 발견된 CVE 5건을 수정합니다. 각 취약점 상세 내용은 공개된 보안 어드바이저리를 참고하세요. 2.2.x를 운영 중인 클러스터는 2.2.5로 업그레이드해야 합니다. runc도 v1.3.6으로 올라갔으므로, 배포 전에 runc 릴리스 노트도 함께 확인하세요.
golang.org/x/crypto가 v0.45.0에서 v0.53.0으로, golang.org/x/net이 v0.47.0에서 v0.55.0으로 올라갔습니다. containerd를 벤더링하거나 라이브러리를 직접 참조해 플러그인을 빌드하고 있다면, 의존성을 다시 vendor하고 재빌드하세요. crypto 범위 내에는 여러 보안 수정이 포함되어 있습니다.
CRI 체크포인트 복원 관련 버그 3건이 한꺼번에 수정됐습니다. CDI 어노테이션이 복원 시 제대로 필터링되고, 복원된 체크포인트가 잘못 재태깅되는 문제가 없어졌으며, 비정상적인 아카이브 콘텐츠에 대한 처리도 강화됐습니다. 프로덕션에서 컨테이너 체크포인트/복원을 쓰고 있다면 업그레이드 우선순위를 높이세요.
Helm v4.2.2는 WaitForDelete의 조기 종료 수정사항을 되돌렸습니다. 상태 감시 레이스 컨디션을 해결하기 위한 한 줄짜리 패치입니다.
이전에 수정된 WaitForDelete의 레이스 컨디션(상태 감시자가 워치를 조기에 취소하는 문제)이 v4.2.2에서 되돌려졌습니다. Helm 테스트 스위트를 광범위하게 실행하거나 WaitForDelete 동작에 의존 중이라면 업그레이드 후 간헐적인 행(hang) 또는 타임아웃이 다시 나타날 수 있습니다. 업그레이드 후 테스트 실행에서 불안정성을 모니터링하세요. 향후 패치에서 적절한 수정이 나올 가능성이 높으므로, v4.2.2에 오래 머물지 마세요.
Helm v4.2.1는 동시 작업 중 발생하는 데이터 경쟁 상태를 고치고, 명령 출력 경로를 수정하며, 버전 범위 제약 파싱 문제를 해결합니다.
Helm 명령 성공 메시지가 stderr 대신 stdout으로 출력되도록 바뀌었습니다. CI/CD 파이프라인, 모니터링, 셸 스크립트에서 Helm 출력을 스트림별로 리다이렉트하거나 필터링한다면 예상 외로 동작할 수 있습니다. grep, tee, 출력 캡처 로직을 확인하세요. 대부분의 스크립트는 그대로 작동하지만, 스트림 의존도가 높은 로직은 재검토가 필요합니다.
Helm 4에서 프리릴리스 버전이나 공백이 없는 범위 제약(예: 'v1.0.0||v1.1.0')을 거부하거나 경고하던 문제가 해결됐습니다. 범위 제약을 피하거나 고정 버전으로 대체한 팀이라면 이제 제약 기반 선택을 도입할 수 있고, 이는 대규모 배포에서 의존성 관리를 단순화합니다.
동시 goroutine 실행 중 여러 경쟁 상태(upgrade+rollback, install+uninstall이 같은 클라이언트 대상, WaitForDelete 타이밍)가 모두 고쳐졌습니다. 고속 동시 Helm 작업(멀티 차트 배포, 병렬 재조정 루프, 대규모 테스트 스위트)을 운영한다면 업그레이드해서 간헐적 실패를 제거하세요. CI 파이프라인에서 불안정한 테스트 결과를 보고 있다면 특히 중요합니다.
Helm v3.21.1은 템플릿 작업 중 nil 포인터 패닉을 고치고 의존성을 업데이트합니다. 안정성 개선 패치입니다.
golang.org/x/net이 v0.55.0으로 올라가 GO-2026-5026을 고칩니다. 이는 공급망 의존성이며 Helm API에 직접 노출되지 않습니다. 보안 검사 도구가 net 취약점을 플래그하면 업그레이드하세요. Helm을 정상적으로 사용하는 경우라면 별도 조치는 필요하지 않습니다.
클러스터 없이 helm template 명령을 실행하는 환경(ClientOnly 모드)에서 nil 포인터 패닉이 발생하던 문제가 고쳐졌습니다. 이제 올바른 템플릿 에러를 반환합니다. 패닉을 잡아서 처리하는 자동화가 있다면 에러 처리를 타입이 있는 템플릿 에러로 업데이트하고 템플릿 워크플로를 테스트하세요.
oras-go v2.6.1 덕분에 레지스트리 작업이 HTTPS에서 plain HTTP로 폴백할 때 인증 정보를 유지합니다. HTTP 전용 엔드포인트를 가진 프라이빗 레지스트리를 사용한다면 안정성이 개선됩니다. 설정 변경은 필요 없으며 자동으로 적용됩니다.
Kubernetes v1.36.2는 Dynamic Resource Allocation 스케줄러, CSI 볼륨 재퍼블리싱, 엔드포인트 컨트롤러의 치명적 버그를 고치고 Go 1.26.4로 빌드한 패치 릴리스입니다.
Kubernetes 1.34 이상에서 바이너리 non-UTF8 데이터를 포함하는 Secret API 객체로부터 환경 변수를 설정하는 컨테이너가 제대로 읽을 수 없는 리그레션이 있었습니다. 1.36.2에서 수정되었습니다. 환경 변수에 텍스트가 아닌 Secret 데이터를 사용하는 워크로드가 있다면 업그레이드하여 디코딩 오류나 묵시적 실패를 예방하세요.
Kubernetes 1.36.0–1.36.1에서 스케줄러가 SharedCounters를 사용하는 드라이버와 멀티 할당 가능 디바이스를 함께 쓸 때 상호 배타적 디바이스 파티션을 여러 Pod에 할당하는 버그가 있습니다. 워크로드 실패, 디바이스 충돌, 크래시, 데이터 손실을 초래할 수 있습니다. DRA를 멀티 할당 가능 디바이스(특히 GPU나 공유 카운터를 사용하는 커스텀 액셀러레이터)로 운영 중이면 1.36.2로 즉시 업그레이드하세요. 최근 Pod 스케줄링 결정을 검토하여 충돌이 없는지 확인하세요.
Kubelet이 주기적 NodePublishVolume 호출(requiresRepublish=true로 트리거됨)이 실패할 때 CSI 마운트 디렉터리를 잘못 삭제하여 Pod에 레거시 볼륨 콘텐츠가 남는 문제가 있었습니다. 1.36.2에서 수정됩니다. requiresRepublish=true인 CSI 드라이버를 운영 중이면 이 패치가 일시적 네트워크 또는 스토리지 오류로 인한 데이터 일관성 위험을 제거합니다. 업그레이드하여 잠재적 데이터 문제를 예방하세요.
Kubernetes v1.35.6은 다중 노드 DRA 클레임 스케줄링, CSI 볼륨 재발행, 엔드포인트 처리의 심각한 버그를 수정하고 Go 1.25.11로 업그레이드했습니다.
1.34+ 버전의 바이너리 데이터(인증서, base64 인코딩된 키 등)를 포함한 Secret에서 환경 변수를 주입하지 못하는 버그가 있었습니다. Secret을 환경 변수로 주입 중이고 그 Secret에 바이너리 데이터가 있다면 v1.35.6으로 업그레이드하세요. 데이터베이스 자격증명이나 키를 Secret 환경 변수로 실행 중이면 버그가 조용히 주입을 깨뜨렸을 수 있으니 빨리 테스트하세요.
Kubernetes v1.35.6은 Go 1.25.11로 빌드됩니다. 커스텀 컨트롤러나 오퍼레이터를 같은 Go 버전에서 실행 중이면 호환성을 확인하고 다시 빌드하세요. CI/CD에서 Go 버전을 고정 중이면 빌드 설정을 업데이트해야 합니다.
세 가지 버그가 해결되었습니다. (1) 공유 카운터를 사용하는 DRA ResourceClaim AllocationMode All에서 스케줄러 패닉 제거. (2) 다중 노드와 노드별 클레임을 함께 사용하는 파드가 더 이상 Pending에서 교착되지 않음. (3) NodePublishVolume 오류 시 kubelet이 마운트 디렉터리를 삭제하지 않아 오래된 볼륨 데이터 손상 방지. DRA나 CSI 재발행을 사용 중이면 이전에 교착 상태가 되던 상황이 제거됩니다. 업그레이드하여 막힌 파드를 정리하고 향후 장애를 방지하세요.
쿠버네티스 v1.34.9는 CSI 마운트 볼륨 처리, 바이너리 Secret 데이터 처리, 엔드포인트 컨트롤러 패닉, kubeadm 인증서 처리를 수정합니다. Go 1.25.11 빌드로 런타임 성능이 향상됩니다.
v1.34 회귀로 인해 kubelet이 republish 실패 시 CSI 마운트 디렉터리를 삭제해 포드에 오래된 볼륨 데이터가 남아있었습니다. spec.requiresRepublish=true로 설정된 CSI 드라이버를 운영 중이면 즉시 업그레이드하세요. kubelet 로그에서 실패한 republish 시도를 확인한 후 업그레이드하면 이 버그를 맞고 있었는지 파악할 수 있습니다.
v1.34에서 바이너리(non-UTF8) 데이터가 포함된 Secret을 참조하는 환경 변수 파싱이 깨졌습니다. 워크로드에서 Secret을 환경 변수로 주입한다면 업그레이드 후 테스트하세요. 애플리케이션 시작 로그에서 파싱 오류를 확인하고, 필요하면 바이너리 Secret 값을 base64로 인코딩해야 할 수도 있습니다.
v1.34.9는 Go 1.25.11을 사용하며, 런타임 최적화와 보안 패치를 포함합니다. 제어 플레인과 워커 노드를 다음에 순환 업그레이드할 때 반영하세요. 애플리케이션 코드 수정은 불필요하지만, Go 업데이트로 인해 클러스터 지연 시간이 감소하고 메모리 사용량이 줄어들 수 있습니다.
CoreDNS v1.14.4는 DNSSEC 서명 버그 수정, 캐시 동작 개선, forward 플러그인의 hostname 지원 등 여러 기능 개선과 수정을 포함합니다.
RRset 서명 주체가 쿼리 존에서 해당 이름의 소유 존으로 바뀌었습니다. 기술적으로 올바른 수정이지만, 위임이 포함된 멀티존 DNSSEC 구성을 운영 중이라면 업그레이드 후 서명된 응답을 반드시 검증하세요. 기존 동작에 의존하던 존은 서명값이 달라질 수 있습니다. 프로덕션 전환 전에 주요 레코드에 dnssec-verify를 돌려보세요.
forward 플러그인이 TO 엔드포인트의 hostname을 런타임에 직접 해석합니다. 업스트림 리졸버 IP가 바뀌는 환경(클라우드 관리형 리졸버 등)이라면 설정을 FQDN으로 전환해 관리 부담을 줄일 수 있습니다. 단, 시작 시 hostname 해석에 실패하면 포워딩에 영향을 줄 수 있으니 스테이징에서 먼저 확인하세요.
기존에는 DNS 레코드의 실제 TTL과 무관하게 캐시 TTL이 3600s로 제한됐습니다. 이 제한이 없어졌으니, 내부 권위 존이나 루트 힌트처럼 변경이 드문 레코드는 max_ttl을 높여 업스트림 쿼리 부하를 줄일 수 있습니다. cache 플러그인 설정을 검토해 적절한 구간에 적용하세요.
CRI-O v1.35.4는 v1.35.3 대비 코드 변경이나 의존성 업데이트가 전혀 없는 패치 릴리스로, 사실상 재빌드 혹은 재태깅 수준입니다.
체인지로그와 의존성 변경이 하나도 없습니다. CI 파이프라인 문제나 아티팩트 서명 교정 목적의 재빌드로 추정됩니다. 현재 v1.35.3을 안정적으로 운영 중이라면 굳이 업그레이드할 이유가 없습니다. 배포 결정 전에 CRI-O GitHub의 릴리스 PR이나 이슈 트래커에서 이 태그가 생성된 배경을 먼저 확인하세요.
변경 사항이 없더라도, cosign으로 tarball 서명을 검증하고 bom 툴로 SPDX SBOM을 확인하는 공급망 검증 절차를 점검하는 기회로 삼으세요. 중요한 릴리스가 나왔을 때 이 프로세스가 이미 익숙해져 있어야 합니다.
CRI-O v1.36.1은 재시작 후 컨테이너 상태의 ImageRef가 repo@digest에서 이미지 ID 해시로 바뀌는 버그를 수정하고, List* RPC 디버그 로그 과다 출력 문제를 개선한 패치 릴리스입니다.
이 버그로 인해 CRI-O 재시작 후 컨테이너 상태의 ImageRef가 repo@digest 대신 원시 이미지 ID로 바뀌는 현상이 발생했습니다. ImageRef를 파싱하는 어드미션 컨트롤러, 감사 파이프라인, 이미지 정책 도구는 잘못된 형식을 받아 검증 실패나 감사 기록 오류를 낼 수 있습니다. 노드 재부팅이나 CRI-O 업그레이드가 잦은 환경이라면 v1.36.1로 즉시 패치하고, 관련 도구가 repo@digest 형식을 올바르게 처리하는지 확인하세요.
ListContainers나 ListPodSandboxes 호출이 빈번한 클러스터에서는 디버그 로그가 과도하게 쌓여 CRI-O 성능에 영향을 줬습니다. 이번 패치로 해당 경로의 로그 출력이 줄어들었습니다. 이 문제를 피하려고 로그 레벨을 낮췄던 환경이라면, 이제 디버그 로그를 다시 켜도 동일한 부담 없이 운영할 수 있습니다.
CRI-O v1.34.9는 동시 StopContainer 호출로 인한 패닉과 빠르게 종료되는 컨테이너의 잘못된 종료 코드 255 보고 문제를 수정한 순수 버그 픽스 릴리스입니다.
노드 드레인, 배치 워크로드의 빠른 파드 교체, 또는 여러 StopContainer 호출을 병렬로 실행하는 자동화가 있다면 기존 버전에서 CRI-O가 패닉으로 완전히 다운될 수 있습니다. 단순 에러가 아닌 런타임 크래시입니다. 해당 시나리오가 가능한 노드라면 v1.34.9로 즉시 업그레이드하세요.
종료 코드 255는 모니터링 스택에서 런타임 수준 장애로 해석되는 경우가 많고, 불필요한 파드 재시작이나 알림을 유발합니다. 빠르게 종료되는 init 컨테이너, 단기 Job 워크로드에서 255 종료 코드가 발생했다면 이 경쟁 조건에 의한 오탐이었을 가능성이 있습니다. 업그레이드 후 알림 규칙과 CrashLoopBackOff 이력을 확인해 잘못 분류된 장애가 없었는지 살펴보세요.
컨테이너가 빠르게 종료될 때 CRI-O가 종료 코드를 255로 잘못 보고하던 경쟁 조건(race condition) 버그를 수정한 패치 릴리스입니다.
모니터링·알림·재시작 정책이 종료 코드 255를 기준으로 동작한다면, 그간 빠르게 종료된 컨테이너들이 잘못 분류됐을 가능성이 있습니다. 업그레이드 후에는 종료 코드 255를 특정 신호로 처리하는 런북이나 OOMKill/CrashLoopBackOff 워크플로를 점검하세요. 단기 실행 컨테이너의 실제 종료 코드가 이제 올바르게 노출됩니다.
v1.33.12의 완전한 드롭인 교체 버전입니다. 의존성 변경도, 설정 수정도 필요 없습니다. 노드 롤링 드레인 후 CRI-O 바이너리만 교체하면 됩니다. 배치 잡, init 컨테이너, 단기 실행 워크로드가 많은 노드부터 우선 적용하는 것이 효과적입니다.
CVE-2026-46680 보안 패치와 함께 샌드박스 서비스 버그, AppArmor 호환성, OCI USER 스펙 처리 문제를 수정한 패치 릴리스입니다.
이번 릴리스의 핵심은 CVE-2026-46680 수정입니다. GHSA 어드바이저리에서 공격 범위와 심각도를 먼저 확인하세요. containerd 2.1.x를 운영 중이라면 이번 업그레이드를 최우선 배포 작업으로 처리해야 합니다. 의존성 변경이 없어 업그레이드 절차는 단순합니다.
기존에는 OCI 스펙의 USER 값이 유효 UID/GID 범위를 벗어나도 사용자명/그룹 조회로 암묵적으로 처리되어 설정 오류가 숨겨졌습니다. 이제는 명시적 에러가 반환되므로, 숫자형 USER 값을 사용하는 컨테이너가 있다면 업그레이드 후 갑자기 실패할 수 있습니다. 프로덕션 배포 전에 컨테이너 스펙을 반드시 점검하세요.
AppArmor abi 조건부 설정 수정은 구버전 AppArmor(예: Ubuntu 20.04의 2.x)를 사용하는 환경에서 실질적인 차단 요인이었습니다. 샌드박스 서비스 버그도 이벤트 기반 워크플로와 샌드박스 생성 설정에 직접 영향을 줍니다. Kata Containers 등 샌드박스 기반 런타임을 쓰고 있다면 이번 수정이 특히 중요합니다.
etcd v3.6.12는 3.6 시리즈 패치 릴리스입니다. 릴리스 노트 자체에는 변경 내용이 없으므로, 업그레이드 전 반드시 CHANGELOG를 직접 확인해야 합니다.
v3.6.12 릴리스 노트에는 변경 내용이 기재되어 있지 않습니다. 현재 운영 버전과 v3.6.12 사이의 모든 변경 사항을 CHANGELOG-3.6.md에서 직접 확인하세요. 공식 업그레이드 가이드도 3.6 시리즈에 breaking change가 있을 수 있다고 명시하고 있으니, 스테이징 환경에서 먼저 검증한 뒤 프로덕션에 적용하는 절차를 권장합니다.
etcd는 gcr.io를 주 레지스트리, quay.io를 보조 레지스트리로 운영합니다. CI/CD 파이프라인이나 배포 매니페스트가 quay.io를 참조하고 있다면, 이미지 동기화 시차가 생길 수 있습니다. 프로덕션 클러스터는 gcr.io/etcd-development/etcd를 기준으로 설정하는 편이 안전합니다.
etcd v3.5.31은 3.5 브랜치의 패치 릴리스입니다. 공개된 릴리스 노트가 매우 간략하므로, 업그레이드 전 전체 CHANGELOG를 직접 확인해야 합니다.
etcd 팀은 패치 릴리스에도 Breaking Change가 포함될 수 있다고 명시하고 있습니다. 마이너 버전이 바뀌지 않았다고 무조건 안전하다고 가정하면 안 됩니다. 현재 운영 중인 클러스터 버전과 API, 스토리지 포맷 변경 여부를 대조한 뒤 유지보수 일정을 잡으세요.
이번 릴리스 노트에 실질적인 변경 내용이 거의 담겨 있지 않습니다. 실제 배포 전에 etcd 저장소의 CHANGELOG-3.5.md를 직접 열어 버그 수정 항목을 확인하세요. 3.5 패치 릴리스에는 컴팩션 처리나 리스 관련 수정이 자주 포함되는 편입니다.
etcd v3.4.45는 3.4 브랜치의 유지보수 릴리스입니다. 릴리스 노트에 세부 내용이 거의 없으므로, 업그레이드 전에 반드시 CHANGELOG를 직접 확인해야 합니다.
릴리스 페이지에서 브레이킹 체인지가 있을 수 있다고 명시하고 있습니다. etcd 3.4.x는 Kubernetes 클러스터에서 광범위하게 사용되는 브랜치입니다. 특히 쿼럼과 데이터 무결성이 중요한 프로덕션 환경이라면 etcd.io의 업그레이드 가이드를 먼저 검토한 뒤 적용하세요.
이번 릴리스 페이지에는 변경 내용이 거의 없습니다. 업그레이드 전에 etcd GitHub 저장소에서 CHANGELOG-3.4.md를 직접 열어 실제 변경 사항을 파악하세요. etcd는 클러스터의 핵심 데이터 저장소인 만큼, 패치처럼 보이는 릴리스라도 내용을 확인하지 않고 적용하는 건 위험합니다.
Lima v2.1.2는 hostagent 리소스 누수, 좀비 프로세스, gRPC 연결 누수를 수정한 유지보수 릴리스입니다. Kubernetes 1.36, Ubuntu 26.04, Fedora 44 템플릿도 업데이트됩니다.
`template:alpine`이 `template:alpine-3.21`, `template:alpine-3.22`, `template:alpine-3.23`으로 분리됐습니다. 스크립트, CI, 설정 파일에서 `template:alpine`을 그대로 참조하면 오류가 발생합니다. 업그레이드 전에 모든 참조를 버전이 명시된 템플릿으로 교체하세요.
스크립트나 dotfile에 `_LIMA_QEMU_UEFI_IN_BIOS` 환경변수가 설정되어 있다면 지금 제거하는 게 좋습니다. 이번 릴리스에서 deprecated 처리됐고, 향후 버전에서 완전히 삭제될 가능성이 높습니다. limactl을 호출하는 CI 파이프라인과 래퍼 스크립트를 함께 점검하세요.
GuestAgentClient 누수, inotify watcher 누적, 재연결 시 gRPC 스트림 오동작을 각각 수정한 네 가지 패치가 포함됐습니다. Lima 인스턴스를 장시간 운영하면서 메모리 증가나 연결 이상을 경험했다면, 이번 릴리스가 직접적인 해결책입니다. 다음 릴리스를 기다리지 말고 바로 업그레이드하는 편이 낫습니다.
containerd v2.2.4는 두 건의 CVE 패치와 함께 overlay, sandbox, AppArmor, seccomp 관련 버그를 수정한 보안 중심 패치 릴리스입니다.
containerd 코어(CVE-2026-46680)와 go-jose 의존성(CVE-2026-34986) 각각 하나씩, 총 두 건의 CVE가 수정됐습니다. 프로덕션 배포 모두에 해당하는 내용이므로 정기 점검 일정을 기다릴 이유가 없습니다. 긴급 패치 프로세스로 처리하세요. Kubernetes 노드에서 containerd를 런타임으로 사용 중이라면 오케스트레이터 종류와 무관하게 모두 영향을 받습니다.
기본 seccomp 프로파일이 AF_ALG(소켓 기반 커널 암호화 API)를 차단하도록 강화됐습니다. 일반적인 워크로드에는 영향이 없지만, 암호화 처리나 하드웨어 오프로드 목적으로 AF_ALG 소켓을 직접 사용하는 컨테이너는 시스템 콜 거부가 발생할 수 있습니다. 업그레이드 전에 커스텀 또는 관대한 seccomp 프로파일을 사용하는 워크로드를 점검해두세요.
사용자 네임스페이스(rootless 컨테이너 포함)에서 overlay 스냅샷터를 쓸 때 'rebase' 기능이 레이어 추출 실패를 일으키던 문제가 해결됐습니다. UserNS 컨텍스트에서 자동으로 비활성화되므로 별도 설정 변경 없이 업그레이드만 하면 됩니다. 업데이트 후 rootless 워크로드의 마운트 정상 동작 여부를 확인하는 정도면 충분합니다.
containerd 2.0.9는 CVE-2026-46680 보안 취약점 패치와 tar 추출 시 TOCTOU 경쟁 조건 수정, containerd 재시작 시 컨테이너 종료 이벤트 유실 문제 등 여러 버그를 수정했습니다.
CVE-2026-46680 보안 취약점이 이번 릴리스에서 수정됐습니다. containerd 2.0.x를 사용 중이라면 즉시 2.0.9로 업그레이드하세요. GHSA 보안 권고문에서 영향받는 구성과 심각도를 확인한 뒤 유지보수 일정을 잡되, 가능한 한 빨리 적용하는 것을 권장합니다.
tar 추출 중 발생하는 TOCTOU 경쟁 조건은 악의적으로 조작된 이미지 레이어로 경로 탈출을 시도하는 데 악용될 수 있습니다. 신뢰할 수 없는 서드파티 이미지를 pull하는 환경이라면 업그레이드와 함께 이미지 소스 제한 정책도 함께 점검하세요.
AppArmor ABI 필드가 이제 조건부로 설정됩니다. AppArmor 3.0 미만 시스템에서는 기존에 호환되지 않는 ABI가 프로파일에 삽입되던 문제가 해결되는 것이지만, 커스텀 프로파일로 이 문제를 우회해왔다면 업그레이드 후 AppArmor 동작을 반드시 검증하세요.
containerd 재시작 후 컨테이너가 예상치 못한 상태로 멈추는 현상, 특히 파드가 빠르게 순환되는 Kubernetes 환경에서 자주 발생했다면 이 수정이 근본 원인을 해결합니다. 별도 설정 변경 없이 업그레이드만으로 적용됩니다.
containerd 1.7.32는 CVE-2026-46680 보안 패치를 포함하며, 기본 seccomp 프로파일에서 AF_ALG 소켓을 차단하고 OCI spec USER 처리 버그도 수정했습니다.
이번 릴리스의 핵심은 CVE-2026-46680입니다. containerd 보안 어드바이저리(GHSA-fqw6-gf59-qr4w)에서 심각도와 공격 범위를 먼저 확인하되, 1.7.x를 운영 중이라면 패치를 미루지 마세요. 유지보수 창을 조정하더라도 업그레이드 자체는 최우선으로 계획해야 합니다.
기본 seccomp 정책이 이제 AF_ALG(커널 암호화) 소켓 패밀리를 차단합니다. 하드웨어 암호화 오프로딩이나 HSM 연동 워크로드는 업그레이드 후 시작에 실패할 수 있습니다. 일반 컨테이너에는 영향이 없지만, 특수한 암호화 기능을 쓰는 컨테이너라면 기본값을 완화하는 대신 커스텀 seccomp 프로파일로 명시적으로 허용하는 방식으로 대응하세요.
기존에는 OCI spec에 유효 범위를 벗어난 UID/GID가 있으면 예측 불가한 사용자 이름 조회가 조용히 실행됐습니다. 이제는 컨테이너 시작 자체가 실패합니다. 고 숫자 UID를 사용하는 이미지가 있다면 업그레이드 전에 미리 점검하세요. 특히 레거시 이미지나 직접 빌드한 OCI spec을 쓰는 경우 주의가 필요합니다.
Ubuntu 20.04, Debian Bullseye 등 AppArmor 2.x를 탑재한 배포판에서 1.7.x 일부 버전이 AppArmor 프로파일 로드 오류를 일으켰습니다. abi 지시어를 조건부로 설정하도록 수정되었으니, 관련 오류를 겪었던 환경이라면 업그레이드 후 프로파일 로딩 상태를 확인하세요.
containerd 2.3.1은 CVE-2026-46680을 패치하고, 기본 seccomp 정책 강화 및 런타임/스냅샷터 버그를 수정한 패치 릴리스입니다.
이번 릴리스에서 CVE-2026-46680이 수정됐습니다. 2.3.0을 운영 중이라면 취약점 세부 정보가 공개되기 전에 모든 노드에 2.3.1을 배포하세요. 패키지 매니저나 배포 파이프라인을 통해 빠르게 적용하는 것이 좋습니다.
기본 seccomp 프로파일이 AF_ALG(커널 소켓 기반 암호화 API)를 차단하도록 강화됐습니다. 대부분의 컨테이너 워크로드에는 영향이 없지만, AF_ALG를 직접 사용하는 애플리케이션은 업그레이드 후 동작이 중단될 수 있습니다. 프로덕션 적용 전에 strace 또는 소켓 호출 감사를 통해 영향 여부를 확인하세요. 커스텀 seccomp 프로파일을 직접 지정한 경우엔 영향받지 않습니다.
Kata Containers, gVisor 등 대체 런타임을 쓰는 환경이라면 샌드박스 태스크 API 수정 사항이 실제 컨테이너 생성 및 태스크 관리에 미치는 영향을 반드시 확인하세요. Runc 옵션의 태스크 필드가 deprecated 처리됐으니, 커스텀 Runc 옵션 설정에서 해당 필드를 제거하는 작업도 미리 진행해두는 것이 좋습니다.
runc 외 런타임(Kata, gVisor 등)에서 샌드박스 태스크 API 엔드포인트가 동작하지 않던 버그를 수정한 패치 릴리스입니다.
api/v1.11.0에서 Kata Containers, gVisor, 커스텀 샌드박스 shim을 사용하는 경우 태스크 API 엔드포인트가 정상 동작하지 않는 버그가 있습니다. 태스크 생성·삭제·exec 등의 작업이 조용히 실패하거나 오작동할 수 있으니, api/v1.11.1로 업그레이드 후 태스크 라이프사이클 동작을 반드시 검증하세요.
이번 수정으로 CreateTaskRequest 프로토에 태스크 API 주소 필드가 추가됐습니다. 커스텀 shim을 직접 구현·관리하고 있다면, 해당 필드를 읽는 코드 경로가 있는지 검토하세요. 기존에 비어 있던 필드가 이제 채워져 전달되므로 동작 차이가 생길 수 있습니다. 일반 runc 워크로드는 별도 조치가 필요 없습니다.
Helm v3.21.0은 Kubernetes 클라이언트 라이브러리를 v1.36으로 올리고, OpenTelemetry CVE를 패치하며, OCI 인덱스 차트 풀 버그를 수정합니다. v3 EOL이 가까워지고 있습니다.
이번 릴리스에서 OpenTelemetry 패키지의 CVE를 직접 수정했습니다. CI/CD 파이프라인이나 자동화 툴링에서 Helm을 사용 중이라면 다음 패치 릴리스를 기다리지 말고 지금 바로 v3.21.0으로 올리세요.
릴리스 노트에 Helm v3 EOL이 명시적으로 경고됩니다. v3.22.0이 Kubernetes v1.37을 타깃으로 하는 마지막 주요 피처 릴리스가 될 수 있습니다. 커스텀 플러그인이나 Helm CLI, Go SDK를 기반으로 한 자동화 코드가 있다면 지금부터 v4 변경 사항을 검토하세요.
OCI 이미지 인덱스 매니페스트에서 차트를 풀하는 버그가 수정됐습니다. 멀티아키텍처 환경에서 이 문제를 회피하기 위해 다이제스트 직접 참조나 특정 매니페스트 태그를 써왔다면, 해당 워크어라운드가 더 이상 필요하지 않을 수 있으니 검토해 보세요.
Helm v4.2.0은 Kubernetes 1.36 클라이언트 지원, mustToToml 템플릿 함수 추가, generateName 리소스에 대한 dry-run 서버 모드 수정, 그리고 post-renderer YAML 파싱 버그 수정을 포함합니다.
--hide-notes와 --render-subchart-notes가 deprecated됐고 향후 릴리스에서 제거될 가능성이 높습니다. helm install, upgrade, template 명령을 쓰는 CI 파이프라인과 스크립트를 지금 점검해서 해당 플래그를 미리 제거해두세요. 나중에 강제로 마이그레이션하는 상황을 피할 수 있습니다.
mustToToml은 mustToJson과 동일하게 동작합니다. TOML 직렬화에 실패할 경우 빈 출력이나 잘못된 결과를 내놓는 대신 명시적 에러를 반환합니다. 차트 템플릿에서 toToml을 쓰고 있다면 mustToToml로 교체해 렌더링 실패를 즉시 감지할 수 있도록 하세요.
이전에는 --dry-run=server가 name 대신 generateName을 사용하는 리소스를 건너뛰어서 검증이 된 것처럼 보였습니다. 이제 수정됐으므로, generateName을 사용하는 차트에 대해 서버 사이드 dry-run을 다시 실행해보세요. 기존에 조용히 무시되던 검증 오류가 드러날 수 있습니다.
v1.36.1은 ZFS 노드, Windows 네트워킹, kubeadm 클러스터 관리 등 8개 버그를 수정한 패치 릴리스입니다.
v1.36.0에서 cadvisor 플러그인 누락으로 ZFS 스토리지를 사용하는 노드의 kubelet이 시작되지 않습니다. v1.36.0을 ZFS 환경에 배포했다면 해당 노드들이 정상 작동하지 않을 가능성이 높으니, 추가 롤아웃 전에 반드시 v1.36.1로 패치하세요.
파드 IP가 재사용될 때 오래된 HNS 엔드포인트가 남아 트래픽이 엉뚱한 노드로 라우팅되는 문제였습니다. 증상이 DNS 설정 오류처럼 보여 원인 파악이 어렵습니다. Windows 노드에서 L2Bridge 네트워킹을 쓴다면 우선순위를 높여 이번 패치를 적용하세요.
클라우드 환경에서 LB가 비동기로 프로비저닝될 때 kubeadm init이 실패하거나 의도치 않게 동작하는 경우가 있었습니다. 이제 부트스트랩 중에는 로컬 API 엔드포인트를 먼저 사용하고 이후 LB 엔드포인트로 전환하는 방식으로 수정됐습니다. 다음 클러스터 초기화나 업그레이드 전에 이 버전으로 올려두는 게 좋습니다.
Kubernetes v1.35.5는 스케줄러 상태 오염, Windows 네트워킹, kube-proxy 대규모 클러스터 동작, kubeadm 초기화 문제를 수정한 패치 릴리스입니다.
kubeadm init이 admin.conf와 super-admin.conf 생성 시 controlPlaneEndpoint 대신 localAPIEndpoint를 사용하도록 바뀌었습니다. 커스텀 controlPlaneEndpoint 설정을 쓰는 클러스터라면 업그레이드 후 생성된 kubeconfig가 올바른지 반드시 검증하세요. 초기화 후 tooling이 controlPlaneEndpoint 기반 kubeconfig를 참조한다면 스테이징에서 먼저 테스트하는 것을 권장합니다.
엔드포인트가 1000개를 넘는 환경에서 kube-proxy가 불필요한 full-sync를 반복 실행하고 있었습니다. 이번 패치로 해당 동작이 멈추므로, 바쁜 클러스터의 CPU와 네트워크 오버헤드를 직접 줄일 수 있습니다. 다음 유지보수 윈도우에 kube-proxy 업그레이드를 포함시키세요.
동일한 이름의 Pod가 스케줄링 실패를 반복할 때 in-flight 상태 추적 데이터가 무한 증가하는 버그였습니다. 스케줄러 메모리 사용량이 지속적으로 증가하거나 스케줄링 지연이 관찰됐다면, 이 패치가 근본 원인을 해결합니다.
v1.34.8은 IPv6 CIDR 주소 할당 오류, 스케줄러 메모리 누수, Windows DNS 라우팅 장애, kubeadm 클러스터 부트스트랩 문제를 수정한 버그 픽스 패치입니다.
kube-apiserver의 kubelet 클라이언트가 이제 공용 역할 대신 'system:kubelet-api-admin' 전용 ClusterRole에 바인딩됩니다. kubeadm으로 관리되는 클러스터는 업그레이드 시 자동으로 적용되지만, 업그레이드 후 'kubectl get clusterrolebinding'으로 실제 적용 여부를 확인하는 것을 권장합니다.
64비트 IPv6 ServiceCIDR 버그로 인해 일부 클러스터에서 서브넷 범위를 벗어난 서비스 IP가 할당되어 있을 수 있습니다. v1.34.8로 업그레이드한 뒤 기존 서비스 IP가 설정된 서브넷 내에 있는지 확인하고, 범위를 벗어난 서비스는 재생성을 검토하세요. /64 IPv6 서비스 CIDR을 사용하는 클러스터에서 특히 확인이 필요합니다.
1000개 이상의 엔드포인트를 운영하는 환경에서 kube-proxy가 대규모 클러스터 모드임에도 불필요한 full-sync를 수행해왔습니다. 이번 패치로 해당 동작이 제거됩니다. 별도 설정 변경 없이 업그레이드만으로 적용되며, 업그레이드 후 kube-proxy CPU 사용량을 모니터링해 개선 효과를 확인하세요.
