릴리즈

metal3-io v0.13.0은 iRMC 드라이버를 제거하고 BMH 펌웨어 스펙을 폐기 예고하면서, HostClaim CRD와 멀티아키텍처 PXE 부팅을 새로 도입한 버전입니다. 업그레이드 전 파괴적 변경 사항 검토가 필수입니다.

• breaking업그레이드 전 iRMC 사용 여부와 BMH.Spec.Firmware 필드를 반드시 점검하세요

  iRMC 드라이버가 삭제되었기 때문에 iRMC BMC 엔드포인트를 가리키는 BareMetalHost 리소스는 업그레이드 즉시 조정이 멈춥니다. BMH.Spec.Firmware는 당장 오류가 나지 않더라도 폐기 예고 상태이므로, 대체 API로의 전환 계획을 지금 수립해야 합니다. 운영 클러스터 작업 전에 BMH 매니페스트와 Helm values 파일 전체를 검색해 두 항목의 사용 여부를 확인하세요.

• breaking관리 클러스터의 CAPI·controller-runtime 호환성을 사전에 확인하세요

  CAPI v1.13.1, controller-runtime v0.23.3 버전 상승은 단순 패치가 아닙니다. 동일한 관리 클러스터에 다른 CAPI 프로바이더가 함께 있다면, 각 프로바이더의 호환성 매트릭스를 지금 확인하세요. 버전 불일치는 CRD 충돌이나 웹훅 오류로 이어질 수 있습니다.

• enhancementHostClaim CRD로 베어메탈 호스트 할당을 선언형으로 전환하세요

  HostClaim·HostClaimSet 리소스를 쓰면 커스텀 컨트롤러 없이 Kubernetes 방식으로 베어메탈 용량을 요청·예약할 수 있습니다. 현재 스크립트나 외부 툴로 호스트 할당을 관리 중이라면, 단순 예약 워크플로는 이제 HostClaim으로 대체 가능한지 평가해볼 시점입니다.

wasmCloud v2.1.0은 오퍼레이터 안정성 수정, 서비스 플러그인 지원 추가, CI 보안 강화를 중심으로 한 점진적 릴리스입니다.

• securitywasmtime 업그레이드 및 cargo audit 적용 — 자체 빌드에도 반영 필요

  wasmtime 버전이 올라가고 rustls-pemfile이 제거됐으며, 빌드 파이프라인에 cargo audit이 추가됐습니다. wasmCloud 컴포넌트를 소스에서 빌드하거나 포크를 유지 관리 중이라면, 지금 바로 자체 CI에도 cargo audit을 추가하세요. WASM 런타임의 의존성 변화는 빠르게 진행되므로 보안 권고를 조기에 파악하는 것이 중요합니다.

• breaking오퍼레이터 readiness 동작 변경 — 헬스체크 및 배포 타임아웃 검토 필요

  오퍼레이터가 이제 레플리카가 실제로 준비된 경우에만 WorkloadDeployment를 Ready로 표시합니다. 기존에 낙관적 Ready 상태에 의존하던 CI/CD 파이프라인이나 모니터링 도구에서 배포가 더 오래 '진행 중'으로 보일 수 있습니다. 업그레이드 후 롤아웃 타임아웃 설정을 반드시 재검토하세요.

• enhancement서비스 플러그인 지원 — 코어 컴포넌트 수정 없이 서비스 확장 가능

  서비스 레이어에서 플러그인을 지원하게 되어, 코어 컴포넌트를 포크하지 않고도 커스텀 동작을 추가할 수 있습니다. 유지보수 가능한 방식으로 서비스 동작을 확장하려 했다면 이번 릴리스가 실험해볼 적기입니다. 새 통합을 설계하기 전에 서비스 플러그인 API 문서부터 살펴보세요.

Vitess v24.0.1은 VTGate 쿼리 플래너의 DML 서브쿼리 버그 수정, 문제가 있던 VTOrc 플래그 되돌리기, VTTablet 불안정 테스트 해결에 집중한 패치 릴리스입니다.

• breakingVTOrc --cells-to-watch 플래그 설정에서 제거하세요

  #19354에서 추가된 'cells to watch' 플래그가 이번 릴리스에서 완전히 롤백됐습니다. v24.0.0 업그레이드 후 VTOrc 설정이나 시작 스크립트에 해당 플래그를 추가했다면, v24.0.1로 올리기 전에 반드시 제거해야 합니다. 그렇지 않으면 VTOrc가 알 수 없는 플래그 오류로 기동에 실패합니다.

• enhancementVTGate를 통해 DML 서브쿼리를 쓴다면 즉시 업그레이드하세요

  DML 문(INSERT/UPDATE/DELETE) 안의 IN/NOT IN 서브쿼리에서 플래너 버그가 있었습니다. 병합된 서브쿼리가 ListArg 플레이스홀더로 정상 치환되지 않아 잘못된 쿼리 결과가 나올 수 있었는데, 이번 패치로 수정됐습니다. VTGate를 통해 서브쿼리가 포함된 DML을 실행하는 환경이라면 빠른 업그레이드를 권장합니다.

v23.0.4는 VTOrc·VTGate·ERS의 패닉 및 데드락, VReplication과 라우팅 규칙의 무결성 버그를 집중적으로 수정한 패치 릴리스입니다.

• securityGo 1.25.9 업그레이드 — 커스텀 빌드 환경 확인 필요

  이번 릴리스 사이클에서 Go 런타임이 1.25.8에서 1.25.9로 올라갔습니다. 소스 빌드나 커스텀 이미지를 유지하고 있다면 go1.25.9로 재빌드해서 Go 패치 레벨의 런타임 수정사항을 반영하세요.

• breakingERS 또는 세미싱크 복제를 사용 중이라면 즉시 업그레이드 필요

  ERS 관련 버그 세 건이 한꺼번에 수정됐습니다. errant GTID 감지 중 nil 포인터 패닉, 취소 로직 오류, 그리고 ERS 실패 후 레플리카 IO 스레드가 재시작되지 않는 문제입니다. 어느 하나라도 발생하면 페일오버 후 클러스터가 비정상 상태로 남을 수 있습니다. VTOrc로 세미싱크를 운영 중이라면 ReplicationStopped + PrimarySemiSyncBlocked 데드락 수정도 동일하게 중요합니다. 복구 자체가 완전히 멈출 수 있거든요. 늦어도 다음 유지보수 창 전에 업그레이드하세요.

