릴리즈

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 로그를 모니터링하세요.

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 우선 + 퍼블릭 클라우드 버스트 패턴에 적합합니다. 기존 정책에는 영향 없고, 이 필드를 추가한 경우에만 동작이 바뀝니다.

v1.17.8은 완료된 인스턴스 ID 재사용 시 워크플로우가 영구 stuck되는 버그와, Sentry OIDC discovery document가 X-Forwarded-Host로 오염될 수 있는 보안 취약점(CWE-346)을 수정합니다.

• securityX-Forwarded-Host를 통한 OIDC discovery document 오염 취약점 조치

  Sentry OIDC 서버를 `--jwt-issuer`나 `--oidc-allowed-hosts` 없이 켜둔 배포는 CWE-346에 노출됩니다. 공격자가 `X-Forwarded-Host` 헤더를 조작한 요청 한 건만으로 discovery document를 오염시킬 수 있고, HTTP 캐시가 최대 1시간 동안 오염된 응답을 서빙할 수 있습니다. 즉시 업그레이드가 어렵다면 `--jwt-issuer`로 issuer를 고정하는 것이 가장 빠른 완화책입니다. 리버스 프록시의 공개 hostname을 `X-Forwarded-Host`로 전달하는 구성이라면 `--oidc-allowed-hosts`를 설정해야 해당 헤더가 계속 동작합니다.

• breaking인스턴스 ID 재사용으로 stuck된 워크플로우 수정 — 업그레이드 필요

  결정적(deterministic) 인스턴스 ID를 재사용하는 워크플로우를 운영 중이라면 이 버그에 해당할 수 있습니다. 사이드카를 1.17.8로 올리면, 다음 retention reminder가 실행될 때 자동으로 복구되며 스케줄러에서 수동으로 job을 지울 필요가 없습니다. `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` 메트릭이 워크플로우당 초당 1씩 올라가고 있다면 이 버그를 겪고 있는 겁니다.

v1.20.8은 보안 전용 패치 릴리스로, Go 런타임을 1.25.10으로 올리고 go-git, golang.org/x/net, x/crypto, docker/cli 등 여러 의존성 CVE를 수정했습니다.

• securityv1.20 운영 클러스터는 즉시 v1.20.8로 업그레이드 필요

  이번 패치는 go-git(두 건), golang.org/x/net, golang.org/x/crypto, docker/cli, in-toto-golang CVE와 Go 런타임 stdlib CVE까지 한꺼번에 잡았습니다. v1.20.8 미만 버전을 운영 중이라면 현재 취약한 상태입니다. 특히 Crossplane이 Git 저장소에서 패키지를 가져오는 환경이라면 go-git과 x/crypto 취약점이 직접 영향을 줄 수 있습니다. '다음 스프린트에 처리'할 수준이 아니니 빠르게 업그레이드 일정을 잡으세요.

• enhancement아직 v1.20을 쓰고 있다면 v1.21+ 전환 검토 시점

  v1.20 라인은 보안 백포트만 받고 있어 기능 개선은 없습니다. 이번 패치를 계기로 업그레이드 블로커를 점검해 보세요. v1.21은 충분히 안정화되었고, 구버전 마이너에 머무르면 이런 보안 패치를 계속 쫓아다녀야 하는 상황이 반복됩니다.

v2.1.6은 보안 패치 중심의 릴리스로, Go 런타임을 1.25.10으로 올리고 go-git, x/crypto, OpenTelemetry 등 여러 취약 의존성을 수정했습니다.

• securityv2.1.x 사용 중이라면 즉시 v2.1.6으로 업그레이드

  Go stdlib, go-git, x/crypto, x/net에 걸친 복수의 CVE가 패치됐습니다. go-git 취약점은 패키지 페치 동작에 영향을 줄 수 있고, x/crypto·x/net 문제는 TLS 및 HTTP 처리에 노출될 수 있습니다. API나 동작 변경은 없어 업그레이드 위험이 낮으므로, 빠르게 적용하는 것이 좋습니다.

