릴리즈

Helm v4.2.1는 동시 작업 중 발생하는 데이터 경쟁 상태를 고치고, 명령 출력 경로를 수정하며, 버전 범위 제약 파싱 문제를 해결합니다.

• breaking업그레이드 후 출력 파싱 로직 검토하기

  Helm 명령 성공 메시지가 stderr 대신 stdout으로 출력되도록 바뀌었습니다. CI/CD 파이프라인, 모니터링, 셸 스크립트에서 Helm 출력을 스트림별로 리다이렉트하거나 필터링한다면 예상 외로 동작할 수 있습니다. grep, tee, 출력 캡처 로직을 확인하세요. 대부분의 스크립트는 그대로 작동하지만, 스트림 의존도가 높은 로직은 재검토가 필요합니다.

• enhancement버전 범위 제약을 제약 없이 사용하기

  Helm 4에서 프리릴리스 버전이나 공백이 없는 범위 제약(예: 'v1.0.0||v1.1.0')을 거부하거나 경고하던 문제가 해결됐습니다. 범위 제약을 피하거나 고정 버전으로 대체한 팀이라면 이제 제약 기반 선택을 도입할 수 있고, 이는 대규모 배포에서 의존성 관리를 단순화합니다.

• enhancement동시 작업 안정성을 위해 업그레이드하기

  동시 goroutine 실행 중 여러 경쟁 상태(upgrade+rollback, install+uninstall이 같은 클라이언트 대상, WaitForDelete 타이밍)가 모두 고쳐졌습니다. 고속 동시 Helm 작업(멀티 차트 배포, 병렬 재조정 루프, 대규모 테스트 스위트)을 운영한다면 업그레이드해서 간헐적 실패를 제거하세요. CI 파이프라인에서 불안정한 테스트 결과를 보고 있다면 특히 중요합니다.

Helm v3.21.1은 템플릿 작업 중 nil 포인터 패닉을 고치고 의존성을 업데이트합니다. 안정성 개선 패치입니다.

• securityGo 보안 패치 GO-2026-5026 적용

  golang.org/x/net이 v0.55.0으로 올라가 GO-2026-5026을 고칩니다. 이는 공급망 의존성이며 Helm API에 직접 노출되지 않습니다. 보안 검사 도구가 net 취약점을 플래그하면 업그레이드하세요. Helm을 정상적으로 사용하는 경우라면 별도 조치는 필요하지 않습니다.

• breakingClientOnly 템플릿 작업이 이제 정상 에러를 반환합니다

  클러스터 없이 helm template 명령을 실행하는 환경(ClientOnly 모드)에서 nil 포인터 패닉이 발생하던 문제가 고쳐졌습니다. 이제 올바른 템플릿 에러를 반환합니다. 패닉을 잡아서 처리하는 자동화가 있다면 에러 처리를 타입이 있는 템플릿 에러로 업데이트하고 템플릿 워크플로를 테스트하세요.

• enhancement레지스트리 인증이 HTTP 폴백 시 유지됩니다

  oras-go v2.6.1 덕분에 레지스트리 작업이 HTTPS에서 plain HTTP로 폴백할 때 인증 정보를 유지합니다. HTTP 전용 엔드포인트를 가진 프라이빗 레지스트리를 사용한다면 안정성이 개선됩니다. 설정 변경은 필요 없으며 자동으로 적용됩니다.

Kubernetes v1.36.2는 Dynamic Resource Allocation 스케줄러, CSI 볼륨 재퍼블리싱, 엔드포인트 컨트롤러의 치명적 버그를 고치고 Go 1.26.4로 빌드한 패치 릴리스입니다.

• security바이너리 non-UTF8 Secret 데이터가 컨테이너 환경 변수에서 정상 처리됨

  Kubernetes 1.34 이상에서 바이너리 non-UTF8 데이터를 포함하는 Secret API 객체로부터 환경 변수를 설정하는 컨테이너가 제대로 읽을 수 없는 리그레션이 있었습니다. 1.36.2에서 수정되었습니다. 환경 변수에 텍스트가 아닌 Secret 데이터를 사용하는 워크로드가 있다면 업그레이드하여 디코딩 오류나 묵시적 실패를 예방하세요.

• breakingDRA 디바이스 할당 버그, 멀티 디바이스 워크로드 영향

  Kubernetes 1.36.0–1.36.1에서 스케줄러가 SharedCounters를 사용하는 드라이버와 멀티 할당 가능 디바이스를 함께 쓸 때 상호 배타적 디바이스 파티션을 여러 Pod에 할당하는 버그가 있습니다. 워크로드 실패, 디바이스 충돌, 크래시, 데이터 손실을 초래할 수 있습니다. DRA를 멀티 할당 가능 디바이스(특히 GPU나 공유 카운터를 사용하는 커스텀 액셀러레이터)로 운영 중이면 1.36.2로 즉시 업그레이드하세요. 최근 Pod 스케줄링 결정을 검토하여 충돌이 없는지 확인하세요.

• enhancementCSI 볼륨 재퍼블리싱 실패가 마운트 상태를 손상시키지 않음

  Kubelet이 주기적 NodePublishVolume 호출(requiresRepublish=true로 트리거됨)이 실패할 때 CSI 마운트 디렉터리를 잘못 삭제하여 Pod에 레거시 볼륨 콘텐츠가 남는 문제가 있었습니다. 1.36.2에서 수정됩니다. requiresRepublish=true인 CSI 드라이버를 운영 중이면 이 패치가 일시적 네트워크 또는 스토리지 오류로 인한 데이터 일관성 위험을 제거합니다. 업그레이드하여 잠재적 데이터 문제를 예방하세요.

Kubernetes v1.35.6은 다중 노드 DRA 클레임 스케줄링, CSI 볼륨 재발행, 엔드포인트 처리의 심각한 버그를 수정하고 Go 1.25.11로 업그레이드했습니다.

• securitySecret 바이너리 데이터의 환경 변수 처리 버그 수정

  1.34+ 버전의 바이너리 데이터(인증서, base64 인코딩된 키 등)를 포함한 Secret에서 환경 변수를 주입하지 못하는 버그가 있었습니다. Secret을 환경 변수로 주입 중이고 그 Secret에 바이너리 데이터가 있다면 v1.35.6으로 업그레이드하세요. 데이터베이스 자격증명이나 키를 Secret 환경 변수로 실행 중이면 버그가 조용히 주입을 깨뜨렸을 수 있으니 빨리 테스트하세요.

• breaking빌드 파이프라인의 Go 런타임을 1.25.11로 업그레이드

  Kubernetes v1.35.6은 Go 1.25.11로 빌드됩니다. 커스텀 컨트롤러나 오퍼레이터를 같은 Go 버전에서 실행 중이면 호환성을 확인하고 다시 빌드하세요. CI/CD에서 Go 버전을 고정 중이면 빌드 설정을 업데이트해야 합니다.

• enhancementDRA 스케줄링과 CSI 재발행이 안정화됨

  세 가지 버그가 해결되었습니다. (1) 공유 카운터를 사용하는 DRA ResourceClaim AllocationMode All에서 스케줄러 패닉 제거. (2) 다중 노드와 노드별 클레임을 함께 사용하는 파드가 더 이상 Pending에서 교착되지 않음. (3) NodePublishVolume 오류 시 kubelet이 마운트 디렉터리를 삭제하지 않아 오래된 볼륨 데이터 손상 방지. DRA나 CSI 재발행을 사용 중이면 이전에 교착 상태가 되던 상황이 제거됩니다. 업그레이드하여 막힌 파드를 정리하고 향후 장애를 방지하세요.

쿠버네티스 v1.34.9는 CSI 마운트 볼륨 처리, 바이너리 Secret 데이터 처리, 엔드포인트 컨트롤러 패닉, kubeadm 인증서 처리를 수정합니다. Go 1.25.11 빌드로 런타임 성능이 향상됩니다.

• breakingrequiresRepublish가 활성화된 CSI 드라이버 운영 중이면 kubelet 업그레이드

  v1.34 회귀로 인해 kubelet이 republish 실패 시 CSI 마운트 디렉터리를 삭제해 포드에 오래된 볼륨 데이터가 남아있었습니다. spec.requiresRepublish=true로 설정된 CSI 드라이버를 운영 중이면 즉시 업그레이드하세요. kubelet 로그에서 실패한 republish 시도를 확인한 후 업그레이드하면 이 버그를 맞고 있었는지 파악할 수 있습니다.

• breaking바이너리 Secret을 환경 변수로 주입하는 워크로드 테스트

  v1.34에서 바이너리(non-UTF8) 데이터가 포함된 Secret을 참조하는 환경 변수 파싱이 깨졌습니다. 워크로드에서 Secret을 환경 변수로 주입한다면 업그레이드 후 테스트하세요. 애플리케이션 시작 로그에서 파싱 오류를 확인하고, 필요하면 바이너리 Secret 값을 base64로 인코딩해야 할 수도 있습니다.

