릴리즈

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 플래그로 시간을 버세요. 단, 장기간 비활성화 상태로 두는 건 피해야 합니다.

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

• securityHTTP/2 HPACK 쿠키-봄 취약점 즉시 패치 필요

  CVE-2026-47774는 공격자가 HPACK으로 압축된 대량의 쿠키를 담은 요청을 보내 메모리를 과도하게 소모시키는 공격입니다. 이번 수정으로 위반 스트림은 즉시 리셋되고, 쿠키도 기존 헤더 크기 제한에 포함됩니다. HTTP/2 트래픽을 처리하는 모든 Envoy 인스턴스에 패치를 배포하세요. 쿠키가 많은 워크로드에서 회귀 문제가 발생하면 `envoy.reloadable_features.http2_include_cookies_in_limits` 플래그로 일시적으로 되돌릴 수 있지만, 이는 임시방편이므로 근본적인 해결책을 병행하세요.

• securityoauth2 필터 사용 중이라면 두 가지 버그 모두 해당

  이번 릴리스에서 oauth2 관련 독립적인 두 문제를 수정했습니다. 하나는 HMAC 검증의 타이밍 차이를 이용해 시크릿 유효성을 추론할 수 있는 사이드채널 문제이고, 다른 하나는 시크릿 불일치 시 AES-CBC 복호화가 약 1/256 확률로 잘못 성공하며 크래시를 일으키는 버그입니다. Envoy의 내장 oauth2 필터로 토큰 검증을 수행 중이라면 즉시 업그레이드해야 합니다.

• enhancement메트릭 수가 많은 환경에서 stats eviction 도입 검토

  새로 추가된 `stats_eviction_interval` 설정으로 Envoy가 미사용 메트릭을 주기적으로 메모리에서 제거합니다. 요청별·사용자별 동적 레이블 등 고카디널리티 메트릭을 다루는 환경이라면 메모리 절감 효과를 기대할 수 있습니다. 다만 eviction은 해당 인터페이스를 구현한 extension에만 적용되므로, 스테이징에서 먼저 동작을 확인한 뒤 적용하는 편이 안전합니다.

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를 지금 설정하는 게 좋습니다.

v2.3.0에서 wash CLI에 워크로드 env/config/secrets 관리 기능이 추가되고, wasmtime 45로 업그레이드되며 보안 패치와 OTel 추적 개선이 함께 이뤄졌습니다.

• securitywasmtime 45 업그레이드 및 의존성 보안 패치 즉시 적용

  이번 릴리스에는 wasmtime이 두 단계 올라갔습니다. 44.0.2는 보안 패치용이었고, 45는 그 직후 나왔습니다. 여기에 별도 의존성 보안 취약점 패치까지 포함되어 있어 누적된 보안 범위가 적지 않습니다. 프로덕션에서 wasmCloud를 운영 중이라면 다음 정기 업그레이드를 기다리지 말고 v2.3.0으로 바로 올리세요.

• enhancementKubernetes RBAC을 클러스터 범위에서 네임스페이스 범위로 좁히기

  runtime.wasmcloud.dev apiGroup RBAC이 이제 클러스터 전체 범위 대신 네임스페이스 단위로 설정 가능합니다. 멀티테넌트 Kubernetes 클러스터에서 wasmCloud 오퍼레이터를 운영 중이라면 기존 RBAC 설정을 검토하고 가능한 네임스페이스 범위로 좁히세요. 공유 클러스터의 보안 태세를 실질적으로 강화할 수 있는 변경입니다.

• enhancementwash workload env/config/secrets로 설정 관리 방식 전환 검토

  설정과 시크릿 관리가 wash CLI에 직접 통합됐습니다. wasmCloud가 지향해온 워크플로우의 핵심 변화로, 이제 환경변수·설정·시크릿을 워크로드의 일급 관심사로 다룰 수 있습니다. 프로덕션 도입 전에 저장소의 otel-config 예제를 먼저 살펴보고 의도된 패턴을 파악하는 걸 권장합니다.

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