• security설치된 프로바이더 이미지도 별도로 취약점 스캔 필요

  Crossplane 코어는 패치됐지만, AWS·GCP·Azure 등 프로바이더는 각자의 의존성 트리를 가진 별도 이미지입니다. Trivy나 Grype로 현재 실행 중인 프로바이더 파드를 스캔해 동일한 취약 버전이 포함돼 있는지 확인하세요. 각 프로바이더 유지관리팀의 별도 패치 릴리스를 기다려야 합니다.

Go 런타임을 1.25.10으로 올리고 go-git, x/crypto 등 의존성 보안 패치를 적용한 순수 보안 패치 릴리스입니다.

• securityv2.2.x 사용 중이라면 즉시 v2.2.2로 업그레이드하세요

  이번 릴리스는 기능 변경 없이 보안 패치만 포함합니다. Go 1.25.10의 stdlib CVE 수정, go-git v5.19.1의 git 취약점 패치, x/crypto의 암호화 취약점 수정이 모두 반영됐습니다. 동작 변경이 없어 업그레이드 위험은 최소화 수준입니다. 이미지 스캔이나 컴플라이언스 요건이 있는 팀은 v2.2.1 이하 버전을 유지할 경우 취약점 탐지 결과가 계속 뜰 겁니다.

• security업그레이드 후 새 이미지 다이제스트로 스캐너 재실행 필요

  go-git가 이번 릴리스에서 두 번 연속 패치된 점은 해당 공격 표면에 대한 실질적인 익스플로잇 압박이 있었음을 시사합니다. 업그레이드 후 새 Crossplane 이미지 다이제스트로 취약점 스캐너를 다시 돌려 모든 탐지 결과가 해소됐는지 확인하세요. in-toto-golang도 함께 패치됐으므로 공급망 관련 CVE 항목도 함께 점검하길 권장합니다.

Crossplane v2.3.0은 고충실도 로컬 렌더 엔진, 리소스별 재조정 제어, 알파 단계의 Provider 삭제 보호 기능을 제공하며, Go stdlib CVE 수정을 포함한 다수의 보안 의존성 업데이트를 반영했습니다.

• securityGo stdlib CVE 수정 — 이미지 업데이트 권장

  stdlib CVE 패치를 위해 Go가 1.25.10으로 올라갔으며, grpc, go-git, go-jose, cloudflare/circl, golang.org/x/net 등 여러 의존성도 보안 패치가 적용됐습니다. 가능한 빨리 Crossplane 배포를 v2.3.0으로 업데이트하세요. 내부 이미지 미러를 운영 중이라면 롤아웃 전에 새 다이제스트가 반영됐는지 확인하세요.

• breakingAPI 임포트 경로 변경 및 신규 CLI 저장소 북마크 필수

  Go 코드에서 Crossplane API를 임포트하고 있다면 `github.com/crossplane/crossplane/v2/apis`를 `github.com/crossplane/crossplane/apis/v2`로 수정해야 합니다. `v1.Resource*` 타입은 `v2.ClusterManagedResource*`로 이름이 바뀌었습니다. CLI 버전 관리도 `github.com/crossplane/cli` 저장소 기준으로 전환해야 하며, 코어와 버전이 달라지므로 CI 파이프라인의 버전 핀을 점검하세요.

• breakingv2.2에서 순차 업그레이드 필수 — 마이너 버전 건너뛰기 금지

  Crossplane은 업그레이드 시 CRD 마이그레이션을 수행하는데, 마이너 버전을 건너뛰면 API 서버 상태가 불일치할 수 있습니다. v1.20 브랜치는 연장 지원을 받지만 v2.x 마이그레이션 계획을 세워야 하며, 공식 업그레이드 가이드의 순차 업그레이드 절차를 반드시 따르세요.

• enhancement리소스별 폴링 어노테이션으로 API 서버 부하 절감

  변경이 드문 안정적인 XR에 `crossplane.io/poll-interval: 24h`를 설정하면 재조정 빈도를 크게 낮출 수 있습니다. `crossplane.io/reconcile-requested-at` 어노테이션과 함께 쓰면 필요할 때만 온디맨드 재조정을 트리거할 수 있습니다. XR에는 즉시 적용되지만, 관리 리소스는 Provider가 crossplane-runtime v2.3.0 기반으로 릴리스된 후 사용 가능합니다.