• enhancement멀티 키스페이스 환경에서 라우팅 규칙 동작 재검증 권장

  VTGate가 스키마 트래커 업데이트 후 라우팅 규칙을 재빌드하지 않고, 라우팅 규칙 AST 재작성 시 타깃 키스페이스를 유실하는 버그가 수정됐습니다. 두 버그 모두 쿼리는 성공처럼 보이지만 실제로는 엉뚱한 키스페이스로 라우팅될 수 있습니다. 멀티 키스페이스에서 라우팅 규칙을 쓰고 있다면 업그레이드 후 트래픽 경로를 반드시 검증하세요.

v1.15.1은 Check 데드락, 세마포어 누수, 실험적 가중치 그래프 캐시 충돌 등 운영 안정성에 직결되는 버그를 수정한 패치 릴리스입니다.

• security`weighted_graph_check` 캐시 충돌은 권한 오판을 유발할 수 있음

  실험적 `weighted_graph_check` 기능을 사용 중이라면, 캐시 키 충돌로 인해 직접 타입·와일드카드·TTU 경로·인터섹션이 포함된 유니온 관계에서 잘못된 Check 결과가 반환될 수 있습니다. 권한 오판은 보안 문제로 직결됩니다. 즉시 업그레이드하고, 당장 업그레이드가 불가능하다면 실험적 기능 플래그를 비활성화하세요.

• breaking데드락·세마포어 누수 버그로 즉시 업그레이드 필요

  두 가지 버그 모두 운영 환경을 조용히 망가뜨릴 수 있습니다. Check 데드락은 오류 발생 시 메시지 스트림이 닫히지 않아 요청 처리가 점점 고갈되고, bounded tuple reader의 세마포어 누수는 타임아웃이 잦은 환경에서 리소스 고갈로 이어집니다. 설정 변경 없이 업그레이드만으로 해결됩니다. Check 응답 지연이나 컨텍스트 취소 후 리소스 압박을 겪었다면 이 버그들이 원인일 가능성이 높습니다.

• enhancementListObjects 오류 전파 수정 — 쿼리 결과 재검증 권장

  단락(short-circuit) 처리 시 무시돼야 할 오류가 ListObjects 응답에 잘못 노출되는 버그가 수정됐습니다. 의도치 않은 ListObjects 오류를 경험했다면 이번 수정이 원인을 해결합니다. 업그레이드 후 테스트 스위트에서 ListObjects 동작을 한 번 재확인해 두는 게 좋습니다.

Harbor v2.15.1은 CVE 패치, GC 작업의 Redis 자격증명 노출 수정, 세션 TTL 갱신 버그 등 보안 및 동작 오류 수정에 집중한 패치 릴리스입니다.

• securityGC 작업에서 Redis 자격증명 노출 — 즉시 업그레이드 및 비밀번호 교체 필요

  이전 버전에서는 GC 작업이 Redis URL(인증 정보 포함)을 extra attributes에 평문으로 저장했습니다. 이 데이터는 Harbor API를 통해 조회 가능하며 로그에도 남을 수 있습니다. Redis 인증을 사용 중이라면 기존에 수집된 GC 작업 메타데이터에 자격증명이 포함됐을 수 있으니, v2.15.1로 업그레이드한 뒤 Redis 비밀번호를 교체하세요.

• security베이스 이미지 CVE 패치 — 다음 스캔 주기 전에 업그레이드 권장

  Photon 베이스 이미지가 CVE 수정을 위해 업데이트됐습니다. v2.15.0을 운영 중인 환경에서는 취약점 스캐너가 기존 이미지를 계속 플래그할 겁니다. 감사 이슈로 번지기 전에 v2.15.1로 업그레이드해 두세요.

• enhancement세션 만료 동작 변경 — 유휴 사용자 로그아웃 가능성 사전 공지 필요

  UI 백그라운드 폴링이 매번 세션 TTL을 초기화하면서 실질적으로 세션이 만료되지 않는 문제가 있었습니다. 이제 설정된 유휴 시간이 지나면 세션이 정상적으로 만료됩니다. 컴플라이언스 목적으로 세션 타임아웃을 설정한 조직에는 반가운 수정이지만, 사용자들이 갑자기 로그아웃되는 상황을 겪을 수 있으니 사전에 공지하는 것이 좋습니다.

Argo CD 3.4.1은 3.4 시리즈의 첫 릴리스(3.4.0 없이 바로 출시)로, ApplicationSet 클러스터 버전 형식 변경이라는 브레이킹 체인지와 함께 대규모 버그 수정, 성능 개선, UI 개선이 포함됩니다.

• securitySwagger UI 보안 헤더 추가 및 JWT 로그아웃 무효화 적용

  두 가지 보안 수정이 포함됩니다. Swagger UI 엔드포인트에 X-Frame-Options와 Content-Security-Policy 헤더가 추가돼 클릭재킹 위험이 줄었고, 로그아웃 시 JWT 토큰이 서버 측에서 즉시 무효화돼 로그아웃 후 세션 재사용이 차단됩니다. 별도 설정 변경은 없지만, 리버스 프록시 환경이라면 업그레이드 후 보안 헤더가 클라이언트까지 제대로 전달되는지 확인하세요.

• breaking업그레이드 전 ApplicationSet 클러스터 버전 라벨 업데이트 필수

  쿠버네티스 버전 라벨 형식이 Major.Minor(예: '1.29')에서 vMajor.Minor.Patch(예: 'v1.29.3')로 바뀌었습니다. argocd.argoproj.io/auto-label-cluster-info를 사용하는 ApplicationSet Cluster Generator가 있다면, 기존 클러스터 시크릿의 라벨 형식이 구버전 그대로입니다. 업그레이드 후 argocd.argoproj.io/kubernetes-version 키로 새 형식을 적용하지 않으면 클러스터 버전 기반 필터가 동작하지 않습니다. 롤아웃 전에 반드시 3.3-3.4 업그레이드 가이드를 확인하세요.

