릴리즈

Kubernetes v1.36.2는 Dynamic Resource Allocation 스케줄러, CSI 볼륨 재퍼블리싱, 엔드포인트 컨트롤러의 치명적 버그를 고치고 Go 1.26.4로 빌드한 패치 릴리스입니다.

• security바이너리 non-UTF8 Secret 데이터가 컨테이너 환경 변수에서 정상 처리됨

  Kubernetes 1.34 이상에서 바이너리 non-UTF8 데이터를 포함하는 Secret API 객체로부터 환경 변수를 설정하는 컨테이너가 제대로 읽을 수 없는 리그레션이 있었습니다. 1.36.2에서 수정되었습니다. 환경 변수에 텍스트가 아닌 Secret 데이터를 사용하는 워크로드가 있다면 업그레이드하여 디코딩 오류나 묵시적 실패를 예방하세요.

• breakingDRA 디바이스 할당 버그, 멀티 디바이스 워크로드 영향

  Kubernetes 1.36.0–1.36.1에서 스케줄러가 SharedCounters를 사용하는 드라이버와 멀티 할당 가능 디바이스를 함께 쓸 때 상호 배타적 디바이스 파티션을 여러 Pod에 할당하는 버그가 있습니다. 워크로드 실패, 디바이스 충돌, 크래시, 데이터 손실을 초래할 수 있습니다. DRA를 멀티 할당 가능 디바이스(특히 GPU나 공유 카운터를 사용하는 커스텀 액셀러레이터)로 운영 중이면 1.36.2로 즉시 업그레이드하세요. 최근 Pod 스케줄링 결정을 검토하여 충돌이 없는지 확인하세요.

• enhancementCSI 볼륨 재퍼블리싱 실패가 마운트 상태를 손상시키지 않음

  Kubelet이 주기적 NodePublishVolume 호출(requiresRepublish=true로 트리거됨)이 실패할 때 CSI 마운트 디렉터리를 잘못 삭제하여 Pod에 레거시 볼륨 콘텐츠가 남는 문제가 있었습니다. 1.36.2에서 수정됩니다. requiresRepublish=true인 CSI 드라이버를 운영 중이면 이 패치가 일시적 네트워크 또는 스토리지 오류로 인한 데이터 일관성 위험을 제거합니다. 업그레이드하여 잠재적 데이터 문제를 예방하세요.

Kubernetes v1.35.6은 다중 노드 DRA 클레임 스케줄링, CSI 볼륨 재발행, 엔드포인트 처리의 심각한 버그를 수정하고 Go 1.25.11로 업그레이드했습니다.

• securitySecret 바이너리 데이터의 환경 변수 처리 버그 수정

  1.34+ 버전의 바이너리 데이터(인증서, base64 인코딩된 키 등)를 포함한 Secret에서 환경 변수를 주입하지 못하는 버그가 있었습니다. Secret을 환경 변수로 주입 중이고 그 Secret에 바이너리 데이터가 있다면 v1.35.6으로 업그레이드하세요. 데이터베이스 자격증명이나 키를 Secret 환경 변수로 실행 중이면 버그가 조용히 주입을 깨뜨렸을 수 있으니 빨리 테스트하세요.

• breaking빌드 파이프라인의 Go 런타임을 1.25.11로 업그레이드

  Kubernetes v1.35.6은 Go 1.25.11로 빌드됩니다. 커스텀 컨트롤러나 오퍼레이터를 같은 Go 버전에서 실행 중이면 호환성을 확인하고 다시 빌드하세요. CI/CD에서 Go 버전을 고정 중이면 빌드 설정을 업데이트해야 합니다.

• enhancementDRA 스케줄링과 CSI 재발행이 안정화됨

  세 가지 버그가 해결되었습니다. (1) 공유 카운터를 사용하는 DRA ResourceClaim AllocationMode All에서 스케줄러 패닉 제거. (2) 다중 노드와 노드별 클레임을 함께 사용하는 파드가 더 이상 Pending에서 교착되지 않음. (3) NodePublishVolume 오류 시 kubelet이 마운트 디렉터리를 삭제하지 않아 오래된 볼륨 데이터 손상 방지. DRA나 CSI 재발행을 사용 중이면 이전에 교착 상태가 되던 상황이 제거됩니다. 업그레이드하여 막힌 파드를 정리하고 향후 장애를 방지하세요.

