릴리즈

v1.33.12는 kubeadm 버그 4건을 수정한 패치 릴리스로, 클러스터 초기화 안정성, etcd 헬스체크, kubelet API RBAC 강화에 집중했습니다.

• securitykube-apiserver kubelet 클라이언트용 RBAC 역할 분리 적용

  kube-apiserver가 kubelet 클라이언트 자격증명에 전용 ClusterRole 'system:kubelet-api-admin'을 사용합니다. RBAC 경계가 명확해지고 자격증명 오용 시 영향 범위가 줄어듭니다. 기존 클러스터에 즉각적인 조치는 불필요하지만, kubeadm 업그레이드 후 RBAC 감사 목록에 해당 역할이 반영됐는지 확인하세요.

• enhancement외부 로드밸런서 환경에서 kubeadm init을 쓴다면 업그레이드 권장

  기존에는 kubeadm init이 로드밸런서 엔드포인트를 kubeconfig에 기록했는데, 첫 번째 apiserver가 뜨기 전에는 LB가 아직 없는 경우가 많아 실패하는 닭-달걀 문제가 있었습니다. 이번 수정으로 초기화 시에는 localAPIEndpoint를 사용하도록 바뀌었습니다. 재시도 스크립트나 수동 kubeconfig 편집으로 우회하던 팀이라면 이 패치로 그 작업이 불필요해집니다.

• enhancementetcd 쿼럼 기반 헬스체크로 오탐 실패 차단

  기존 헬스체크는 멤버 하나라도 비정상이면 kubeadm 작업 전체를 막았습니다. 쿼럼이 유지되는 한 작업이 진행되도록 바뀌었습니다. 3노드나 5노드 etcd 구성에서 멤버 하나의 장애로 kubeadm upgrade나 join이 실패했던 경험이 있다면, 이 패치가 그 문제를 해결해 줍니다.

CRI-O v1.36.0은 CNI 상태 지속 모니터링, GOMAXPROCS 주입 설정, TLS 강화 옵션, CVE 패치를 포함하며, 여러 레이스 컨디션과 cgroupv2 버그도 수정했습니다.

• securityv1.36.0 업그레이드로 CVE-2026-35469 즉시 패치

  spdystream 의존성에 CVE-2026-35469가 존재합니다. v1.35.x를 운영 중이라면 이 취약점 하나만으로도 업그레이드 사유가 충분합니다. 업그레이드 후 릴리스 번들을 cosign으로 서명 검증하고, 이번 릴리스에 포함된 SLSA 출처 증명과 OpenVEX 취약점 보고서도 확인하세요.

• breakingCNI 플러그인 STATUS verb 지원 여부를 업그레이드 전에 반드시 확인

  이제 CRI-O는 초기 준비 완료 이후에도 CNI 플러그인에 STATUS verb를 지속적으로 호출합니다. 조용히 degraded 상태였던 플러그인이 노드를 NetworkReady=false로 바꿔 파드 스케줄링을 차단할 수 있습니다. Cilium, Calico, Flannel은 STATUS를 지원하지만 오래된 커스텀 플러그인은 그렇지 않을 수 있습니다. 운영 환경 적용 전 반드시 비운영 클러스터에서 동작을 검증하세요.

• enhancement운영 환경 CRI-O API에 TLS 최소 버전과 cipher suite 명시적 설정 권장

  `[crio.api]`에 추가된 `tls_min_version`과 `tls_cipher_suites` 옵션으로 스트리밍·메트릭 엔드포인트에 TLS 정책을 강제할 수 있습니다. 기본값은 TLS 1.2지만, 보안 요구사항이 높은 환경이라면 `tls_min_version = TLS13`으로 명시하고 취약 cipher suite를 제거하세요. 다음 노드 롤아웃 전에 Ansible, SaltStack 등 구성 관리 도구에 반영해 두는 것이 좋습니다.

v1.35.3은 CVE-2026-35469 패치, 컨테이너 중지 시 패닉 및 종료 코드 경쟁 조건 수정, GOMAXPROCS 하한 주입 기능 추가가 핵심입니다.

• securityCVE-2026-35469 패치를 위해 v1.35.3으로 즉시 업그레이드

  spdystream 의존성의 취약점(CVE-2026-35469)이 moby/spdystream v0.5.1 업데이트로 수정됐습니다. v1.35.x를 사용 중이라면 별도 우회책 없이 바이너리 업그레이드만이 해결 방법이니 v1.35.3으로 바로 올리세요.

• breakingCNI 헬스 모니터링은 추가됐다가 같은 릴리스에서 롤백됨

  STATUS verb를 이용한 CNI 플러그인 상태 모니터링 기능이 추가됐지만, 노드 부트스트래핑 회귀가 확인돼 즉시 되돌렸습니다. v1.35.3에서 CNI 동작은 이전과 동일합니다. 이 기능을 보고 도입을 계획했다면 일단 보류하세요. 수정 후 이후 릴리스에 다시 포함될 가능성이 높습니다.

• enhancement'min_injected_gomaxprocs'로 Go 워크로드의 CPU 과소활용 방지

  CPU request가 낮으면 GOMAXPROCS가 1로 설정돼 Go 기반 워크로드 성능이 저하됩니다. 새로운 'min_injected_gomaxprocs' 옵션을 설정하면 CRI-O가 max(하한값, cpu.request)를 GOMAXPROCS로 주입합니다. CPU request는 낮게 잡았지만 스레드가 필요한 Go 사이드카나 에이전트를 운영한다면 CRI-O 설정에 이 값을 지정해 두세요.

CRI-O v1.34.8은 spdystream 의존성의 CVE-2026-35469를 패치하고, 런타임 메트릭 추가 및 GOMAXPROCS 주입 설정 기능을 제공합니다.

• securityCVE-2026-35469 패치 — v1.34.8로 즉시 업그레이드

  spdystream은 exec, attach, port-forward 같은 스트리밍 연결에 쓰이므로 취약점 노출 범위가 넓습니다. 설정 변경 없이 바이너리 교체만으로 패치가 완료되므로, 모든 노드를 v1.34.8로 업그레이드하세요.

• enhancement새 런타임 메트릭으로 노드 설정 감사

  `container_runtime_crio_default_runtime` 메트릭을 Prometheus에서 수집하면 각 노드가 기대하는 런타임(runc, kata-containers 등)으로 실제 동작 중인지 확인할 수 있습니다. 노드 이미지 업그레이드 후 설정 드리프트를 조기에 잡을 수 있으니, 업그레이드 후 예상치 못한 런타임 값에 대한 알림 규칙을 추가하세요.

• enhancementcpu.request가 낮은 워크로드에 min_injected_gomaxprocs 검토

  cpu.request가 0.1코어처럼 낮은 컨테이너는 Go 런타임이 GOMAXPROCS=1로 동작해 병렬 처리가 직렬화됩니다. `min_injected_gomaxprocs`로 하한값을 높이면 스레드 수가 적절히 올라갑니다. 다만 노드 밀도가 높은 환경에서는 전체 컨테이너의 고루틴 스케줄링 오버헤드가 커질 수 있으니, Guaranteed QoS가 아닌 워크로드부터 시험 적용하고 CPU 스로틀링 메트릭을 확인한 뒤 클러스터 전체에 배포하세요.

CVE-2026-35469 보안 패치와 컨테이너 GOMAXPROCS 하한값을 지정하는 min_injected_gomaxprocs 옵션이 추가된 유지보수 릴리스입니다.

• securityCVE-2026-35469 즉시 패치 필요

  spdystream은 CRI-O 내부 HTTP/2 멀티플렉싱 경로에서 사용됩니다. CVE-2026-35469가 해당 라이브러리에서 발견된 만큼, v1.33.x를 운영 중인 클러스터는 다음 정기 유지보수 창까지 기다리지 말고 v1.33.12로 업그레이드하세요. 내부 취약점 스캐너에서 이 CVE가 탐지되고 있다면 우선순위를 높여 처리하는 게 맞습니다.

