릴리즈

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

wasmCloud v2.5.0은 wasmtime 46 업그레이드와 wasip3 기본 활성화를 중심으로 한 기능 릴리스이며, keyvalue bucket WIT 인터페이스의 breaking 변경과 quinn-proto의 medium 심각도 보안 수정이 함께 포함되어 있습니다. 나머지는 새로운 비동기 keyvalue/blobstore 인터페이스, 오퍼레이터 하드닝, 런타임 및 도구 관련 각종 수정으로 구성됩니다.

• securityquinn-proto 보안 수정 (RUSTSEC-2026-0185)

  소스에서 wasmCloud를 빌드하거나 의존성 스캔을 돌리는 경우 해당됩니다. 이번 릴리스에서 quinn-proto가 RUSTSEC-2026-0185(medium) 패치를 받았습니다. 애플리케이션 코드 수정 없이 업그레이드만 하면 됩니다.

• breakingkeyvalue bucket이 공유 types 인터페이스로 이동

  wasmcloud:keyvalue 인터페이스를 사용하는 컴포넌트에 해당됩니다. bucket 타입이 인터페이스 내부 정의에서 빠져나와 공유 types 인터페이스로 옮겨졌습니다. 기존 wasmcloud:keyvalue WIT 기반으로 만든 컴포넌트와 프로바이더는 업그레이드 전에 바인딩을 갱신하고 코드를 다시 생성해야 합니다.

• breakingwasmtime 46, wasip3 기본 활성화

  이 런타임에서 동작하는 모든 컴포넌트에 해당됩니다. wasmtime이 46으로 올라가고 wasip3 지원이 기본으로 켜집니다. 전체 배포 전에 기존 컴포넌트를 새 런타임에서 먼저 테스트하세요. 특히 wasip3 동작 변화에 민감한 컴포넌트는 주의가 필요합니다.

wasmCloud 2.4.0은 WorkloadDeployments 자동 스케일링을 추가하고, 아키텍처 지원을 확대하며(s390x), wash CLI와 호스트 플러그인 API를 개선합니다. 대체로 운영상 이점이 있는 점진적 개선입니다.

• enhancement변동 트래픽을 다루는 WorkloadDeployment는 자동 스케일링 활성화하기

  wasmCloud 2.4.0에서 WorkloadDeployments 자동 스케일링을 지원합니다. 현재 고정 레플리카 개수로 운영하면서 피크 시간이나 배치 처리 윈도우처럼 수요가 변동한다면, 자동 스케일링을 활성화하여 수동 조정과 유휴 비용을 줄일 수 있습니다. Helm 차트나 YAML 매니페스트에서 자동 스케일링 설정을 검토하고, 프로덕션 배포 전에 스테이징 환경에서 임계값을 테스트하세요.

• enhancements390x나 다른 비x86 시스템에 배포하는 경우 wash CLI 업데이트하기

  wash가 이제 s390x-unknown-linux-gnu용으로 빌드됩니다. IBM 메인프레임이나 s390x 시스템을 운영 중이라면, 에뮬레이션이나 우회책 없이 wash를 네이티브로 빌드하고 실행할 수 있습니다. 릴리스 애셋에서 새 바이너리를 받아 호스트 설정과 호환되는지 확인하세요.