• enhancementv1.35.3이 정상 동작 중이라면 업그레이드 불필요

  체인지로그와 의존성 변경이 하나도 없습니다. CI 파이프라인 문제나 아티팩트 서명 교정 목적의 재빌드로 추정됩니다. 현재 v1.35.3을 안정적으로 운영 중이라면 굳이 업그레이드할 이유가 없습니다. 배포 결정 전에 CRI-O GitHub의 릴리스 PR이나 이슈 트래커에서 이 태그가 생성된 배경을 먼저 확인하세요.

• enhancement배포 전 cosign과 SBOM으로 아티팩트 무결성 검증 습관화

  변경 사항이 없더라도, cosign으로 tarball 서명을 검증하고 bom 툴로 SPDX SBOM을 확인하는 공급망 검증 절차를 점검하는 기회로 삼으세요. 중요한 릴리스가 나왔을 때 이 프로세스가 이미 익숙해져 있어야 합니다.

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를 관리하는 환경에서는 이 설정을 켜면 조정 병목이 해소됩니다. 기존에는 느린 클러스터 하나가 전체 조정을 막는 문제가 있었는데, 멀티테넌트나 멀티클러스터 구성에서 특히 체감 차이가 큽니다.

v1.17.0은 캐시 키 생성 방식을 TLV 인코딩으로 교체해 해시 플러딩 공격을 차단하고, OpenTelemetry 트레이스 샘플러를 설정 가능하게 만들었습니다.

• security해시 플러딩 방어를 위해 즉시 업그레이드

  기존 문자열 연결 방식의 캐시 키는 해시 플러딩 공격과 키 충돌 위험에 노출되어 있었습니다. TLV 인코딩과 프로세스별 해시 시딩으로 두 문제를 모두 해결했으며, 설정 변경 없이 버전 업그레이드만으로 적용됩니다. 멀티테넌트 환경이나 외부에 노출된 OpenFGA를 운영 중이라면 이번 릴리스를 우선 적용하세요.

• enhancementAPI 게이트웨이나 서비스 메시 뒤에서 운영한다면 parent-based 샘플링 설정 권장

  기존에는 OpenFGA가 업스트림의 샘플링 결정을 따르지 못해 스택 전체에서 트레이스가 일관되지 않게 수집되는 문제가 있었습니다. `OPENFGA_TRACE_SAMPLER=parentbased_always_on` 또는 `parentbased_traceidratio`로 설정하면 호출 서비스의 샘플링 결정을 그대로 따릅니다. OpenFGA가 대형 트레이싱 시스템의 다운스트림에 위치한다면, 불필요한 트레이스 노이즈를 줄이고 기존 옵저버빌리티 전략과 일관성을 맞출 수 있습니다.

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와 웹훅 파드의 메모리 사용량 추이를 모니터링해 안정화를 확인하세요.

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

• security3MiB 웹훅 바디 제한 적용 — 업그레이드 전 사전 검증 필요

  웹훅 요청 바디가 3MiB로 제한됩니다. 대규모 어노테이션, 환경 변수, 임베디드 설정이 포함된 Knative Service 매니페스트를 배포하는 환경이라면, 업그레이드 후 어드미션 요청이 거부될 수 있습니다. 운영 환경 적용 전에 가장 큰 Knative Service 스펙을 확인해 단일 어드미션 요청이 3MiB를 초과하지 않는지 점검하세요.

• enhancement메모리·연결 누수 수정 — 장기 운영 클러스터라면 빠르게 업그레이드

  만료된 매처의 메모리 누수와 네트워크 프로버의 유휴 연결 누수가 함께 수정되었습니다. 리컨실리에이션이 잦거나 헬스체크가 활발한 클러스터에서는 이 누수가 쌓여 컨트롤러나 네트워킹 컴포넌트의 메모리 사용량이 서서히 증가했을 수 있습니다. 별도 설정 변경 없이 버전 업그레이드만으로 해결됩니다.

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를 기준으로 설정하는 편이 안전합니다.