• enhancementGo 런타임 업데이트로 성능과 보안 강화

  v1.34.9는 Go 1.25.11을 사용하며, 런타임 최적화와 보안 패치를 포함합니다. 제어 플레인과 워커 노드를 다음에 순환 업그레이드할 때 반영하세요. 애플리케이션 코드 수정은 불필요하지만, Go 업데이트로 인해 클러스터 지연 시간이 감소하고 메모리 사용량이 줄어들 수 있습니다.

Dapr 1.16.15는 발급자 키가 Ed25519 또는 RSA일 때 dapr-sentry가 기동 직후 crash-loop에 빠지는 버그를 수정합니다. 1.18에서 다운그레이드했거나 발급자 키를 교체한 경우 즉시 확인이 필요합니다.

• breaking1.18 다운그레이드 또는 발급자 키 교체 환경은 1.16.15로 업그레이드하세요

  1.18에서 1.16으로 다운그레이드하면 dapr-trust-bundle 시크릿에 Ed25519 발급자 키가 그대로 남습니다. 이 상태에서 dapr-sentry는 crash-loop에 빠지고 새로운 mTLS 인증서 발급이 전면 중단됩니다. 기존 사이드카는 인증서가 만료되기 전까지는 동작하지만, 파드 재시작이나 인증서 만료 시점에 identity 취득에 실패합니다. 1.16.15로 즉시 업그레이드하세요. 당장 업그레이드가 어렵다면, dapr-trust-bundle의 발급자 키를 ECDSA P-256으로 교체하는 방법이 유일한 임시 해결책입니다.

Falco 0.44.1은 BPF 반복자 제어 옵션을 추가하고 libs 버전 업을 통해 여러 BPF 관련 버그를 수정합니다. 커널 레벨 추적을 사용하는 배포 환경의 안정성에 중점을 둔 최소한의 릴리스입니다.

• breakinglibs와 커널 드라이버를 함께 업데이트하세요

  이번 릴리스에서 libs는 0.25.4로, 드라이버는 10.2.0+driver로 업그레이드됩니다. 커널 드라이버 버전을 Falco와 분리해서 관리한다면 같은 유지보수 기간에 둘 다 업데이트해야 합니다. 버전이 맞지 않으면 시스템 호출 캡처 실패나 무음 데이터 손실이 발생할 수 있습니다.

• enhancementBPF 반복자로 인한 성능 또는 호환성 문제가 있으면 비활성화 옵션 활용

  Falco 0.44.1에서 BPF 반복자를 비활성화하는 설정 옵션이 추가되었습니다. 커널의 BPF 반복자 구현이 불안정하거나 반복자 오버헤드로 인한 높은 CPU 사용량을 관찰하고 있다면 비활성화를 테스트해보세요. 업그레이드 후 Falco 로그와 메트릭을 확인하여 0.44.0에서 겪던 BPF 관련 불안정성이 해결되었는지 검증하세요.

Envoy v1.38.2는 소규모 패치 릴리스입니다. RTDS 런타임 버그 수정 1건과 HTTP/2 쿠키 관련 opt-in 기능 2건이 포함되며, 보안 수정은 없습니다.

• breakingRTDS 런타임 가드 삭제 동작 변경 — 오버라이드 제거 로직 검증 필요

  RTDS 런타임 가드 오버라이드를 삭제할 때 기본값으로 복원되길 기대했다면, 기존 버전에서는 그 동작이 잘못되어 있었습니다. v1.38.2 업그레이드 후에는 삭제 시 기본값이 올바르게 복원됩니다. 런타임 오버라이드를 제거하는 자동화 스크립트나 CI 파이프라인이 있다면, 업그레이드 전후로 동작을 확인하세요.

• enhancementHTTP/2 쿠키 헤더 크기 제한 플래그 활용 검토

  envoy.reloadable_features.http2_max_cookies_size_in_kb를 설정하면 HTTP/2에서 재조합된 cookie 헤더의 최대 크기를 제한할 수 있습니다. 신뢰할 수 없는 트래픽을 처리하거나 대형 쿠키가 빈번히 유입되는 환경이라면, 적절한 값을 설정해 메모리 사용을 줄이세요. 기본값은 무제한이므로 명시적으로 opt-in해야 합니다.

Envoy v1.37.4는 RTDS 버그 수정 하나와 HTTP/2 쿠키 관련 옵트인 기능 두 가지를 포함한 소규모 패치입니다. CVE는 없습니다.

• breakingRTDS 오버라이드 삭제 동작 변경 — 런타임 가드 기본값 확인 필요

  RTDS로 런타임 가드 오버라이드를 관리 중이라면, 기존에는 오버라이드를 삭제해도 이전 값이 남아 있었습니다. 이번 수정으로 삭제 시 프로세스 전체 기본값으로 복원됩니다. 오버라이드 삭제 후 적용될 기본값이 의도한 값인지 확인하세요. 특히 기존 버그 동작을 우회하는 방식으로 설정했던 경우 반드시 검토가 필요합니다.

• enhancement신뢰할 수 없는 HTTP/2 클라이언트가 있다면 쿠키 크기 제한 설정을 고려하세요

  이번 릴리스 이전에는 HTTP/2 재조립 cookie 헤더에 크기 제한이 없었습니다. 외부 HTTP/2 트래픽을 프록시한다면 envoy.reloadable_features.http2_max_cookies_size_in_kb를 적절한 값(예: 32–64 KB)으로 설정해 비정상적으로 큰 쿠키가 업스트림에 전달되는 상황을 막을 수 있습니다. 기본값은 무제한이므로 명시적으로 설정해야 합니다.

• enhancementHTTP/2 헤더 히스토그램을 스테이징에서 먼저 켜서 트래픽 특성을 파악하세요

  envoy.reloadable_features.http2_record_histograms를 활성화하면 헤더 수, 바이트 크기, 쿠키 관련 메트릭을 히스토그램으로 수집할 수 있습니다. HTTP/2 헤더 부하를 파악하는 데 유용하지만, 향후 릴리스에서 제거될 임시 기능입니다. 프로덕션 대시보드에 장기 의존하지 않도록 주의하세요.

Envoy v1.36.8은 RTDS 버그 수정 1건과 HTTP/2 관찰성 기능 2건을 담은 소규모 패치입니다. Breaking change나 CVE는 없습니다.

• breakingHTTP/2 헤더 히스토그램은 임시 기능 — 영구 대시보드에 연결하지 마세요

  http2_record_histograms 기능과 그 runtime guard는 향후 Envoy 릴리스에서 제거될 예정이라고 명시되어 있습니다. HTTP/2 헤더 디버깅 목적으로 활성화하더라도, 이 메트릭을 영구 대시보드나 알림에 연결해두면 업그레이드 시 깨집니다. 임시 디버깅 용도로만 쓰세요.

• enhancementHTTP/2 헤더·쿠키 크기 문제를 디버깅할 때 새 히스토그램 활용

  HTTP/2 요청이 예상보다 크거나 쿠키 관련 이상 동작이 보인다면 envoy.reloadable_features.http2_record_histograms를 켜서 헤더 항목 수, 바이트 크기, 쿠키 메트릭을 수집하세요. 업스트림 서비스를 과도하게 큰 쿠키 헤더로부터 보호해야 한다면 envoy.reloadable_features.http2_max_cookies_size_in_kb로 크기 상한도 함께 설정하는 것이 좋습니다.

Dapr 1.18은 워크플로우 보안·내구성(변조 감지, 접근 정책, 히스토리 전파, 동시성 제한)을 크게 보강했습니다. Jobs API와 HotReload가 GA로 승격되었고, 업그레이드 전 반드시 검토해야 할 breaking change가 여럿 포함되어 있습니다.

• security공유·멀티테넌트 클러스터에서 WorkflowAccessPolicy 적용 검토

  1.18 이전에는 같은 trust domain의 모든 호출자가 다른 앱의 워크플로우를 스케줄, 종료, 조회할 수 있었습니다. WorkflowAccessPolicy CRD로 이를 per-operation 수준에서 제한할 수 있습니다. 기본값은 여전히 전체 허용이라 기존 배포에 즉각적인 영향은 없지만, 공유 클러스터를 운영 중이라면 지금 정책을 정의해두는 편이 낫습니다. 또한 redis common 컴포넌트의 TLS 인증서 검증 무조건 건너뛰기 버그가 이번 릴리스에서 수정되었으니, 업그레이드 전 Redis TLS 설정이 올바른지 확인하세요.

• breaking1.18에서 1.17.6 이하로 직접 롤백 금지

  Sentry 1.18은 Ed25519 키로 서명된 CA를 dapr-trust-bundle 시크릿에 기록합니다. 1.17.7 미만의 Sentry는 이 번들을 파싱하지 못해 크래시 루프에 빠지고, 신규 인증서 발급이 전면 중단됩니다. 업그레이드 전에 롤백 목표 버전이 1.17.7 이상인지 반드시 확인하세요. 1.17.7 미만으로 내려가야 한다면 1.17.7로 먼저 롤백해 안정화한 뒤 계속 진행하세요. 워크플로우 ID 재사용에 의존하는 코드도 함께 점검하세요 — 이제 conflict 에러를 반환합니다.

