릴리즈

containerd v2.2.4는 두 건의 CVE 패치와 함께 overlay, sandbox, AppArmor, seccomp 관련 버그를 수정한 보안 중심 패치 릴리스입니다.

• securityCVE 두 건 포함 — 즉시 v2.2.4로 업데이트

  containerd 코어(CVE-2026-46680)와 go-jose 의존성(CVE-2026-34986) 각각 하나씩, 총 두 건의 CVE가 수정됐습니다. 프로덕션 배포 모두에 해당하는 내용이므로 정기 점검 일정을 기다릴 이유가 없습니다. 긴급 패치 프로세스로 처리하세요. Kubernetes 노드에서 containerd를 런타임으로 사용 중이라면 오케스트레이터 종류와 무관하게 모두 영향을 받습니다.

• securityAF_ALG 기본 차단 추가 — 커스텀 워크로드 사전 검토 필요

  기본 seccomp 프로파일이 AF_ALG(소켓 기반 커널 암호화 API)를 차단하도록 강화됐습니다. 일반적인 워크로드에는 영향이 없지만, 암호화 처리나 하드웨어 오프로드 목적으로 AF_ALG 소켓을 직접 사용하는 컨테이너는 시스템 콜 거부가 발생할 수 있습니다. 업그레이드 전에 커스텀 또는 관대한 seccomp 프로파일을 사용하는 워크로드를 점검해두세요.

• enhancementUserNS + overlay 환경의 레이어 추출 오류 수정

  사용자 네임스페이스(rootless 컨테이너 포함)에서 overlay 스냅샷터를 쓸 때 'rebase' 기능이 레이어 추출 실패를 일으키던 문제가 해결됐습니다. UserNS 컨텍스트에서 자동으로 비활성화되므로 별도 설정 변경 없이 업그레이드만 하면 됩니다. 업데이트 후 rootless 워크로드의 마운트 정상 동작 여부를 확인하는 정도면 충분합니다.

containerd 2.0.9는 CVE-2026-46680 보안 취약점 패치와 tar 추출 시 TOCTOU 경쟁 조건 수정, containerd 재시작 시 컨테이너 종료 이벤트 유실 문제 등 여러 버그를 수정했습니다.

• securityCVE-2026-46680 즉시 패치

  CVE-2026-46680 보안 취약점이 이번 릴리스에서 수정됐습니다. containerd 2.0.x를 사용 중이라면 즉시 2.0.9로 업그레이드하세요. GHSA 보안 권고문에서 영향받는 구성과 심각도를 확인한 뒤 유지보수 일정을 잡되, 가능한 한 빨리 적용하는 것을 권장합니다.

• securitytar 추출 TOCTOU 수정 — 외부 이미지 사용 환경은 특히 주목

  tar 추출 중 발생하는 TOCTOU 경쟁 조건은 악의적으로 조작된 이미지 레이어로 경로 탈출을 시도하는 데 악용될 수 있습니다. 신뢰할 수 없는 서드파티 이미지를 pull하는 환경이라면 업그레이드와 함께 이미지 소스 제한 정책도 함께 점검하세요.

• breakingAppArmor 3.0 미만 환경은 업그레이드 후 프로파일 동작 확인 필요

  AppArmor ABI 필드가 이제 조건부로 설정됩니다. AppArmor 3.0 미만 시스템에서는 기존에 호환되지 않는 ABI가 프로파일에 삽입되던 문제가 해결되는 것이지만, 커스텀 프로파일로 이 문제를 우회해왔다면 업그레이드 후 AppArmor 동작을 반드시 검증하세요.

• enhancement컨테이너 종료 이벤트 유실 수정 — 파드 교체가 잦은 환경에서 효과적

  containerd 재시작 후 컨테이너가 예상치 못한 상태로 멈추는 현상, 특히 파드가 빠르게 순환되는 Kubernetes 환경에서 자주 발생했다면 이 수정이 근본 원인을 해결합니다. 별도 설정 변경 없이 업그레이드만으로 적용됩니다.