etcd v3.5.31은 3.5 브랜치의 패치 릴리스입니다. 공개된 릴리스 노트가 매우 간략하므로, 업그레이드 전 전체 CHANGELOG를 직접 확인해야 합니다.

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

  etcd 팀은 패치 릴리스에도 Breaking Change가 포함될 수 있다고 명시하고 있습니다. 마이너 버전이 바뀌지 않았다고 무조건 안전하다고 가정하면 안 됩니다. 현재 운영 중인 클러스터 버전과 API, 스토리지 포맷 변경 여부를 대조한 뒤 유지보수 일정을 잡으세요.

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

  이번 릴리스 노트에 실질적인 변경 내용이 거의 담겨 있지 않습니다. 실제 배포 전에 etcd 저장소의 CHANGELOG-3.5.md를 직접 열어 버그 수정 항목을 확인하세요. 3.5 패치 릴리스에는 컴팩션 처리나 리스 관련 수정이 자주 포함되는 편입니다.

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

• breaking패치 릴리스라도 공식 업그레이드 가이드를 반드시 검토하세요

  릴리스 페이지에서 브레이킹 체인지가 있을 수 있다고 명시하고 있습니다. etcd 3.4.x는 Kubernetes 클러스터에서 광범위하게 사용되는 브랜치입니다. 특히 쿼럼과 데이터 무결성이 중요한 프로덕션 환경이라면 etcd.io의 업그레이드 가이드를 먼저 검토한 뒤 적용하세요.

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

  이번 릴리스 페이지에는 변경 내용이 거의 없습니다. 업그레이드 전에 etcd GitHub 저장소에서 CHANGELOG-3.4.md를 직접 열어 실제 변경 사항을 파악하세요. etcd는 클러스터의 핵심 데이터 저장소인 만큼, 패치처럼 보이는 릴리스라도 내용을 확인하지 않고 적용하는 건 위험합니다.

v1.17.9는 Azure Cosmos DB를 워크플로 액터 상태 저장소로 사용할 때 customStatus 행이 없는 워크플로가 퍼지 루프에 영구적으로 갇히는 버그를 수정합니다.

• breakingCosmos DB를 워크플로 상태 저장소로 쓴다면 즉시 업그레이드

  state.azure.cosmosdb를 워크플로 액터 상태 저장소로 사용하는 배포는 모두 영향권입니다. TTL이 지난 워크플로가 퍼지되지 않고, 스케줄러가 초당 한 번씩 퍼지를 계속 시도하면서 CPU를 낭비하고 로그를 오염시키며 dapr_runtime_workflow_operation_count{status=failed} 메트릭을 계속 올립니다. 1.17.9로 업그레이드 후 사이드카를 재시작하면, 멈춰 있던 워크플로는 다음 리텐션 리마인더 실행 시 자동으로 복구됩니다. 업그레이드 이후 별도 수동 조치는 불필요합니다.

• enhancement업그레이드 전 메트릭으로 피해 규모 먼저 확인

  업그레이드 전에 dapr_runtime_workflow_operation_count를 operation=purge_workflow, status=failed 레이블로 조회해보세요. Cosmos DB 배포에서 이 값이 계속 증가하고 있다면 멈춰 있는 워크플로가 존재한다는 뜻입니다. 업그레이드 전후 수치를 비교하면 수정이 제대로 적용됐는지 명확히 검증할 수 있습니다.

flagd core v0.16.0은 비활성화 플래그 평가 결과를 FLAG_DISABLED 오류에서 reason=DISABLED 성공 응답으로 변경합니다. gRPC/OFREP 직접 호출자와 평가 메타데이터 검사 코드에 영향을 줍니다.