• enhancementAppSet 컨트롤러 및 repo-server 성능 개선 — 대규모 클러스터에서 효과 기대

  parentUIDToChildren 자료구조 최적화, 컨트롤러 시크릿 deep-copy 감소, CLI 서버사이드 diff 병렬 배치 처리, checkout 시 repoLock 최적화 등 여러 성능 개선이 한꺼번에 들어왔습니다. 대규모 클러스터에서 AppSet 컨트롤러 CPU 사용량이 높거나 조정 지연이 있었다면 이번 업그레이드 후 개선 효과가 보일 겁니다. 롤아웃 후 컨트롤러 CPU와 조정 지연 메트릭을 모니터링하세요.

OpenYurt v1.7.0은 엣지 업그레이드 다운타임을 최소화하는 OTA 이미지 사전 캐싱, 레이블 기반 YurtHub 배포, K8s-on-K8s 지원, Kubernetes v1.34 호환성을 추가했습니다. 동시에 여러 deprecated 컴포넌트가 완전히 제거됩니다.

• breaking업그레이드 전 제거된 컴포넌트 사용 여부 점검 필수

  YurtAppOverrider, YurtAppDaemon(컨트롤러 및 웹훅), yurt-coordinator, delegate lease 컨트롤러가 이번 릴리스에서 완전히 삭제됩니다. 매니페스트나 Helm values, 자동화 스크립트에서 이 컴포넌트를 참조하고 있다면 업그레이드 후 조용히 실패하거나 배포가 중단될 수 있습니다. 업그레이드 전 전수 점검이 필요하고, NodePool CRD의 v1beta2 승격 및 enableLeaderElections 필드명 변경도 함께 반영해야 합니다.

• enhancement엣지 DaemonSet 업그레이드에 OTA 이미지 사전 캐싱 도입

  네트워크가 불안정하거나 대역폭이 제한된 엣지 노드에서 DaemonSet을 운영 중이라면, ImagePreHeat 컨트롤러가 업그레이드 다운타임 문제의 실질적인 해결책입니다. 롤아웃 전에 OTA API 엔드포인트로 사전 캐싱을 트리거하고, PodImageReady 조건으로 이미지 준비 상태를 확인한 뒤 실제 업그레이드를 시작하는 흐름을 팀 운영 절차에 반영하세요.

• enhancement엣지 노드 온보딩을 레이블 기반 방식으로 전환

  YurtNodeConversionController 덕분에 노드에 레이블 하나만 붙이면 YurtHub 설치부터 systemd 등록까지 자동으로 처리됩니다. 대규모 엣지 노드 플릿을 운영한다면 운영 부담을 크게 줄일 수 있는 기능입니다. 다만 systemd와 직접 상호작용하는 신규 기능인 만큼, 프로덕션 적용 전에 비중요 노드 풀에서 먼저 검증하는 것을 권장합니다.

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 등 구성 관리 도구에 반영해 두는 것이 좋습니다.

NATS 워크로드 준비 상태 오류 수정, Kubernetes 오퍼레이터 배포 상태 정확도 개선, 보안 강화에 집중한 유지보수 릴리스입니다.

• securitywasmtime 업그레이드 및 cargo audit 추가 — 자체 Wasm 공급망 점검 필요

  이번 릴리스에서 wasmtime을 올리고 rustls-pemfile을 제거했으며, CI에 cargo audit가 추가됐습니다. Rust로 커스텀 wasmCloud 컴포넌트나 프로바이더를 빌드한다면 자체 파이프라인에도 cargo audit를 추가하세요. rustls-pemfile이 제거됐으므로, 코드에서 직접 이 크레이트를 임포트하고 있다면 의존성을 업데이트해야 합니다.

• breaking오퍼레이터 WorkloadDeployment 준비 상태 판단 기준 변경

  WorkloadDeployment의 Ready 조건이 이제 배포 객체 생성 시점이 아니라 실제 레플리카 가용성을 기준으로 바뀌었습니다. 배포 직후 Ready=True를 기대하는 CD 파이프라인이나 헬스체크 자동화가 있다면 반드시 검토하세요. 동작이 더 정확해졌지만, Ready 도달 시간이 이전보다 길어 보일 수 있습니다.

• enhancementNATS 구독 준비 상태 수정으로 오탐 방지

  기존에는 NATS 구독이 실제로 연결되기 전에 호스트가 Ready 상태를 보고하는 경우가 있었습니다. 이번 수정으로 준비 상태가 실제 구독 가용성과 연동됩니다. Kubernetes에서 호스트 헬스 기반으로 트래픽 라우팅이나 준비 게이트를 사용한다면 업그레이드 후 정확한 준비 신호를 받을 수 있습니다.

Argo CD v3.1.16은 서버 측 이중 삭제 오류를 수정하고 SonarQube 스캔 액션 의존성을 업데이트한 소규모 패치입니다.

• security배포 파이프라인에 cosign 서명 검증 적용 검토

  Argo CD 이미지는 SLSA Level 3 기준을 충족합니다. 아직 어드미션 단계에서 서명 검증을 강제하지 않고 있다면, Kyverno나 OPA Gatekeeper 같은 정책 엔진에 이미지 서명 검증 규칙을 추가하는 것을 권장합니다.

• enhancement이중 삭제 오류가 발생하는 환경이라면 즉시 패치 적용

  캐스케이드 삭제나 조정 루프에서 삭제 작업을 재시도하는 파이프라인이 있다면, 기존 버전에서 불필요한 오류가 발생해 알림을 유발하거나 재시도 실패로 이어질 수 있었습니다. 변경 범위가 좁아 업그레이드 리스크가 낮습니다.

Longhorn v1.11.2는 컴퓨트/스토리지 분리 아키텍처에서의 CSI 스케줄링 오류, 레플리카 무한 루프, longhorn-manager 메모리 증가 문제를 수정한 안정성 패치입니다.

• breaking컴퓨트/스토리지 분리 클러스터라면 CSI 스케줄링 설정 확인 필수

  컴퓨트 노드와 스토리지 노드를 분리 운영 중이고 WaitForFirstConsumer PVC를 사용한다면, 컴퓨트 노드가 CSI 용량을 0으로 보고하면서 Pod가 Pending 상태로 멈추는 문제가 발생했을 수 있습니다. v1.11.2로 업그레이드 후 새로 추가된 CSIStorageCapacity 설정을 조정해 비스토리지 노드에서 용량 리포팅이 발생하지 않도록 하고, 기존에 Pending 상태였던 PVC가 정상 스케줄링되는지 확인하세요.