쿠버네티스 v1.34.9는 CSI 마운트 볼륨 처리, 바이너리 Secret 데이터 처리, 엔드포인트 컨트롤러 패닉, kubeadm 인증서 처리를 수정합니다. Go 1.25.11 빌드로 런타임 성능이 향상됩니다.

• breakingrequiresRepublish가 활성화된 CSI 드라이버 운영 중이면 kubelet 업그레이드

  v1.34 회귀로 인해 kubelet이 republish 실패 시 CSI 마운트 디렉터리를 삭제해 포드에 오래된 볼륨 데이터가 남아있었습니다. spec.requiresRepublish=true로 설정된 CSI 드라이버를 운영 중이면 즉시 업그레이드하세요. kubelet 로그에서 실패한 republish 시도를 확인한 후 업그레이드하면 이 버그를 맞고 있었는지 파악할 수 있습니다.

• breaking바이너리 Secret을 환경 변수로 주입하는 워크로드 테스트

  v1.34에서 바이너리(non-UTF8) 데이터가 포함된 Secret을 참조하는 환경 변수 파싱이 깨졌습니다. 워크로드에서 Secret을 환경 변수로 주입한다면 업그레이드 후 테스트하세요. 애플리케이션 시작 로그에서 파싱 오류를 확인하고, 필요하면 바이너리 Secret 값을 base64로 인코딩해야 할 수도 있습니다.

• enhancementGo 런타임 업데이트로 성능과 보안 강화

  v1.34.9는 Go 1.25.11을 사용하며, 런타임 최적화와 보안 패치를 포함합니다. 제어 플레인과 워커 노드를 다음에 순환 업그레이드할 때 반영하세요. 애플리케이션 코드 수정은 불필요하지만, Go 업데이트로 인해 클러스터 지연 시간이 감소하고 메모리 사용량이 줄어들 수 있습니다.

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

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이 실패했던 경험이 있다면, 이 패치가 그 문제를 해결해 줍니다.

Kubernetes v1.36은 다수의 GA 승격, DRA 대규모 확장, 갱 스케줄링 API 신규 도입, 그리고 업그레이드 전 즉시 조치가 필요한 메트릭 이름 변경을 포함하는 대형 릴리스입니다.

• breaking업그레이드 전 모니터링 수정 필수 — 메트릭 이름 두 개 변경

  volume_operation_total_errors와 etcd_bookmark_counts가 각각 volume_operation_errors_total, etcd_bookmark_total로 이름이 바뀌었습니다. 기존 이름을 쓰는 Prometheus 알림이나 Grafana 대시보드는 업그레이드 후 조용히 동작을 멈춥니다. v1.36을 프로덕션에 적용하기 전에 모니터링 스택 전체를 점검하고 참조를 모두 교체하세요.

• breakingDRA 사용 중이라면 RBAC 업데이트 필수

  DRAResourceClaimGranularStatusAuthorization 피처 게이트가 v1.36에서 베타로 기본 활성화됩니다. DRA 스케줄러·컨트롤러는 resourceclaims/binding에 대한 update/patch 권한이, DRA 드라이버는 resourceclaims/driver에 대한 associated-node:update 또는 arbitrary-node:update 권한(특정 resourceNames로 제한)이 필요합니다. DRA 드라이버를 운영 중이라면 업그레이드 전에 RBAC 매니페스트를 반드시 점검하고 수정하세요. 누락 시 파드 스케줄링이 실패합니다.

• breakingflex-volume·git-repo 볼륨 플러그인 제거 — 마이그레이션 필수

  kubeadm은 더 이상 flex-volume 플러그인 디렉터리를 자동으로 마운트하지 않으며, git-repo 볼륨 플러그인은 영구적으로 비활성화됩니다. 재활성화 옵션이 없으므로 git-repo 볼륨을 사용하는 워크로드는 init 컨테이너 패턴이나 CSI 드라이버로 전환해야 합니다. kubeadm 환경에서 flex-volume을 계속 쓰려면 v1.36 업그레이드 전에 distroless 기반이 아닌 KCM 이미지와 extraVolumes 설정을 수동으로 구성해야 합니다.