• breakingerrorCode 또는 reason 필드를 검사하는 코드 전수 확인 필요

  FLAG_DISABLED 오류 코드 분기나 gRPC/OFREP 응답의 reason 필드를 조건으로 사용하는 코드는 업그레이드 후 동작이 바뀝니다. 오류 경로 대신 reason=DISABLED가 포함된 성공 응답을 받게 됩니다. 업그레이드 전에 코드베이스 전체에서 FLAG_DISABLED 문자열, 오류 코드 분기문, reason 조건 처리 로직을 찾아 수정하세요. SDK를 통해 반환값만 사용하는 경우는 변경 없이 업그레이드 가능합니다.

• enhancementreason=DISABLED를 옵저버빌리티 신호로 적극 활용

  이번 변경으로 '플래그 비활성화'와 '평가 오류'를 메트릭과 로그에서 명확히 구분할 수 있게 됐습니다. 대시보드와 알림 규칙에서 reason=DISABLED를 오류가 아닌 정상 신호로 처리하도록 업데이트하면, 불필요한 알림 노이즈를 줄이면서도 비활성화 플래그 사용 현황을 추적하는 게 훨씬 수월해집니다.

flagd v0.16.0에서 비활성화 플래그 평가가 오류 반환에서 reason=DISABLED로 성공 응답하는 방식으로 바뀌었습니다. gRPC/OFREP 직접 호출 코드나 평가 메타데이터를 검사하는 코드에 영향을 줍니다.

• breakingFLAG_DISABLED 또는 errorCode를 검사하는 코드 전수 점검 필요

  gRPC/OFREP 직접 호출, core/pkg/model import, 또는 평가 응답의 reason이나 errorCode를 읽는 코드가 있다면 업그레이드 전에 반드시 수정해야 합니다. FLAG_DISABLED 오류는 더 이상 발생하지 않고, 대신 reason=DISABLED가 담긴 성공 응답이 옵니다. SDK를 통해 반환값만 읽는 경우는 영향 없지만, FLAG_DISABLED를 기반으로 모니터링 알림이나 분기 로직을 구성했다면 조용히 동작을 멈출 수 있습니다. 코드베이스에서 FLAG_DISABLED와 errorCode 검사 부분을 먼저 grep으로 찾아 확인하세요.

KEDA v2.20은 4개의 브레이킹 제거, Kubernetes 이벤트 RBAC 마이그레이션, 신규 스케일러 2개, 자격증명 누출 및 커넥션 누출을 포함한 다수의 버그 수정을 담고 있습니다.

• securityPulsar, RabbitMQ, AWS 스케일러의 자격증명 누출 및 커넥션 누출 패치

  Pulsar 스케일러는 크로스호스트 리다이렉트나 HTTPS→HTTP 다운그레이드 시 bearer/basic 인증 헤더가 그대로 유출되는 문제가 있었습니다. RabbitMQ는 AMQP 커넥션 누출, AWS 스케일러(SQS, Kinesis, DynamoDB, CloudWatch)는 스케일러 종료 시 TCP 커넥션 누출이 있었습니다. 해당 스케일러를 운영 중이라면 v2.20 업그레이드만으로 문제가 해결됩니다. 별도 설정 변경은 없지만, Pulsar 스케일러에 사용된 자격증명은 사전 교체를 권장합니다.

• breaking업그레이드 전 RBAC 반드시 수정 — events.k8s.io 마이그레이션은 선택이 아닙니다

  KEDA에 커스텀 또는 제한된 RBAC를 사용 중이라면, 업그레이드 전에 오퍼레이터 Role에 events.k8s.io/events에 대한 create/patch 권한을 추가해야 합니다. 공식 Helm 차트와 매니페스트는 이미 반영되어 있지만, 별도로 관리하는 RBAC는 이벤트 기록이 조용히 멈춥니다. 또한 삭제된 4개 설정(GCP PubSub subscriptionSize, Huawei minMetricValue, IBM MQ tls, InfluxDB triggerMetadata의 authToken)을 사용하는 ScaledObject가 있다면 업그레이드 후 검증 실패가 발생하므로 사전에 정리해야 합니다.

