릴리즈

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 모두에서 기능 게이트를 활성화한 뒤, 큐 쿼터가 엄격하게 적용되는 배치 잡 워크로드부터 어노테이션을 적용해 낭비성 노드 프로비저닝을 줄이세요.