• enhancementProvider 삭제 보호는 비프로덕션 환경에서 먼저 검증

  신규 `--enable-provider-deletion-protection` 알파 플래그는 관리 리소스가 존재하는 동안 Provider 삭제를 막는 `ClusterUsage` 리소스를 자동으로 생성합니다. 공유 클러스터에서 유용한 안전장치인 만큼, 기존 `ClusterUsage` 웹훅이 자동 생성된 리소스를 올바르게 처리하는지 스테이징에서 먼저 확인한 뒤 프로덕션에 적용하세요.

wasmCloud v2.2.0은 WASI Preview 3 TLS 지원, HTTP 아웃고잉 요청 커스터마이징 트레이트, 네임스페이스 범위 오퍼레이터 버그 수정을 포함합니다.

• breaking`watchNamespaces` 사용 중인 오퍼레이터, 업그레이드 후 RBAC 반드시 확인

  네임스페이스 범위 롤 적용 방식이 변경되어, `watchNamespaces`가 설정된 환경에서는 업그레이드 후 오퍼레이터의 RBAC 권한이 올바르게 구성되어 있는지 확인해야 합니다. 롤 바인딩이 잘못된 경우 컴포넌트 조정(reconciliation)이 조용히 실패할 수 있어 장애 탐지가 어렵습니다.

• enhancement`wasi:tls`로 Wasm 컴포넌트 내 TLS 처리 도입 검토

  이제 호스트 측 TLS 종료에 의존하지 않고 Wasm 컴포넌트 안에서 직접 TLS 연결을 다룰 수 있습니다. 보안 아웃바운드 연결이 필요한 컴포넌트를 개발 중이라면 `wasi:tls` 인터페이스를 테스트해보세요. 다만 WASI 스펙이 아직 안정화 단계가 아니므로, 프로덕션 적용은 스펙 확정 후로 미루는 편이 안전합니다.

• enhancementCI 파이프라인에서 `wash new --non-interactive` 정식 활용

  `wash new`의 인터랙티브 프롬프트 때문에 CI에서 우회책을 쓰고 있었다면 이번 수정으로 깔끔하게 해결됩니다. 파이프라인 스크립트를 `--non-interactive` 플래그를 사용하도록 정리하세요. `wash config`에 유효성 검사와 정리 기능이 추가된 김에, 기존 설정 관리 흐름도 함께 점검할 만합니다.

Dapr v1.17.7은 워크플로우 안정성, 메시징 정확성, 컨트롤 플레인 복원력을 겨냥한 집중적인 버그 수정 릴리스입니다. 워크플로우, Kafka, RabbitMQ를 운영 중이라면 즉시 업그레이드를 권장합니다.

• security1.18에서 다운그레이드했거나 Ed25519/RSA 키를 사용 중이라면 Sentry를 즉시 업그레이드하세요

  dapr/kit의 타입 스위치 버그로 인해 Ed25519 및 RSA 발급자 키가 있을 때 Sentry가 'unsupported key type'으로 시작에 실패하고 크래시 루프에 빠집니다. Sentry가 크래시 루프 상태이면 mTLS 인증서 발급과 갱신이 모두 중단됩니다. 만료되지 않은 인증서를 가진 사이드카는 계속 동작하지만, 파드 재시작이나 인증서 만료 시 조용히 인증이 실패합니다. 트러스트 번들을 마이그레이션할 필요 없이 1.17.7로 업그레이드하는 것만으로 해결됩니다.

• breaking스케줄러 etcd 컴팩션 모드 변경 — PVC 용량 점검 필수

  내장 etcd의 컴팩션 방식이 주기(10분) 기반에서 리비전(100만) 기반으로 바뀌고, 기본 스토리지 크기가 1Gi에서 16Gi로 늘어납니다. Kubernetes StatefulSet의 volumeClaimTemplates는 불변이라 기존 1Gi PVC는 자동으로 조정되지 않습니다. 워크플로우를 실제로 운영 중이라면 업그레이드 전에 현재 PVC 사용률을 확인하고, 용량이 부족하다면 클러스터에서 직접 PVC를 먼저 확장해야 합니다. Helm 차트는 기존 PVC 크기를 덮어쓰지 않도록 lookup 헬퍼를 사용하지만, 자동 확장은 하지 않습니다.