• breaking서비스 호출 시 hop-by-hop 헤더 제거 — 앱 동작 점검 필요

  Connection, Keep-Alive, Transfer-Encoding 등 HTTP hop-by-hop 헤더가 서비스 호출 경로에서 RFC 7230에 따라 제거됩니다. 해당 헤더가 그대로 전달된다고 가정하는 앱은 조용히 깨질 수 있습니다. 업그레이드 전에 서비스 호출 코드를 검토하고, hop-by-hop에 의존하는 부분은 일반 헤더로 대체하세요.

• enhancement감사 요건이 있는 워크플로우에 히스토리 서명 활성화 검토

  워크플로우 히스토리 서명은 opt-in이며 기본 비활성 상태입니다. mTLS가 활성화되어 있어야 사용할 수 있습니다. 클러스터 전체에 활성화하기 전에 서명 없이 실행 중인 워크플로우가 완료되거나 purge되도록 기다리세요 — 서명 없이 시작된 워크플로우에 서명을 활성화하면 하드 검증 에러가 발생하며 소급 적용은 불가합니다. 변조가 감지되면 해당 워크플로우는 DAPR_WORKFLOW_HISTORY_TAMPERED 에러와 함께 종료되고, 원본 상태는 포렌식 검토를 위해 보존됩니다. 컴플라이언스 요건이 있거나 멀티테넌트 워크플로우를 운영하는 환경에 적합합니다.

Envoy v1.35.12는 RTDS 런타임 가드 버그 수정 1건과 HTTP/2 쿠키·헤더 관찰용 opt-in 기능 2건이 포함된 마이너 패치입니다. Breaking change나 CVE는 없습니다.

• breakingRTDS 오버라이드 삭제 동작 변경 — 런타임 가드 기본값 확인 필요

  RTDS로 런타임 가드 오버라이드를 관리하고 있다면 스테이징에서 동작을 검증하세요. 이전에는 오버라이드를 삭제해도 기존 값이 유지됐지만, 이제는 프로세스 기본값으로 복원됩니다. 삭제 후에도 값이 유지된다고 가정하는 자동화 스크립트가 있다면 동작이 달라집니다.

• enhancementHTTP/2 쿠키 크기 제한 플래그로 메모리 사용량 통제

  envoy.reloadable_features.http2_max_cookies_size_in_kb는 기본적으로 비활성화 상태입니다. 신뢰할 수 없는 HTTP/2 트래픽을 받는 환경이라면, 재조합된 cookie 헤더로 인한 메모리 소비를 제한하기 위해 적절한 값을 설정하세요. 먼저 새로 추가된 히스토그램으로 실제 쿠키 크기를 측정한 뒤 상한값을 결정하는 순서가 좋습니다.

Chaos Mesh v2.8.3은 컨테이너 이미지의 critical/high CVE를 패치하고, CrashLoopBackOff 상태 파드에서 NetworkChaos 복구가 실패하던 버그를 수정한 패치 릴리스입니다.

• securitycritical/high CVE 패치를 위해 v2.8.3으로 업그레이드

  Go 툴체인과 containerd에서 critical/high 수준의 CVE가 확인됐습니다. release-2.8 브랜치를 운영 중이라면 즉시 v2.8.3으로 업그레이드하세요. 설정 변경은 필요 없고 이미지 교체만으로 충분합니다.

• breakingCrashLoopBackOff 파드를 대상으로 한 NetworkChaos 실험 재검증 필요

  이전 버전에서는 대상 컨테이너가 CrashLoopBackOff 상태일 때 NetworkChaos 복구가 실패했습니다. v2.8.3은 이를 pause 컨테이너 PID로 폴백해 수정했습니다. 의도적으로 크래시가 반복되는 워크로드를 포함한 카오스 실험을 운영 중이라면, 업그레이드 후 복구 동작을 다시 확인하세요.

NATS v2.12.11은 단일 버그 수정 패치입니다. v2.12.7에서 도입된 JetStream regression으로 per-subject 메시지 수 제한이 설정된 스트림에서 'Message Not Found' 오류가 발생하는 문제를 고쳤습니다.

• breakingmax_msgs_per_subject 설정 중이라면 즉시 업그레이드

  NATS 2.12.7~2.12.10을 운영하면서 스트림에 MaxMsgsPerSubject(max_msgs_per_subject)를 설정했다면, subject 상태가 잘못 추적되어 'Message Not Found' 오류가 간헐적으로 발생할 수 있습니다. 컨슈머가 메시지를 놓치거나 예기치 않게 동작할 수 있으므로, 2.12.11로 바로 업그레이드하세요. 이미 2.14.x를 사용 중이라면 영향받지 않습니다.

CoreDNS v1.14.4는 DNSSEC 서명 버그 수정, 캐시 동작 개선, forward 플러그인의 hostname 지원 등 여러 기능 개선과 수정을 포함합니다.

• breakingDNSSEC 서명 동작 변경 — 위임 존 구성 검토 필요

  RRset 서명 주체가 쿼리 존에서 해당 이름의 소유 존으로 바뀌었습니다. 기술적으로 올바른 수정이지만, 위임이 포함된 멀티존 DNSSEC 구성을 운영 중이라면 업그레이드 후 서명된 응답을 반드시 검증하세요. 기존 동작에 의존하던 존은 서명값이 달라질 수 있습니다. 프로덕션 전환 전에 주요 레코드에 dnssec-verify를 돌려보세요.

• enhancementforward 엔드포인트를 IP 대신 hostname으로 지정 가능

  forward 플러그인이 TO 엔드포인트의 hostname을 런타임에 직접 해석합니다. 업스트림 리졸버 IP가 바뀌는 환경(클라우드 관리형 리졸버 등)이라면 설정을 FQDN으로 전환해 관리 부담을 줄일 수 있습니다. 단, 시작 시 hostname 해석에 실패하면 포워딩에 영향을 줄 수 있으니 스테이징에서 먼저 확인하세요.

• enhancement캐시 TTL 상한 제거 — 안정적인 레코드는 max_ttl 상향 검토

  기존에는 DNS 레코드의 실제 TTL과 무관하게 캐시 TTL이 3600s로 제한됐습니다. 이 제한이 없어졌으니, 내부 권위 존이나 루트 힌트처럼 변경이 드문 레코드는 max_ttl을 높여 업스트림 쿼리 부하를 줄일 수 있습니다. cache 플러그인 설정을 검토해 적절한 구간에 적용하세요.

OTel Collector v0.154.0은 exporterhelper 시작 시 nil 포인터 패닉을 수정하고, --skip-get-modules 동작 방식을 변경합니다. TLS·CORS 설정 옵션도 소폭 추가됐습니다.

• securityinclude_insecure_cipher_suites는 기본 비활성 — 건드리지 마세요

  새로 추가된 configtls 옵션으로 취약한 암호 스위트를 다시 활성화할 수 있지만, 기본값은 비활성입니다. 레거시 피어 연동이 불가피한 경우가 아니라면 운영 환경에서 true로 설정하지 마세요. 불가피하게 켜야 한다면 임시 조치로 간주하고 추적 관리하세요.

• breaking--skip-get-modules를 쓰는 빌드 파이프라인 점검 필요

  OCB 기반 빌드 스크립트에서 --skip-get-modules 실행 시 go.mod가 암묵적으로 재생성되는 동작에 의존했다면, 이제 그 동작은 사라졌습니다. CI 파이프라인을 확인하고, 필요하다면 go mod tidy 단계를 명시적으로 추가하세요.

• enhancementsending_queue에 sizer를 설정한다면 즉시 업그레이드

  sending_queue.sizer를 사용하면서 batch.enabled: false로 설정한 경우, 컬렉터가 시작 시 패닉으로 죽는 문제가 이번 릴리스에서 수정됐습니다. 해당 구성을 사용 중이라면 v0.154.0으로 업그레이드하세요.

KEDA 2.20.1은 동시 스케일링 중 패닉을 유발하는 경합 조건을 고치고 ScaledJob의 누락된 시작 이벤트를 복원합니다. 2.20.0을 운영 중이면 업그레이드가 필수입니다.

• security동시 스케일링 중 패닉 크래시가 발생했다면 2.20.1로 업그레이드하기

  상태 업데이트 로직의 동시 맵 읽기/쓰기 경합 조건이 여러 트리거가 동시에 스케일링될 때 KEDA를 패닉하게 만들었습니다. 2.20.1에서 수정되었습니다. 2.20.0에서 높은 스케일링 활동 중에 패닉 크래시를 경험했다면 즉시 업그레이드하세요.

• breaking업그레이드 전에 v2.20.0 호환성 변경사항 확인하기

  KEDA 2.20.0에서 호환성을 깨는 변경이 있었습니다. 2.20.0 이전 버전에서 KEDA를 운영 중이라면 2.20.1로 업그레이드하기 전에 GitHub의 v2.20.0 릴리스 노트를 반드시 읽으세요. 2.20.0 릴리스 노트를 건너뛰고 2.20.1로 바로 업그레이드하지 마세요.