containerd 1.7.32는 CVE-2026-46680 보안 패치를 포함하며, 기본 seccomp 프로파일에서 AF_ALG 소켓을 차단하고 OCI spec USER 처리 버그도 수정했습니다.

• securityCVE-2026-46680 즉시 패치 — 1.7.32로 업그레이드

  이번 릴리스의 핵심은 CVE-2026-46680입니다. containerd 보안 어드바이저리(GHSA-fqw6-gf59-qr4w)에서 심각도와 공격 범위를 먼저 확인하되, 1.7.x를 운영 중이라면 패치를 미루지 마세요. 유지보수 창을 조정하더라도 업그레이드 자체는 최우선으로 계획해야 합니다.

• security기본 seccomp에서 AF_ALG 차단 — 커스텀 워크로드 사전 점검 필요

  기본 seccomp 정책이 이제 AF_ALG(커널 암호화) 소켓 패밀리를 차단합니다. 하드웨어 암호화 오프로딩이나 HSM 연동 워크로드는 업그레이드 후 시작에 실패할 수 있습니다. 일반 컨테이너에는 영향이 없지만, 특수한 암호화 기능을 쓰는 컨테이너라면 기본값을 완화하는 대신 커스텀 seccomp 프로파일로 명시적으로 허용하는 방식으로 대응하세요.

• breaking범위 초과 USER 값은 이제 명시적 오류로 처리

  기존에는 OCI spec에 유효 범위를 벗어난 UID/GID가 있으면 예측 불가한 사용자 이름 조회가 조용히 실행됐습니다. 이제는 컨테이너 시작 자체가 실패합니다. 고 숫자 UID를 사용하는 이미지가 있다면 업그레이드 전에 미리 점검하세요. 특히 레거시 이미지나 직접 빌드한 OCI spec을 쓰는 경우 주의가 필요합니다.

• enhancementAppArmor 2.x 호환성 복구 — 구형 배포판 운영자 확인

  Ubuntu 20.04, Debian Bullseye 등 AppArmor 2.x를 탑재한 배포판에서 1.7.x 일부 버전이 AppArmor 프로파일 로드 오류를 일으켰습니다. abi 지시어를 조건부로 설정하도록 수정되었으니, 관련 오류를 겪었던 환경이라면 업그레이드 후 프로파일 로딩 상태를 확인하세요.

containerd 2.3.1은 CVE-2026-46680을 패치하고, 기본 seccomp 정책 강화 및 런타임/스냅샷터 버그를 수정한 패치 릴리스입니다.

• securityCVE-2026-46680 즉시 패치 — 2.3.0에서 업그레이드 필수

  이번 릴리스에서 CVE-2026-46680이 수정됐습니다. 2.3.0을 운영 중이라면 취약점 세부 정보가 공개되기 전에 모든 노드에 2.3.1을 배포하세요. 패키지 매니저나 배포 파이프라인을 통해 빠르게 적용하는 것이 좋습니다.

• security기본 seccomp 정책에서 AF_ALG 차단 — 커널 암호화 API 사용 워크로드 사전 검증 필요

  기본 seccomp 프로파일이 AF_ALG(커널 소켓 기반 암호화 API)를 차단하도록 강화됐습니다. 대부분의 컨테이너 워크로드에는 영향이 없지만, AF_ALG를 직접 사용하는 애플리케이션은 업그레이드 후 동작이 중단될 수 있습니다. 프로덕션 적용 전에 strace 또는 소켓 호출 감사를 통해 영향 여부를 확인하세요. 커스텀 seccomp 프로파일을 직접 지정한 경우엔 영향받지 않습니다.