• enhancementAWS 크로스 어카운트 스케일링, External ID 네이티브 지원으로 간소화

  TriggerAuthentication podIdentity에 External ID 필드가 추가되어 모든 AWS 스케일러에서 크로스 어카운트 IAM assume-role을 공식적으로 지원합니다. 기존에 우회책을 쓰고 있었다면, TriggerAuthentication 매니페스트에 externalId 필드를 설정하는 것으로 대체할 수 있습니다.

Lima v2.1.2는 hostagent 리소스 누수, 좀비 프로세스, gRPC 연결 누수를 수정한 유지보수 릴리스입니다. Kubernetes 1.36, Ubuntu 26.04, Fedora 44 템플릿도 업데이트됩니다.

• breakingAlpine 템플릿 분리 — 인스턴스 설정 업데이트 필요

  `template:alpine`이 `template:alpine-3.21`, `template:alpine-3.22`, `template:alpine-3.23`으로 분리됐습니다. 스크립트, CI, 설정 파일에서 `template:alpine`을 그대로 참조하면 오류가 발생합니다. 업그레이드 전에 모든 참조를 버전이 명시된 템플릿으로 교체하세요.

• breaking_LIMA_QEMU_UEFI_IN_BIOS 사용 중단 — 즉시 제거 권장

  스크립트나 dotfile에 `_LIMA_QEMU_UEFI_IN_BIOS` 환경변수가 설정되어 있다면 지금 제거하는 게 좋습니다. 이번 릴리스에서 deprecated 처리됐고, 향후 버전에서 완전히 삭제될 가능성이 높습니다. limactl을 호출하는 CI 파이프라인과 래퍼 스크립트를 함께 점검하세요.

• enhancementHostagent 리소스 누수 수정 — 장기 실행 인스턴스라면 바로 업그레이드

  GuestAgentClient 누수, inotify watcher 누적, 재연결 시 gRPC 스트림 오동작을 각각 수정한 네 가지 패치가 포함됐습니다. Lima 인스턴스를 장시간 운영하면서 메모리 증가나 연결 이상을 경험했다면, 이번 릴리스가 직접적인 해결책입니다. 다음 릴리스를 기다리지 말고 바로 업그레이드하는 편이 낫습니다.

Volcano v1.15.0은 갱 인식 선점/회수, DRA 큐 쿼터, 오토스케일러 친화적 스케줄링 게이트를 도입하고, 이중 계산·경쟁 조건·롤백 오류 등 핵심 스케줄러 버그를 대거 수정했습니다.

• securityCVE-2026-44247 웹훅 DoS 취약점 및 Prometheus XSS 패치 적용

  CVE-2026-44247은 과도하게 큰 웹훅 요청 본문으로 웹훅 서버 메모리를 고갈시킬 수 있는 DoS 취약점입니다. Prometheus 의존성도 저장형 XSS 어드바이저리(GHSA-vffh-x6r8-xx99)에 대응해 업데이트되었습니다. Volcano 어드미션 웹훅을 외부에 노출하는 환경이라면 v1.15.0으로 즉시 업그레이드하세요. 별도 우회 방법은 없습니다.

• breakinggangPreempt/gangReclaim과 기존 preempt/reclaim 혼용 금지

  gangPreempt, gangReclaim은 기존 preempt, reclaim 액션과 스케줄러 액션 목록에 함께 사용할 수 없습니다. 업그레이드 전에 스케줄러 ConfigMap을 반드시 점검해 두 세트가 공존하지 않도록 하세요. 또한 DRA 스케줄링이 기본 활성화로 바뀌었으므로, DRA 드라이버가 없는 클러스터에서는 predicate.DynamicResourceAllocationEnable: false를 명시적으로 설정해야 합니다.

• enhancement스케줄링 게이트로 큐 제한 시 오토스케일러 과잉 스케일업 방지

  Cluster Autoscaler나 Karpenter를 Volcano와 함께 운영 중이라면, 큐 용량 초과로 대기 중인 파드가 불필요한 노드 추가를 유발하는 문제가 있었습니다. 새 스케줄링 게이트 기능이 이를 깔끔하게 해결합니다. 파드 단위 opt-in 방식으로, scheduling.volcano.sh/queue-allocation-gate: 'true' 어노테이션을 설정하면 됩니다. 스케줄러와 webhook-manager 모두에서 기능 게이트를 활성화한 뒤, 큐 쿼터가 엄격하게 적용되는 배치 잡 워크로드부터 어노테이션을 적용해 낭비성 노드 프로비저닝을 줄이세요.