• enhancementScaledJob 스케일러 시작 이벤트 가시성 복원하기

  KEDA가 Kubernetes 이벤트 수집(aggregation) 키 충돌로 인해 ScaledJob에 대한 KEDAScalersStarted 이벤트를 발생시키지 못했습니다. 이 이벤트를 추적하는 모니터링 도구나 대시보드는 ScaledJob 시작 신호를 놓쳤을 수 있습니다. 2.20.1로 업그레이드하여 정상적인 이벤트 발생을 복원하세요.

gRPC v1.81.1은 Windows·ARM 메모리 안전성 버그를 수정한 패치 릴리스입니다. API 호환성을 깨는 변경은 없습니다.

• breakingPython 3.9, Ruby 3.1 지원 종료 — 런타임 버전 확인 필요

  Python 3.9 또는 Ruby 3.1에서 gRPC를 쓰고 있다면 v1.81.1로 업그레이드 시 빌드가 깨집니다. 업그레이드 전에 서비스 런타임 버전을 확인하고, Python 3.10+, Ruby 3.2+로 먼저 올리세요.

• enhancementWindows·ARM 배포 환경은 이번 패치 적용 권장

  Windows EventEngine race 2건과 ARM completion queue 종료 race가 수정됐습니다. use-after-free나 assertion crash는 재현이 어렵지만 서비스를 간헐적으로 죽이는 유형입니다. Windows 서버나 Graviton 같은 ARM 호스트에서 gRPC를 운영 중이라면 패치를 적용하세요.

• enhancementgrpc-status에서 protobuf 7.x 사용 가능

  grpc-status 패키지의 protobuf 상한이 7.x까지 풀렸습니다. protobuf 최신 버전을 요구하는 다른 라이브러리와 함께 쓸 때 버전 충돌로 고생했다면, 이제 상한 고정을 제거해도 됩니다.

v2 업그레이드 준비 상태를 자동으로 점검하는 CLI 명령 추가, golang.org/x/net 보안 패치, 런타임 업데이트가 포함된 패치 릴리스입니다.

• securitygolang.org/x/net 보안 패치 — 즉시 업그레이드 필요

  golang.org/x/net이 보안 이슈로 v0.55.0으로 업데이트됐습니다. 릴리스 노트가 명시적으로 보안 업데이트로 분류한 만큼, 선택이 아닌 필수 조치입니다. 다음 정기 점검 시점을 기다리지 말고, 가능한 가장 빠른 유지보수 창에 v1.20.9로 업그레이드하세요.

• breakingupgrade check 결과는 경고가 아닌 실제 차단 항목

  이 명령은 v2에서 제거되거나 변경된 기능 — 네이티브 P&T Composition, ControllerConfig, 외부 시크릿 스토어, 미정규화 패키지 소스 — 의 실제 사용 여부를 검사합니다. 단순한 deprecation 경고가 아니라 업그레이드를 막는 하드 블로커입니다. 점검 결과에 문제가 있다면, v2 업그레이드 전에 제공된 마이그레이션 가이드를 따라 선행 작업을 완료해야 합니다. 그냥 업그레이드하면 운영 중인 워크로드가 중단됩니다.

• enhancementv2 마이그레이션 계획 전 upgrade check 먼저 실행

  v1.x 컨트롤 플레인을 운영 중이고 v2 전환이 로드맵에 있다면, 지금 당장 `crossplane beta upgrade check`를 실행해 보세요. 어떤 Composition, ControllerConfig, 패키지 참조가 업그레이드를 막는지 정확히 알 수 있어 수동 감사에 드는 시간을 크게 줄일 수 있습니다. `-o json` 옵션과 함께 CI 파이프라인에 연결하면, v2 업그레이드 PR 병합 전 자동 게이팅도 간단히 구현됩니다.

v1.17.1은 이터레이터 캐시의 stale read 버그와 타입 이름에 '|' 문자가 포함될 때 continuation token이 깨지는 문제를 수정한 패치 릴리스입니다.

• security캐시 stale read로 잘못된 권한 결정이 반환될 수 있었음 — 즉시 패치

  이터레이터 캐시가 쓰기 시각을 기준으로 LastModified를 설정하고 있어, 캐시 항목이 유효 기간을 초과해 살아남아 오래된 데이터를 서빙할 수 있었습니다. 권한 시스템에서 만료된 'allow' 판정이 그대로 반환되는 건 실질적인 보안 위험입니다. 캐싱을 활성화해 운영 중이라면 v1.17.1로 즉시 업그레이드하세요.

• breaking'|' 포함 타입 이름 사용 중이라면 페이지네이션 즉시 재검증

  FGA 모델에서 '|' 문자가 들어간 타입 이름을 쓴다면, continuation token이 잘못 역직렬화되어 ListObjects 등 페이지네이션 API가 불완전하거나 잘못된 결과를 반환했을 수 있습니다. 오류 메시지 없이 조용히 깨지는 유형이라 놓치기 쉽습니다. v1.17.1로 업그레이드한 뒤 해당 타입 이름을 참조하는 페이지네이션 흐름을 반드시 재테스트하세요.

• enhancementv2Check 폴백 제거 — 에러 처리 로직 사전 점검 필요

  기존에는 스로틀링이나 유효성 검증 오류 발생 시 v2Check가 v1 동작으로 조용히 폴백해 실제 문제가 숨겨졌습니다. 이제 해당 오류가 직접 반환됩니다. 애플리케이션이 check 오류를 묵시적으로 삼키거나 폴백 동작을 가정하고 있다면, 이전에 보이지 않던 오류가 갑자기 노출될 수 있습니다. 프로덕션 배포 전 부하 상황에서 반드시 테스트하세요.

Istio 1.29.4는 Envoy의 CVSS 7.5 DoS 취약점(CVE-2026-47774)을 패치하고, 클러스터 전체 unhealthy 엔드포인트로 트래픽이 라우팅될 수 있던 앰비언트 모드 버그 등 6건의 결함을 수정합니다.

• securityCVE-2026-47774 즉시 패치 — 인증 없이 DoS 가능

  CVE-2026-47774는 외부 공격자가 인증 없이 조작된 HTTP/2 요청만으로 Envoy 메모리를 고갈시킬 수 있는 취약점입니다. 쿠키 헤더 크기가 요청 헤더 검증에서 완전히 반영되지 않고, HPACK 블록 제한이 인코딩된 바이트 기준으로만 적용되는 두 가지 문제가 결합된 결과입니다. 인그레스 게이웨이처럼 HTTP/2를 외부에 노출하는 환경이라면 지금 바로 1.29.4로 업그레이드해야 합니다.

• breaking앰비언트 모드: publishNotReadyAddresses + 트래픽 분산 조합 점검 필요

  publishNotReadyAddresses:true와 PreferSameZone 또는 PreferSameNode 트래픽 분산을 함께 쓰는 Service가 하나라도 있으면, 동일 프리셋을 사용하는 모든 Service에 healthPolicy:AllowAll이 전파되어 클러스터 전체에서 준비되지 않은 엔드포인트로 트래픽이 흘렀을 가능성이 있습니다. 업그레이드 전후로 ztunnel 로그에서 AllowAll 항목을 확인해 수정이 제대로 적용됐는지 검증하세요.

• enhancement구형 커널 환경: nftables → iptables 자동 전환으로 CNI 안정성 향상

  JSON을 지원하지 않는 nft 바이너리가 있는 호스트에서 CNI 에이전트가 파드 제거마다 오류를 기록하며 무한 재시도하던 문제가 수정됐습니다. 이제 시작 시점에 JSON 지원 여부를 감지해 iptables 백엔드로 자동 전환합니다. 별도 조치는 불필요하지만, CNI 에이전트 로그에서 'JSON support not compiled-in' 오류가 반복됐던 환경이라면 업그레이드 후 오류가 사라지는지 확인하세요.

Istio 1.28.8은 Envoy HTTP/2 메모리 고갈 취약점(CVSS 7.5)을 패치하고, TLS 인증서 전달 오류, 라우트 필터 상태 미보고, ambient 모드 헬스 정책 오염 버그를 수정합니다.

• securityHTTP/2 엔드포인트 노출 중이라면 즉시 CVE-2026-47774 패치 적용

  인증 없이도 조작된 HTTP/2 요청만으로 Envoy 프로세스 메모리를 고갈시킬 수 있습니다. 쿠키 헤더 바이트가 크기 검증에서 누락되고, HPACK 제한이 인코딩 크기에만 적용되어 디코딩 후 실제 크기를 제어하지 못하는 구조적 결함입니다. 외부 트래픽이나 신뢰할 수 없는 HTTP/2 트래픽을 받는 클러스터는 지금 바로 1.28.8로 업그레이드하세요. 즉시 업그레이드가 어렵다면 Envoy 요청 헤더 크기 제한 설정이나 WAF 규칙으로 임시 대응하세요.