• breaking비-runc 런타임 사용자: 업그레이드 후 샌드박스 태스크 API 동작 검증 필요

  Kata Containers, gVisor 등 대체 런타임을 쓰는 환경이라면 샌드박스 태스크 API 수정 사항이 실제 컨테이너 생성 및 태스크 관리에 미치는 영향을 반드시 확인하세요. Runc 옵션의 태스크 필드가 deprecated 처리됐으니, 커스텀 Runc 옵션 설정에서 해당 필드를 제거하는 작업도 미리 진행해두는 것이 좋습니다.

runc 외 런타임(Kata, gVisor 등)에서 샌드박스 태스크 API 엔드포인트가 동작하지 않던 버그를 수정한 패치 릴리스입니다.

• breakingnon-runc 런타임 사용 중이라면 즉시 업그레이드 필요

  api/v1.11.0에서 Kata Containers, gVisor, 커스텀 샌드박스 shim을 사용하는 경우 태스크 API 엔드포인트가 정상 동작하지 않는 버그가 있습니다. 태스크 생성·삭제·exec 등의 작업이 조용히 실패하거나 오작동할 수 있으니, api/v1.11.1로 업그레이드 후 태스크 라이프사이클 동작을 반드시 검증하세요.

• enhancement커스텀 shim 관리자라면 프로토 변경 내용 확인

  이번 수정으로 CreateTaskRequest 프로토에 태스크 API 주소 필드가 추가됐습니다. 커스텀 shim을 직접 구현·관리하고 있다면, 해당 필드를 읽는 코드 경로가 있는지 검토하세요. 기존에 비어 있던 필드가 이제 채워져 전달되므로 동작 차이가 생길 수 있습니다. 일반 runc 워크로드는 별도 조치가 필요 없습니다.

Helm v3.21.0은 Kubernetes 클라이언트 라이브러리를 v1.36으로 올리고, OpenTelemetry CVE를 패치하며, OCI 인덱스 차트 풀 버그를 수정합니다. v3 EOL이 가까워지고 있습니다.

• securityOpenTelemetry CVE 패치를 위해 즉시 업그레이드

  이번 릴리스에서 OpenTelemetry 패키지의 CVE를 직접 수정했습니다. CI/CD 파이프라인이나 자동화 툴링에서 Helm을 사용 중이라면 다음 패치 릴리스를 기다리지 말고 지금 바로 v3.21.0으로 올리세요.

• breakingHelm v4 마이그레이션 계획을 지금 시작해야 합니다

  릴리스 노트에 Helm v3 EOL이 명시적으로 경고됩니다. v3.22.0이 Kubernetes v1.37을 타깃으로 하는 마지막 주요 피처 릴리스가 될 수 있습니다. 커스텀 플러그인이나 Helm CLI, Go SDK를 기반으로 한 자동화 코드가 있다면 지금부터 v4 변경 사항을 검토하세요.

• enhancement멀티아키텍처 레지스트리 환경에서 OCI 인덱스 차트 풀 재검토

  OCI 이미지 인덱스 매니페스트에서 차트를 풀하는 버그가 수정됐습니다. 멀티아키텍처 환경에서 이 문제를 회피하기 위해 다이제스트 직접 참조나 특정 매니페스트 태그를 써왔다면, 해당 워크어라운드가 더 이상 필요하지 않을 수 있으니 검토해 보세요.

Helm v4.2.0은 Kubernetes 1.36 클라이언트 지원, mustToToml 템플릿 함수 추가, generateName 리소스에 대한 dry-run 서버 모드 수정, 그리고 post-renderer YAML 파싱 버그 수정을 포함합니다.

• breakingCI 스크립트에서 deprecated 플래그 제거

  --hide-notes와 --render-subchart-notes가 deprecated됐고 향후 릴리스에서 제거될 가능성이 높습니다. helm install, upgrade, template 명령을 쓰는 CI 파이프라인과 스크립트를 지금 점검해서 해당 플래그를 미리 제거해두세요. 나중에 강제로 마이그레이션하는 상황을 피할 수 있습니다.