• breakingStrictIPCIDRValidation 기본 활성화 — IP/CIDR 값 점검 필요

  이제 API 필드에서 선행 0이 있는 IP(예: 010.0.0.1)나 호스트 비트가 설정된 CIDR(예: 192.168.1.5/24)을 거부합니다. 기존 오브젝트는 validation ratcheting으로 보존되지만, 신규 생성 및 업데이트는 실패합니다. 업그레이드 전에 매니페스트, Helm 차트, 자동화 스크립트에서 비정규 IP/CIDR 값을 점검하세요.

• enhancementMutatingAdmissionPolicy GA 승격 — 단순 Webhook 교체 검토 시점

  CEL 기반 MutatingAdmissionPolicy가 v1으로 GA 승격되어 기본 활성화됩니다. 레이블/어노테이션 주입이나 기본값 설정처럼 단순한 뮤테이팅 웹훅을 운영 중이라면 MutatingAdmissionPolicy로 교체를 검토할 때입니다. 웹훅 서버 유지, 인증서 관리, 가용성 걱정 없이 CEL 기반 정책으로 동일한 기능을 구현할 수 있습니다. 상태가 없는 단순 뮤테이션부터 시작하는 것을 권장합니다.

v1.33.11은 MultiCIDRServiceAllocator 활성화 시 apiserver 기동 실패와 nft 1.1.3에서의 kube-proxy nftables 오작동을 수정한 패치 릴리스입니다. Go 1.25.9로 컴파일러도 업데이트됐습니다.

• breakingMultiCIDRServiceAllocator + 대규모 클러스터라면 즉시 업그레이드

  MultiCIDRServiceAllocator가 활성화된 환경에서 네임스페이스가 많으면, 업그레이드 중 apiserver가 아직 준비되지 않은 어드미션 플러그인으로부터 Forbidden 오류를 받고 기동에 실패하는 문제가 있었습니다. 이번 패치로 재시도 로직이 추가됩니다. 이 문제 때문에 1.33 업그레이드를 미뤄왔다면 이제 적용할 수 있습니다. apiserver 로그에서 IP 복구 컨트롤러의 Forbidden 오류를 확인해 보세요.

• breakingnft 1.1.3 사용 노드는 kube-proxy nftables가 사실상 불통 — 즉시 패치 필요

  nft 1.1.3이 설치된 노드(일부 최신 배포판 기본값)에서는 kube-proxy nftables 모드가 제대로 작동하지 않습니다. 처음에는 트래픽이 흐르는 것처럼 보여도 규칙 업데이트가 올바르게 적용되지 않습니다. 노드에서 'nft --version'으로 버전을 확인하고, 1.1.3이라면 이 패치 릴리스로 업그레이드하는 것이 가장 확실한 해결책입니다.

• enhancementOTel v1.41.0 대폭 업그레이드 — 옵저버빌리티 파이프라인 검증 필요

  OpenTelemetry Go SDK가 v1.33.0에서 v1.41.0으로 한 번에 올라갔습니다. 버전 차이가 큰 만큼, Kubernetes 텔레메트리 데이터를 수집하거나 OTel SDK와 연동되는 사이드카를 운영 중이라면 업그레이드 전 비운영 환경에서 트레이싱·메트릭 파이프라인이 정상 작동하는지 먼저 확인하세요. Kubernetes 기능 자체의 변화는 없지만 버전 갭이 충분히 커서 점검할 가치가 있습니다.

v1.34.7은 감사 로그 지연 시간 누락 버그와 nftables kube-proxy 호환성 문제를 수정하고, Go 1.25.9로 재빌드한 패치 릴리스입니다.