• enhancement업그레이드 전 워크플로우 페이로드 크기 비율 대시보드를 미리 구성하세요

  새로 추가된 dapr_runtime_workflow_payload_size_ratio와 dapr_runtime_workflow_activity_payload_size_ratio 메트릭은 페이로드 크기를 --max-body-size 대비 비율로 표현합니다. 업그레이드 후 histogram_quantile(0.99, ...) > 0.9 조건으로 Prometheus 알림을 설정해두면, 워크플로우가 0.95 임계치에 걸려 Stall 상태가 되기 전에 미리 감지할 수 있습니다. 페이로드가 크거나 히스토리가 긴 워크플로우를 운영 중이라면 특히 유용합니다. --max-body-size가 명시적으로 설정된 경우에만 메트릭이 기록된다는 점도 참고하세요.

v1.12.4는 웹훅 서버의 DoS 취약점(CVE-2026-44247)과 스케줄러 버그 2건을 수정한 보안 패치 릴리스입니다. v1.12.3 이하를 운영 중이라면 즉시 업그레이드하세요.

• security웹훅 서버 OOM 취약점 즉시 패치 필요

  CVE-2026-44247은 웹훅 엔드포인트에 네트워크 접근이 가능한 파드가 대용량 HTTP 본문을 전송해 웹훅 서버를 OOM으로 종료시킬 수 있는 취약점입니다. CVSS 범위(Scope)가 'Changed'로 평가되어 공격 파드를 넘어 클러스터 전체 어드미션 제어가 마비될 수 있습니다. 즉시 v1.12.4로 업그레이드하세요. 즉시 업그레이드가 어렵다면 NetworkPolicy로 웹훅 서비스에 접근 가능한 네임스페이스와 파드를 최소화하는 것이 우선입니다.

• breaking멀티 큐 선점 결과가 잘못 적용됐을 가능성 점검

  preemptorTasks 덮어쓰기 버그로 인해 멀티 큐 선점을 사용하는 클러스터에서 스케줄링 결정이 잘못 이루어졌을 수 있습니다. QueueOrderFn이 무시되거나 우선순위 낮은 잡이 제대로 선점되지 않았을 가능성이 있습니다. 업그레이드 후 큐 선점 동작을 검토하고, 큐 순서 정책이 의도대로 적용되는지 확인하세요. 업그레이드 전 장시간 대기 중인 잡이 있었다면 원인일 수 있습니다.

• enhancement스케줄러 재시작 시 발생하던 간헐적 오류 해소

  이벤트 핸들러 완료 대기 수정으로 Volcano 재시작 또는 롤링 업그레이드 직후 스케줄링이 불안정했던 현상이 해결됩니다. 별도 조치 없이 업그레이드만으로 충분하지만, 재시작 후 간헐적으로 스케줄링 실패가 관찰됐다면 이 버그가 원인이었을 가능성이 높습니다.

v1.13.3은 웹훅 서버의 DoS 취약점(CVE-2026-44247)을 패치하고 스케줄러 버그 4건을 수정합니다. v1.13.2 이하를 사용 중이라면 즉시 업그레이드하세요.

• securityCVE-2026-44247 즉시 패치 필요 — v1.13.2 이하 전체 영향

  웹훅 엔드포인트에 네트워크 접근 가능한 파드라면 임의 크기의 HTTP 바디를 전송해 웹훅 서버를 OOM으로 종료시킬 수 있습니다. 웹훅 서버가 죽으면 Job·Queue 어드미션이 전부 막히므로 멀티테넌트 클러스터에서 실질적 피해가 큽니다. 사용 중인 브랜치에 맞춰 v1.13.3(또는 v1.12.4, v1.14.2)으로 업그레이드하세요. 즉시 업그레이드가 어렵다면 NetworkPolicy로 웹훅 서버의 443 포트 접근을 신뢰할 수 있는 소스로만 제한하세요.