• enhancementTOML 템플릿에서 mustToToml로 전환

  mustToToml은 mustToJson과 동일하게 동작합니다. TOML 직렬화에 실패할 경우 빈 출력이나 잘못된 결과를 내놓는 대신 명시적 에러를 반환합니다. 차트 템플릿에서 toToml을 쓰고 있다면 mustToToml로 교체해 렌더링 실패를 즉시 감지할 수 있도록 하세요.

• enhancementgenerateName 리소스에 대한 서버 사이드 dry-run 재검증

  이전에는 --dry-run=server가 name 대신 generateName을 사용하는 리소스를 건너뛰어서 검증이 된 것처럼 보였습니다. 이제 수정됐으므로, generateName을 사용하는 차트에 대해 서버 사이드 dry-run을 다시 실행해보세요. 기존에 조용히 무시되던 검증 오류가 드러날 수 있습니다.

v1.36.1은 ZFS 노드, Windows 네트워킹, kubeadm 클러스터 관리 등 8개 버그를 수정한 패치 릴리스입니다.

• breakingZFS 노드 운영 중이라면 즉시 업그레이드 필요

  v1.36.0에서 cadvisor 플러그인 누락으로 ZFS 스토리지를 사용하는 노드의 kubelet이 시작되지 않습니다. v1.36.0을 ZFS 환경에 배포했다면 해당 노드들이 정상 작동하지 않을 가능성이 높으니, 추가 롤아웃 전에 반드시 v1.36.1로 패치하세요.

• breakingWindows L2Bridge 사용자: DNS 타임아웃의 근본 원인 해소

  파드 IP가 재사용될 때 오래된 HNS 엔드포인트가 남아 트래픽이 엉뚱한 노드로 라우팅되는 문제였습니다. 증상이 DNS 설정 오류처럼 보여 원인 파악이 어렵습니다. Windows 노드에서 L2Bridge 네트워킹을 쓴다면 우선순위를 높여 이번 패치를 적용하세요.

• enhancementkubeadm 부트스트랩, 느린 로드밸런서 환경에서도 안정화

  클라우드 환경에서 LB가 비동기로 프로비저닝될 때 kubeadm init이 실패하거나 의도치 않게 동작하는 경우가 있었습니다. 이제 부트스트랩 중에는 로컬 API 엔드포인트를 먼저 사용하고 이후 LB 엔드포인트로 전환하는 방식으로 수정됐습니다. 다음 클러스터 초기화나 업그레이드 전에 이 버전으로 올려두는 게 좋습니다.

Kubernetes v1.35.5는 스케줄러 상태 오염, Windows 네트워킹, kube-proxy 대규모 클러스터 동작, kubeadm 초기화 문제를 수정한 패치 릴리스입니다.

• breakingkubeadm 사용자: 업그레이드 후 kubeconfig 생성 동작 확인 필요

  kubeadm init이 admin.conf와 super-admin.conf 생성 시 controlPlaneEndpoint 대신 localAPIEndpoint를 사용하도록 바뀌었습니다. 커스텀 controlPlaneEndpoint 설정을 쓰는 클러스터라면 업그레이드 후 생성된 kubeconfig가 올바른지 반드시 검증하세요. 초기화 후 tooling이 controlPlaneEndpoint 기반 kubeconfig를 참조한다면 스테이징에서 먼저 테스트하는 것을 권장합니다.

• enhancement대규모 클러스터: kube-proxy 업그레이드로 불필요한 전체 동기화 차단

  엔드포인트가 1000개를 넘는 환경에서 kube-proxy가 불필요한 full-sync를 반복 실행하고 있었습니다. 이번 패치로 해당 동작이 멈추므로, 바쁜 클러스터의 CPU와 네트워크 오버헤드를 직접 줄일 수 있습니다. 다음 유지보수 윈도우에 kube-proxy 업그레이드를 포함시키세요.