v1.17.3은 차트 업그레이드 차단 문제를 고치고, 멀티 클러스터 검색 가시성을 바로잡으며, 과다 스케줄링을 방지하고, 자격증 로테이션 중 클러스터 준비 상태 감지를 안정화했습니다.

• breaking차트 업그레이드 차단 해제: ConfigMap 크기 문제 해결됨

  karmada-operator-chart가 Karmada CRD를 ConfigMap에 포함시킬 때 크기 제한을 초과하여 차트 업그레이드를 막았습니다. 이것이 v1.17.3에서 고쳐졌습니다. 이 오류로 구 차트 버전에 갇혀 있었다면 지금 업그레이드하여 Karmada 배포 업데이트 능력을 회복하세요.

• breaking스케줄러가 이제 클러스터 리소스 제한을 준수함

  스케줄러가 이전에는 클러스터에 리소스가 부족한데도 여러 워크로드 복제본을 배치했습니다. v1.17.3에서 과다 스케줄링을 고칩니다. 업그레이드 후 현재 배포를 감시하여 실제 배치가 기대와 맞는지 확인하고 필요시 복제본 수를 조정하세요.

• enhancement검색이 이제 복구된 클러스터 리소스를 올바르게 반영함

  karmada-search가 이제 복구된 클러스터를 제대로 감시하고 지연 없이 리소스를 반영합니다. 클러스터 복구 시나리오(장애 조치 또는 복원)에서 검색 기능에 의존한다면 v1.17.3으로 업그레이드하여 새로 복구된 멤버 클러스터의 가시성을 확보하세요.

• enhancement클러스터 준비 상태가 이제 실패 임계값을 대기함

  임시 자격증 로테이션 실패(SecretRef 누락)는 이제 즉시 실패하지 않고 ClusterFailureThreshold까지 대기한 후 클러스터를 NotReady로 표시합니다. 일상적인 로테이션 중 과민 장애 조치를 방지합니다. 안정적인 자격증 로테이션 프로세스가 이미 있다면 조치 불필요하며, 이것은 거짓 양성을 줄입니다.

Karmada v1.16.6은 세 가지 신뢰성 문제를 수정했습니다: 클러스터 재연결 시 watch 기반 리소스 발견, 동시 스케줄링 시 스케줄러의 리소스 과다 할당, 일시적 자격증명 오류 시 과민한 클러스터 failover.

• breaking스케줄러 리소스 과다 할당 문제 수정

  기존에는 여러 template 리소스가 동시에 배치될 때 클러스터 리소스 부족 상태에서도 워크로드를 배치했습니다. v1.16.6으로 업그레이드하여 리소스 가용성 검증을 제대로 적용하세요. 업그레이드 후 클러스터 리소스 제한과 현재 배포가 의도한 용량 제약을 준수하는지 확인하세요.

• breaking클러스터 준비 상태가 failure threshold를 존중합니다

  시크릿 로테이션 중 일시적 자격증명 오류가 더 이상 클러스터를 즉시 Ready=False로 표시하고 failover를 유발하지 않습니다. 이제 ClusterFailureThreshold를 존중한 후 클러스터 상태를 변경합니다. ClusterFailureThreshold를 조정하거나 빠른 failover 동작에 의존한다면, 스테이징 환경에서 클러스터 자격증명 로테이션을 테스트하여 failover 시점이 기대하는 동작과 일치하는지 확인하세요.