• enhancement컨테이너 헬스 체크 설정을 검토하여 NATS 연결 상태 활용하기

  컨테이너 헬스 체크가 이제 별도 프로브 대신 NATS 연결 상태를 사용합니다. 장애 감지가 단순해집니다. 컨테이너가 NATS 연결을 잃으면 더 빠르게 unhealthy로 표시됩니다. 특히 지연 시간이 크거나 네트워크가 혼잡하여 NATS 재연결이 오래 걸릴 수 있는 환경에서는 헬스 체크 임계값과 타임아웃을 확인하세요.

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 예제를 먼저 살펴보고 의도된 패턴을 파악하는 걸 권장합니다.

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

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`에 유효성 검사와 정리 기능이 추가된 김에, 기존 설정 관리 흐름도 함께 점검할 만합니다.

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

Wasmtime 44 업그레이드, 풀링 할당자 충돌 수정, Linux GPU 지원을 위한 glibc 빌드 추가가 포함된 패치 릴리스입니다.

• security풀링 할당자 충돌이 있었다면 즉시 업그레이드하세요

  기존에는 호스트 하드웨어의 지원 여부 확인 없이 풀링 할당자가 활성화되었고, 이로 인해 런타임 충돌이나 예측 불가한 메모리 동작이 발생할 수 있었습니다. 특정 호스트 유형에서 wash-runtime 불안정 증상이 있었다면 이번 수정이 원인을 해결한 겁니다. 업그레이드 후 메모리 할당 동작을 모니터링하세요.

• breakingWasmtime 44 업그레이드 전 스테이징 환경에서 반드시 검증하세요

  Wasmtime 44는 하위 런타임의 메이저 버전 변경입니다. wasmCloud가 감싸고 있긴 하지만, Wasmtime은 버전마다 메모리 처리, WASI 인터페이스, 컴포넌트 모델 동작에 변화가 생기는 경우가 있습니다. 프로덕션 클러스터 업그레이드 전에 반드시 비프로덕션 환경에서 컴포넌트 워크로드를 검증하세요.

• enhancementLinux GPU 워크로드 운영 중이라면 glibc 빌드로 전환을 검토하세요

  Linux에서 GPU 기능을 사용하는 wasmCloud 워크로드를 운영 중이거나 계획하고 있다면, 새로운 glibc 빌드가 동적 링크 런타임을 기대하는 표준 Linux 배포판과의 호환성 문제를 해결합니다. 새 아티팩트를 받아 GPU 호스트 환경에서 검증해 보세요.

v2.0.4는 wash dev/host TLS 지원 확장, Helm 차트 게이트웨이 라우팅 수정, 거버넌스 문서 업데이트를 담은 유지보수 릴리스입니다.

• breaking로컬 Helm 게이트웨이 라우팅 설정 반드시 확인

  values.local.yaml에서 gateway가 기본 비활성화로 바뀌었고, hello-world 예제는 Kubernetes Service를 통해 라우팅됩니다. 로컬 Helm values를 직접 커스터마이징해 게이트웨이 기반 라우팅을 쓰고 있었다면, 업그레이드 전에 변경된 기본값과 비교해 충돌 여부를 점검해야 합니다.

• enhancement로컬·프로덕션 환경 모두 TLS 설정 적용 검토

  이제 wash dev와 wash host 모두 TLS를 지원합니다. 그동안 로컬 개발에서 TLS를 건너뛰었다면, 이번 기회에 설정을 맞춰보세요. 로컬 단계에서 인증서·연결 문제를 미리 잡아야 프로덕션 장애를 예방할 수 있습니다.

v2.0.3은 NATS 구독자 초기화 경쟁 조건 버그 수정, Kubernetes EndpointSlice 지원 추가, 컨테이너 비루트 소유권 설정, Helm 차트 확장 구성을 포함합니다.

• security즉시 업그레이드: 컨테이너가 기본적으로 비루트로 실행됩니다

  이전 릴리스는 루트 소유권으로 실행되어 컨테이너 보안 관점에서 문제가 있었습니다. 이번 릴리스부터 비루트 소유권이 기본값으로 변경됐습니다. 볼륨 마운트나 루트 권한에 의존하는 init 컨테이너가 있다면 프로덕션 적용 전 반드시 테스트하고, 필요하면 파드 스펙의 fsGroup 또는 runAsUser 설정을 조정하세요.

• breakingHelm 차트 이미지 태그 기본값 변경 — values 파일을 점검하세요

  기본 이미지 태그가 더 이상 하드코딩된 값을 사용하지 않고 chart.yaml의 appVersion을 따릅니다. values 파일에서 태그를 명시적으로 오버라이드하고 있다면 대부분 그대로 동작하겠지만, 기존 기본값 방식으로 이미지 버전을 고정했던 경우라면 차트 업그레이드 후 배포된 이미지 버전을 반드시 확인하세요.

• enhancementKubernetes 1.21 이상이라면 EndpointSlice를 활성화하세요

  EndpointSlice는 기존 Endpoints API를 대체하는 방식으로, 백엔드 수가 많을 때 확장성이 훨씬 뛰어납니다. kube-apiserver 부하를 줄이고 기존 Endpoints API의 스케일 한계를 피하려면 Helm values에서 EndpointSlice 옵션을 활성화하세요. Kubernetes 1.21 이상 환경이라면 지금 바로 적용할 수 있습니다.

v2.0.2는 wasmtime v43 업그레이드, Kubernetes Host 파드 리콘실러 추가, 설치 스크립트 개선을 담은 패치 릴리스입니다.

• enhancementwasmtime 43 런타임 개선 적용을 위한 업그레이드 권장

  wasmtime 43은 업스트림 버그 수정과 성능 개선을 포함합니다. v2.0.1을 운영 중이라면 위험 부담이 낮은 업그레이드입니다. wasmCloud API 변경은 없으므로 호스트만 재배포하면 됩니다.

• enhancementKubernetes 운영자: 새 Host 파드 리콘실러 검증 필요

  Host 파드 리콘실러는 Kubernetes에서 동작하는 wasmCloud 호스트 파드의 생명주기를 더 정교하게 처리합니다. wasmCloud 오퍼레이터를 사용 중이라면 프로덕션 적용 전에 스테이징 클러스터에서 파드 재시작과 스케줄링 동작을 먼저 검증하세요.

• enhancementWindows 사용자: winget으로 wash 설치 가능

  wash가 winget 패키지 레지스트리에 등록됐습니다. Windows 환경의 팀은 바이너리를 수동으로 받는 대신 winget으로 표준화된 설치가 가능해졌으며, Windows 러너 기반 CI 파이프라인 구성에도 활용할 수 있습니다.

v2.0.1은 runtime-operator Go 모듈의 v2 경로 마이그레이션, 프로토 재생성, 임시 go.work 우회 코드 제거를 담은 정리성 패치 릴리스입니다.

• breakingruntime-operator Go 모듈을 직접 임포트한다면 경로 수정 필요

  runtime-operator의 Go 모듈 경로가 v2로 변경됐습니다. 이 모듈을 직접 임포트하는 Go 코드가 있다면 import 경로에 /v2 접미사를 추가해야 합니다. wasmCloud를 오퍼레이터로만 실행하고 모듈을 직접 임포트하지 않는다면 별도 조치는 불필요합니다.

• enhancementv2.0.0에서 proto 또는 lint 문제를 겪었다면 이 패치로 업그레이드하세요

  프로토 재생성과 임시 go.work shim 제거가 포함되어 있어, v2.0.0 기준으로 오퍼레이터를 소스 빌드하던 경우 의존성 해석 오류나 낡은 proto 문제가 해소됩니다.

wasmCloud v2.0.0이 정식 출시됐습니다. HTTP/2·gRPC 지원, OpenTelemetry 메트릭, wasmtime 42 업그레이드, RUSTSEC-2026-0007 보안 패치가 포함됩니다.

• securityRUSTSEC-2026-0007 패치 — 즉시 업그레이드 필요

  v2.0.0 이전 빌드를 사용 중이라면 이 취약점 패치만으로도 업그레이드 이유가 충분합니다. cargo-audit이나 Dependabot을 통해 취약한 의존성이 실제로 해소됐는지 환경 내에서 직접 확인하세요.

• breakingHelm 사용자 필독: CRD 경로 변경, GitOps 파이프라인 점검 필요

  CRD 위치가 templates/crds에서 최상위 /crds 디렉토리로 바뀌었습니다. ArgoCD, Flux, 또는 기존 Helm 기반 GitOps 파이프라인이 이전 경로를 참조하고 있다면 업그레이드 즉시 배포가 깨집니다. 업그레이드 전에 Helm 릴리스 설정과 CI/CD 스크립트를 반드시 수정하세요.

• enhancement지금 바로 메트릭 수집 설정 — v2의 관측 가능성을 활용하세요

  OpenTelemetry 메트릭이 기본 포함됐습니다. 이미 OTEL 콜렉터를 운영 중이라면 wasmCloud v2를 연결해 런타임 메트릭 수집을 시작하세요. 프로덕션 전환 후가 아니라 지금, 기준 대시보드를 잡아두는 게 맞는 순서입니다.