• enhancement스케줄러 메모리 누수 수정 — 스케줄링 불안정 증상이 있다면 즉시 적용하세요

  동일한 이름의 Pod가 스케줄링 실패를 반복할 때 in-flight 상태 추적 데이터가 무한 증가하는 버그였습니다. 스케줄러 메모리 사용량이 지속적으로 증가하거나 스케줄링 지연이 관찰됐다면, 이 패치가 근본 원인을 해결합니다.

v1.34.8은 IPv6 CIDR 주소 할당 오류, 스케줄러 메모리 누수, Windows DNS 라우팅 장애, kubeadm 클러스터 부트스트랩 문제를 수정한 버그 픽스 패치입니다.

• securitykubeadm: kube-apiserver kubelet 접근에 전용 ClusterRole 적용

  kube-apiserver의 kubelet 클라이언트가 이제 공용 역할 대신 'system:kubelet-api-admin' 전용 ClusterRole에 바인딩됩니다. kubeadm으로 관리되는 클러스터는 업그레이드 시 자동으로 적용되지만, 업그레이드 후 'kubectl get clusterrolebinding'으로 실제 적용 여부를 확인하는 것을 권장합니다.

• breakingIPv6 클러스터: 업그레이드 전 ServiceCIDR 할당 상태 점검 필요

  64비트 IPv6 ServiceCIDR 버그로 인해 일부 클러스터에서 서브넷 범위를 벗어난 서비스 IP가 할당되어 있을 수 있습니다. v1.34.8로 업그레이드한 뒤 기존 서비스 IP가 설정된 서브넷 내에 있는지 확인하고, 범위를 벗어난 서비스는 재생성을 검토하세요. /64 IPv6 서비스 CIDR을 사용하는 클러스터에서 특히 확인이 필요합니다.

• enhancement대규모 클러스터: kube-proxy full-sync 제거로 컨트롤 플레인 부하 감소

  1000개 이상의 엔드포인트를 운영하는 환경에서 kube-proxy가 대규모 클러스터 모드임에도 불필요한 full-sync를 수행해왔습니다. 이번 패치로 해당 동작이 제거됩니다. 별도 설정 변경 없이 업그레이드만으로 적용되며, 업그레이드 후 kube-proxy CPU 사용량을 모니터링해 개선 효과를 확인하세요.

v1.33.12는 kubeadm 버그 4건을 수정한 패치 릴리스로, 클러스터 초기화 안정성, etcd 헬스체크, kubelet API RBAC 강화에 집중했습니다.

• securitykube-apiserver kubelet 클라이언트용 RBAC 역할 분리 적용

  kube-apiserver가 kubelet 클라이언트 자격증명에 전용 ClusterRole 'system:kubelet-api-admin'을 사용합니다. RBAC 경계가 명확해지고 자격증명 오용 시 영향 범위가 줄어듭니다. 기존 클러스터에 즉각적인 조치는 불필요하지만, kubeadm 업그레이드 후 RBAC 감사 목록에 해당 역할이 반영됐는지 확인하세요.

• enhancement외부 로드밸런서 환경에서 kubeadm init을 쓴다면 업그레이드 권장

  기존에는 kubeadm init이 로드밸런서 엔드포인트를 kubeconfig에 기록했는데, 첫 번째 apiserver가 뜨기 전에는 LB가 아직 없는 경우가 많아 실패하는 닭-달걀 문제가 있었습니다. 이번 수정으로 초기화 시에는 localAPIEndpoint를 사용하도록 바뀌었습니다. 재시도 스크립트나 수동 kubeconfig 편집으로 우회하던 팀이라면 이 패치로 그 작업이 불필요해집니다.

• enhancementetcd 쿼럼 기반 헬스체크로 오탐 실패 차단

  기존 헬스체크는 멤버 하나라도 비정상이면 kubeadm 작업 전체를 막았습니다. 쿼럼이 유지되는 한 작업이 진행되도록 바뀌었습니다. 3노드나 5노드 etcd 구성에서 멤버 하나의 장애로 kubeadm upgrade나 join이 실패했던 경험이 있다면, 이 패치가 그 문제를 해결해 줍니다.

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

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

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