• enhancementWatch 발견이 재연결 클러스터의 리소스를 반영합니다

  Karmada-search는 네트워크 단절이나 재시작 후 재연결된 클러스터의 리소스를 이제 제대로 반영합니다. 멀티 클러스터 배포에서 watch 기반 리소스 발견을 사용한다면, 업그레이드 후 재연결된 클러스터의 리소스가 수동 개입 없이 검색에 나타나는지 확인하세요. 재연결된 클러스터의 리소스 동기화 지연이 있는지 search 로그를 모니터링하세요.

Karmada v1.15.9이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

v1.18.0은 하이브리드 클라우드 버스트 스케줄링을 위한 overflow cluster affinities와 리소스 이중 할당 방지 메커니즘을 추가합니다. v1.18.x로 올리기 전에 반드시 v1.17.3+를 먼저 적용해야 합니다.

• securityAlpine 베이스 이미지 3.23.4로 업데이트

  기본 Alpine 이미지가 3.23.3에서 3.23.4로 올라갔습니다. 일반 업그레이드 외에 별도 조치는 없지만, 이미지 digest를 고정해 쓰는 환경이라면 digest 값을 업데이트하세요.

• breakingv1.18.x 업그레이드 전 v1.17.3+ 필수 적용

  v1.18.x로 올리기 전에 반드시 v1.17.3+ 상태여야 합니다. 이 순서를 건너뛰면 operator 업그레이드가 실패합니다. `karmadactl version`으로 현재 버전을 확인하고, v1.17.3+가 아니라면 먼저 해당 버전으로 올리세요.

• breakingDeprecated gRPC 필드 교체 — 커스텀 플러그인 수정 필요

  karmada-scheduler-estimator의 gRPC 필드 여러 개가 deprecated 처리됐습니다. `resourceRequest` → `resourceRequestBytes`, `nodeAffinity` → `nodeAffinityBytes`, `tolerations` → `tolerationsBytes`로 교체됩니다. 커스텀 estimator 플러그인이나 이 필드를 직접 읽는 툴링이 있다면 업그레이드 전에 수정하세요. 기존 필드는 v1.18에서는 아직 남아 있지만 이후 릴리스에서 제거됩니다.

• breaking삭제된 플래그 및 메트릭 레이블 — 기존 설정 충돌 주의

  karmada-controller-manager에서 `--cluster-lease-duration`, `--cluster-lease-renew-interval-fraction` 플래그가 삭제됐습니다. Karmada Init Configuration의 `Etcd.Local.InitImage`도 제거됐습니다. 배포 스크립트나 Helm values에 이 항목들이 있으면 업그레이드 전에 제거하세요. 그렇지 않으면 컴포넌트 기동에 실패합니다. Prometheus 대시보드도 확인하세요 — `cluster`, `cluster_name` 레이블이 사라지고 `member_cluster`로 바뀌었습니다.

• enhancement스케줄러 오라우팅 및 eviction 누락 버그 수정

  스케줄러 버그 두 건이 이번 릴리스에서 수정됐습니다. 첫째, 클러스터 레플리카가 부족한 binding이 5분 타이머 큐 대신 exponential backoff(1~10초) 큐로 잘못 라우팅되어 워크로드가 멈춘 것처럼 보이는 문제입니다. 둘째, 여러 컨트롤러가 동일한 ResourceBinding을 동시에 수정할 때 graceful eviction 태스크가 조용히 누락되어 실패 클러스터에서 워크로드가 대피되지 않는 race condition입니다. 이런 증상을 겪었다면 v1.18.0으로 업그레이드 후 해당 워크로드 상태를 재확인하세요.

• enhancement고부하 환경에서 SchedulingOvercommitProtection 활성화 검토

  SchedulingOvercommitProtection feature gate(기본값: 비활성)는 연속 스케줄링 요청 사이에 클러스터 리소스를 과잉 할당하는 문제를 방지합니다. Pod가 노드에 바인딩되기 전에 동일 클러스터에 중복 스케줄링이 발생하는 환경에서 효과적입니다. staging에서 검증 후 karmada-scheduler와 karmada-scheduler-estimator 양쪽에 `--feature-gates=SchedulingOvercommitProtection=true`를 설정하세요.