• enhancementmin_injected_gomaxprocs로 Go 워크로드 CPU 활용률 개선

  Go 런타임은 기본적으로 노드의 전체 논리 CPU 수를 GOMAXPROCS로 설정하는데, cpu.request가 작은 컨테이너에서는 고루틴 스케줄링 효율이 떨어집니다. 이 옵션으로 하한값(예: 2 또는 4)을 지정하면 OS 스레드 부족 현상을 방지할 수 있습니다. Burstable, BestEffort QoS 파드에만 적용되고 Guaranteed 파드는 영향받지 않습니다. 먼저 cpu.request가 낮은 Go 기반 워크로드를 파악한 뒤, 보수적인 값으로 시작해 고루틴 동작을 모니터링하면서 점진적으로 조정하세요.

etcd v3.6.11 패치 릴리스입니다. 릴리스 노트 자체엔 상세 내용이 없으니, 업그레이드 전 반드시 CHANGELOG-3.6.md를 직접 확인하세요.

• breaking업그레이드 전 공식 가이드 반드시 확인

  릴리스 노트에 breaking change 가능성이 명시되어 있습니다. 단순 패치라고 넘기지 말고, CHANGELOG-3.6.md와 업그레이드 가이드를 현재 버전과 비교한 뒤, 비운영 클러스터에서 먼저 검증하세요.

• enhancement파이프라인의 컨테이너 레지스트리 출처 점검

  etcd의 공식 기본 레지스트리는 gcr.io입니다. CI/CD나 쿠버네티스 매니페스트에 quay.io/coreos/etcd가 아직 남아 있다면 보조 미러를 쓰는 셈이라 최신 이미지 반영이 늦을 수 있습니다. gcr.io/etcd-development/etcd로 이미지 참조를 교체하세요.

etcd v3.5.30은 3.5 시리즈의 유지보수 릴리스입니다. 릴리스 노트에 구체적인 내용이 없으므로 GitHub의 CHANGELOG-3.5.md를 직접 확인해야 합니다.

• breaking업그레이드 전 CHANGELOG 직접 확인 필수

  릴리스 공지가 CHANGELOG-3.5.md를 가리키는 것에 그치고 있습니다. 프로덕션 클러스터를 업그레이드하기 전에 반드시 현재 버전 이후의 모든 항목을 꼼꼼히 읽어야 합니다. 동작 방식 변경이나 데이터 포맷 변경은 사전 검토 없이 넘어가면 장애로 이어질 수 있습니다.

• enhancement컨테이너 이미지 소스를 gcr.io로 우선 설정

  프로젝트 공식 기준으로 gcr.io가 기본 레지스트리이고 quay.io는 보조입니다. 배포 파이프라인이나 에어갭 미러가 여전히 quay.io를 기본으로 쓰고 있다면, gcr.io를 우선으로 전환하는 편이 좋습니다. 신규 이미지는 gcr.io에 먼저 올라오는 경향이 있습니다.

etcd v3.4.44는 3.4 브랜치의 유지보수 릴리스입니다. 릴리스 노트에 변경 내용이 없으므로, 업그레이드 전에 반드시 CHANGELOG를 직접 확인해야 합니다.

• breaking릴리스 노트가 비어 있음 — CHANGELOG 직접 확인 필수

  이번 릴리스 노트에는 변경 내용이 전혀 기재되어 있지 않습니다. 운영 클러스터에 적용하기 전, CHANGELOG-3.4.md를 직접 열어 현재 버전과 비교하세요. Kubernetes 컨트롤 플레인에서 이 단계를 건너뛰면 업그레이드 도중 예상치 못한 동작 변경에 맞닥뜨릴 수 있습니다.

• enhancement3.4 사용 중이라면 3.5 마이그레이션 계획을 세울 시점

  3.4.x는 현재 중요 버그 수정만 받는 상태입니다. Kubernetes 백엔드로 etcd를 운영 중이라면 지원 기간이 긴 3.5로의 전환을 검토할 때입니다. 업그레이드 전에 사용 중인 Kubernetes 버전과의 호환성을 먼저 확인하세요.

containerd 2.3.0은 Kubernetes 릴리스 주기에 맞춘 새 4개월 케이던스 하의 첫 LTS 버전으로, 2년 이상 지원이 보장되며 NRI, EROFS, 관측성 분야에서 대폭 개선됐습니다.

• breaking업그레이드 전 NRI 플러그인 이름에서 쉼표 제거 필수

  새 OCI 훅 소유자 누적 로직이 쉼표를 내부 구분자로 씁니다. 이름에 쉼표가 포함된 NRI 플러그인은 2.3.0에서 동작하지 않습니다. 지금 바로 플러그인 이름을 점검하고, 쉼표가 있다면 바이너리 이름과 설정 파일 모두 변경한 뒤 업그레이드하세요.

• enhancement1.7 → 2.3 LTS 마이그레이션 계획 수립 시작

  이번 릴리스는 containerd 1.7 LTS의 공식 업그레이드 대상입니다. 순차적 LTS 간 직접 업그레이드가 공식 테스트됩니다. 아직 1.7을 쓰고 있다면 지금이 마이그레이션 계획을 세울 적기입니다. 2.3은 최소 2년 지원이 보장되므로, 대략 2027년까지 Kubernetes 클러스터의 안정적인 기반이 됩니다.

• enhancement트레이스 전파 설정으로 플러그인·런타임 관측성 확보

  이제 OTel 트레이스가 containerd와 플러그인 간 gRPC RPC를 통해 전파되고, 트레이스 ID를 로그에 주입할 수 있습니다. Jaeger나 Tempo 같은 분산 트레이싱 스택을 운영 중이라면, containerd 설정에서 OTLP 익스포터를 구성하고 로그의 trace ID 주입을 활성화하세요. 컨테이너 라이프사이클 이벤트가 트레이싱 백엔드에서 보이지 않던 공백이 드디어 채워집니다.

containerd API v1.11.0은 containerd 2.3 릴리스에 맞춰 새 shim 부트스트랩 프로토콜, 컨테이너 파일시스템 복사 전송 타입, 샌드박스 spec 필드를 도입했습니다.