• breakingAuto-Balance 사용 중이라면 이번 패치 우선 적용 권장

  Replica Auto-Balance가 무한 스케줄링 루프에 진입하는 버그가 수정됐습니다. 이 문제는 CPU를 과도하게 소모하고 볼륨 운영을 불안정하게 만들 수 있습니다. Auto-Balance를 활성화한 클러스터라면 이번 릴리스를 우선 적용하세요. 업그레이드 후 별도 설정 변경은 필요 없습니다.

• enhancement대규모 클러스터라면 longhorn-manager 메모리 개선 효과 확인

  인포머 캐싱 최적화로 longhorn-manager Pod의 메모리 사용량이 줄었습니다. 노드와 볼륨이 많은 환경일수록 체감 효과가 큽니다. 업그레이드 외에 추가 설정은 필요 없지만, 업그레이드 전후 메모리 사용량을 비교해두면 개선 효과를 수치로 확인할 수 있습니다.

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 기반 워크로드를 파악한 뒤, 보수적인 값으로 시작해 고루틴 동작을 모니터링하면서 점진적으로 조정하세요.

in-toto v3.1.0은 sslib 해시 함수를 내재화하고 ruff로 코드 스타일을 전환했습니다. 유지보수 중심 릴리스지만 sslib 의존성 변경은 실무 환경에 영향을 줄 수 있습니다.

• breakingsslib를 별도로 사용 중이라면 지금 마이그레이션 계획을 세우세요

  in-toto가 sslib의 해시 함수를 직접 내재화한 이유는 sslib가 지원 중단 수순을 밟고 있기 때문입니다. 프로젝트 의존성 트리에서 sslib를 직접 또는 간접적으로 끌어오는 경로가 있다면 지금 확인하고 대체 방안을 마련해야 합니다. in-toto 업그레이드만으로 sslib 문제가 해결된다고 보면 안 됩니다.

• enhancement`in-toto-run` 반환 코드 전달 동작 변경 — CI 파이프라인을 점검하세요

  기존에는 `in-toto-run`이 래핑된 명령의 종료 코드를 무시해서 CI에서 실패가 묻히는 경우가 있었습니다. 이제 종료 코드가 정상적으로 전달되므로, `in-toto-run` 이후 종료 코드를 검사하는 스크립트나 CI 스텝이 있다면 동작이 바뀌었는지 반드시 확인하세요. 이전에는 통과하던 단계가 실패로 잡힐 수 있습니다.

• enhancement기여자·패키저라면 개발 환경을 ruff로 맞추세요

  코드베이스 전체가 ruff 기준으로 정리됐습니다. fork를 유지하거나 PR을 올릴 계획이라면 기존 flake8/pylint 설정이 불필요한 충돌을 만들 수 있으니, 로컬 개발 환경을 ruff로 전환한 뒤 작업하는 게 좋습니다.

v4.0.6은 스캔 결과의 정확성을 크게 개선한 릴리스로, 네임스페이스 필터 오류, OPA 평가 실패 시 묵시적 누락, CVE 예외 처리 대소문자 구분 버그 등 결과에 직접 영향을 주는 문제들을 수정했습니다.

• securityCVE 예외 목록의 대소문자 일관성 점검 필요

  이전 버전에서는 이미지 스캔 CVE 예외 매칭이 대소문자를 구분했기 때문에, 소문자로 등록된 'ghsa-xxxx' 예외는 적용되지 않았습니다. 업그레이드 후 예외 목록의 CVE/GHSA ID 표기를 검토하고, 실제로 예외 처리되고 있는 항목을 다시 확인하세요.

• securityHTTP 핸들러 로그에서 요청 바디 기록 제거 — 기존 로그 검토 권고

  이전까지 Kubescape의 HTTP 핸들러가 스캔 요청 전체 바디를 로그에 기록했는데, 여기에 리소스 매니페스트나 민감한 설정 데이터가 포함될 수 있었습니다. 이번 릴리스에서 해당 로깅이 제거됐습니다. 기존에 수집된 로그에 매니페스트 내용이 포함되어 있을 수 있으므로, 로그 보존 정책을 검토하고 필요시 데이터를 폐기하세요.

• breaking업그레이드 후 스캔 결과 변화 예상 — 기존의 거짓 통과가 실패로 전환됨

  두 가지 버그로 인해 리소스가 스캔 결과에서 조용히 사라지고 있었습니다. OPA 평가 오류가 무시되던 문제와 GVR 수집 부분 실패가 억제되던 문제가 모두 수정됐습니다. 기존 컴플라이언스 점수가 비정상적으로 깔끔했다면, 업그레이드 후 새로 나타나는 실패 항목은 회귀가 아니라 원래부터 존재했던 문제입니다. 결과 기준선을 재정립해야 할 수 있습니다.

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

오퍼레이터 안정성, NATS 구독 준비 상태 감지, 보안 의존성 업그레이드에 집중한 유지보수 릴리즈입니다. API 변경은 없지만 프로덕션에서 주의할 수정 사항이 있습니다.

• securitywasmtime 보안 업그레이드 및 cargo audit 도입 — 즉시 업그레이드 권장

  이번 릴리즈에서 wasmtime이 업그레이드되고 rustls-pemfile 의존성이 제거됐습니다. 또한 cargo audit이 CI에 통합되어 이후 의존성 취약점을 조기에 탐지할 수 있게 됐습니다. Wasm 런타임에서 구버전 wasmtime을 유지할 이유가 없으므로, 2.0.5 이하를 사용 중이라면 즉시 업그레이드하세요.

• breaking오퍼레이터 준비 상태 판단 기준 변경 — 헬스체크 및 롤아웃 전략 검토 필요

  WorkloadDeployment의 Ready 조건이 이제 디플로이먼트 오브젝트 생성 시점이 아닌 실제 레플리카 가용성 기준으로 평가됩니다. CI/CD 파이프라인이나 모니터링에서 Ready 조건을 트래픽 전환이나 다음 단계 진행의 게이트로 사용하고 있다면, 정상 시작 중에도 '준비 안 됨' 구간이 길어질 수 있습니다. 롤아웃 대기 조건과 알림 임계값을 점검하세요.