• breaking감사 로그 지연 시간 데이터가 조용히 누락됐습니다 — 즉시 패치 필요

  이 패치 이전의 1.34.x 클러스터는 500ms를 넘는 요청에 대해 감사 로그에서 지연 시간 어노테이션을 누락시켰습니다. 보안 감사나 컴플라이언스 도구가 이 어노테이션을 파싱해 SLO 추적이나 이상 감지에 활용하고 있다면, 그 기간의 데이터에는 공백이 있는 셈입니다. v1.34.7로 업그레이드 후, 해당 기간 감사 로그가 불완전하다는 사실을 기록으로 남겨두세요.

• breakingnft 1.1.3 환경에서 nftables kube-proxy가 완전히 동작 불가 — 우회 없으면 즉시 업그레이드

  Fedora 42, Ubuntu 25.04처럼 nft 1.1.3이 기본 탑재된 신형 배포판에서 kube-proxy를 nftables 모드로 실행하면 네트워킹 자체가 동작하지 않습니다. 성능 저하가 아닌 완전한 장애입니다. nft를 구버전으로 고정하거나 v1.34.7로 즉시 업그레이드하세요. 수정 사항은 knftables 라이브러리 업그레이드(v0.0.17 → v0.0.21)에 포함되어 있습니다.

• enhancementOTel v1.41.0으로 대폭 업그레이드 — 트레이싱 연동 검증 필요

  OpenTelemetry Go 패키지가 v1.35.0에서 v1.41.0으로 올라갔습니다. API 호환성은 유지되지만, 스팬 전파나 메트릭 수집 내부 동작이 상당 부분 변경됐습니다. Kubernetes OTel 스팬을 활용하는 커스텀 계측 코드나 사이드카가 있다면, 프로덕션 적용 전에 스테이징에서 반드시 검증하세요.

v1.35.4는 사이드카 컨테이너 재시작 불가, StatefulSet 병렬 스케일링 회귀, kube-proxy nftables 오작동, 감사 로그 레이턴시 어노테이션 오류 등 5개의 실제 버그를 수정한 패치 릴리스입니다.

• breakingStatefulSet maxUnavailable 동작에 의존 중이라면 즉시 확인 필요

  MaxUnavailableStatefulSet 기능 게이트가 1.35.4에서 다시 기본 비활성화됐습니다. 1.35.x로 업그레이드하면서 maxUnavailable 기반 병렬 파드 관리를 기대했다면, 그 동작은 현재 없는 셈입니다. StatefulSet 스펙에 maxUnavailable을 설정해둔 경우 조용히 무시됩니다. 업그레이드 전 스펙을 점검하고, 해당 기능 게이트가 다시 안정화될 때까지 운영 전략을 조정하세요.

• breaking사이드카 + startupProbe 조합 사용 중이면 빠른 업그레이드 권장

  restartPolicy: Always인 initContainer와 startupProbe를 함께 쓰는 파드는 kubelet 재시작 이후 크래시된 컨테이너가 영원히 재시작되지 않고 RestartCount: 0에 멈추는 현상이 있었습니다. 서비스 메시 프록시, 로그 수집기 등 사이드카 패턴을 쓰는 프로덕션 워크로드가 영향을 받습니다. 이미 이 상태에 빠진 파드가 있다면, 1.35.4로 업그레이드 후 해당 파드를 수동으로 삭제·재생성하는 것이 복구 방법입니다.

• enhancementnft 1.1.3 노드 환경이라면 kube-proxy 업그레이드 우선 적용

  nftables 버전 1.1.3이 설치된 시스템에서 kube-proxy의 nftables 모드가 완전히 동작하지 않는 문제가 있었습니다. 네트워킹 자체가 깨지는 조용한 장애입니다. 최근 Debian/Ubuntu 계열 일부 배포판이 nft 1.1.3을 포함하므로, 해당 환경의 노드 컴포넌트는 이번 패치를 우선 적용하세요.

v1.35.3은 kubeadm 버그 수정 2건과 DRA 퇴출 상태 메시지 정리 1건으로 구성된 소규모 패치입니다. 위험도가 낮아 안심하고 적용할 수 있습니다.