• breakingambient 모드에서 publishNotReadyAddresses + 존 기반 트래픽 분산 조합 즉시 점검 필요

  ambient 모드에서 publishNotReadyAddresses:true와 PreferSameZone 또는 PreferSameNode를 함께 쓰는 서비스가 있다면, 해당 트래픽 분산 프리셋을 공유하는 모든 서비스의 ztunnel 헬스 정책이 AllowAll로 오염되어 클러스터 전체에서 준비되지 않은 엔드포인트로 트래픽이 흘렀을 가능성이 있습니다. 업그레이드 후 영향받은 서비스의 엔드포인트 헬스 동작을 재확인하고, 문제가 활성화된 기간 동안 비정상 파드로 트래픽이 유입됐는지 점검하세요.

• enhancement라우트 필터 묵살 버그 수정으로 설정 디버깅 신뢰성 향상

  기존에는 HTTPRoute/GRPCRoute에서 잘못된 헤더 값을 가진 필터가 Envoy 설정에서 아무 오류 없이 사라져 트래픽 동작 이상의 원인을 찾기가 매우 어려웠습니다. 이제 invalid filter status가 Gateway API 리소스 상태에 명시적으로 표시됩니다. 업그레이드 후 과거 감으로 디버깅했던 라우트 설정을 재검토하면 헤더 필터 거부 여부를 바로 확인할 수 있습니다.

Istio 1.30.1은 Envoy HTTP/2에서 발생하는 CVSS 7.5 DoS 취약점 패치와 함께 CNI 에이전트 패닉, 트래픽 분산 정책 오염 버그, 일관 해시 로드밸런싱 회귀 등 13개 버그를 수정합니다.

• securityCVE-2026-47774 즉시 패치 — 비인증 HTTP/2 DoS 공격 가능

  인증 없이 조작된 HTTP/2 요청만으로 Envoy 메모리를 고갈시킬 수 있습니다. Cookie 헤더 크기 계산 누락과 HPACK 디코딩 한도 미적용이 원인입니다. Istio 1.30.x를 운영 중이라면 지금 바로 1.30.1로 업그레이드하세요. 특히 신뢰할 수 없는 외부 트래픽에 노출된 인그레스 게이트웨이가 가장 위험한 지점입니다.

• breaking앰비언트 모드 + 트래픽 분산 정책 사용자: 서비스 즉시 점검

  publishNotReadyAddresses: true와 PreferSameZone 또는 PreferSameNode를 함께 사용하는 Service가 있다면, 해당 버그로 인해 동일 프리셋을 공유하는 무관한 다른 Service들에도 healthPolicy: AllowAll이 적용되었을 수 있습니다. 결과적으로 준비되지 않은 파드로 트래픽이 라우팅됐을 가능성이 있습니다. 1.30.1 업그레이드 후 엔드포인트 상태를 검증하고, 준비되지 않은 파드에 트래픽이 유입됐는지 확인하세요.

• enhancement업그레이드 후 'istioctl analyze'로 Gateway API CRD 버전 점검

  1.30.0에서 Gateway API CRD를 업데이트하지 않고 Istio만 업그레이드하면 TLS 패스스루가 조용히 깨지는 문제가 있었습니다. istiod가 관련 리소스를 오류 없이 필터링하기 때문에 원인 파악이 어려웠는데, 새 IST0176 검사가 이를 명확히 잡아냅니다. 업그레이드 후 istioctl analyze를 실행하고 IST0176 경고가 있으면 운영 환경에서 라우팅 장애로 번지기 전에 조치하세요.

HTTP/2 CVE 2건과 oauth2 취약점 2건을 수정한 보안 패치입니다. HTTP/2 또는 oauth2 필터를 운영 중이라면 즉시 업그레이드해야 합니다.

• securityHTTP/2·oauth2 CVE — 다음 정기 점검을 기다리지 말고 지금 패치하세요

  HPACK 쿠키 폭탄을 통한 메모리 소진(CVE-2026-47774), nghttp2 취약점(CVE-2026-27135), oauth2 HMAC 타이밍 오라클, oauth2 크래시 유발 버그까지 총 4개의 보안 이슈가 수정됐습니다. oauth2 필터를 쓰고 있다면 HMAC 타이밍 사이드채널이 특히 위험합니다. 공격자가 반복 요청으로 HMAC 시크릿의 유효성을 추적할 수 있습니다. v1.38.1로 즉시 업그레이드하세요. HTTP/2 헤더 제한 동작은 기본값으로 활성화되므로, 명확한 이유 없이 `envoy.reloadable_features.http2_include_cookies_in_limits`로 되돌리지 마세요.

• breakingHTTP 응답 본문에서 upstream 장애 이유가 제거됩니다 — 클라이언트 에러 처리 로직을 점검하세요

  이전까지 HTTP 응답 본문에 포함되던 upstream transport failure reason이 사라집니다. 이 정보를 파싱하거나 표시하는 다운스트림 클라이언트나 대시보드가 있다면 업그레이드 전에 반드시 확인해야 합니다. 액세스 로그에는 여전히 기록되니 모니터링 방식을 조정하세요. 이전 동작이 꼭 필요하다면 `envoy.reloadable_features.hide_transport_failure_reason_in_response_body`로 일시적으로 복원할 수 있습니다.

• breakingEDS 배치 업데이트 시 LB 재구성 병합이 opt-in으로 전환됩니다

  EDS 배치 호스트 업데이트 중 로드밸런서 재구성 병합이 기본 비활성화됩니다. 파드 수가 많은 Kubernetes 환경에서 롤링 배포가 잦다면 LB 재구성 빈도가 늘어 CPU 부하가 증가할 수 있습니다. 업그레이드 후 컨트롤 플레인과의 상호작용 패턴을 벤치마킹하세요. 성능 저하가 확인되면 `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`로 이전 동작을 복원하세요.

v1.37.3은 HTTP/2 CVE 2건과 oauth2 취약점을 수정한 보안 패치입니다. HTTP/2 또는 oauth2 필터를 사용 중이라면 즉시 업그레이드해야 합니다.

• securityHTTP/2 운영 환경은 즉시 패치하세요

  이번 릴리스에서 HTTP/2 관련 CVE 두 건이 수정됩니다. CVE-2026-47774는 대량의 쿠키를 전송해 헤더 크기 제한을 우회하고 메모리를 과도하게 소비시키는 쿠키-봄 공격을 허용하는 취약점이고, CVE-2026-27135는 nghttp2 라이브러리 수준의 취약점입니다. HTTP/2 트래픽을 처리하는 환경이라면 v1.37.3으로 즉시 업그레이드하세요. 새로운 쿠키 계산 방식은 기본 활성화되며, 문제가 발생하면 `envoy.reloadable_features.http2_include_cookies_in_limits` 플래그로 임시 비활성화할 수 있지만 영구적인 해결책으로 쓰면 안 됩니다.

• security업그레이드 후 oauth2 HMAC 시크릿을 교체하세요

  HMAC 검증의 타이밍 사이드채널을 통해 공격자가 특정 시크릿의 유효 여부를 탐색했을 가능성이 있습니다. 특히 인터넷에 노출된 환경이라면 업그레이드 후 oauth2 HMAC 시크릿을 교체하는 것이 좋습니다. AES-CBC 크래시 수정도 단순한 안정성 문제가 아닙니다. 1/256 확률의 오복호화는 예측 불가능한 인증 동작으로 이어질 수 있었습니다.

• breaking쿠키가 많은 요청은 HTTP/2 스트림 리셋이 발생할 수 있습니다

  CVE-2026-47774 수정으로 인해 쿠키가 `mutable_max_request_headers_kb` 및 `max_headers_count` 제한에 포함됩니다. 이전에는 통과되던 쿠키 다수 포함 요청이 제한에 걸려 스트림 리셋으로 거부될 수 있습니다. 프로덕션 배포 전에 스테이징에서 쿠키가 많은 트래픽 패턴을 테스트하고, 현재 설정된 헤더 크기 제한이 실제 워크로드에 적합한지 검토하세요.

v1.36.7은 HTTP/2 관련 CVE 2건, oauth2 필터의 HMAC 타이밍 사이드채널 및 충돌 버그를 수정한 보안 패치입니다. 즉시 업그레이드가 필요합니다.

• securityHTTP/2 CVE 2건 — 즉시 패치 적용 필요

  CVE-2026-47774는 HPACK 압축 쿠키를 이용해 Envoy 메모리를 고갈시키는 공격 벡터입니다. 패치 후에는 쿠키가 `mutable_max_request_headers_kb` 및 `max_headers_count` 제한에 포함됩니다. 업그레이드 후 정상 요청이 리셋된다면 `envoy.reloadable_features.http2_include_cookies_in_limits` 플래그로 일시적으로 되돌릴 수 있지만, 먼저 헤더 크기 설정을 점검하세요. CVE-2026-27135는 별도 우회 방법이 없으므로 반드시 업그레이드해야 합니다.

• securityoauth2 필터 사용 중이라면 이번 릴리스를 최우선으로 배포하세요

  HMAC 타이밍 사이드채널은 공격자가 반복 요청으로 시크릿 유효성을 추론할 수 있는 취약점입니다. AES-CBC 충돌 버그(불량 토큰 기준 1/256 확률)는 의도적으로 트리거할 수 있어 서비스 안정성에도 영향을 줍니다. 두 이슈 모두 설정으로 우회할 방법이 없으므로, oauth2 필터를 쓰는 환경이라면 이번 패치를 최우선으로 배포하세요.