• enhancementNATS 구독 준비 상태 버그 수정 — 시작 시 레이스 컨디션 겪었다면 확인 필요

  호스트가 이제 NATS 구독 워크로드가 실제로 준비된 후에 ready를 보고합니다. 시작 시 NATS 연결이 완전히 맺어지기 전에 컴포넌트가 구독을 시도하는 레이스 컨디션을 겪은 적 있다면, 이번 수정으로 해결됩니다. 별도 설정 변경 없이 업그레이드 후 시작 시퀀스가 예상대로 동작하는지 확인하면 됩니다.

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 버전과의 호환성을 먼저 확인하세요.

의존성 업데이트 중심의 일반적인 엣지 릴리스이며, 멀티클러스터 서비스 정리 버그 수정과 최소 지원 쿠버네티스 버전의 1.31 상향이 주요 변경 사항입니다.

• securityRust TLS 관련 크레이트 일괄 업데이트

  aws-lc-rs 1.16.3, rustls-webpki 0.103.13, rustls-pki-types 1.14.1이 한 번에 업데이트됐습니다. 명시적인 CVE는 없지만, 이 패키지들은 Linkerd mTLS의 암호화 기반입니다. 보안 요구사항이 엄격한 환경이라면 이전 엣지 버전 대신 이 릴리스를 채택하는 근거가 됩니다.

• breaking쿠버네티스 최소 지원 버전이 1.31로 상향됨

  MSKV가 1.31로 올라가면서 1.30 이하 클러스터는 공식 지원 범위를 벗어납니다. 이 엣지 릴리스를 적용하기 전에 클러스터 버전을 반드시 확인하세요. 아직 1.30을 사용 중이라면 쿠버네티스를 먼저 업그레이드하거나, 이 릴리스 적용을 보류하는 것이 맞습니다.

• enhancement멀티클러스터 사용 시 업그레이드 후 미러 서비스 상태 점검 권장

  여러 네임스페이스에 걸쳐 멀티클러스터 서비스를 운영 중이라면, 이전 버전의 정리 로직이 의도치 않게 다른 네임스페이스에 영향을 줬을 가능성이 있습니다. 업그레이드 후에는 미러링된 서비스가 올바른 상태인지 확인하세요. 특히 기본 네임스페이스 외에 스테일 미러나 예상치 못한 서비스 삭제가 발생한 적 있다면 반드시 점검이 필요합니다.

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

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 주입을 활성화하세요. 컨테이너 라이프사이클 이벤트가 트레이싱 백엔드에서 보이지 않던 공백이 드디어 채워집니다.

flagd core v0.15.5는 fractional rollout과 JSONLogic and/or 연산자의 평가 버그를 수정한 릴리스입니다. 복잡한 플래그 타게팅 룰을 운영 중인 팀은 업그레이드를 권장합니다.

• security의존성 보안 알림 해소

  Dependabot 보안 알림 항목들이 이번 릴리스에서 처리됐습니다. CVE 번호는 명시되지 않았지만 전이 의존성의 알려진 취약점이 대상입니다. 보안 민감 환경에서 flagd를 운영 중이라면 업그레이드하세요.

• breakingFractional 평가기 버그 수정: targeting key 없는 사용자가 있다면 반드시 업그레이드

  targeting key가 없거나 null인 사용자(예: 비로그인 익명 사용자)가 fractional 평가를 거치면 이전 버전에서 잘못된 버킷에 배정될 수 있었습니다. percentage rollout을 사용 중이라면 업그레이드하세요.

• breakingJSONLogic and/or 버그 수정으로 평가 결과 달라질 수 있음

  and/or 조건을 조합한 복합 플래그 룰이 v0.15.4에서 잘못 평가됐을 수 있습니다. 업그레이드 후 기존 룰의 평가 결과가 바뀔 수 있으므로, 복합 boolean 조건을 쓰는 룰은 배포 전에 검증하세요.

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

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

v3.3.9는 ApplicationSet DuckType Generator 패닉, 파드 로그 UI 크래시 등 버그 4건을 수정하고, CVE 대응을 위해 Go 버전을 올린 패치 릴리스입니다.

• securityGo CVE 패치 포함 — 즉시 업그레이드 권장

  이번 릴리스는 Go 런타임 CVE 수정을 명시적 목적으로 버전을 올렸습니다. 구체적인 CVE ID는 릴리스 노트에 명시되어 있지 않지만, 3.3.x를 운영 중이라면 다음 정기 점검 때까지 기다리지 말고 바로 3.3.9로 올리세요. 컨테이너 이미지는 cosign 서명 및 SLSA Level 3 증명이 적용되어 있으니, 파이프라인에서 서명 검증을 요구한다면 배포 전 확인하세요.

• breakingDuckType Generator 패닉 수정 — 영향받은 ApplicationSet 동작 확인 필요

  클러스터 레이블에 비문자열 값이 있는 환경에서 DuckType Generator를 사용 중이었다면, 기존 버전에서는 조용히 패닉이 발생했습니다. 업그레이드 후 해당 ApplicationSet들이 정상 처리되면서 이전에 실패하던 동기화가 갑자기 활성화될 수 있습니다. 업그레이드 직후 ApplicationSet 리소스 상태를 점검해 예상치 못한 동작이 없는지 확인하세요.

• enhancementOCI 메타데이터 캐싱 복구 — 레지스트리 부하 감소 기대

  Redis 캐시가 제대로 동작하지 않아 OCI 소스 조회가 매번 레지스트리에 직접 요청을 보내고 있었습니다. 수정 후 캐싱이 정상 작동하므로, OCI 기반 ApplicationSet이나 Helm 차트를 사용 중이라면 레지스트리 요청 수 감소와 응답 지연 개선을 기대할 수 있습니다. 별도 설정 변경은 필요하지 않습니다.

Argo CD v3.2.11은 이중 삭제 오류, 401 스트림 충돌, 오래된 컨테이너 인덱스로 인한 파드 로그 뷰어 충돌 등 세 가지 버그를 수정한 패치 릴리스입니다.