• breaking멀티 큐 선점 동작 변경 — 업그레이드 후 워크로드 검증 필요

  선점 관련 두 가지 수정으로 스케줄링 결정 결과가 달라질 수 있습니다. preemptorTasks 덮어쓰기 방지와 QueueOrderFn 적용으로, 기존에 선점하던 Job이 더 이상 선점하지 않거나 그 반대 상황이 생길 수 있습니다. 업그레이드 전에 스테이징 환경에서 멀티 큐 선점 시나리오를 반드시 검증하세요.

• enhancement스케줄러 기동 시 경쟁 조건 제거 — 재시작이 잦은 환경에 유효

  OOM 재시작이나 롤링 업데이트로 스케줄러 파드가 자주 재시작되는 환경에서 특히 효과적입니다. 이전에는 초기화 완료 전에 스케줄링이 시작되는 좁은 경쟁 구간이 있었고, 이로 인해 이벤트 누락이 생길 수 있었습니다. 별도 설정 변경 없이 업그레이드만 하면 되며, 업그레이드 후 스케줄러 기동 로그에서 이상 징후를 확인하세요.

v1.14.2는 웹훅 서버 OOM DoS CVE와 스케줄러 정확성 관련 다수의 버그를 수정합니다. 1.12/1.13/1.14 브랜치 사용자는 즉시 업그레이드해야 합니다.

• securityCVE-2026-44247 즉시 패치 — 1.12/1.13/1.14 전 버전 영향

  웹훅 엔드포인트에 네트워크 접근 가능한 Pod이면 누구든 대용량 요청 바디를 전송해 웹훅 서버를 OOM으로 강제 종료할 수 있습니다. CVSS 6.8(Moderate)이지만 웹훅이 죽으면 클러스터 전체의 워크로드 어드미션이 차단되므로 실제 영향은 큽니다. 사용 중인 브랜치에 맞게 v1.14.2, v1.13.3, v1.12.4 중 하나로 즉시 업그레이드하세요. 즉시 업그레이드가 어렵다면 NetworkPolicy로 웹훅 서비스에 접근 가능한 Pod을 제한해 임시 완화 조치를 취하세요.

• breaking1.14.x 신규 배포 후 스케줄러 패닉 여부 확인 필요

  초기 설치 시 레이스 컨디션으로 스케줄러가 패닉 후 재시작되는 버그가 있었습니다. 1.14.x 최근 배포 후 스케줄러 CrashLoopBackOff를 겪었다면 이 수정 사항이 원인입니다. 업그레이드 후 스케줄러 Pod이 안정적으로 유지되는지 확인하세요. 설정 변경은 불필요하지만, 조용한 재시작으로 스케줄링 사이클이 누락됐을 수 있으니 모니터링 알림 내역을 검토하세요.

• enhancement멀티 큐 프리엠션 동작 정상화 — 프리엠션 정책 재검증 권장

  멀티 큐 프리엠션에서 preemptorTasks 덮어쓰기 문제와 QueueOrderFn이 무시되던 두 가지 버그가 함께 수정됐습니다. 커스텀 큐 정렬 함수와 함께 큐 간 프리엠션을 사용 중이라면, 이전까지 스케줄러가 설정대로 동작하지 않았을 가능성이 높습니다. 업그레이드 후 프리엠션 시나리오를 검증해 잡이 기대한 우선순위 순서대로 처리되는지 확인하세요. 설정 변경은 필요 없지만 실제 동작이 달라집니다.

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 문서부터 살펴보세요.

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에서 호스트 헬스 기반으로 트래픽 라우팅이나 준비 게이트를 사용한다면 업그레이드 후 정확한 준비 신호를 받을 수 있습니다.

오퍼레이터 안정성, 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 연결이 완전히 맺어지기 전에 컴포넌트가 구독을 시도하는 레이스 컨디션을 겪은 적 있다면, 이번 수정으로 해결됩니다. 별도 설정 변경 없이 업그레이드 후 시작 시퀀스가 예상대로 동작하는지 확인하면 됩니다.