• breaking배포 전 헤더 크기 제한 설정 반드시 검토

  기존에 헤더 크기 계산에서 제외됐던 쿠키가 이제 제한에 포함됩니다. 쿠키가 많거나 큰 애플리케이션은 업그레이드 후 `max_headers_count` 또는 `mutable_max_request_headers_kb` 초과로 HTTP/2 스트림이 리셋될 수 있습니다. 롤아웃 전에 실 트래픽의 쿠키 크기를 기준으로 현재 제한값을 점검하고, 필요하다면 reloadable feature 플래그로 시간을 버세요. 단, 장기간 비활성화 상태로 두는 건 피해야 합니다.

KubeVirt v1.8.3은 보안 취약점 패치, 인가 버그 수정, 라이브 마이그레이션 안정화, GPU/DRA 장치 처리 개선을 포함한 패치 릴리스로, 빠른 배포가 권장됩니다.

• securityCVE 및 심볼릭 링크 취약점 — 즉시 업그레이드 필요

  gRPC CVE(GHSA-p77j-4mvh-x3m3)와 VMExport 디렉터리 핸들러의 심볼릭 링크 탐색 취약점, 두 가지 보안 문제가 이번 릴리스에서 수정됐습니다. VMExport를 사용하거나 VM 데이터를 외부에 노출하는 환경이라면 업그레이드를 최우선으로 처리하세요. 업그레이드 전후로 기존 VMExport 디렉터리에 악의적인 심볼릭 링크가 없는지 점검하는 것도 잊지 마세요.

• breaking메트릭 이름 변경 — 업그레이드 전에 대시보드와 알림 규칙 수정 필요

  kubevirt_vm_created_total과 kubevirt_vm_created_by_pod_total은 완전히 deprecated 처리됐고, 다수의 recording rule도 네이밍 컨벤션 준수를 위해 이름이 바뀝니다. Grafana 대시보드, 알림 규칙, SLO 쿼리에서 이 메트릭을 참조하고 있다면 업그레이드 후 조용히 매칭이 끊깁니다. 프로덕션 배포 전에 옵저버빌리티 스택을 전수 점검하고 새 이름으로 마이그레이션하세요.

• enhancement라이브 마이그레이션 안정성 향상 — IPv6 및 크로스 네임스페이스 환경 포함

  이번 릴리스에서 라이브 마이그레이션 관련 버그 여러 건이 해결됐습니다. IPv6 클러스터의 크로스 네임스페이스 마이그레이션이 정상 작동하고, kubevirt_vmi_info 중복 시리즈로 인한 알림 오작동도 수정됐으며, 마이그레이션 중 GuestAgentPing 프로브로 인한 파드 재시작도 더 이상 발생하지 않습니다. IPv6나 멀티 네임스페이스 환경에서 불안정성 때문에 라이브 마이그레이션을 꺼리고 있었다면, 이번 버전이 그 장벽을 없애줄 겁니다.

KubeVirt v1.7.4는 gRPC CVE 패치, 인가 버그 수정, IPv6 환경 라이브 마이그레이션 수정, VM 수명주기 이벤트 중 프로브 오동작 수정을 포함한 패치 릴리스입니다.

• securityCVE-2026-33186 패치를 위해 즉시 v1.7.4로 업그레이드

  gRPC 의존성에서 CVE-2026-33186 취약점이 발견되어 1.79.3으로 업그레이드됐습니다. KubeVirt를 v1.7.4로 업그레이드하는 것 외에 별도의 설정 변경은 필요 없습니다. gRPC를 통해 신뢰할 수 없는 입력을 처리하는 워크로드가 있다면 업그레이드를 우선순위에 두세요.