• enhancement파드 로그 뷰어나 스트리밍 UI를 사용한다면 즉시 패치 적용 권장

  수정된 세 가지 버그 중 두 개가 UI 안정성 문제입니다. 특히 파드 로그 뷰어 충돌은 장애 대응 중 로그를 열었을 때 빈 화면이나 에러가 뜨는 상황을 만드는 골치 아픈 문제입니다. 설정 변경 없이 버전 업그레이드만으로 해결되니 다음 유지보수 윈도우에 적용하면 됩니다.

• enhancement자동화된 정리 워크플로우를 운영 중이라면 이중 삭제 수정 사항 확인

  GitOps 조정 루프나 스크립트 기반 리소스 삭제 파이프라인에서 동일 리소스에 삭제 요청이 두 번 이상 발생하는 경우, 이전에는 서버가 오류를 반환했습니다. 이제는 이 상황을 정상적으로 처리합니다. 업그레이드 외 별도 조치는 필요 없습니다.

v1.16.0은 URI 빌트인 함수 추가, Data API 메타데이터 지원, OTLP 메트릭 내보내기와 함께, v1.15.x에서 발생한 로그 유실 버그를 수정한 릴리스입니다.

• securityunits.parse_bytes 지수 상한 적용 — 타임아웃 우회 차단

  units.parse_bytes에 비정상적으로 큰 지수 값을 넣으면 평가 타임아웃을 유발해 정책 집행을 우회할 수 있었습니다. v1.16.0에서 지수 크기에 상한을 두어 수정됐습니다. 사용자 입력이 units.parse_bytes로 전달되는 정책이 있다면 이번 수정이 직접 해당됩니다. 신뢰할 수 없는 소스에서 바이트 문자열을 파싱하는 정책을 우선 검토하세요.

• breakingv1.15.x 사용 중이라면 즉시 업그레이드 — 로그가 소리 없이 사라집니다

  v1.15.x의 BufferedLogger 버그로 인해 첫 번째 flush 이후 번들 다운로드 로그, print() 출력, 플러그인 로그가 전부 유실됩니다. 옵저버빌리티 스택에서 조용히 데이터가 손실되는 상황입니다. v1.15.x를 프로덕션에서 운영 중이라면 즉시 v1.16.0으로 업그레이드하고, 그 기간 동안의 로그 파이프라인에 공백이 없는지 확인하세요.

• enhancementuri.parse / uri.is_valid로 기존 정규식 기반 URL 검증 로직 교체하세요

  지금까지 많은 OPA 정책이 URL 파싱이나 검증에 정규식이나 문자열 조작을 써왔는데, 유지보수가 어렵고 엣지 케이스에 취약합니다. uri.parse는 RFC 3986 기반의 구조화된 컴포넌트(scheme, host, path, query 등)를 반환하고, uri.is_valid는 간결한 boolean 검사를 제공합니다. 리다이렉트 URI, 웹훅 URL, 혹은 URL을 포함하는 입력을 다루는 정책이 있다면 커스텀 파싱 로직을 이 빌트인으로 교체하는 게 낫습니다.

NATS v2.14.0은 2.13.x를 건너뛰고 출시됐습니다. JetStream 스케줄링, 고속 배치 퍼블리싱, 컨슈머 리셋 API, Raft 데이터 손실 방지 수정이 핵심입니다. 업그레이드 전 마이그레이션 가이드 확인이 필수입니다.

• breaking2.13.x 건너뜀 — 반드시 2.14 업그레이드 가이드를 먼저 읽으세요

  이번 릴리스는 2.12.x에서 바로 2.14.x로 올라갑니다. ACL로 JetStream ACK·플로우 컨트롤 주제를 제어하고 있다면 지금 당장 주목해야 합니다. 새 도메인 인식 형식($JS.ACK.domain.acchash.stream.consumer.>)은 현재 기본 비활성이지만 v2.15에서 기본 활성화됩니다. v2.15 업그레이드 전에 ACL 규칙을 미리 업데이트해 두세요.

• breakingRaft 스냅샷 손상 시 기동 거부 — 복구 절차를 미리 검증하세요

  기존에는 스냅샷이 손상되거나 로그와 정렬이 맞지 않아도 노드가 조용히 기동됐습니다. 이제는 기동 자체를 거부합니다. 올바른 방향이지만, 비정상 종료를 경험한 클러스터가 있다면 업그레이드 전에 스냅샷 무결성을 먼저 점검하세요. 운영 런북에도 이 시나리오의 복구 절차를 추가해 두는 게 좋습니다.

• enhancementConsumer Reset API로 컨슈머 재설정 작업이 훨씬 간단해졌습니다

  기존에는 컨슈머를 이전 시퀀스로 되돌리려면 삭제 후 재생성하는 번거로운 과정이 필요했습니다. 새 $JS.API.CONSUMER.RESET API를 쓰면 그 자리에서 바로 되감기가 됩니다. 컨슈머 재처리나 장애 복구 시나리오를 다루는 내부 도구나 런북이 있다면 이 API를 쓰도록 업데이트하세요.

Vitess v24는 구조화 JSON 로깅을 기본 채택하고, 샤드 키스페이스에서 윈도우 함수 푸시다운을 지원하며, 백업 MANIFEST 명령 주입 취약점을 차단합니다. 총 460개 PR이 병합됐습니다.

• security백업 MANIFEST 명령 주입 취약점 기본 차단

  v24 이전에는 백업 스토리지 쓰기 권한을 가진 공격자가 MANIFEST 파일을 수정해 VTTablet 복구 시 임의 셸 명령을 실행할 수 있었습니다. v24부터 --external-decompressor-use-manifest 플래그 없이는 MANIFEST의 압축 해제 명령이 무시됩니다. v23 이하를 운영 중이라면 백업 스토리지 접근 제어를 보안 경계로 간주하고 쓰기 권한 보유자를 즉시 감사하세요.