• enhancementetcd learner 엔드포인트 버그 수정을 위해 kubeadm 업그레이드 권장

  etcd learner 멤버 수정이 이번 패치에서 운영상 가장 중요한 변경 사항입니다. kubeadm으로 관리하는 클러스터에서 노드 조인이나 멤버 승격 중 etcd 클라이언트 연결 문제를 겪은 적 있다면 이 패치가 근본 원인을 해결합니다. 설정 변경 없이 kubeadm 바이너리만 업데이트하면 되므로, 다음 유지보수 창에 적용하는 것을 권장합니다.

• enhancement피어 마운트 환경에서 kubeadm reset 안정성 향상

  /var/lib/kubelet에 피어 마운트가 구성된 환경(특정 컨테이너 런타임 또는 중첩 마운트 설정)에서 reset 자동화가 실패한 경험이 있다면 이 수정이 적용됩니다. EINVAL 오류가 reset 과정을 막지 않으므로, 원인 불명의 reset 실패를 겪고 있는 경우 업그레이드할 만합니다.

v1.34.6은 etcd learner 엔드포인트 문제와 클러스터 리셋 시 kubelet 언마운트 오류를 수정하는 소규모 패치 릴리스입니다.

• enhancementetcd 멤버 추가 작업이 있다면 즉시 업그레이드 검토

  etcd learner는 아직 투표권이 없는 상태인데, 이 시점에 클라이언트 엔드포인트에 포함되면 프로모션 완료 전까지 요청 실패가 발생할 수 있습니다. etcd 노드 추가 중 간헐적 클라이언트 오류를 겪었다면 이 패치가 해결책입니다. 그렇지 않다면 일반 패치 주기에 맞춰 적용하면 됩니다.

• enhancementkubeadm reset 실패 경험이 있다면 이 패치를 우선 적용

  /var/lib/kubelet 하위 바인드 마운트를 정리하지 못해 reset이 중간에 멈추는 문제가 수정됐습니다. 마운트 네임스페이스가 겹치거나 특정 파일시스템 설정을 쓰는 노드에서 주로 발생합니다. 리셋 실패 후 수동 정리를 반복했다면, 이 패치로 해당 번거로움을 없앨 수 있습니다.

v1.33.10은 ValidatingAdmissionPolicy의 kube-controller-manager 크래시 버그와 kubeadm 운영 버그 두 건을 수정한 소규모 패치입니다. 의존성 변경은 없습니다.

• breaking개방형 스키마 VAP 사용 중이라면 즉시 패치 필요

  `additionalProperties: true`를 사용하는 ValidatingAdmissionPolicy가 존재하면 kube-controller-manager가 nil 포인터 예외로 완전히 다운됩니다. 우아한 성능 저하가 아닌 즉각적인 크래시입니다. v1.33.x를 사용 중이라면 현재 배포된 VAP 정책을 점검하고, 개방형 스키마 정책을 추가하기 전에 반드시 v1.33.10으로 업그레이드하세요.

• enhancementHA 클러스터 컨트롤 플레인 확장 전 업그레이드 권장

  etcd는 신규 멤버를 learner로 먼저 등록한 뒤 승격시키는데, 이전 버전 kubeadm은 learner를 클라이언트 엔드포인트 풀에 포함시켜 조인 과정에서 간헐적 etcd 클라이언트 오류를 유발했습니다. kubeadm으로 관리되는 HA 클러스터에서 컨트롤 플레인 노드를 추가할 계획이 있다면, 작업 전에 이 패치를 적용하세요.

• enhancement노드 자동화 해제 스크립트에서 kubeadm reset 안정성 개선

  /var/lib/kubelet이 bind 마운트된 노드에서 `kubeadm reset`을 실행하면 EINVAL 오류로 정리 작업이 중간에 실패했습니다. 이제 peer 마운트에서 예상되는 EINVAL을 무시하므로 reset이 깔끔하게 완료됩니다. 노드 폐기를 스크립트로 자동화하는 환경이라면 이 패치의 효과를 바로 체감할 수 있습니다.

Kubernetes v1.35.2는 v1.35 시리즈의 안정성과 버그 수정을 제공하는 패치 릴리스로, 호환성을 유지하면서 프로덕션 환경에서 발견된 문제들을 해결합니다.