• breakingVNC, SEV, evacuate 서브리소스 사용 시 RBAC 정책 재검토 필요

  SubjectAccessReview 버그로 인해 vnc/screenshot, sev/*, evacuate/cancel 서브리소스의 인가 검사가 잘못된 이름을 기준으로 평가되고 있었습니다. 이는 보안 문제인 동시에 인가 로직 자체의 정합성 문제입니다. v1.7.4로 업그레이드한 뒤, 관련 서브리소스에 설정된 RBAC 정책이 의도대로 동작하는지 반드시 확인하세요. 허용되어야 할 접근이 차단되거나, 그 반대 상황이 발생했을 가능성이 있습니다.

• enhancement마이그레이션이나 일시 중지 중 virt-launcher 파드가 재시작되는 문제 해소

  GuestAgentPing 프로브를 사용하는 환경에서 라이브 마이그레이션, 사용자 일시 중지, 스냅샷, 저장, 덤프 중 virt-launcher 파드가 불필요하게 재시작되는 현상이 있었습니다. 이번 수정으로 해당 상태에서의 프로브 오탐이 억제됩니다. 별도 조치 없이 업그레이드만으로 해결되며, 마이그레이션 중 프로브를 비활성화하는 등의 임시 대응책을 운영 중이었다면 제거해도 됩니다.

KubeVirt v1.6.6은 CVE 패치, virt-api 인가 오류, IPv6 환경의 크로스 네임스페이스 라이브 마이그레이션 버그 등 9건의 주요 결함을 수정한 패치 릴리스입니다.

• securityCVE-2026-33186 패치 적용을 위해 v1.6.6으로 즉시 업그레이드

  grpc 의존성 업데이트로 CVE-2026-33186이 수정됐습니다. 멀티테넌트 환경이거나 gRPC 엔드포인트가 외부에 노출된 클러스터라면 이번 업그레이드의 가장 중요한 이유입니다. 패치 릴리스이므로 업그레이드 경로는 단순하며, 현재 버전을 확인하고 빠르게 롤아웃 계획을 수립하세요.

• securityvirt-api 인가 오류 수정 후 RBAC 정책 검토 필요

  vnc/screenshot, sev/*, evacuate/cancel 같은 딥 경로에서 SubjectAccessReview가 잘못된 서브리소스 이름으로 평가되고 있었습니다. 결과적으로 접근 허용 또는 거부가 의도와 다르게 동작했을 수 있습니다. 업그레이드 후 VNC, SEV, 이배큐에이션 서브리소스에 대한 RBAC 정책이 기대대로 작동하는지 반드시 검증하세요.

• breakingIPv6 클러스터에서 크로스 네임스페이스 마이그레이션 동작 복구 — 업그레이드 후 검증 권장

  IPv6 클러스터에서 크로스 네임스페이스 라이브 마이그레이션이 조용히 실패하고 있었습니다. 이번 패치로 정상 동작이 복구됐는데, 프로덕션 워크플로에 반영하기 전에 업그레이드 후 테스트 마이그레이션을 직접 실행해 수정이 제대로 적용됐는지 확인하는 게 좋습니다.

• enhancementPCI hostdev 사용 VM의 재시작 안정성 개선

  PCI 패스스루 hostdev를 사용하는 VM이 블록 볼륨 핫플러그 후 재시작에 실패하던 문제가 수정됐습니다. PCI 토폴로지 게이팅이 아키텍처만 보고 머신 타입을 무시하던 것이 원인이었습니다. 별도 설정 변경 없이 업그레이드만으로 해결되므로, 관련 증상을 겪었다면 이번 릴리스에서 해소될 겁니다.

v2.19.0은 경량 검색용 /api/v3/trace-summaries 엔드포인트를 도입하고 UI 검색을 이 API로 전환했습니다. ClickHouse TLS 지원과 gRPC 최대 메시지 크기 설정도 추가됐습니다.

• breakingUI 검색의 /api/v3/trace-summaries 전환 — 백엔드 호환성 확인 필수

  이번 버전부터 UI 검색은 /api/v3/trace-summaries만 사용합니다. gRPC 스토리지 플러그인을 커스텀으로 운영 중이라면 SummaryReader 인터페이스 구현 여부를 반드시 확인하세요. 미구현 시 전체 트레이스 집계 폴백 경로로 동작하지만 성능 차이가 있습니다. UI와 백엔드를 별도로 관리한다면, UI를 이 버전으로 올리기 전에 백엔드도 v2.19.0으로 먼저 업그레이드해야 합니다.

• breakingAPI v3 클라이언트에서 query.num_traces를 query.search_depth로 교체

  기존 query.num_traces는 deprecated 별칭으로 당분간 작동하지만, 스크립트·대시보드·연동 도구에서 query.search_depth로 교체하는 걸 지금 진행하는 편이 좋습니다. 또한 HTTP 쿼리 파라미터는 camelCase가 정식 형식이 됐고 snake_case는 deprecated 별칭으로 전환됐으니 함께 확인하세요.

• enhancementgRPC 스토리지에서 메시지 크기 오류가 있다면 max_recv_msg_size_mib 설정

  gRPC 원격 스토리지 플러그인 사용 시 큰 트레이스가 기본 메시지 크기 제한에 걸리는 경우가 많습니다. 새로운 max_recv_msg_size_mib 옵션으로 이 한도를 명시적으로 올릴 수 있습니다. 'received message larger than max' 오류를 경험한 적 있다면 Jaeger 배포 설정에 이 값을 추가하세요.

• enhancement프로덕션 ClickHouse 스토리지에 TLS 설정 적용

  ClickHouse 스토리지 플러그인에 TLS 설정이 추가됐습니다. Jaeger 백엔드로 ClickHouse를 사용 중이고 네트워크 경계를 넘는 연결이 있다면, 네트워크 레벨 통제에만 의존하지 말고 TLS를 지금 설정하는 게 좋습니다.

CRI-O v1.36.1은 재시작 후 컨테이너 상태의 ImageRef가 repo@digest에서 이미지 ID 해시로 바뀌는 버그를 수정하고, List* RPC 디버그 로그 과다 출력 문제를 개선한 패치 릴리스입니다.

• breakingImageRef를 파싱하는 도구가 있다면 즉시 업그레이드 필요

  이 버그로 인해 CRI-O 재시작 후 컨테이너 상태의 ImageRef가 repo@digest 대신 원시 이미지 ID로 바뀌는 현상이 발생했습니다. ImageRef를 파싱하는 어드미션 컨트롤러, 감사 파이프라인, 이미지 정책 도구는 잘못된 형식을 받아 검증 실패나 감사 기록 오류를 낼 수 있습니다. 노드 재부팅이나 CRI-O 업그레이드가 잦은 환경이라면 v1.36.1로 즉시 패치하고, 관련 도구가 repo@digest 형식을 올바르게 처리하는지 확인하세요.

• enhancement디버그 로그 재활성화 가능 — List* RPC 로그 과다 출력 해소

  ListContainers나 ListPodSandboxes 호출이 빈번한 클러스터에서는 디버그 로그가 과도하게 쌓여 CRI-O 성능에 영향을 줬습니다. 이번 패치로 해당 경로의 로그 출력이 줄어들었습니다. 이 문제를 피하려고 로그 레벨을 낮췄던 환경이라면, 이제 디버그 로그를 다시 켜도 동일한 부담 없이 운영할 수 있습니다.

CRI-O v1.34.9는 동시 StopContainer 호출로 인한 패닉과 빠르게 종료되는 컨테이너의 잘못된 종료 코드 255 보고 문제를 수정한 순수 버그 픽스 릴리스입니다.

• breaking동시 StopContainer 패닉 위험 — 노드 드레인·빠른 파드 종료 환경은 즉시 업그레이드

  노드 드레인, 배치 워크로드의 빠른 파드 교체, 또는 여러 StopContainer 호출을 병렬로 실행하는 자동화가 있다면 기존 버전에서 CRI-O가 패닉으로 완전히 다운될 수 있습니다. 단순 에러가 아닌 런타임 크래시입니다. 해당 시나리오가 가능한 노드라면 v1.34.9로 즉시 업그레이드하세요.

• enhancement종료 코드 255 오탐 해소 — 알림 규칙과 재시작 정책 점검 권장

  종료 코드 255는 모니터링 스택에서 런타임 수준 장애로 해석되는 경우가 많고, 불필요한 파드 재시작이나 알림을 유발합니다. 빠르게 종료되는 init 컨테이너, 단기 Job 워크로드에서 255 종료 코드가 발생했다면 이 경쟁 조건에 의한 오탐이었을 가능성이 있습니다. 업그레이드 후 알림 규칙과 CrashLoopBackOff 이력을 확인해 잘못 분류된 장애가 없었는지 살펴보세요.

컨테이너가 빠르게 종료될 때 CRI-O가 종료 코드를 255로 잘못 보고하던 경쟁 조건(race condition) 버그를 수정한 패치 릴리스입니다.

• breaking종료 코드 255로 실제 컨테이너 장애가 가려졌을 수 있음

  모니터링·알림·재시작 정책이 종료 코드 255를 기준으로 동작한다면, 그간 빠르게 종료된 컨테이너들이 잘못 분류됐을 가능성이 있습니다. 업그레이드 후에는 종료 코드 255를 특정 신호로 처리하는 런북이나 OOMKill/CrashLoopBackOff 워크플로를 점검하세요. 단기 실행 컨테이너의 실제 종료 코드가 이제 올바르게 노출됩니다.

• enhancement1.33.x 사용자라면 설정 변경 없이 바로 업그레이드 가능

  v1.33.12의 완전한 드롭인 교체 버전입니다. 의존성 변경도, 설정 수정도 필요 없습니다. 노드 롤링 드레인 후 CRI-O 바이너리만 교체하면 됩니다. 배치 잡, init 컨테이너, 단기 실행 워크로드가 많은 노드부터 우선 적용하는 것이 효과적입니다.

CVE-2026-46680 보안 패치와 함께 샌드박스 서비스 버그, AppArmor 호환성, OCI USER 스펙 처리 문제를 수정한 패치 릴리스입니다.

• securityCVE-2026-46680 즉시 패치 적용

  이번 릴리스의 핵심은 CVE-2026-46680 수정입니다. GHSA 어드바이저리에서 공격 범위와 심각도를 먼저 확인하세요. containerd 2.1.x를 운영 중이라면 이번 업그레이드를 최우선 배포 작업으로 처리해야 합니다. 의존성 변경이 없어 업그레이드 절차는 단순합니다.

• breakingOCI USER 범위 초과 값이 이제 명시적 오류로 실패 — 스펙 사전 점검 필요

  기존에는 OCI 스펙의 USER 값이 유효 UID/GID 범위를 벗어나도 사용자명/그룹 조회로 암묵적으로 처리되어 설정 오류가 숨겨졌습니다. 이제는 명시적 에러가 반환되므로, 숫자형 USER 값을 사용하는 컨테이너가 있다면 업그레이드 후 갑자기 실패할 수 있습니다. 프로덕션 배포 전에 컨테이너 스펙을 반드시 점검하세요.

• enhancementAppArmor 3.0 미만 환경이나 샌드박스 런타임 사용자는 업그레이드 적극 권장

  AppArmor abi 조건부 설정 수정은 구버전 AppArmor(예: Ubuntu 20.04의 2.x)를 사용하는 환경에서 실질적인 차단 요인이었습니다. 샌드박스 서비스 버그도 이벤트 기반 워크플로와 샌드박스 생성 설정에 직접 영향을 줍니다. Kata Containers 등 샌드박스 기반 런타임을 쓰고 있다면 이번 수정이 특히 중요합니다.

Rook v1.20은 CSI 드라이버 관리를 Ceph CSI 오퍼레이터로 이관하는 breaking change를 포함하며, 암호화 OSD 자동 리사이즈, Vault Agent SSE-S3 지원, 동시 클러스터 조정 안정화도 함께 제공됩니다.

• breaking업그레이드 전에 CSI 설정 마이그레이션 경로를 먼저 정리하세요

  기존 클러스터는 업그레이드 후에도 이전 CSI 설정이 그대로 유지되지만, 이후 변경은 반드시 Ceph-CSI OperatorConfig와 Driver CR로 처리해야 합니다. Helm 사용자는 ceph-csi-drivers 차트가 오퍼레이터 설정을 담당하고, 커스텀 이미지는 rook-ceph 차트 values에 남습니다. 업그레이드 전에 현재 CSI 커스터마이징 항목을 미리 정리해두지 않으면, 나중에 설정 변경이 필요할 때 당황하게 됩니다.

• enhancement커스텀 CRUSH 룰이 있다면 업그레이드 전에 반드시 확인하세요

  이제 mgr 시작 시 미사용 CRUSH 룰이 자동으로 삭제됩니다. 페일오버나 수동 배치용으로 의도적으로 남겨둔 CRUSH 룰이 있다면, 업그레이드 전에 오퍼레이터 configmap에 ROOK_DELETE_UNUSED_CRUSH_RULES=false를 설정하세요. 필요한 순간에 CRUSH 룰이 사라져 있는 상황은 최악의 타이밍에 터집니다.

• enhancement다중 CephCluster 운영 환경이라면 동시 조정 기능을 활성화하세요

  ROOK_RECONCILE_CONCURRENT_CLUSTERS가 stable로 승격됐습니다. 단일 오퍼레이터로 여러 CephCluster를 관리하는 환경에서는 이 설정을 켜면 조정 병목이 해소됩니다. 기존에는 느린 클러스터 하나가 전체 조정을 막는 문제가 있었는데, 멀티테넌트나 멀티클러스터 구성에서 특히 체감 차이가 큽니다.

v2.14.2는 JetStream 데이터 무결성 문제, 락 해제 버그, 프로토콜 손상 위험을 다수 수정한 안정성 패치입니다. JetStream을 운영 중이라면 즉시 업그레이드를 권장합니다.

• security프로토콜 손상 경로 차단 — WebSocket 및 JetStream 사용자 필수 확인

  $JS.ACK 주제 재작성과 압축 WebSocket 버퍼 처리에서 각각 발생하던 프로토콜 손상 버그가 수정됐습니다. 잘못된 프레임이 생성되면 스트림 상태나 클라이언트 세션이 오염될 수 있습니다. WebSocket 엔드포인트를 외부에 노출하거나 JetStream ACK에 의존하는 환경이라면 보안 이슈에 준해 업그레이드를 우선 처리하세요.

• breaking두 건의 락 미해제 버그 — 운영 중단 위험, 즉시 패치 필요

  파일스토어와 컨슈머 코드 경로 각각에서, 특정 오류 조건(쓰기 오류, 시작 시퀀스 오류) 발생 시 락이 영원히 반환되지 않는 버그가 있었습니다. 재시작 없이는 회복되지 않으며, 설명되지 않는 JetStream 정지 현상이 있었다면 이 버그가 원인일 가능성이 높습니다. v2.14.2로 즉시 업그레이드하세요.

• enhancement주제 수가 많은 스트림의 CPU 급등 문제 자동 해결

  파일스토어의 블록 스킵 체크가 주제 수가 매우 많은 스트림에서 CPU를 무한 점유하는 현상이 있었는데, 업그레이드 후 별도 설정 변경 없이 자동으로 해결됩니다. 이 문제를 피하려고 스트림 설계를 억지로 단순화했다면, 업그레이드 후 원래 의도한 구조로 되돌리는 것을 검토해볼 만합니다.

v2.12.10은 프로토콜 수준의 데이터 손상 위험, JetStream Raft/쿼럼 버그, 고카디널리티 스트림의 CPU 폭주 문제를 수정한 버그픽스 릴리스입니다.

• securityx/crypto 및 nkeys 즉시 업데이트

  golang.org/x/crypto가 v0.52.0으로, nkeys가 v0.4.16으로 업데이트됐습니다. 두 라이브러리는 NATS 인증 흐름의 암호화 연산을 담당합니다. 클러스터가 외부에 노출되어 있거나 분산 인증을 사용한다면 정기 점검을 기다리지 말고 지금 바로 패치하세요.

• breakingWebSocket·JetStream 사용자는 프로토콜 손상 수정을 위해 즉시 업그레이드 필요

  압축 WebSocket 클라이언트의 버퍼 오용과 $JS.ACK 주제 재작성, 두 가지 독립적인 프로토콜 손상 버그가 수정됐습니다. 둘 다 메시지 프레이밍을 조용히 망가뜨릴 수 있습니다. WebSocket 클라이언트나 ACK가 있는 JetStream 워크로드를 운영 중이라면 2.12.9 이하를 그대로 두는 건 실질적인 위험입니다. 서버를 먼저 업그레이드한 뒤 클라이언트를 업데이트하세요.

• enhancement고카디널리티 JetStream 스트림 CPU 폭주 수정 — 설정 검토 병행 필요

  주제 수가 매우 많은 스트림에서 블록 스킵 체크가 CPU 폭주를 일으킬 수 있었는데, 해당 케이스에서 체크가 비활성화됐습니다. JetStream 노드에서 수백만 개의 주제를 가진 스트림 운영 중 원인 불명의 CPU 스파이크가 있었다면 이 버그 때문일 가능성이 높습니다. 업그레이드 후 Counter 스트림과 메시지 스케줄 설정도 검토하세요 — 이전에는 통과됐던 잘못된 설정이 새 제약 조건으로 인해 거부될 수 있습니다.

Longhorn v1.12.0은 V2 Data Engine을 GA로 승격하고, 듀얼스택·IPv6 지원을 추가하며, 연쇄 볼륨 분리를 유발하던 instance-manager 패닉과 복제본 스케줄링 버그를 수정했습니다.

• breaking업그레이드 전 V2 Backing Image 볼륨 반드시 마이그레이션

  Backing Image로 생성된 V2 볼륨은 인플레이스 업그레이드가 불가합니다. v1.12.0으로 업그레이드하기 전, 해당 볼륨을 백업하고 삭제한 뒤 백업에서 복원하세요. 복원된 볼륨은 backing image 의존성이 없습니다. 이 과정을 건너뛰면 업그레이드 후 볼륨 연결이 실패합니다. 향후 VM 디스크 이미지 임포트는 CDI를 사용하세요.

• breakingV2 볼륨은 패치 업그레이드 전 반드시 분리 필요

  V2 볼륨은 v1.12.x 패치 릴리스 간 라이브 업그레이드를 지원하지 않습니다. 패치 업그레이드 적용 전 모든 V2 볼륨을 분리할 유지보수 시간을 확보하세요. v1.12에서 v1.13으로의 마이너 버전 라이브 업그레이드는 계획 중이지만 아직 지원되지 않습니다.

• breaking암호화 볼륨 라이브 마이그레이션 전 엔진 이미지 업그레이드 필요

  암호화 볼륨의 LUKS2 헤더 사전 할당 수정으로 제약이 생겼습니다. 암호화된 마이그레이터블 볼륨의 라이브 마이그레이션은 CLI API 버전 12 이상의 엔진 이미지가 필요합니다. 라이브 마이그레이션 시도 전 엔진 이미지를 v1.12.0 이상으로 업그레이드하세요.

• enhancement기존 V2 배포의 SPDK CPU 할당량 검토 권장

  기본 CPU 마스크가 1코어에서 2코어로 변경됐습니다. 수동으로 단일 코어를 설정해 V2 볼륨을 운영 중인 클러스터는 코어 수 증가를 검토하세요. 단일 코어 환경에서 고부하 I/O가 발생하면 RPC 기아와 운영 불안정이 생깁니다. ARM64에서 NVMe 백엔드 노드 디스크를 쓰는 경우, I/O 멈춤 버그가 해결될 때까지 멀티코어 SPDK 설정을 피하고 AIO 백엔드 디스크를 사용하세요.

• enhancement듀얼스택 활성화 전 노드 IP 패밀리 순서 반드시 확인

  듀얼스택 Kubernetes 클러스터를 지원하지만, 모든 노드의 IP 패밀리 순서가 동일해야 합니다(전체 IPv4 우선 또는 전체 IPv6 우선). 활성화 전 노드 네트워크 설정을 점검하세요. 노드 간 순서가 혼재하면 복제본-엔진 간 연결 장애가 발생하는데, 오류 메시지만 봐서는 원인을 파악하기 어렵습니다.

Knative Serving v1.22.1은 네트워크 프로버의 유휴 연결 누수, 웹훅 만료 매처의 메모리 누수를 수정하고, 웹훅 요청 본문 크기를 3MiB로 제한하는 패치 릴리스입니다.

• security웹훅 본문 3MiB 제한 — 즉시 업그레이드 권장

  웹훅 요청 본문에 상한이 생겼습니다. 과도하게 큰 페이로드로 메모리를 고갈시킬 수 있는 경로가 차단된 셈입니다. 멀티테넌트 환경이나 외부 트래픽이 들어오는 클러스터라면 다음 정기 점검을 기다리지 말고 지금 업그레이드하세요.

• breaking3MiB 초과 웹훅 요청은 거부됨 — 업그레이드 전 객체 크기 확인 필수

  Knative 어드미션 웹훅에 큰 오브젝트(환경 변수가 많거나 어노테이션이 방대한 Service, Configuration 등)를 제출하는 워크로드가 있다면 업그레이드 후 요청이 실패할 수 있습니다. 배포 전에 오브젝트 크기를 점검하고, 불필요한 메타데이터나 spec 필드를 정리해두세요.

• enhancement연결·메모리 누수 수정 — 장기 운영 클러스터일수록 효과 큼

  프로버 연결 누수와 만료 매처 메모리 누수는 즉각적인 장애보다 시간이 지날수록 파드 상태를 서서히 악화시키는 유형입니다. v1.22.0을 오래 운영 중인 클러스터라면 이미 영향을 받고 있을 가능성이 높습니다. 업그레이드 후 activator와 웹훅 파드의 메모리 사용량 추이를 모니터링해 안정화를 확인하세요.

etcd v3.6.12는 3.6 시리즈 패치 릴리스입니다. 릴리스 노트 자체에는 변경 내용이 없으므로, 업그레이드 전 반드시 CHANGELOG를 직접 확인해야 합니다.

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

  v3.6.12 릴리스 노트에는 변경 내용이 기재되어 있지 않습니다. 현재 운영 버전과 v3.6.12 사이의 모든 변경 사항을 CHANGELOG-3.6.md에서 직접 확인하세요. 공식 업그레이드 가이드도 3.6 시리즈에 breaking change가 있을 수 있다고 명시하고 있으니, 스테이징 환경에서 먼저 검증한 뒤 프로덕션에 적용하는 절차를 권장합니다.

• enhancement컨테이너 레지스트리 설정 재확인

  etcd는 gcr.io를 주 레지스트리, quay.io를 보조 레지스트리로 운영합니다. CI/CD 파이프라인이나 배포 매니페스트가 quay.io를 참조하고 있다면, 이미지 동기화 시차가 생길 수 있습니다. 프로덕션 클러스터는 gcr.io/etcd-development/etcd를 기준으로 설정하는 편이 안전합니다.