• securitygRPC v1.59.0 → v1.79.3 대폭 업그레이드 — 보안 패치 다수 포함

  마이너 버전이 20단계 올라간 만큼 그간 쌓인 보안·안정성 수정이 상당합니다. gRPC를 별도로 핀닝하거나 벤더링하는 환경이라면 v1.79.3 기준으로 의존성 트리를 재조정해야 합니다. golang.org/x/* 패키지들도 일괄 업그레이드됐으니, 이 API 버전을 프로덕션에 올리기 전에 전체 의존성 감사를 권장합니다.

• breaking샌드박스 API 변경: Container 필드 제거됨 — 관련 코드 즉시 점검 필요

  샌드박스 메타데이터에서 Container 필드가 삭제되고 spec 필드로 대체됐습니다. 샌드박스 메타데이터를 직접 읽거나 쓰는 컨트롤러, 커스텀 런타임, 내부 툴링이 있다면 지금 바로 점검해야 합니다. 이전 proto 정의로 컴파일된 코드는 containerd 2.3 환경에서 런타임 오류가 발생합니다.

• breakingshim 부트스트랩 프로토콜이 protobuf로 교체 — 커스텀 shim은 반드시 업데이트

  부트스트랩 프로토콜이 JSON에서 protobuf로 바뀌었고, 기능과 로그레벨도 문자열에서 enum으로 변경됐습니다. 커스텀 shim을 유지하거나 containerd API를 직접 벤더링하는 경우, containerd 2.3 배포 전에 부트스트랩 처리 로직을 반드시 수정해야 합니다. kata-containers, nydus 같은 서드파티 shim의 호환 릴리스도 함께 확인하세요.

Kubernetes v1.36은 다수의 GA 승격, DRA 대규모 확장, 갱 스케줄링 API 신규 도입, 그리고 업그레이드 전 즉시 조치가 필요한 메트릭 이름 변경을 포함하는 대형 릴리스입니다.

• breaking업그레이드 전 모니터링 수정 필수 — 메트릭 이름 두 개 변경

  volume_operation_total_errors와 etcd_bookmark_counts가 각각 volume_operation_errors_total, etcd_bookmark_total로 이름이 바뀌었습니다. 기존 이름을 쓰는 Prometheus 알림이나 Grafana 대시보드는 업그레이드 후 조용히 동작을 멈춥니다. v1.36을 프로덕션에 적용하기 전에 모니터링 스택 전체를 점검하고 참조를 모두 교체하세요.

• breakingDRA 사용 중이라면 RBAC 업데이트 필수

  DRAResourceClaimGranularStatusAuthorization 피처 게이트가 v1.36에서 베타로 기본 활성화됩니다. DRA 스케줄러·컨트롤러는 resourceclaims/binding에 대한 update/patch 권한이, DRA 드라이버는 resourceclaims/driver에 대한 associated-node:update 또는 arbitrary-node:update 권한(특정 resourceNames로 제한)이 필요합니다. DRA 드라이버를 운영 중이라면 업그레이드 전에 RBAC 매니페스트를 반드시 점검하고 수정하세요. 누락 시 파드 스케줄링이 실패합니다.

• breakingflex-volume·git-repo 볼륨 플러그인 제거 — 마이그레이션 필수

  kubeadm은 더 이상 flex-volume 플러그인 디렉터리를 자동으로 마운트하지 않으며, git-repo 볼륨 플러그인은 영구적으로 비활성화됩니다. 재활성화 옵션이 없으므로 git-repo 볼륨을 사용하는 워크로드는 init 컨테이너 패턴이나 CSI 드라이버로 전환해야 합니다. kubeadm 환경에서 flex-volume을 계속 쓰려면 v1.36 업그레이드 전에 distroless 기반이 아닌 KCM 이미지와 extraVolumes 설정을 수동으로 구성해야 합니다.

• breakingStrictIPCIDRValidation 기본 활성화 — IP/CIDR 값 점검 필요

  이제 API 필드에서 선행 0이 있는 IP(예: 010.0.0.1)나 호스트 비트가 설정된 CIDR(예: 192.168.1.5/24)을 거부합니다. 기존 오브젝트는 validation ratcheting으로 보존되지만, 신규 생성 및 업데이트는 실패합니다. 업그레이드 전에 매니페스트, Helm 차트, 자동화 스크립트에서 비정규 IP/CIDR 값을 점검하세요.

• enhancementMutatingAdmissionPolicy GA 승격 — 단순 Webhook 교체 검토 시점

  CEL 기반 MutatingAdmissionPolicy가 v1으로 GA 승격되어 기본 활성화됩니다. 레이블/어노테이션 주입이나 기본값 설정처럼 단순한 뮤테이팅 웹훅을 운영 중이라면 MutatingAdmissionPolicy로 교체를 검토할 때입니다. 웹훅 서버 유지, 인증서 관리, 가용성 걱정 없이 CEL 기반 정책으로 동일한 기능을 구현할 수 있습니다. 상태가 없는 단순 뮤테이션부터 시작하는 것을 권장합니다.

CoreDNS v1.14.3은 모든 전송 계층에 TSIG 완전 검증을 적용하고, Go 보안 CVE 13건을 패치하며, 캐시 프리페치 개선과 forward 플러그인의 max_age 옵션을 추가한 운영 보안 강화 릴리스입니다.

• securityGo CVE 13건 및 TSIG 취약점 수정 — 즉시 업그레이드 필요

  Go 1.26.2가 런타임 CVE 13건을 해결합니다. 여기에 더해 DoH, DoH3, QUIC, gRPC 전송 계층의 TSIG 검증 누락도 함께 수정됐습니다. 해당 전송 방식과 TSIG를 같이 쓰고 있다면, 이전 버전에서는 인증되지 않은 요청이 통과될 수 있었습니다. v1.14.3으로 업그레이드한 뒤 강화된 검증 정책에 맞게 TSIG 설정을 재확인하세요.

• breakingDoH GET 요청 크기 제한 적용 — 클라이언트 호환성 확인 필요

  CoreDNS가 DoH GET 요청의 dns 쿼리 파라미터 크기를 초과하면 이제 명시적으로 거부합니다. 비표준 구현이나 커스텀 DoH 클라이언트를 사용 중이라면 스테이징에서 먼저 테스트하세요. 표준을 따르는 클라이언트는 대부분 영향이 없지만, 자체 구현 클라이언트는 반드시 검증이 필요합니다.

• enhancementforward 플러그인 max_age로 오래된 업스트림 연결 관리

  수명이 긴 업스트림 연결은 중간 네트워크 장비에 의해 조용히 끊기거나 성능이 저하될 수 있습니다. 새로운 max_age 옵션으로 연결 최대 수명을 강제 설정할 수 있습니다. 산발적인 업스트림 타임아웃이나 일시적 해석 실패를 경험했다면, 업스트림 안정성에 따라 30초~5분 범위에서 max_age를 설정해 주기적 재연결을 유도해 보세요.

v1.33.11은 MultiCIDRServiceAllocator 활성화 시 apiserver 기동 실패와 nft 1.1.3에서의 kube-proxy nftables 오작동을 수정한 패치 릴리스입니다. Go 1.25.9로 컴파일러도 업데이트됐습니다.

• breakingMultiCIDRServiceAllocator + 대규모 클러스터라면 즉시 업그레이드

  MultiCIDRServiceAllocator가 활성화된 환경에서 네임스페이스가 많으면, 업그레이드 중 apiserver가 아직 준비되지 않은 어드미션 플러그인으로부터 Forbidden 오류를 받고 기동에 실패하는 문제가 있었습니다. 이번 패치로 재시도 로직이 추가됩니다. 이 문제 때문에 1.33 업그레이드를 미뤄왔다면 이제 적용할 수 있습니다. apiserver 로그에서 IP 복구 컨트롤러의 Forbidden 오류를 확인해 보세요.

• breakingnft 1.1.3 사용 노드는 kube-proxy nftables가 사실상 불통 — 즉시 패치 필요

  nft 1.1.3이 설치된 노드(일부 최신 배포판 기본값)에서는 kube-proxy nftables 모드가 제대로 작동하지 않습니다. 처음에는 트래픽이 흐르는 것처럼 보여도 규칙 업데이트가 올바르게 적용되지 않습니다. 노드에서 'nft --version'으로 버전을 확인하고, 1.1.3이라면 이 패치 릴리스로 업그레이드하는 것이 가장 확실한 해결책입니다.

• enhancementOTel v1.41.0 대폭 업그레이드 — 옵저버빌리티 파이프라인 검증 필요

  OpenTelemetry Go SDK가 v1.33.0에서 v1.41.0으로 한 번에 올라갔습니다. 버전 차이가 큰 만큼, Kubernetes 텔레메트리 데이터를 수집하거나 OTel SDK와 연동되는 사이드카를 운영 중이라면 업그레이드 전 비운영 환경에서 트레이싱·메트릭 파이프라인이 정상 작동하는지 먼저 확인하세요. Kubernetes 기능 자체의 변화는 없지만 버전 갭이 충분히 커서 점검할 가치가 있습니다.

v1.34.7은 감사 로그 지연 시간 누락 버그와 nftables kube-proxy 호환성 문제를 수정하고, Go 1.25.9로 재빌드한 패치 릴리스입니다.

• breaking감사 로그 지연 시간 데이터가 조용히 누락됐습니다 — 즉시 패치 필요

  이 패치 이전의 1.34.x 클러스터는 500ms를 넘는 요청에 대해 감사 로그에서 지연 시간 어노테이션을 누락시켰습니다. 보안 감사나 컴플라이언스 도구가 이 어노테이션을 파싱해 SLO 추적이나 이상 감지에 활용하고 있다면, 그 기간의 데이터에는 공백이 있는 셈입니다. v1.34.7로 업그레이드 후, 해당 기간 감사 로그가 불완전하다는 사실을 기록으로 남겨두세요.

• breakingnft 1.1.3 환경에서 nftables kube-proxy가 완전히 동작 불가 — 우회 없으면 즉시 업그레이드

  Fedora 42, Ubuntu 25.04처럼 nft 1.1.3이 기본 탑재된 신형 배포판에서 kube-proxy를 nftables 모드로 실행하면 네트워킹 자체가 동작하지 않습니다. 성능 저하가 아닌 완전한 장애입니다. nft를 구버전으로 고정하거나 v1.34.7로 즉시 업그레이드하세요. 수정 사항은 knftables 라이브러리 업그레이드(v0.0.17 → v0.0.21)에 포함되어 있습니다.

• enhancementOTel v1.41.0으로 대폭 업그레이드 — 트레이싱 연동 검증 필요

  OpenTelemetry Go 패키지가 v1.35.0에서 v1.41.0으로 올라갔습니다. API 호환성은 유지되지만, 스팬 전파나 메트릭 수집 내부 동작이 상당 부분 변경됐습니다. Kubernetes OTel 스팬을 활용하는 커스텀 계측 코드나 사이드카가 있다면, 프로덕션 적용 전에 스테이징에서 반드시 검증하세요.

v1.35.4는 사이드카 컨테이너 재시작 불가, StatefulSet 병렬 스케일링 회귀, kube-proxy nftables 오작동, 감사 로그 레이턴시 어노테이션 오류 등 5개의 실제 버그를 수정한 패치 릴리스입니다.

• breakingStatefulSet maxUnavailable 동작에 의존 중이라면 즉시 확인 필요

  MaxUnavailableStatefulSet 기능 게이트가 1.35.4에서 다시 기본 비활성화됐습니다. 1.35.x로 업그레이드하면서 maxUnavailable 기반 병렬 파드 관리를 기대했다면, 그 동작은 현재 없는 셈입니다. StatefulSet 스펙에 maxUnavailable을 설정해둔 경우 조용히 무시됩니다. 업그레이드 전 스펙을 점검하고, 해당 기능 게이트가 다시 안정화될 때까지 운영 전략을 조정하세요.

• breaking사이드카 + startupProbe 조합 사용 중이면 빠른 업그레이드 권장

  restartPolicy: Always인 initContainer와 startupProbe를 함께 쓰는 파드는 kubelet 재시작 이후 크래시된 컨테이너가 영원히 재시작되지 않고 RestartCount: 0에 멈추는 현상이 있었습니다. 서비스 메시 프록시, 로그 수집기 등 사이드카 패턴을 쓰는 프로덕션 워크로드가 영향을 받습니다. 이미 이 상태에 빠진 파드가 있다면, 1.35.4로 업그레이드 후 해당 파드를 수동으로 삭제·재생성하는 것이 복구 방법입니다.

• enhancementnft 1.1.3 노드 환경이라면 kube-proxy 업그레이드 우선 적용

  nftables 버전 1.1.3이 설치된 시스템에서 kube-proxy의 nftables 모드가 완전히 동작하지 않는 문제가 있었습니다. 네트워킹 자체가 깨지는 조용한 장애입니다. 최근 Debian/Ubuntu 계열 일부 배포판이 nft 1.1.3을 포함하므로, 해당 환경의 노드 컴포넌트는 이번 패치를 우선 적용하세요.

containerd v2.2.3은 spdystream의 CVE-2026-35469를 패치하고, 병렬 언팩 시 whiteout 누락 버그, tar 추출 경쟁 조건, Go 1.24 심링크 회귀 등 여러 버그를 수정했습니다.

• securityCVE-2026-35469 패치: 즉시 v2.2.3으로 업그레이드

  CVE-2026-35469는 containerd가 스트리밍 연결에 사용하는 moby/spdystream에서 발견된 취약점입니다. 이번 릴리스에 spdystream v0.5.1이 포함되어 수정됐습니다. 2.2.x 버전을 운영 중이라면 다음 정기 점검을 기다리지 말고 지금 바로 업그레이드하세요.

• breaking병렬 언팩 whiteout 버그 — 영향받은 이미지는 재풀링 필요

  병렬 언팩이 활성화된 환경에서 레이어 간 파일 삭제를 표시하는 whiteout 파일이 무시되는 버그가 있었습니다. overlayfs와 병렬 언팩을 함께 사용했다면 레이어 삭제 시맨틱이 제대로 적용되지 않았을 수 있습니다. 업그레이드 후 병렬 언팩으로 받은 이미지는 재풀링해서 레이어 상태를 확인하는 것이 좋습니다.

• enhancementGo 1.24 + NixOS 계열 환경의 컨테이너 기동 실패: 이번 릴리스로 해결됩니다

  Go 1.24로 빌드된 바이너리에서 rootfs 내 사용자/그룹 조회 시 절대 심링크 처리에 회귀가 생겼습니다. /etc/passwd나 /etc/group이 심링크인 NixOS 계열 시스템에서 주로 나타나는 문제입니다. Go 1.24 빌드로 전환한 뒤 사용자 조회 실패나 컨테이너 기동 오류를 겪었다면 v2.2.3 업그레이드로 해결됩니다.

containerd 2.0.8은 CVE-2026-35469 보안 패치, CRI 에러 메시지의 인증 정보 노출 수정, containerd 재시작 후 CNI DEL이 실행되지 않던 버그 수정을 포함합니다.

• securityCVE-2026-35469 대응: 즉시 2.0.8로 업그레이드

  CVE-2026-35469는 moby/spdystream 의존성에 존재하는 취약점입니다. 2.0.x를 운영 중인 클러스터라면 다음 유지보수 주기를 기다리지 말고 2.0.8로 올리세요. 해당 advisory의 심각도를 확인한 뒤 업그레이드 우선순위를 판단하기 바랍니다.

• security과거 파드 이벤트 로그에서 인증 정보 노출 여부 점검

  이번 수정 이전에는 레지스트리 인증 정보 등 URL에 포함된 민감 데이터가 CRI gRPC 에러 메시지와 파드 이벤트에 평문으로 기록될 수 있었습니다. Datadog, Splunk, ELK 등 외부 로깅 백엔드로 파드 이벤트를 수집 중이라면, 최근 로그에서 노출된 쿼리 파라미터가 없는지 점검하세요. 2.0.8부터는 containerd 내부에서 마스킹 처리됩니다.

• breaking업그레이드 후 CNI 네트워크 정리가 정상 동작하는지 확인

  이번에 수정된 CNI DEL 버그로 인해, containerd 재시작 이후 파드를 삭제할 때 CNI 플러그인 정리가 실행되지 않아 노드에 네트워크 상태가 남아 있을 수 있습니다. 2.0.8로 업그레이드한 뒤에는 containerd 재시작을 경험한 노드에서 파드 삭제 시 CNI DEL이 제대로 호출되는지 검증하세요. 이전에 고아 네트워크 인터페이스나 IP 할당 충돌이 발생했다면 이 버그가 원인이었을 가능성이 높습니다.

containerd 2.1.7은 spdystream의 CVE-2026-35469를 패치하고, gRPC 자격 증명 누출 방지 및 tar 추출 TOCTOU 경쟁 조건 수정 등 보안 강화 변경을 포함합니다.

• securityCVE-2026-35469 패치를 위해 즉시 2.1.7로 업그레이드

  moby/spdystream의 CVE-2026-35469가 이번 릴리스에서 수정됐습니다. spdystream은 CRI 스트리밍 경로에서 사용되므로 exec/attach/port-forward를 쓰는 Kubernetes 워크로드가 잠재적으로 영향을 받습니다. 모든 노드의 containerd를 2.1.7로 업그레이드하세요. 설정 변경 없이 바이너리 교체 후 데몬 재시작만 하면 됩니다.

• securitypod 이벤트를 통한 자격 증명 누출 경로 차단

  이번 수정 전까지 레지스트리 자격 증명이 포함된 원시 오류가 pod 이벤트에 노출될 수 있었습니다. 네임스페이스 범위 사용자에게 pod 이벤트 접근을 허용하는 클러스터라면 자격 증명이 로그나 이벤트 스트림에 노출됐을 가능성이 있습니다. 영향받은 클러스터에서 사용된 레지스트리 pull secret을 교체한 뒤 2.1.7로 업그레이드하세요.

• enhancementCNI DEL 버그 수정으로 재시작 후 네트워크 자원 누수 방지

  기존에는 containerd 재시작 후 정리되는 샌드박스에 CNI DEL이 호출되지 않아 IP 등 네트워크 자원이 누수됐습니다. 노드 재시작 후 스테일 IP나 CNI 상태 이상을 겪은 적 있다면 이 버그가 원인일 가능성이 높습니다. 2.1.7로 업그레이드하고, 기존 누수 상태를 정리하려면 containerd 재시작 전 노드를 드레인하는 편이 안전합니다.

v1.7.31은 spdystream의 CVE-2026-35469를 패치하고, 재시작 후 CNI DEL이 실행되지 않던 버그와 gRPC 에러를 통한 자격증명 노출 문제를 수정합니다.

• securityCVE-2026-35469 패치: 즉시 v1.7.31로 업그레이드

  CVE-2026-35469는 SPDY 멀티플렉싱에 쓰이는 moby/spdystream 라이브러리의 취약점입니다. 수정본은 이번 릴리스에 포함된 spdystream v0.5.1에 담겨 있습니다. 1.7.x 이전 버전을 운영 중이라면 즉시 업그레이드하세요. 특히 CRI 스트리밍 서버가 노출되어 있거나 kubectl exec/attach/port-forward 트래픽이 containerd를 통해 흐르는 클러스터라면 더욱 시급합니다.

• security파드 이벤트 로그에서 자격증명 노출 여부 점검

  원시 에러 메시지에 레지스트리 자격증명이 포함된 채로 gRPC를 통해 반환되고 파드 이벤트에 노출되는 버그가 있었습니다. 업그레이드 후, 수정 전 기간의 파드 이벤트 로그(kubectl get events 또는 로그 수집 시스템)를 검토해 인증 토큰, 비밀번호, 이미지 풀 시크릿이 포함된 항목이 있는지 확인하세요. 노출된 자격증명이 발견되면 즉시 교체해야 합니다.

• breaking업그레이드 후 CNI 네트워크 정리 동작 검증 필요

  CNI DEL 버그 수정으로, 기존에 containerd 재시작 후 스테일 네트워크 상태를 남기던 컨테이너가 이제 제대로 정리됩니다. 올바른 동작이지만, CNI DEL이 생략된다고 가정하는 자동화 스크립트나 워크플로가 있다면 미리 테스트하세요. 비정상 재시작 이력이 있는 노드는 업그레이드 후 첫 파드 삭제 시 정리 작업이 실행될 수 있습니다.

차트 추출 시 발생하는 경로 순회 취약점을 수정한 보안 패치입니다. 외부 출처 차트를 사용하는 환경은 즉시 업그레이드하세요.

• security차트 추출 경로 순회 취약점 — 즉시 업그레이드 필요

  Chart.yaml의 차트 이름에 '..' 같은 점-세그먼트를 사용하면 Helm이 의도된 추출 디렉토리 밖으로 파일을 쓸 수 있는 전형적인 경로 순회 공격입니다. 퍼블릭 저장소, 서드파티 레지스트리, 또는 완전히 신뢰할 수 없는 출처의 차트를 파이프라인에서 사용하고 있다면 즉시 v3.20.2로 업그레이드하세요. 내부에서만 작성한 차트를 에어갭 환경에서 운영하는 팀은 위험도가 낮지만, 다음 유지보수 윈도우에 업그레이드하는 것이 바람직합니다.

Helm v4.1.4는 보안 전용 패치로, 차트 경로 탈출, 플러그인 서명 우회, 플러그인 버전 경로 탈출 등 세 가지 취약점을 수정했습니다.

• security즉시 업그레이드 — 세 CVE 모두 외부 입력으로 악용 가능

  차트 추출 경로 우회와 플러그인 버전 경로 탈출은 파일시스템의 임의 위치에 파일을 쓸 수 있게 합니다. 서명 우회 취약점은 배포 채널을 제어할 수 있는 공격자가 서명되지 않은 플러그인을 설치하도록 허용합니다. 외부 또는 반신뢰 소스에서 차트나 플러그인을 가져오는 CI/CD 파이프라인이 있다면, 이번 패치 이전 버전에서는 노출 상태입니다. 유지보수 윈도우를 기다리지 말고 v4.1.4(또는 4월 8일 출시 예정인 v3.20.3)로 즉시 업그레이드하세요.

• security업그레이드 전 설치된 플러그인 출처를 반드시 점검

  GHSA-q5jf-9vfq-h4h7 취약점으로 인해, 플러그인 검증이 활성화된 상태에서도 .prov 파일이 없으면 서명되지 않은 플러그인이 설치될 수 있었습니다. 업그레이드 전에 'helm plugin list'로 설치된 플러그인을 확인하고 출처를 수동 검증하세요. 업그레이드 후에는 공식 소스에서 플러그인을 재설치해 서명 검증이 올바르게 동작하는지 확인하는 게 좋습니다.

• enhancementCI 파이프라인에서 Helm 버전을 v4.1.4로 명시적 고정

  'latest' 또는 마이너 버전 태그로 Helm을 참조하고 있다면 v4.1.4로 정확히 고정하세요. 이번 릴리스에서 Helm 팀이 CodeQL 액션을 커밋 SHA로 고정한 것처럼, 파이프라인의 모든 툴체인 의존성에 동일한 원칙을 적용하는 것이 좋습니다.

Lima v2.1.1은 Windows 바이너리 아티팩트 추가와 소수의 엣지 케이스 버그 수정에 집중한 패치 릴리스이며, nerdctl 보안 업데이트가 포함되어 있습니다.

• securitynerdctl 배포판 업데이트로 BuildKit·CNI 보안 패치 적용

  번들된 nerdctl이 v2.2.1에서 v2.2.2로 올라가면서 BuildKit 0.28.1과 CNI plugins 1.9.1이 함께 업데이트됐습니다. 두 업스트림 모두 보안 수정이 포함되어 있습니다. Lima의 nerdctl 템플릿으로 컨테이너 워크로드를 운영 중이라면 v2.1.1로 빠르게 업그레이드하고, BuildKit 및 CNI plugins 릴리스 노트에서 본인 환경에 해당하는 CVE를 직접 확인하세요.

• enhancementWindows 사용자는 공식 바이너리로 전환

  v2.1.1부터 Lima의 Windows 바이너리가 공식 릴리스에 포함됩니다. 팀 내 Windows 개발자(예: WSL2 기반 Lima 사용자)가 있다면 커스텀 빌드 대신 공식 릴리스 바이너리를 사용하도록 안내하세요. 온보딩이 간소화되고 검증된 빌드를 일관되게 유지할 수 있습니다.

• enhancement기업 환경 Mac 사용자의 UID 범위 오류 해결

  macOS 게스트가 이제 관례적인 UID 범위 밖의 값도 수용합니다. LDAP이나 Active Directory로 관리되는 기업 Mac에서 Lima를 사용하다 원인 불명의 오류를 겪었던 경우라면 이번 수정으로 해결됩니다. 별도 설정 변경 없이 업그레이드만 하면 됩니다.

v1.33.11은 코드 변경이나 의존성 업데이트가 전혀 없는 유지보수 재빌드 릴리스입니다.

• enhancementv1.33.10 운영 중이라면 이번 업그레이드는 건너뛰어도 됩니다

  기능 변경도, 보안 수정도 없습니다. v1.33.10을 안정적으로 운영 중이라면 굳이 유지보수 창을 잡을 이유가 없습니다. 실질적인 수정이 포함된 v1.33.12 이상을 기다렸다가 업그레이드하는 편이 낫습니다.

• enhancementSBOM·cosign 검증 파이프라인 테스트 기회로 활용하세요

  모든 빌드에 SPDX SBOM과 cosign 번들 파일이 포함됩니다. 소프트웨어 공급망 보안 요건이 있다면, 영향도가 낮은 이번 릴리스를 활용해 cosign 검증 워크플로를 파이프라인에 통합하고 테스트해두는 게 좋습니다.

CRI-O v1.35.2는 이미지 풀 자격증명 검증, 메트릭 누락, OCI 아티팩트 스토어 오염 문제를 수정한 버그픽스 패치입니다.

• breaking업그레이드 후 자격증명 프로바이더 동작 검증 필요

  PullImage 수정으로 이미지 풀 시 반환값이 달라졌습니다. Kubernetes 자격증명 프로바이더 플러그인을 쓰거나 이미지 풀 동작을 검증하는 자동화가 있다면, 프로덕션 적용 전 반드시 테스트하세요. 기존 동작은 엣지 케이스에서 자격증명 검증을 조용히 건너뛸 수 있었습니다.

• enhancement메트릭 파이프라인 점검 — 데이터가 누락됐을 수 있음

  이번 패치 이전 v1.35.x를 운영 중이었다면, 'all' 설정 시 메트릭이 불완전하게 수집됐을 겁니다. 업그레이드 후 메트릭 수가 늘어날 수 있는데, 이는 정상입니다. 대시보드와 알림 임계값을 미리 확인해두세요.

• enhancement에어갭·미러 환경에서 additional_artifact_stores 활용

  에어갭 클러스터나 내부 아티팩트 미러를 운영한다면, 새로운 'additional_artifact_stores' 옵션으로 읽기 전용 소스를 여러 개 깔끔하게 설정할 수 있습니다. pinned_images 수정과 함께 쓰면 고정 이미지가 의도한 스토어에서 일관되게 풀리는지 보장할 수 있습니다.

CRI-O v1.34.7은 v1.34.6 대비 코드 변경이나 의존성 업데이트가 전혀 없는 패치 릴리스입니다. 사실상 재빌드 수준의 릴리스입니다.

• enhancementv1.34.6 사용 중이라면 업그레이드 급하지 않습니다

  기능 변경도, 보안 패치도 없습니다. v1.34.6을 운영 중이라면 당장 올릴 이유가 없습니다. 다만 컴플라이언스 정책상 최신 패치 태그가 필요하거나, 아티팩트 출처 추적이 요구되는 환경이라면 SPDX SBOM과 cosign 번들이 모두 갖춰져 있으므로 그 목적으로는 활용 가능합니다.

etcd v3.6.10은 3.6 시리즈의 패치 릴리스입니다. 릴리스 노트가 간략하므로, 업그레이드 전 전체 CHANGELOG를 반드시 확인하세요.

• breaking업그레이드 전 공식 가이드 필독

  v3.6 릴리스는 브레이킹 체인지가 포함될 수 있다고 명시하고 있습니다. 클러스터 업그레이드 전에 v3.6 공식 업그레이드 가이드와 CHANGELOG-3.6.md 전문을 검토하세요. 일반 패치처럼 무심코 적용하면 운영 장애로 이어질 수 있습니다.

• enhancement컨테이너 이미지 소스를 gcr.io로 전환

  etcd는 gcr.io/etcd-development/etcd를 기본 레지스트리로, quay.io/coreos/etcd를 보조로 지정했습니다. 이미지 풀 설정이나 에어갭 미러 구성이 여전히 quay.io를 우선하고 있다면 gcr.io 기준으로 업데이트하는 것이 좋습니다.

etcd v3.5.29는 3.5 브랜치의 유지보수 릴리스입니다. 릴리스 노트 자체에는 세부 변경 사항이 없어 CHANGELOG를 직접 확인해야 합니다.

• security컨테이너 이미지 레지스트리 출처 검증

  CI/CD 파이프라인에서 etcd 이미지를 사용한다면, 기본 레지스트리인 gcr.io/etcd-development/etcd를 사용하는지 확인하세요. quay.io 미러는 보조 레지스트리라 최신 이미지 반영이 늦을 수 있습니다. 플로팅 태그 대신 이미지 다이제스트를 고정해 공급망 위험을 줄이세요.

• breaking패치 릴리스라도 공식 업그레이드 가이드를 건너뛰지 마세요

  릴리스 노트가 명시적으로 3.5.x 패치 버전에도 브레이킹 체인지가 있을 수 있다고 경고합니다. 특히 Kubernetes 컨트롤 플레인 백엔드로 etcd를 운영 중이라면 스테이징 환경에서 먼저 검증하세요. etcd 업그레이드 실패는 클러스터 전체 장애로 이어질 수 있습니다.

• enhancement업그레이드 전 CHANGELOG-3.5.md 확인

  이번 릴리스 노트에는 구체적인 변경 내용이 없습니다. etcd GitHub 저장소의 CHANGELOG-3.5.md에서 v3.5.29 항목을 직접 확인하세요. 3.5 브랜치 패치 릴리스에는 버그 픽스나 CVE 패치가 포함되는 경우가 많은데, 버전 번호만 보고 넘어가기 쉽습니다.

etcd v3.4.43은 3.4 브랜치의 유지보수 릴리스입니다. 릴리스 노트에 변경 내역이 없으므로, 업그레이드 전 CHANGELOG를 직접 확인해야 합니다.

• breaking패치 버전 업그레이드에도 업그레이드 가이드 확인 필요

  패치 릴리스라도 etcd 팀은 간헐적으로 동작 변경이나 기능 폐기를 포함시킵니다. etcd는 컨트롤 플레인의 데이터 저장소인 만큼, 패치 버전이라고 무조건 안전하다고 가정하지 말고 v3.4 공식 업그레이드 가이드를 반드시 점검하세요.

• enhancement업그레이드 전 CHANGELOG 직접 확인

  릴리스 노트에 변경 내역이 기재되어 있지 않습니다. 업그레이드 전에 CHANGELOG-3.4.md를 열어 현재 버전과 차이를 직접 비교하세요. 3.4.x 패치는 버그 수정과 CVE 백포트를 포함하는 경우가 많아, 검토를 건너뛰면 중요한 수정 사항을 놓칠 수 있습니다.

etcd v3.6.9은 유지보수 릴리스입니다. 공개된 릴리스 노트에 변경 사항이 기재되어 있지 않으므로, 업그레이드 전 반드시 전체 CHANGELOG를 확인해야 합니다.

• breaking업그레이드 전 CHANGELOG 직접 확인 — 릴리스 노트만으로는 부족

  v3.6.9 릴리스 노트에는 변경 내역이 전혀 없습니다. etcd 클러스터를 업그레이드하기 전에 CHANGELOG-3.6.md를 직접 열어 현재 버전 이후 항목을 꼼꼼히 확인하세요. 3.6 시리즈에는 브레이킹 체인지가 포함될 수 있고, etcd는 상태 저장 시스템이라 이 단계를 건너뛰면 실제 장애로 이어질 수 있습니다.

• enhancementquay.io에서 이미지를 받는다면 버전 일치 여부 검증 필요

  etcd의 기본 레지스트리는 gcr.io/etcd-development/etcd입니다. 파이프라인이 quay.io/coreos/etcd를 사용한다면, 해당 이미지가 gcr.io 이미지와 다이제스트 수준에서 일치하는지 확인하세요. 보조 레지스트리는 업데이트가 늦을 수 있습니다. 태그만 핀닝하는 것으로는 부족하고, 다이제스트로 고정해야 버전 불일치를 막을 수 있습니다.

etcd v3.5.28은 3.5 시리즈의 패치 릴리스입니다. 릴리스 노트 내용이 빈약하므로, 업그레이드 전 반드시 전체 CHANGELOG를 확인해야 합니다.

• breaking릴리스 노트가 불완전하므로 CHANGELOG를 직접 확인할 것

  v3.5.28 릴리스 노트에는 실제 변경 내용이 전혀 없습니다. etcd 클러스터를 업그레이드하기 전, 반드시 저장소의 CHANGELOG-3.5.md를 열어 현재 버전 이후 항목을 직접 검토하세요. etcd는 상태 저장 시스템인 만큼 이 단계를 건너뛰는 건 실질적인 위험입니다.

• enhancement컨테이너 이미지는 기본 레지스트리에서 받을 것

  gcr.io/etcd-development/etcd가 공식 이미지 소스입니다. quay.io/coreos/etcd는 보조 레지스트리로 업데이트가 늦을 수 있습니다. 현재 quay.io에서 이미지를 받고 있다면, 운영 환경 배포 전 이미지 다이제스트가 기본 레지스트리와 일치하는지 반드시 검증하세요.

etcd v3.4.42는 3.4 브랜치의 유지보수 릴리스입니다. 릴리스 노트 자체에는 변경 내용이 거의 없으므로, 업그레이드 전에 전체 CHANGELOG를 반드시 확인하세요.

• breaking패치 릴리스라도 업그레이드 가이드 확인 필수

  릴리스 노트에 명시적으로 Breaking Change 가능성이 언급되어 있습니다. 3.4.x 패치 버전이라 가능성은 낮지만, 스냅샷이나 WAL 처리 관련 변경이 포함될 수 있습니다. 프로덕션 클러스터에 적용하기 전에 해당 버전의 업그레이드 가이드를 반드시 검토하세요.

• enhancement업그레이드 전 전체 CHANGELOG 직접 확인

  공개된 릴리스 노트에는 변경 내용이 사실상 없습니다. 어떤 버그 픽스나 패치가 포함됐는지 파악하려면 etcd 저장소에서 CHANGELOG-3.4.md를 직접 확인하세요. 합의 저장소를 내용도 모른 채 업그레이드하는 건 피해야 합니다.

v1.35.3은 kubeadm 버그 수정 2건과 DRA 퇴출 상태 메시지 정리 1건으로 구성된 소규모 패치입니다. 위험도가 낮아 안심하고 적용할 수 있습니다.

• enhancementetcd learner 엔드포인트 버그 수정을 위해 kubeadm 업그레이드 권장

  etcd learner 멤버 수정이 이번 패치에서 운영상 가장 중요한 변경 사항입니다. kubeadm으로 관리하는 클러스터에서 노드 조인이나 멤버 승격 중 etcd 클라이언트 연결 문제를 겪은 적 있다면 이 패치가 근본 원인을 해결합니다. 설정 변경 없이 kubeadm 바이너리만 업데이트하면 되므로, 다음 유지보수 창에 적용하는 것을 권장합니다.

• enhancement피어 마운트 환경에서 kubeadm reset 안정성 향상

  /var/lib/kubelet에 피어 마운트가 구성된 환경(특정 컨테이너 런타임 또는 중첩 마운트 설정)에서 reset 자동화가 실패한 경험이 있다면 이 수정이 적용됩니다. EINVAL 오류가 reset 과정을 막지 않으므로, 원인 불명의 reset 실패를 겪고 있는 경우 업그레이드할 만합니다.

v1.34.6은 etcd learner 엔드포인트 문제와 클러스터 리셋 시 kubelet 언마운트 오류를 수정하는 소규모 패치 릴리스입니다.

• enhancementetcd 멤버 추가 작업이 있다면 즉시 업그레이드 검토

  etcd learner는 아직 투표권이 없는 상태인데, 이 시점에 클라이언트 엔드포인트에 포함되면 프로모션 완료 전까지 요청 실패가 발생할 수 있습니다. etcd 노드 추가 중 간헐적 클라이언트 오류를 겪었다면 이 패치가 해결책입니다. 그렇지 않다면 일반 패치 주기에 맞춰 적용하면 됩니다.

• enhancementkubeadm reset 실패 경험이 있다면 이 패치를 우선 적용

  /var/lib/kubelet 하위 바인드 마운트를 정리하지 못해 reset이 중간에 멈추는 문제가 수정됐습니다. 마운트 네임스페이스가 겹치거나 특정 파일시스템 설정을 쓰는 노드에서 주로 발생합니다. 리셋 실패 후 수동 정리를 반복했다면, 이 패치로 해당 번거로움을 없앨 수 있습니다.

v1.33.10은 ValidatingAdmissionPolicy의 kube-controller-manager 크래시 버그와 kubeadm 운영 버그 두 건을 수정한 소규모 패치입니다. 의존성 변경은 없습니다.

• breaking개방형 스키마 VAP 사용 중이라면 즉시 패치 필요

  `additionalProperties: true`를 사용하는 ValidatingAdmissionPolicy가 존재하면 kube-controller-manager가 nil 포인터 예외로 완전히 다운됩니다. 우아한 성능 저하가 아닌 즉각적인 크래시입니다. v1.33.x를 사용 중이라면 현재 배포된 VAP 정책을 점검하고, 개방형 스키마 정책을 추가하기 전에 반드시 v1.33.10으로 업그레이드하세요.

• enhancementHA 클러스터 컨트롤 플레인 확장 전 업그레이드 권장

  etcd는 신규 멤버를 learner로 먼저 등록한 뒤 승격시키는데, 이전 버전 kubeadm은 learner를 클라이언트 엔드포인트 풀에 포함시켜 조인 과정에서 간헐적 etcd 클라이언트 오류를 유발했습니다. kubeadm으로 관리되는 HA 클러스터에서 컨트롤 플레인 노드를 추가할 계획이 있다면, 작업 전에 이 패치를 적용하세요.

• enhancement노드 자동화 해제 스크립트에서 kubeadm reset 안정성 개선

  /var/lib/kubelet이 bind 마운트된 노드에서 `kubeadm reset`을 실행하면 EINVAL 오류로 정리 작업이 중간에 실패했습니다. 이제 peer 마운트에서 예상되는 EINVAL을 무시하므로 reset이 깔끔하게 완료됩니다. 노드 폐기를 스크립트로 자동화하는 환경이라면 이 패치의 효과를 바로 체감할 수 있습니다.

Lima v2.1.0은 macOS·FreeBSD 게스트를 실험적으로 지원하고, 게스트 홈 디렉터리 경로를 변경하며 디스크 파일 구조를 통합했습니다. 업그레이드 전 마이그레이션 고려가 필요합니다.

• breaking디스크 파일 통합으로 다운그레이드 불가

  v2.1에서 한 번 실행된 인스턴스는 v2.0·v1.x와 호환되지 않습니다. 업그레이드 전에 중요한 VM 인스턴스를 스냅샷하거나 백업하세요. CI 파이프라인이나 팀 공유 환경에서 Lima 버전을 고정해 쓰고 있다면, 모든 사용자가 동시에 업그레이드해야 합니다. 인스턴스별 롤백은 불가능합니다.

• breaking`/home/${USER}.linux` 하드코딩 경로 점검 필요

  게스트 홈 디렉터리가 `/home/${USER}.guest`로 바뀌었습니다. 심볼릭 링크 덕분에 대부분은 그냥 동작하겠지만, `.linux` 경로를 직접 참조하는 스크립트·dotfile·바인드 마운트 설정은 따로 확인해야 합니다. 특히 심볼릭 링크를 따라가지 않는 컨테이너 볼륨 설정이 있다면 지금 수정하세요.

• enhancementAI 에이전트 워크플로에는 `--sync` 플래그 적용

  Claude Code, Aider 같은 AI 코딩 에이전트를 Lima 셸 안에서 실행한다면, `limactl shell --sync`를 쓰면 에이전트가 호스트 파일을 실수로 수정하는 상황을 막을 수 있습니다. 에이전트를 구동하는 스크립트나 자동화 설정에 이 플래그를 기본으로 추가해 두는 걸 권장합니다.

• enhancementk3s 템플릿으로 멀티노드 클러스터 로컬 테스트 가능

  내장 k3s 템플릿이 멀티노드 클러스터를 지원하게 됐습니다. 그동안 이 한계 때문에 Rancher Desktop이나 커스텀 설정을 써왔다면, 이제 네이티브 템플릿으로 전환할 시점입니다. 로컬 Kubernetes 테스트 환경을 더 현실적으로 구성할 수 있습니다.

Helm v3.20.1은 차트 값 처리와 OCI 레지스트리 운영에서 배포 실패를 유발할 수 있는 두 가지 중요한 버그를 수정했습니다.

• enhancement값 처리 수정을 위해 즉시 업그레이드

  차트 배포를 중단시킬 수 있는 두 가지 버그가 해결되었습니다. nil 값 보존 수정으로 차트 기본값을 재정의할 때 예상치 못한 동작을 방지하고, OCI 태그+다이제스트 수정으로 두 식별자를 모두 사용하는 레지스트리에서 차트를 제대로 가져올 수 있게 됩니다. 업그레이드 후 기존 차트를 테스트해서 값 재정의가 예상대로 작동하는지 확인하세요.

• enhancementOCI 차트 참조 정상 동작 확인

  태그+다이제스트 참조(`registry/chart:v1.0@sha256:abc123` 형태)와 함께 OCI 레지스트리를 사용한다면, 이번 릴리스에서 이전의 'invalid byte' 오류가 수정되었습니다. 차트 불변성을 위해 태그+다이제스트 조합을 사용하기 전에 CI/CD 파이프라인을 이 버전으로 업데이트하세요.

Helm v4.1.3는 OCI 레지스트리, dry-run 작업, 값 처리에서 배포 실패나 예측 불가능한 동작을 일으키던 여러 중요한 버그를 수정했습니다.

• breakingOCI 레지스트리 워크플로우 즉시 업데이트

  컨테이너 이미지와 Helm 차트를 같은 태그로 저장하는 OCI 레지스트리를 사용한다면 즉시 업그레이드하세요. 이전 버그는 완전한 풀링 실패를 일으켰습니다. 업그레이드 후 차트 풀링을 테스트해서 레지스트리 설정과의 호환성을 확인하세요.

• enhancement오토스케일링 업그레이드 타임아웃 검토

  이제 업그레이드가 조기 실패하지 않고 클러스터 오토스케일러와 롤링 업데이트를 제대로 기다립니다. 배포 파이프라인을 검토하고 이 문제를 우회하려고 추가했던 인위적인 지연을 줄이는 것을 고려하세요. 초기 업그레이드를 면밀히 모니터링해서 개선된 동작을 확인하세요.

• enhancementgenerateName 사용 시 dry-run 작업 검증

  서버사이드 dry-run이 이제 generateName 필드를 올바르게 처리합니다. generateName을 사용하는 리소스에 대해 dry-run 검증을 피하고 있었다면 CI/CD 파이프라인에서 다시 활성화하세요. 배포 전 검증 범위가 개선됩니다.

containerd 2.2.2는 프로덕션 쿠버네티스 워크로드에 영향을 줄 수 있는 CRI 네트워킹 버그, 레지스트리 인증정보 유출, AppArmor 호환성 문제를 수정했습니다.

• security레지스트리 인증정보 노출 방지를 위한 업데이트

  레지스트리 인증정보가 에러 메시지와 파드 이벤트에 노출될 수 있었습니다. 인증이 필요한 프라이빗 레지스트리를 사용한다면 즉시 이 패치를 배포하세요. 해당 인증정보가 권한 없는 사용자가 접근할 수 있는 로그나 쿠버네티스 이벤트에 나타날 수 있기 때문입니다.

• breaking재시작 후 CNI 네트워크 정리 문제 해결

  containerd 재시작 후 CNI DEL 작업이 실행되지 않아 오래된 네트워크 구성이 남아있었습니다. 파드 네트워킹 안정성에 영향을 줍니다. 다음 유지보수 기간 전에 업데이트해서 네트워크 네임스페이스 누수와 잠재적인 IP 충돌을 방지하세요.

• enhancementAppArmor 호환성을 위한 업그레이드

  AppArmor 프로파일이 이제 최신 커널에서 유닉스 도메인 소켓과 올바르게 동작합니다. 최신 커널 버전을 실행하면서 AppArmor가 활성화된 상태에서 소켓 연결 문제를 겪고 있다면, 이 업데이트가 호환성 문제를 해결해줍니다.

CoreDNS v1.14.2는 ACL 우회 방지와 루프 감지 보안 강화 등 중요한 보안 수정사항을 포함하며, 로드 밸런서 뒤에서 클라이언트 IP를 보존할 수 있는 프록시 프로토콜 지원을 추가했습니다.

• securityACL 우회 취약점 수정을 위한 즉시 업그레이드 필요

  이번 릴리스는 rewrite 플러그인이 ACL 제한을 우회할 수 있는 CVE-2026-26017을 수정합니다. 접근 제어에 ACL 플러그인을 사용하는 팀은 이 업그레이드를 우선시하고, rewrite 규칙이 제한된 존을 의도치 않게 노출하지 않는지 확인해야 합니다.

• security다중 CVE 수정을 위한 Go 런타임 업데이트

  Go 1.26.1 업데이트는 런타임의 5개 CVE를 해결했습니다. CoreDNS 수정사항과 함께 기반 Go 보안 개선사항도 얻을 수 있도록 롤아웃을 계획하세요. 특히 CoreDNS 인스턴스가 인터넷에 노출되어 있다면 더욱 중요합니다.

• enhancement로드 밸런서 환경에서 proxyproto 플러그인 배포

  로드 밸런서 뒤에서 CoreDNS를 운영하며 로깅이나 ACL을 위해 실제 클라이언트 IP 가시성이 필요하다면 새로운 proxyproto 플러그인을 설정하세요. 클라이언트 IP 기반 정책이나 감사 추적이 필요한 환경에서 특히 유용합니다.

CRI-O v1.33.10은 고성능 훅의 IRQ SMP 어피니티 처리에서 발생하는 치명적인 버그를 수정했습니다. 이 버그는 컨테이너 삭제 지연 시나리오에서 컨테이너 간 IRQ 간섭을 일으킬 수 있었습니다.

• security고성능 훅 사용 시 즉시 업데이트 필요

  이 버그는 컨테이너 간 IRQ 처리를 방해해서 고성능 워크로드에서 성능 저하나 예상치 못한 동작을 일으킬 수 있습니다. 고성능 훅을 활성화한 CRI-O를 운영 중이라면(주로 HPC나 지연 시간에 민감한 환경) 컨테이너 정리 중 발생하는 IRQ SMP 어피니티 손상을 방지하기 위해 즉시 업그레이드하세요.