• enhancement하이브리드 클라우드 버스트 스케줄링용 Overflow Cluster Affinities

  PropagationPolicy/ClusterPropagationPolicy에 `overflowAffinities` 필드가 추가됐습니다. 1순위 클러스터 그룹이 소진되면 선언 순서대로 보조 그룹으로 레플리카를 넘기고, 스케일다운 시에는 보조 그룹부터 먼저 회수합니다. IDC 우선 + 퍼블릭 클라우드 버스트 패턴에 적합합니다. 기존 정책에는 영향 없고, 이 필드를 추가한 경우에만 동작이 바뀝니다.

Linkerd edge-26.5.5이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

OpenFeature core/v0.15.8이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

OpenFeature flagd/v0.15.7이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

v1.120.3은 Go 의존성 CVE 2건을 패치하고 AWS·Azure·Oracle·DigitalOcean 프로바이더 전반의 버그를 수정합니다. OVH 프로바이더 추가와 cosign 이미지 서명도 포함됐습니다.

• security취약한 Go 의존성 패치 — 즉시 업그레이드 필요

  이번 릴리스에서 Go 의존성 취약점 GHSA-xmrv-pmrh-hhx2와 CVE-2026-34986를 패치했습니다. v1.120.3 이전 버전을 운영 중이라면 즉시 업그레이드하세요. 코드 변경이 아닌 의존성 수준의 취약점입니다.

• breakingMCP 서버가 기본 비활성화로 변경 — 배포 설정 확인 필요

  MCP 서버의 기본값이 활성화에서 비활성화(MCP_SERVER_ENABLED=false)로 바뀌었습니다. 기본 활성화 상태를 전제로 운영 중이었다면 업그레이드 전에 배포 매니페스트에서 해당 환경 변수를 명시적으로 설정해야 합니다.

• enhancementcosign 이미지 서명 검증을 어드미션 파이프라인에 추가

  컨테이너 이미지에 cosign keyless 서명과 SLSA provenance 어테스테이션이 추가됐습니다. Kyverno나 cosign verify 같은 정책 도구를 사용 중이라면 OpenCost 이미지에 대한 서명 검증 정책을 CI 또는 배포 시점에 적용할 수 있습니다.

Backstage v1.51.1이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

Linkerd edge-26.5.4이(가) 릴리즈되었지만, 공개된 노트가 짧아 요약할 내용이 충분하지 않습니다. 자세한 내용은 원문 릴리즈 노트를 확인하세요.

gRPC v1.81.0은 Python 3.9와 Ruby 3.1 지원을 종료하고, Windows·ARM에서의 크래시급 레이스 컨디션을 수정하며, Python AsyncIO observability를 추가했습니다.

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

  gRPC 1.81.0부터 Python 3.9를 지원하지 않습니다. Python 3.9 환경에서 gRPC를 운영 중이라면 런타임을 3.10 이상으로 올리기 전까지는 이전 버전을 유지하세요. 이 릴리스로 업그레이드하기 전에 Python 버전 계획을 먼저 잡아야 합니다.

• breakingRuby 3.1 지원 종료 — Ruby 런타임 업그레이드 필요

  Ruby 3.1이 EOL에 도달하면서 gRPC 1.81.0에서 지원이 끊겼습니다. Ruby 3.1로 gRPC를 운영 중이라면 이 릴리스를 적용하기 전에 Ruby 3.2 이상으로 업그레이드해야 합니다.

• enhancementWindows·ARM 안정성 버그 수정 — 운영 중이라면 업그레이드 고려

  Windows에서 use-after-free와 assertion 오류를 유발하는 레이스 컨디션 두 건, ARM 환경(weak memory model)에서 completion queue 셧다운 레이스가 수정됐습니다. Windows나 ARM 기반 인프라에서 gRPC를 운영 중이라면 크래시로 이어질 수 있는 문제들이 이번에 해결된 것이므로, 안정성 확인 후 업그레이드를 검토하세요.