• breaking백업 복구 설정에서 MANIFEST 압축 해제 동작 확인 필요

  --external-decompressor 플래그 없이 MANIFEST에 저장된 명령으로 압축 해제에 의존하던 환경이라면, v24에서 복구 시 압축 해제가 묵시적으로 건너뛰어져 복구 자체가 실패할 수 있습니다. 기존 동작을 유지하려면 VTTablet 설정에 --external-decompressor-use-manifest를 추가하세요. 다만 보안 고려가 필요합니다 — 백업 스토리지 쓰기 권한이 있는 공격자가 임의 명령을 실행할 수 있는 경로가 됩니다. --external-decompressor로 명시적으로 전달하는 방식으로 전환하는 것이 더 안전합니다.

• breakingVTOrc API 엔드포인트와 메트릭 참조 즉시 교체

  /api/replication-analysis는 v24에서 404를 반환합니다. 해당 URL을 호출하는 모니터링 스크립트, Grafana 대시보드, 알림 규칙이 있다면 프로덕션 배포 전에 /api/detection-analysis로 전환하세요 (파라미터와 응답 형식 동일). DiscoverInstanceTimings를 사용하는 대시보드도 DiscoveryInstanceTimings로 교체해야 합니다.

• enhancementOpenTelemetry 트레이싱 마이그레이션은 지금 하세요

  opentracing-jaeger와 opentracing-datadog는 v24에서 지원 중단 경고가 나오고 v25에서 완전히 제거됩니다. 마이그레이션 자체는 간단합니다. --tracer opentracing-jaeger를 --tracer opentelemetry로, --jaeger-agent-host host:port를 --otel-endpoint host:4317로 바꾸면 됩니다. Jaeger v1.35 이상은 기본적으로 4317 포트에서 OTLP를 수신하고, Datadog는 Agent의 OTLP 수집 엔드포인트를 사용하면 됩니다. 이번 업그레이드 주기에 처리하는 편이 낫습니다.

• enhancementVTOrc에 --cell 플래그 지금 추가하세요

  v24에서는 선택 사항이지만 v25부터 필수가 됩니다. 멀티셀 환경이라면 지금 추가하는 것이 좋습니다. 기동 시 토폴로지 검증으로 설정 오류를 조기에 잡을 수 있고, 향후 VTOrc의 크로스셀 복구 로직도 이 플래그를 기반으로 동작할 예정입니다. 다운타임 없이 플래그 하나로 v25 강제 변경을 미리 피할 수 있습니다.

v1.17.2는 스케줄러 큐 오라우팅 버그, 오퍼레이터 초기화 실패, Job 레플리카 할당 오류를 수정한 패치 릴리스입니다. Alpine 베이스 이미지도 보안 목적으로 업그레이드됐습니다.

• security에어갭/미러 환경이라면 Alpine 3.23.4 기반 이미지를 새로 동기화해야 합니다

  베이스 이미지가 Alpine 3.23.3에서 3.23.4로 올라갔습니다. 미러링된 프라이빗 레지스트리를 쓰는 환경이라면 v1.17.2 이미지를 다시 풀하고 동기화하세요. 컴플라이언스 절차상 필요하다면 Alpine 변경 이력에서 수정된 CVE 목록을 확인하세요.

• breaking스케줄러 backoffQ 오분류로 숨겨졌던 스케줄링 실패가 표면화될 수 있음

  레플리카 부족 상태의 바인딩이 unschedulableBindings가 아닌 backoffQ로 잘못 라우팅되고 있었습니다. 즉, 실제로는 스케줄 불가 상태인 워크로드가 지수 백오프로 재시도되며 조용히 지연되고 있었을 수 있습니다. 업그레이드 후에는 이런 워크로드들이 unschedulableBindings에서 보이기 시작할 수 있으니, 기존에 스케줄이 느리거나 멈춰 있던 워크로드를 점검하세요.

• enhancementkarmada-operator로 tolerations/affinity를 쓰거나 멀티클러스터 Job을 운영 중이라면 즉시 패치 권장

  오퍼레이터 관리 디플로이먼트가 tolerations와 affinity 설정을 조용히 무시하고 있었는데, 의도치 않은 노드에 파드가 배치될 수 있는 문제입니다. Job completions 오할당도 분산 워크로드의 Job 완료 시맨틱을 망가뜨릴 수 있는 버그입니다. 두 기능 중 하나라도 쓰고 있다면 바로 업그레이드하세요.

Karmada v1.16.5는 스케줄러 큐 오라우팅, Job 레플리카 할당 오류, 오퍼레이터 조정 실패를 수정하고 Alpine 베이스 이미지를 업데이트한 패치 릴리스입니다.

• securityAlpine 3.23.4 베이스 이미지 — Karmada 컴포넌트 재빌드 및 재배포

  Alpine 3.23.3에서 3.23.4로의 업데이트는 업스트림 보안 이슈를 반영한 것입니다. 공식 이미지는 이미 반영되어 있으므로, 커스텀 빌드 이미지를 사용 중이라면 베이스 이미지를 동일하게 업데이트하고 이미지 스캔 파이프라인도 함께 점검하세요.

• breaking스케줄러 큐 오라우팅으로 워크로드가 멈출 수 있음 — 즉시 패치 권장

  클러스터 레플리카가 부족한 바인딩이 unschedulableBindings 대신 backoffQ로 잘못 들어가던 버그입니다. 충분한 클러스터 자원이 생겼는데도 바인딩이 계속 Pending 상태로 남아 있었다면 이 버그의 영향을 받은 것입니다. v1.16.5로 업그레이드하면 영향받은 바인딩은 자동으로 재스케줄됩니다.

• breakingJob completions 클러스터 배분 오류 — 기존 Job 결과 검토 필요

  v1.16.4에서 실행된 멀티클러스터 Job은 클러스터별 completion 수가 의도치 않게 치우쳐 있을 수 있습니다. 업그레이드 후, 해당 버전에서 실행된 Job의 완료 결과를 확인해 프로덕션 환경의 작업 분배에 이상이 없는지 점검하세요.

v1.15.8은 스케줄러 큐 오분류, ClusterAffinities 이벤트 누락, 오퍼레이터 초기화 실패를 수정한 버그픽스 패치입니다. Alpine 기반 이미지도 보안 업데이트됐습니다.