• enhancement정기 패치 업그레이드 계획 수립

  안정성 수정사항이 포함된 표준 패치 릴리스입니다. 다음 유지보수 창구 동안 표준 롤링 업데이트 절차를 사용하여 업그레이드를 예약하세요. 비프로덕션 환경에서 먼저 테스트하되, v1.35.x와 완전 호환되므로 위험도는 최소화됩니다.

• enhancement컨테이너 레지스트리 참조 업데이트

  배포 매니페스트, Helm 차트, CI/CD 파이프라인을 업데이트하여 새로운 v1.35.2 컨테이너 이미지를 참조하도록 하세요. 모든 이미지는 동일한 registry.k8s.io 경로를 유지하며 버전 태그만 업데이트됩니다.

Kubernetes v1.32.13은 안정적인 v1.32 시리즈의 패치 릴리스로, 버그 수정과 보안 개선에 집중하며 하위 호환성을 유지합니다.

• security보안 패치 즉시 적용

  이 패치 릴리스에는 중요한 보안 수정 사항이 포함되어 있을 가능성이 높습니다. 특히 이전 v1.32.x 버전을 실행 중인 경우 프로덕션 클러스터의 즉시 업그레이드를 계획하세요. 스테이징에서 먼저 테스트한 후 표준 유지보수 창을 통해 프로덕션에 배포하세요.

• enhancement컨테이너 이미지 및 바이너리 업데이트

  최신 v1.32.13 컨테이너 이미지를 가져오고 인프라 전체의 노드 바이너리를 업데이트하세요. API 호환성을 유지하는 간단한 현장 업그레이드입니다. 새 이미지 태그를 참조하도록 CI/CD 파이프라인을 업데이트하세요.

• enhancement다중 아키텍처 지원 검증

  혼합 아키텍처 클러스터를 실행하는 경우 모든 아키텍처(amd64, arm64, ppc64le, s390x)가 일관되게 업데이트되었는지 확인하세요. 매니페스트 목록이 자동 아키텍처 선택을 지원하지만, 배포 자동화가 이를 올바르게 처리하는지 검증하세요.

Kubernetes v1.33.9는 중요한 버그 수정 및 안정성 개선을 제공하는 패치 릴리스입니다. 1.33 브랜치의 운영 이슈를 해결하면서 하위 호환성을 유지합니다.

• enhancement정기 패치 업그레이드 계획

  버그 수정 및 안정성 개선이 포함된 표준 패치 릴리스입니다. 다음 유지보수 시간에 이전 1.33.x 버전에서 업그레이드를 계획하세요. 비프로덕션 환경에서 먼저 테스트하고 표준 롤링 업데이트 절차를 따르시기 바랍니다.

• enhancement다중 아키텍처 지원 검증

  모든 컨테이너 이미지가 amd64, arm64, ppc64le, s390x 아키텍처에서 매니페스트 리스트를 지원합니다. 혼합 아키텍처 클러스터를 운영하는 경우, 배포 도구가 올바른 아키텍처별 이미지를 제대로 가져오는지 검증하세요.

Kubernetes v1.34.5는 1.34 시리즈에 대한 표준적인 버그 수정 및 안정성 개선을 제공하는 패치 릴리스로, 주요 기능 변경이나 호환성을 깨뜨리는 수정 사항은 없습니다.

• enhancement유지보수 창구 동안 정기 업그레이드 일정 계획

  패치 릴리스로서 v1.34.5에는 다음 예정된 유지보수 창구 동안 적용해야 할 안정성 및 버그 수정사항이 포함되어 있습니다. 비프로덕션 환경에서 먼저 테스트한 후, 표준 롤링 업그레이드 절차를 사용하여 적용하세요. 구성 변경이나 특별한 마이그레이션 단계는 필요하지 않습니다.

• enhancement배포에서 컨테이너 이미지 태그 업데이트

  배포 매니페스트, Helm 차트, CI/CD 파이프라인을 업데이트하여 새로운 v1.34.5 컨테이너 이미지를 참조하도록 하세요. 최신 안정성 수정사항을 받기 위해 플로팅 태그보다는 특정 버전 태그를 사용하는 클러스터에 특히 중요합니다.