• securityalpine:3.23.4 반영을 위해 이미지 재빌드 또는 공식 이미지 교체

  alpine 3.23.4에는 보안 패치가 포함되어 있습니다. 업스트림 기반 이미지로 커스텀 빌드를 운영 중이라면 새 베이스 이미지로 재빌드가 필요하고, 공식 이미지를 사용 중이라면 v1.15.8 이미지로 교체하면 충분합니다.

• breaking스케줄러 큐 오분류로 워크로드 지연 — 즉시 패치 필요

  레플리카 부족 상태의 바인딩이 unschedulableBindings가 아닌 backoffQ로 들어가면, 지수 백오프 방식으로 재시도가 반복되어 워크로드 재스케줄링이 예상보다 훨씬 오래 걸립니다. ClusterAffinities와 레플리카 제약을 함께 사용 중이라면 v1.15.8로 즉시 업그레이드해야 합니다.

• enhancement오퍼레이터 초기화 멱등성 확보 — 재시작 시 실패 반복 해소

  기존에는 오퍼레이터가 초기화 도중 재시작되면 시크릿 중복 생성으로 재조정이 실패했습니다. 이제 멱등한 방식으로 수정되어, 파드 재시작이나 롤링 업데이트 중 발생하던 init 실패가 더 이상 재현되지 않습니다. 오퍼레이터 초기화 실패를 반복적으로 겪었다면 이번 패치로 해결됩니다.

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의 호환 릴리스도 함께 확인하세요.

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

v0.18.0은 LLMInferenceService 성숙화, CVE 3건 패치, 멀티노드 추론 기반 작업이 중심인 대형 릴리스입니다. LLM 워크로드를 운영 중이라면 업그레이드 전 꼼꼼히 검토해야 합니다.

• security즉시 적용 필요: 이번 릴리스에 CVE 3건 포함

  CVE-2026-32597(PyJWT 크리티컬 헤더 우회), CVE-2026-33186(gRPC 인증 우회), CVE-2026-30922(pyasn1 DoS)가 모두 패치됐습니다. gRPC 추론 엔드포인트나 Python 런타임을 외부에 노출 중이라면 선택 사항이 아닙니다. 특히 gRPC 인증 우회는 인증되지 않은 요청이 보호된 추론 엔드포인트에 도달할 수 있어 즉시 v0.18.0으로 업그레이드하거나 패치를 적용해야 합니다.

• breakingPYTHONPATH 웹훅 차단—ServingRuntime 사전 점검 필수

  이제 InferenceService나 ServingRuntime 스펙에 PYTHONPATH를 설정하면 어드미션 웹훅에서 거부됩니다. 커스텀 Python 모듈 경로 설정을 위해 PYTHONPATH를 쓰던 ServingRuntime이 있다면 업그레이드 후 배포가 막힙니다. 업그레이드 전에 모든 ServingRuntime과 ISVC 매니페스트를 점검하고 PYTHONPATH 사용을 제거하거나 대체 방법으로 바꿔야 합니다.

• breakingHelm 차트명 변경—기존 릴리스 마이그레이션 계획 필요

  KServe Helm 차트명이 'kserve'에서 'kserve-resources'로 바뀌었습니다. 기존 릴리스 이름으로 그냥 업그레이드하면 차트를 찾지 못합니다. 기존 Helm 릴리스 이름을 변경하거나 언인스톨 후 재설치하는 방식으로 마이그레이션을 계획해야 하며, 차트명을 참조하는 CI 파이프라인과 GitOps 설정도 함께 수정해야 합니다.

• enhancementLLMInferenceService 오토스케일링 실운영 수준 도달—LLM 워크로드에 검토 권장

  KEDA/HPA·WVA 기반 오토스케일링과 멀티노드 워크로드를 위한 LWS 오토스케일링 타겟이 추가됐습니다. vLLM 기반 추론을 대규모로 운영하면서 수동 스케일링에 어려움을 겪고 있다면 스테이징에서 llmisvc 오토스케일링을 테스트해볼 시점입니다. WVA 의존성이 v0.6.0-rc3으로 올라간 만큼 GA는 아니지만 근접한 상태로 봐야 합니다.

Kyverno 1.18은 HTTP 컨텍스트 보안을 강화하고 이미지 검증 우회 버그를 수정했으며, CLI에서 더 많은 정책 유형을 테스트할 수 있게 됐습니다.

• security업그레이드 전 HTTP 컨텍스트 정책 전수 검토 필수

  HTTP 컨텍스트를 사용하는 정책은 이제 블록리스트 강제 적용을 받습니다. 기존에 정상 동작하던 외부 HTTP 호출이 업그레이드 후 차단될 수 있습니다. 1.18로 전환하기 전에 HTTP 컨텍스트 항목이 있는 정책을 모두 파악하고, 대상 URL이 기본 블록리스트에 포함되지 않는지 확인하세요. 필요하다면 FLAG_HTTP_BLOCKLIST 오버라이드를 설정해야 합니다. 스코프 토큰 인증 방식도 바뀌었으므로 폭넓은 토큰 권한에 의존하는 정책이 있다면 비프로덕션 클러스터에서 먼저 검증하세요.

• security이미지 검증 우회 버그 패치 — 실제 적용 여부 재확인 권장

  processResourceWithPatches가 패치 실패 시 nil을 반환해 이미지 검증을 조용히 건너뛰는 버그가 수정됐습니다. 이미지 검증 정책을 운영 중이었다면 그동안 실제로 적용되고 있었는지 확신하기 어렵습니다. 업그레이드 후 준수 여부 스캔을 다시 실행해 결과를 확인하세요. CVE-2026-32280(중간 인증서 제한)과 CVE-2026-32283(Go 툴체인 업그레이드)도 포함됐으니 보안 측면에서 빠른 업그레이드를 권장합니다.

• enhancementsuccessEventActions로 이벤트 과부하 해소

  정책 범위가 넓은 대규모 클러스터에서는 성공 이벤트가 etcd를 압박하고 이벤트 스트림을 쓸모없게 만들기 쉽습니다. 새 successEventActions 파라미터를 Kyverno ConfigMap에 추가하면 어떤 성공 이벤트를 방출할지 직접 제어할 수 있습니다. 기존 omitEvents 설정과 충돌하면 경고가 발생하니 병행 설정 시 주의하세요.