WIPI

프로그래밍과 기술 이슈를 빠르게 정리하는 개발 블로그

목록으로

Programming Notes

Kubernetes v1.35: 팀버네테스 (세계수 릴리스)

편집자 : Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao 이전 릴리스와 마찬가지로 Kubernetes v1.35 릴리스는 새로운 안정화, 베타 및 알파 기능을 소개합니다. 고품질 릴리스의...

작성자

편집자: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

이전 릴리스와 마찬가지로 Kubernetes v1.35 릴리스는 새로운 안정화, 베타 및 알파 기능을 소개합니다. 고품질 릴리스의 꾸준한 출시는 저희 개발 사이클의 강점과 커뮤니티의 활발한 지원을 잘 보여줍니다.

이번 릴리스는 17개의 안정화된 기능, 19개의 베타 기능, 22개의 알파 기능을 포함하여 총 60개의 개선 사항으로 구성되어 있습니다.

이번 릴리스에는 일부 폐지 및 제거 사항도 있으니 반드시 확인하시기 바랍니다.

릴리스 테마 및 로고

2025년은 옥타린의 반짝임: 마법의 색 (v1.33)으로 시작하여 바람과 의지 (v1.34)의 강풍을 타고 왔습니다. 올해는 여러 영역을 묶어주는 생명의 나무, 위그드라실(Yggdrasil)에서 영감을 받은 세계수에 손을 대며 마무리합니다. 위대한 나무처럼, Kubernetes는 글로벌 커뮤니티의 보살핌으로 고리마다, 릴리스마다 성장하고 있습니다.

중심에는 지구를 감싸는 쿠버네티스 바퀴가 있으며, 꾸준히 참여하는 끈기 있는 유지보수 담당자, 기여자, 사용자들에 의해 굳건히 지탱되고 있습니다. 일상 업무와 삶의 변화, 그리고 꾸준한 오픈소스 관리 속에서 그들은 오래된 API를 정리하고, 새로운 기능을 접목하며, 세계 최대 오픈소스 프로젝트 중 하나를 건강하게 유지하고 있습니다.

세 마리의 다람쥐가 나무를 지키고 있습니다. 검토자를 위한 LGTM 스크롤을 든 마법사, 새로운 가지를 자르는 릴리스 팀을 위한 도끼와 쿠버네티스 방패를 든 전사, 그리고 어두운 이슈 큐에 빛을 비추는 트리저들을 위한 랜턴을 든 도적입니다.

이들은 훨씬 더 큰 모험 파티를 대표합니다. Kubernetes v1.35는 세계수에 또 하나의 성장 고리를 추가하며, 여러 손길과 다양한 경로, 그리고 뿌리가 깊어질수록 가지가 더 높이 뻗는 커뮤니티에 의해 형성된 새로운 성장을 보여줍니다.

주요 업데이트 스포트라이트

Kubernetes v1.35는 새로운 기능과 개선 사항으로 가득합니다. 릴리스 팀에서 강조하고 싶은 몇 가지 주요 업데이트는 다음과 같습니다!

안정화: 파드 리소스의 인플레이스 업데이트

Kubernetes는 파드 리소스의 인플레이스 업데이트를 정식 출시 (GA)했습니다. 이 기능을 통해 사용자는 파드나 컨테이너를 다시 시작할 필요 없이 CPU 및 메모리 리소스를 조정할 수 있습니다. 이전에는 이러한 수정에는 파드를 다시 생성해야 했으며, 이는 특히 스테이트풀 또는 배치 애플리케이션의 경우 워크로드에 지장을 줄 수 있었습니다. 초기 Kubernetes 릴리스에서는 기존 파드의 인프라 리소스 설정(요청 및 제한)만 변경할 수 있었습니다. 새로운 인플레이스 기능은 더 원활하고 비중단적인 수직 스케일링을 가능하게 하여 효율성을 향상하고 개발을 단순화할 수 있습니다.

이 작업은 SIG 노드가 주도한 KEP #1287의 일환으로 수행되었습니다.

베타: 워크로드 아이덴티티 및 보안을 위한 파드 인증서

이전에는 파드에 인증서를 전달하기 위해 외부 컨트롤러(cert-manager, SPIFFE/SPIRE), CRD 오케스트레이션 및 시크릿 관리가 필요했으며, 로테이션은 사이드카 또는 init 컨테이너에 의해 처리되었습니다. Kubernetes v1.35는 자동화된 인증서 로테이션을 통해 네이티브 워크로드 아이덴티티를 가능하게 하여 서비스 메시 및 제로 트러스트 아키텍처를 획기적으로 단순화합니다.

이제 kubelet은 키를 생성하고, PodCertificateRequest를 통해 인증서를 요청하며, 자격 증명 번들을 파드의 파일 시스템에 직접 기록합니다. kube-apiserver는 어드미션 시 노드 제한을 강제하여, 타사 서명자가 가장 흔히 겪는 문제인 노드 격리 경계를 실수로 위반하는 것을 방지합니다. 이를 통해 발행 경로에 베어러 토큰이 없는 순수 mTLS 흐름이 가능해집니다.

이 작업은 SIG Auth가 주도한 KEP #4317의 일환으로 수행되었습니다.

알파: 스케줄링 전 노드 선언 기능

컨트롤 플레인이 새로운 기능을 활성화해도 노드가 뒤처지는 경우(Kubernetes 스큐 정책에 따라 허용됨), 스케줄러는 해당 기능을 필요로 하는 파드를 호환되지 않는 오래된 노드에 배치할 수 있습니다. 노드 선언 기능 프레임워크를 통해 노드는 지원하는 Kubernetes 기능을 선언할 수 있습니다. 새로운 알파 기능이 활성화되면 노드는 지원하는 기능을 보고하고, 새로운 .status.declaredFeatures 필드를 통해 이 정보를 컨트롤 플레인에 게시합니다. 그러면 kube-scheduler, 어드미션 컨트롤러 및 타사 구성 요소가 이러한 선언을 사용할 수 있습니다. 예를 들어, 파드가 호환되는 노드에서만 실행되도록 스케줄링 및 API 유효성 검사 제약 조건을 적용할 수 있습니다.

이 작업은 SIG 노드가 주도한 KEP #5328의 일환으로 수행되었습니다.

안정화 단계로 전환되는 기능

다음은 v1.35 릴리스 이후 안정화된 개선 사항 중 일부입니다.

PreferSameNode 트래픽 분배

서비스의 trafficDistribution 필드가 트래픽 라우팅에 대한 더 명시적인 제어를 제공하도록 업데이트되었습니다. 새로운 옵션인 PreferSameNode가 도입되어 서비스가 로컬 노드의 엔드포인트를 사용할 수 있는 경우 엄격하게 우선순위를 지정하고, 그렇지 않으면 원격 엔드포인트로 대체하도록 합니다.

동시에 기존 PreferClose 옵션은 PreferSameZone으로 이름이 변경되었습니다. 이 변경 사항은 트래픽이 현재 가용성 영역 내에서 선호된다는 것을 명시적으로 나타내어 API를 자명하게 만듭니다. PreferClose는 하위 호환성을 위해 유지되지만, PreferSameZone은 이제 영역별 라우팅의 표준이 되어 노드 수준 및 영역 수준 선호도가 명확하게 구분되도록 합니다.

이 작업은 SIG 네트워크가 주도한 KEP #3015의 일환으로 수행되었습니다.

Job API managed-by 메커니즘

Job API에는 이제 외부 컨트롤러가 Job 상태 동기화를 처리할 수 있도록 하는 managedBy 필드가 포함됩니다. Kubernetes v1.35에서 안정화 단계로 전환되는 이 기능은 주로 MultiKueue에 의해 주도됩니다. MultiKueue는 관리 클러스터에서 생성된 Job이 작업자 클러스터에 미러링되어 실행되고 상태 업데이트가 다시 전파되는 멀티 클러스터 디스패칭 시스템입니다. 이 워크플로우를 활성화하려면 빌트인 Job 컨트롤러가 특정 Job 리소스에 대해 작동하지 않아야 Kueue 컨트롤러가 대신 상태 업데이트를 관리할 수 있습니다.

목표는 Job 동기화를 다른 컨트롤러에 깔끔하게 위임하는 것입니다. 이 기능은 해당 컨트롤러에 사용자 정의 매개변수를 전달하거나 CronJob 동시성 정책을 수정하는 것을 목표로 하지 않습니다.

이 작업은 SIG 앱이 주도한 KEP #4368의 일환으로 수행되었습니다.

.metadata.generation을 사용한 안정적인 파드 업데이트 추적

역사적으로 Pod API에는 Deployment와 같은 다른 Kubernetes 오브젝트에서 발견되는 metadata.generation 필드가 없었습니다. 이러한 누락으로 인해 컨트롤러와 사용자는 kubelet이 파드 사양의 최신 변경 사항을 실제로 처리했는지 확인할 신뢰할 수 있는 방법이 없었습니다. 이 모호성은 인플레이스 파드 수직 스케일링과 같은 기능에서 특히 문제가 되었는데, 리소스 크기 조정 요청이 언제 정확히 시행되었는지 알기 어려웠습니다.

Kubernetes v1.33은 알파 기능으로 파드에 .metadata.generation 필드를 추가했습니다. 이 필드는 이제 v1.35 Pod API에서 안정화되었으며, 이는 파드의 spec이 업데이트될 때마다 .metadata.generation 값이 증가함을 의미합니다. 이 개선의 일환으로 Pod API는 또한 kubelet이 성공적으로 확인하고 처리한 생성 번호를 보고하는 .status.observedGeneration 필드를 얻었습니다. 파드 조건도 각각 클라이언트가 보고 및/또는 관찰할 수 있는 자체 개별 observedGeneration 필드를 포함합니다.

이 기능이 v1.35에서 안정화 단계로 전환되었기 때문에 모든 워크로드에 사용할 수 있습니다.

이 작업은 SIG 노드가 주도한 KEP #5067의 일환으로 수행되었습니다.

토폴로지 매니저를 위한 설정 가능한 NUMA 노드 제한

토폴로지 매니저는 역사적으로 어피니티 계산 중 상태 폭발을 방지하기 위해 지원할 수 있는 최대 NUMA 노드 수에 대해 8이라는 하드 코딩된 제한을 사용했습니다. (여기에 중요한 세부 사항이 있습니다. _NUMA 노드_는 Kubernetes API의 노드와 동일하지 않습니다.) 이 NUMA 노드 수에 대한 제한은 8개 이상의 NUMA 노드를 가진 CPU 아키텍처를 특징으로 하는 최신 하이엔드 서버를 Kubernetes가 완전히 활용하는 것을 방해했습니다.

Kubernetes v1.31은 토폴로지 매니저 정책 구성에 새로운 베타 max-allowable-numa-nodes 옵션을 도입했습니다. Kubernetes v1.35에서는 이 옵션이 안정화되었습니다. 이를 활성화하는 클러스터 관리자는 8개 이상의 NUMA 노드를 가진 서버를 사용할 수 있습니다.

구성 옵션은 안정화되었지만, Kubernetes 커뮤니티는 대규모 NUMA 호스트에서 성능 저하를 인지하고 있으며, 이를 개선하기 위한 제안된 개선 사항(KEP-5726)이 있습니다. 이에 대한 자세한 내용은 노드에서 토폴로지 관리 정책 제어를 참조하십시오.

이 작업은 SIG 노드가 주도한 KEP #4622의 일환으로 수행되었습니다.

베타 단계의 새로운 기능

다음은 v1.35 릴리스 이후 베타 단계로 전환된 개선 사항 중 일부입니다.

Downward API를 통해 노드 토폴로지 레이블 노출

파드 내에서 영역 및 가용성 영역과 같은 노드 토폴로지 정보에 액세스하는 것은 일반적으로 Kubernetes API 서버를 쿼리해야 했습니다. 이 방법은 기능적이지만, 인프라 메타데이터를 검색하기 위해서만 광범위한 RBAC 권한 또는 사이드카 컨테이너를 필요로 하여 복잡성과 보안 위험을 초래합니다. Kubernetes v1.35는 Downward API를 통해 노드 토폴로지 레이블을 직접 노출하는 기능을 베타 단계로 승격시킵니다.

kubelet은 이제 topology.kubernetes.io/zone 및 topology.kubernetes.io/region과 같은 표준 토폴로지 레이블을 환경 변수 또는 프로젝티드 볼륨 파일로 파드에 주입할 수 있습니다. 주요 이점은 워크로드가 토폴로지 인식을 할 수 있는 더 안전하고 효율적인 방법이라는 것입니다. 이를 통해 애플리케이션은 API 서버에 의존하지 않고 자체 가용성 영역이나 지역에 자체적으로 적응할 수 있으며, 최소 권한 원칙을 준수하여 보안을 강화하고 클러스터 구성을 단순화합니다.

참고: Kubernetes는 이제 모든 파드에 사용 가능한 토폴로지 레이블을 주입하여 Downward API의 입력으로 사용할 수 있습니다. v1.35 업그레이드와 함께 대부분의 클러스터 관리자는 각 파드에 여러 개의 새로운 레이블이 추가되는 것을 보게 될 것이며, 이는 설계의 일부로 예상되는 동작입니다.

이 작업은 SIG 노드가 주도한 KEP #4742의 일환으로 수행되었습니다.

스토리지 버전 마이그레이션을 위한 네이티브 지원

Kubernetes v1.35에서는 스토리지 버전 마이그레이션을 위한 네이티브 지원이 베타 단계로 전환되고 기본적으로 활성화됩니다. 이로써 마이그레이션 로직이 코어 Kubernetes 컨트롤 플레인("인-트리")에 직접 통합되어 외부 도구에 대한 종속성이 제거됩니다.

역사적으로 관리자는 스키마를 업데이트하거나 미사용 데이터를 재 암호화하기 위해 수동 "읽기/쓰기 루프"(종종 kubectl get을 kubectl replace로 파이핑)에 의존했습니다. 이 방법은 비효율적이며, 특히 시크릿과 같은 대규모 리소스의 경우 충돌이 발생하기 쉬웠습니다. 이번 릴리스에서는 빌트인 컨트롤러가 업데이트 충돌 및 일관성 토큰을 자동으로 처리하여 최소한의 운영 오버헤드로 저장된 데이터가 최신 상태로 유지되도록 하는 안전하고 간소화되며 신뢰할 수 있는 방법을 제공합니다.

이 작업은 SIG API 머시너리가 주도한 KEP #4192의 일환으로 수행되었습니다.

변경 가능한 볼륨 연결 제한

CSI(Container Storage Interface) 드라이버는 스토리지 시스템을 컨테이너화된 워크로드에 노출하는 일관된 방법을 제공하는 Kubernetes 플러그인입니다. CSINode 오브젝트는 노드에 설치된 모든 CSI 드라이버에 대한 세부 정보를 기록합니다. 그러나 보고된 부착 용량과 실제 노드의 부착 용량 사이에 불일치가 발생할 수 있습니다. CSI 드라이버가 시작된 후 볼륨 슬롯이 소모되면 kube-scheduler는 용량이 충분하지 않은 노드에 스테이트풀 파드를 할당하여 궁극적으로 ContainerCreating 상태에 갇히게 될 수 있습니다.

Kubernetes v1.35는 CSINode.spec.drivers[*].allocatable.count를 변경 가능하게 하여 노드의 사용 가능한 볼륨 부착 용량을 동적으로 업데이트할 수 있도록 합니다. 또한 CSIDriver 오브젝트를 통해 정의된 설정 가능한 새로고침 간격을 도입하여 CSI 드라이버가 모든 노드에서 allocatable.count 값이 업데이트되는 빈도를 제어할 수 있도록 합니다. 또한 용량 부족으로 인한 볼륨 부착 실패를 감지하면 CSINode.spec.drivers[*].allocatable.count를 자동으로 업데이트합니다. 이 기능은 v1.34에서 MutableCSINodeAllocatableCount 기능 플래그가 기본적으로 비활성화된 상태로 베타 단계로 전환되었지만, 피드백 시간을 주기 위해 v1.35에서도 베타 상태로 유지되며 기능 플래그는 기본적으로 활성화됩니다.

이 작업은 SIG 스토리지가 주도한 KEP #4876의 일환으로 수행되었습니다.

기회적 배치(Opportunistic batching)

역사적으로 Kubernetes 스케줄러는 O(파드 수 × 노드 수)의 시간 복잡도로 파드를 순차적으로 처리했으며, 이는 호환 가능한 파드에 대한 중복 계산을 초래할 수 있었습니다. 이 KEP는 파드 스케줄링 시그니처를 통해 호환 가능한 파드를 식별하고 함께 배치하여 공유된 필터링 및 점수 결과를 가능하게 함으로써 성능을 향상시키는 기회적 배치(opportunistic batching) 메커니즘을 도입합니다.

파드 스케줄링 시그니처는 두 파드가 스케줄링 관점에서 "동일"하다는 것을 보장합니다. 이는 파드 및 노드 속성뿐만 아니라 시스템의 다른 파드와 파드 배치에 대한 전역 데이터를 고려합니다. 이는 주어진 시그니처를 가진 모든 파드가 임의의 노드 집합에서 동일한 점수/실행 가능성 결과를 얻을 것임을 의미합니다.

배치 메커니즘은 필요할 때마다 호출할 수 있는 두 가지 작업(생성 및 지명)으로 구성됩니다. 생성은 유효한 시그니처를 가진 파드의 스케줄링 결과로부터 새로운 배치 정보 집합을 생성합니다. 지명은 생성된 배치 정보를 사용하여 시그니처가 정식 파드의 시그니처와 일치하는 새 파드의 지정된 노드 이름을 설정합니다.

이 작업은 SIG 스케줄링이 주도한 KEP #5598의 일환으로 수행되었습니다.

StatefulSet의 maxUnavailable

StatefulSet은 파드 그룹을 실행하고 각 파드에 대한 고정된 아이덴티티를 유지합니다. 이는 안정적인 네트워크 식별자 또는 영구 스토리지가 필요한 스테이트풀 워크로드에 중요합니다. StatefulSet의 .spec.updateStrategy.<type>이 RollingUpdate로 설정되면 StatefulSet 컨트롤러는 StatefulSet의 각 파드를 삭제하고 다시 생성합니다. 이는 파드 종료와 동일한 순서(가장 큰 서수부터 가장 작은 서수까지)로 진행되며, 각 파드를 한 번에 하나씩 업데이트합니다.

Kubernetes v1.24는 StatefulSet의 rollingUpdate 구성 설정에 maxUnavailable이라는 새로운 알파 필드를 추가했습니다. 이 필드는 클러스터 관리자가 명시적으로 선택하지 않는 한 Kubernetes API의 일부가 아니었습니다. Kubernetes v1.35에서는 이 필드가 베타 단계이며 기본적으로 사용할 수 있습니다. 이 필드를 사용하여 업데이트 중 사용할 수 없는 최대 파드 수를 정의할 수 있습니다. 이 설정은 spec.podManagementPolicy가 Parallel로 설정된 경우 가장 효과적입니다. maxUnavailable은 양수(예: 2) 또는 원하는 파드 수의 백분율(예: 10%)로 설정할 수 있습니다. 이 필드가 지정되지 않으면, 한 번에 하나의 파드만 업데이트하는 이전 동작을 유지하기 위해 기본값은 1이 됩니다. 이 개선 사항은 (하나 이상의 파드가 다운되는 것을 허용할 수 있는) 스테이트풀 애플리케이션이 업데이트를 더 빨리 완료할 수 있도록 합니다.

이 작업은 SIG 앱이 주도한 KEP #961의 일환으로 수행되었습니다.

kuberc에서 설정 가능한 자격 증명 플러그인 정책

선택적 kuberc 파일은 이미 실행 중인 CI 파이프라인을 예상치 못한 출력으로 방해하지 않고 서버 구성과 클러스터 자격 증명을 사용자 선호도와 분리하는 방법입니다.

v1.35 릴리스의 일환으로 kuberc는 사용자가 자격 증명 플러그인 정책을 구성할 수 있는 추가 기능을 얻습니다. 이 변경 사항은 모든 플러그인을 허용하거나 거부하는 credentialPluginPolicy와 credentialPluginAllowlist를 사용하여 허용된 플러그인 목록을 지정할 수 있는 기능을 도입합니다.

이 작업은 SIG Auth와 SIG CLI의 협력을 통해 KEP #3104의 일환으로 수행되었습니다.

KYAML

YAML은 사람이 읽을 수 있는 데이터 직렬화 형식입니다. Kubernetes에서는 YAML 파일이 파드, 서비스 및 디플로이먼트와 같은 리소스를 정의하고 구성하는 데 사용됩니다. 그러나 복잡한 YAML은 읽기 어렵습니다. YAML의 중요한 공백은 들여쓰기 및 중첩에 대한 세심한 주의를 필요로 하며, 선택적 문자열 따옴표는 예상치 못한 타입 강제 변환을 유발할 수 있습니다(참고: 노르웨이 버그). JSON이 대안이 될 수 있지만, 주석을 지원하지 않고 후행 쉼표 및 따옴표로 묶인 키에 대한 엄격한 요구 사항을 가지고 있습니다.

KYAML은 Kubernetes를 위해 특별히 설계된 더 안전하고 덜 모호한 YAML 하위 집합입니다. v1.34에서 선택적 알파 기능으로 도입된 이 기능은 Kubernetes v1.35에서 베타 단계로 전환되었으며 기본적으로 활성화됩니다. 환경 변수 KUBECTL_KYAML=false를 설정하여 비활성화할 수 있습니다.

KYAML은 YAML과 JSON 모두와 관련된 문제를 해결합니다. 모든 KYAML 파일은 유효한 YAML 파일이기도 합니다. 이는 KYAML을 작성하고 모든 버전의 kubectl에 입력으로 전달할 수 있음을 의미합니다. 또한 입력을 파싱하기 위해 엄격한 KYAML로 작성할 필요가 없다는 것을 의미합니다.

이 작업은 SIG CLI가 주도한 KEP #5295의 일환으로 수행되었습니다.

HorizontalPodAutoscaler에 대한 설정 가능한 허용 오차

Horizontal Pod Autoscaler (HPA)는 역사적으로 스케일링 동작에 대해 고정된 전역 10% 허용 오차에 의존했습니다. 이 하드코딩된 값의 단점은 5% 로드 증가 시 스케일링이 필요한 것과 같이 높은 민감도를 요구하는 워크로드가 스케일링되지 않는 경우가 많았고, 다른 워크로드는 불필요하게 진동할 수 있었다는 것입니다.

Kubernetes v1.35에서는 설정 가능한 허용 오차 기능이 베타 단계로 전환되고 기본적으로 활성화됩니다. 이 개선 사항을 통해 사용자는 HPA behavior 필드 내에서 리소스별 맞춤형 허용 오차 범위(tolerance window)를 정의할 수 있습니다. 특정 허용 오차(예: 5%에 대해 0.05로 낮춤)를 설정함으로써 운영자는 오토스케일링 민감도에 대한 정밀한 제어를 얻을 수 있으며, 중요한 워크로드가 클러스터 전체 구성 조정을 필요로 하지 않고 작은 메트릭 변경에 신속하게 반응하도록 보장합니다.

이 작업은 SIG 오토스케일링이 주도한 KEP #4951의 일환으로 수행되었습니다.

파드의 사용자 네임스페이스 지원

Kubernetes는 사용자 네임스페이스 지원을 추가하여, 파드가 호스트 ID를 공유하는 대신 격리된 사용자 및 그룹 ID 매핑으로 실행될 수 있도록 합니다. 이는 컨테이너가 내부적으로는 루트로 작동하지만 실제로는 호스트의 비특권 사용자에 매핑되어, 침해 발생 시 권한 에스컬레이션 위험을 줄인다는 것을 의미합니다. 이 기능은 파드 수준 보안을 향상하고 컨테이너 내에서 루트가 필요한 워크로드를 더 안전하게 실행할 수 있도록 합니다. 시간이 지남에 따라 ID 매핑 마운트를 통해 스테이트리스 및 스테이트풀 파드 모두에 대한 지원이 확장되었습니다.

이 작업은 SIG 노드가 주도한 KEP #127의 일환으로 수행되었습니다.

VolumeSource: OCI 아티팩트 및/또는 이미지

파드를 생성할 때 컨테이너에 데이터, 바이너리 또는 구성 파일을 제공해야 하는 경우가 많습니다. 이는 콘텐츠를 메인 컨테이너 이미지에 포함하거나 사용자 정의 init 컨테이너를 사용하여 파일을 다운로드하고 emptyDir에 압축 해제하는 것을 의미했습니다. 이 두 가지 접근 방식은 여전히 유효합니다. Kubernetes v1.31은 image 볼륨 유형에 대한 지원을 추가하여 파드가 OCI 컨테이너 이미지 아티팩트를 볼륨으로 선언적으로 풀고 압축 해제할 수 있도록 했습니다. 이를 통해 표준 OCI 레지스트리 도구를 사용하여 구성, 바이너리 또는 머신러닝 모델과 같은 데이터 전용 아티팩트를 패키징하고 전달할 수 있습니다.

이 기능을 통해 데이터와 컨테이너 이미지를 완전히 분리하고 추가 init 컨테이너나 시작 스크립트가 필요 없게 됩니다. 이미지 볼륨 유형은 v1.33부터 베타 상태였으며 v1.35에서 기본적으로 활성화됩니다. 이 기능을 사용하려면 containerd v2.1 이상과 같은 호환 가능한 컨테이너 런타임이 필요하다는 점에 유의하십시오.

이 작업은 SIG 노드가 주도한 KEP #4639의 일환으로 수행되었습니다.

캐시된 이미지에 대한 kubelet 자격 증명 확인 강제 적용

imagePullPolicy: IfNotPresent 설정은 현재 파드에 해당 이미지를 풀 자격 증명이 없더라도 파드가 노드에 이미 캐시된 컨테이너 이미지를 사용할 수 있도록 합니다. 이 동작의 단점은 멀티테넌트 클러스터에서 보안 취약점을 생성한다는 것입니다. 유효한 자격 증명을 가진 파드가 민감한 프라이빗 이미지를 노드에 풀면, 동일한 노드의 후속 무단 파드가 로컬 캐시에 의존하여 해당 이미지에 단순히 액세스할 수 있습니다.

이 KEP는 kubelet이 캐시된 이미지에 대한 자격 증명 확인을 강제하는 메커니즘을 도입합니다. kubelet은 파드가 로컬에 캐시된 이미지를 사용하도록 허용하기 전에, 파드에 해당 이미지를 풀 유효한 자격 증명이 있는지 확인합니다. 이는 노드에 이미 존재하는지 여부와 관계없이 승인된 워크로드만 프라이빗 이미지를 사용할 수 있도록 보장하여 공유 클러스터의 보안 상태를 크게 강화합니다.

Kubernetes v1.35에서는 이 기능이 베타 단계로 전환되고 기본적으로 활성화됩니다. 사용자는 KubeletEnsureSecretPulledImages 기능 게이트를 false로 설정하여 여전히 비활성화할 수 있습니다. 또한 imagePullCredentialsVerificationPolicy 플래그는 운영자가 원하는 보안 수준을 구성할 수 있도록 하며, 하위 호환성을 우선하는 모드부터 최대 보안을 제공하는 엄격한 적용 모드까지 다양합니다.

이 작업은 SIG 노드가 주도한 KEP #2535의 일환으로 수행되었습니다.

세분화된 컨테이너 재시작 규칙

역사적으로 restartPolicy 필드는 엄격하게 파드 수준에서 정의되어 파드 내의 모든 컨테이너에 동일한 동작을 강제했습니다. 이 전역 설정의 단점은 AI/ML 훈련 작업과 같은 복잡한 워크로드에 대한 세분성 부족이었습니다. 이러한 작업은 종종 작업 완료를 관리하기 위해 파드에 restartPolicy: Never를 필요로 했지만, 개별 컨테이너는 특정 재시도 가능한 오류(예: 네트워크 글리치 또는 GPU 초기화 실패)에 대해 인플레이스 재시작으로 이점을 얻을 수 있었습니다.

Kubernetes v1.35는 컨테이너 API 자체 내에서 restartPolicy 및 restartPolicyRules를 활성화하여 이 문제를 해결합니다. 이를 통해 사용자는 파드의 전체 정책과 독립적으로 작동하는 개별 정규 및 init 컨테이너에 대한 재시작 전략을 정의할 수 있습니다. 예를 들어, 이제 컨테이너는 특정 오류 코드로 종료되는 경우에만 자동으로 재시작하도록 구성할 수 있어, 일시적인 실패로 인해 전체 파드를 재스케줄링하는 높은 오버헤드를 피할 수 있습니다.

이번 릴리스에서는 이 기능이 베타 단계로 전환되고 기본적으로 활성화됩니다. 사용자는 컨테이너 사양에서 restartPolicyRules를 즉시 활용하여 장기 실행 워크로드의 복구 시간과 리소스 활용을 최적화할 수 있으며, 파드의 더 넓은 수명 주기 로직을 변경할 필요가 없습니다.

이 작업은 SIG 노드가 주도한 KEP #5307의 일환으로 수행되었습니다.

시크릿 필드를 통한 CSI 드라이버의 서비스 계정 토큰 옵트인

Container Storage Interface (CSI) 드라이버에 서비스 계정 토큰을 제공하는 것은 전통적으로 volume_context 필드에 토큰을 주입하는 방식에 의존했습니다. 이 접근 방식은 volume_context가 민감하지 않은 구성 데이터를 위한 것이며 드라이버 및 디버깅 도구에 의해 일반 텍스트로 자주 로깅되어 자격 증명이 유출될 가능성이 있다는 점에서 심각한 보안 위험을 초래합니다.

Kubernetes v1.35는 CSI 드라이버가 NodePublishVolume 요청의 전용 시크릿 필드를 통해 서비스 계정 토큰을 수신하도록 하는 옵트인 메커니즘을 도입합니다. 드라이버는 이제 CSIDriver 오브젝트에서 serviceAccountTokenInSecrets 필드를 true로 설정하여 kubelet이 토큰을 안전하게 채우도록 지시함으로써 이 동작을 활성화할 수 있습니다.

주요 이점은 로그 및 오류 메시지에서 의도치 않은 자격 증명 노출을 방지하는 것입니다. 이 변경 사항은 민감한 워크로드 아이덴티티가 적절한 보안 채널을 통해 처리되도록 보장하며, 기존 드라이버와의 하위 호환성을 유지하면서 시크릿 관리의 모범 사례에 부합합니다.

이 작업은 SIG Auth와 SIG 스토리지가 협력하여 KEP #5538의 일환으로 수행되었습니다.

디플로이먼트 상태: 종료 중인 레플리카 수

역사적으로 디플로이먼트 상태는 사용 가능한 및 업데이트된 레플리카에 대한 세부 정보를 제공했지만, 종료 중인 파드에 대한 명시적인 가시성은 부족했습니다. 이 누락의 단점은 사용자 및 컨트롤러가 안정적인 디플로이먼트와 여전히 정리 작업을 실행하거나 긴 유예 기간을 준수하는 파드를 가진 디플로이먼트를 쉽게 구분할 수 없었다는 것입니다.

Kubernetes v1.35는 디플로이먼트 상태 내의 terminatingReplicas 필드를 베타 단계로 승격시킵니다. 이 필드는 삭제 타임스탬프가 설정되었지만 시스템에서 아직 제거되지 않은 파드의 수를 제공합니다. 이 기능은 디플로이먼트가 파드 교체를 처리하는 방법을 개선하기 위한 더 큰 이니셔티브의 기초 단계이며, 롤아웃 중에 새 파드를 생성할 시기에 대한 향후 정책의 기반을 마련합니다.

주요 이점은 수명 주기 관리 도구 및 운영자의 가시성이 향상된다는 것입니다. 종료 중인 파드의 수를 노출함으로써 외부 시스템은 이제 개별 파드 목록을 수동으로 쿼리하고 필터링할 필요 없이 후속 작업을 진행하기 전에 완전한 종료를 기다리는 것과 같은 더 많은 정보를 바탕으로 결정을 내릴 수 있습니다.

이 작업은 SIG 앱이 주도한 KEP #3973의 일환으로 수행되었습니다.

알파 단계의 새로운 기능

다음은 v1.35 릴리스 이후 알파 단계로 전환된 개선 사항 중 일부입니다.

Kubernetes의 갱 스케줄링 지원

AI/ML 훈련 작업 또는 HPC 시뮬레이션과 같은 상호 의존적인 워크로드 스케줄링은 기본 Kubernetes 스케줄러가 파드를 개별적으로 배치하기 때문에 전통적으로 어려웠습니다. 이는 종종 일부 파드가 시작되는 동안 다른 파드는 리소스를 무기한 기다리게 되는 부분 스케줄링으로 이어져 교착 상태 및 클러스터 용량 낭비를 초래했습니다.

Kubernetes v1.35는 새로운 워크로드 API 및 PodGroup 개념을 통해 소위 "갱 스케줄링"에 대한 네이티브 지원을 도입합니다. 이 기능은 "전체 또는 전무(all-or-nothing)" 스케줄링 전략을 구현하여, 정의된 파드 그룹이 클러스터가 전체 그룹을 동시에 수용할 충분한 리소스를 가지고 있는 경우에만 스케줄링되도록 합니다.

주요 이점은 배치 및 병렬 워크로드의 안정성과 효율성이 향상된다는 것입니다. 부분 배포를 방지함으로써 리소스 교착 상태를 제거하고, 완전한 작업이 실행될 수 있을 때만 값비싼 클러스터 용량이 활용되도록 보장하여 대규모 데이터 처리 작업의 오케스트레이션을 크게 최적화합니다.

이 작업은 SIG 스케줄링이 주도한 KEP #4671의 일환으로 수행되었습니다.

제약된 가장

역사적으로 Kubernetes RBAC의 impersonate 동사는 전체 또는 전무(all-or-nothing) 방식으로 작동했습니다. 즉, 사용자가 대상 아이덴티티를 가장하도록 승인되면 모든 관련 권한을 얻었습니다. 이 광범위한 권한 부여의 단점은 최소 권한 원칙을 위반하여 관리자가 가장하는 사람을 특정 작업이나 리소스로 제한하는 것을 방지했다는 것입니다.

Kubernetes v1.35는 가장 흐름에 보조 인증 검사를 추가하는 새로운 알파 기능인 제약된 가장을 도입합니다. ConstrainedImpersonation 기능 게이트를 통해 활성화되면 API 서버는 기본 impersonate 권한뿐만 아니라 가장하는 사람이 새로운 동사 접두사(예: impersonate-on:<모드>:<동사>)를 사용하여 특정 작업에 대해 승인되었는지도 확인합니다. 이를 통해 관리자는 지원 엔지니어가 클러스터 관리자를 가장하여 로그만 볼 수 있도록 허용하고 전체 관리자 액세스를 부여하지 않는 것과 같은 세분화된 정책을 정의할 수 있습니다.

이 작업은 SIG Auth가 주도한 KEP #5284의 일환으로 수행되었습니다.

Kubernetes 구성 요소의 Flagz

API 서버 또는 kubelet과 같은 Kubernetes 구성 요소의 런타임 구성을 확인하는 것은 전통적으로 호스트 노드 또는 프로세스 인수에 대한 특권 접근을 필요로 했습니다. 이를 해결하기 위해 /flagz 엔드포인트가 HTTP를 통해 명령줄 옵션을 노출하도록 도입되었습니다. 그러나 초기 출력은 일반 텍스트로 제한되어 자동화된 도구가 구성을 안정적으로 파싱하고 유효성을 검사하기 어려웠습니다.

Kubernetes v1.35에서는 /flagz 엔드포인트가 구조화되고 기계 판독 가능한 JSON 출력을 지원하도록 향상되었습니다. 승인된 사용자는 이제 표준 HTTP 콘텐츠 협상을 사용하여 버전이 지정된 JSON 응답을 요청할 수 있으며, 원래의 일반 텍스트 형식은 사람의 검사를 위해 계속 사용할 수 있습니다. 이 업데이트는 가시성 및 규정 준수 워크플로우를 크게 개선하여 외부 시스템이 취약한 텍스트 파싱이나 직접적인 인프라 접근 없이 구성 요소 구성을 프로그램적으로 감사할 수 있도록 합니다.

이 작업은 SIG Instrumentation이 주도한 KEP #4828의 일환으로 수행되었습니다.

Kubernetes 구성 요소의 Statusz

kube-apiserver 또는 kubelet과 같은 Kubernetes 구성 요소의 문제 해결은 전통적으로 구조화되지 않은 로그 또는 텍스트 출력을 파싱하는 것을 포함했으며, 이는 취약하고 자동화하기 어려웠습니다. 이전에 기본 /statusz 엔드포인트가 존재했지만, 표준화된 기계 판독 가능한 형식이 부족하여 외부 모니터링 시스템의 유용성을 제한했습니다.

Kubernetes v1.35에서는 /statusz 엔드포인트가 구조화되고 기계 판독 가능한 JSON 출력을 지원하도록 향상되었습니다. 승인된 사용자는 이제 표준 HTTP 콘텐츠 협상을 사용하여 이 형식을 요청하여 버전 정보 및 상태 지표와 같은 정확한 상태 데이터를 취약한 텍스트 파싱에 의존하지 않고 검색할 수 있습니다. 이 개선 사항은 모든 핵심 구성 요소에 걸쳐 자동화된 디버깅 및 가시성 도구를 위한 안정적이고 일관된 인터페이스를 제공합니다.

이 작업은 SIG Instrumentation이 주도한 KEP #4827의 일환으로 수행되었습니다.

CCM: 인포머를 사용한 워치 기반 라우트 컨트롤러 조정

클라우드 환경 내에서 네트워크 라우트를 관리하는 것은 전통적으로 Cloud Controller Manager (CCM)가 클라우드 제공업체의 API를 주기적으로 폴링하여 라우트 테이블을 확인하고 업데이트하는 방식에 의존했습니다. 이 고정 간격 조정 방식은 비효율적일 수 있으며, 종종 많은 양의 불필요한 API 호출을 생성하고 노드 상태 변경과 해당 라우트 업데이트 사이에 지연 시간을 초래합니다.

Kubernetes v1.35 릴리스를 위해 클라우드 컨트롤러 매니저 라이브러리는 라우트 컨트롤러를 위한 워치 기반 조정 전략을 도입합니다. 컨트롤러는 타이머에 의존하는 대신 인포머를 활용하여 추가, 삭제 또는 관련 필드 업데이트와 같은 특정 노드 이벤트를 감시하고, 실제로 변경이 발생할 때만 라우트 동기화를 트리거합니다.

주요 이점은 클라우드 제공업체 API 사용량이 크게 줄어들어 속도 제한에 도달할 위험이 낮아지고 운영 오버헤드가 감소한다는 것입니다. 또한 이 이벤트 기반 모델은 클러스터 토폴로지 변경 후 라우트 테이블이 즉시 업데이트되도록 보장하여 클러스터 네트워킹 레이어의 응답성을 향상시킵니다.

이 작업은 SIG Cloud Provider가 주도한 KEP #5237의 일환으로 수행되었습니다.

임계값 기반 배치에 대한 확장된 톨러레이션 연산자

Kubernetes v1.35는 워크로드가 안정성 요구 사항을 표현할 수 있도록 하여 SLA 인식 스케줄링을 도입합니다. 이 기능은 톨러레이션에 숫자 비교 연산자를 추가하여 파드가 서비스 보증 또는 장애 도메인 품질과 같은 SLA 지향 테인트(taint)를 기반으로 노드를 일치시키거나 피할 수 있도록 합니다.

주요 이점은 스케줄러의 더 정확한 배치를 통해 향상된다는 것입니다. 중요한 워크로드는 더 높은 SLA 노드를 요구할 수 있으며, 우선 순위가 낮은 워크로드는 더 낮은 SLA 노드를 선택할 수 있습니다. 이는 안정성을 저하시키지 않고 활용률을 높이고 비용을 절감합니다.

이 작업은 SIG 스케줄링이 주도한 KEP #5471의 일환으로 수행되었습니다.

Job이 일시 중단된 경우 변경 가능한 컨테이너 리소스

배치 워크로드를 실행하는 것은 종종 리소스 제한에 대한 시행착오를 포함합니다. 현재 Job 사양은 변경 불가능하므로, Job이 메모리 부족(OOM) 오류 또는 불충분한 CPU로 인해 실패하는 경우 사용자는 단순히 리소스를 조정할 수 없습니다. Job을 삭제하고 새 Job을 생성해야 하며, 실행 기록과 상태를 잃게 됩니다.

Kubernetes v1.35는 정지 상태에 있는 Job의 리소스 요청 및 제한을 업데이트하는 기능을 도입합니다. MutablePodResourcesForSuspendedJobs 기능 게이트를 통해 활성화되는 이 개선 사항을 통해 사용자는 실패한 Job을 일시 중지하고, 적절한 리소스 값으로 파드 템플릿을 수정한 다음, 수정된 구성으로 실행을 재개할 수 있습니다.

주요 이점은 잘못 구성된 Job의 더 원활한 복구 워크플로우입니다. 일시 중단 중에 인플레이스 수정이 가능하게 함으로써, 사용자는 Job의 수명 주기 아이덴티티를 방해하거나 완료 상태를 잃지 않고 리소스 병목 현상을 해결할 수 있어 배치 처리의 개발자 경험을 크게 향상시킵니다.

이 작업은 SIG 앱이 주도한 KEP #5440의 일환으로 수행되었습니다.

기타 주목할 만한 변경 사항

동적 리소스 할당(DRA)의 지속적인 혁신

핵심 기능은 v1.34에서 안정화 단계로 전환되었으며, 비활성화할 수 있는 기능이 있었습니다. v1.35에서는 항상 활성화됩니다. 여러 알파 기능도 크게 개선되었으며 테스트 준비가 완료되었습니다. 다가오는 릴리스에서 베타로 승격하는 길을 열 수 있도록 이러한 기능에 대한 피드백을 제공해 주시기를 권장합니다.

DRA를 통한 확장 리소스 요청

디바이스 플러그인을 통한 확장 리소스 요청과 비교했을 때 여러 기능적 격차(예: init 컨테이너에서 장치 점수 매기기 및 재사용)가 해결되었습니다.

장치 테인트(Taint) 및 톨러레이션(Toleration)

새로운 "None" 효과는 스케줄링이나 실행 중인 파드에 즉시 영향을 주지 않고 문제를 보고하는 데 사용될 수 있습니다. DeviceTaintRule은 이제 진행 중인 축출에 대한 상태 정보를 제공합니다. "None" 효과는 실제로 파드를 축출하기 전에 "테스트 실행"을 위해 사용될 수 있습니다.

  • effect: None으로 DeviceTaintRule 생성.
  • 상태를 확인하여 몇 개의 파드가 축출될지 확인.
  • effect: None을 effect: NoExecute로 교체.

분할 가능한 장치

이제 동일한 분할 가능한 장치에 속하는 장치를 다른 ResourceSlice에 정의할 수 있습니다. 자세한 내용은 공식 문서에서 확인할 수 있습니다.

소비 가능한 용량, 장치 바인딩 조건

여러 버그가 수정되거나 추가 테스트가 추가되었습니다. 소비 가능한 용량 및 장치 바인딩 조건에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다.

비교 가능한 리소스 버전 의미론

Kubernetes v1.35는 클라이언트가 리소스 버전을 해석할 수 있는 방식을 변경합니다.

v1.35 이전에는 클라이언트가 수행할 수 있는 유일한 지원 비교는 문자열 동등성 확인이었습니다. 두 리소스 버전이 같으면 동일한 것이었습니다. 클라이언트는 또한 API 서버에 리소스 버전을 제공하고 컨트롤 플레인에 특정 리소스 버전 이후의 모든 이벤트를 스트리밍하는 것과 같은 내부 비교를 수행하도록 요청할 수 있었습니다.

v1.35에서는 모든 인-트리 리소스 버전이 새로운 더 엄격한 정의를 충족합니다. 값은 특수한 형태의 십진수입니다. 그리고 비교할 수 있기 때문에 클라이언트는 두 개의 다른 리소스 버전을 비교하는 자체 작업을 수행할 수 있습니다. 예를 들어, 이는 크래시 후 재연결하는 클라이언트가 업데이트가 있었지만 그동안 손실된 변경 사항이 없는 경우와 구별하여 업데이트 손실 시점을 감지할 수 있음을 의미합니다.

이 의미론의 변경은 스토리지 버전 마이그레이션, 인포머(클라이언트 헬퍼 개념)의 성능 개선, 컨트롤러 안정성과 같은 다른 중요한 사용 사례를 가능하게 합니다. 이러한 모든 경우에 한 리소스 버전이 다른 리소스 버전보다 최신인지 여부를 아는 것이 필요합니다.

이 작업은 SIG API 머시너리가 주도한 KEP #5504의 일환으로 수행되었습니다.

v1.35의 안정화, 폐지 및 제거

안정화 단계로 전환

다음은 안정화(정식 출시) 단계로 전환된 모든 기능 목록입니다. 새로운 기능 및 알파에서 베타로의 전환을 포함한 전체 업데이트 목록은 릴리스 노트를 참조하십시오.

이번 릴리스에는 총 15개의 개선 사항이 안정화 단계로 승격되었습니다.

폐지, 제거 및 커뮤니티 업데이트

Kubernetes가 개발되고 성숙해짐에 따라 프로젝트의 전반적인 건전성을 개선하기 위해 기능이 폐지, 제거 또는 더 나은 기능으로 대체될 수 있습니다. 이 프로세스에 대한 자세한 내용은 Kubernetes 폐지 및 제거 정책을 참조하십시오. Kubernetes v1.35에는 몇 가지 폐지 사항이 포함되어 있습니다.

Ingress NGINX 중단

수년 동안 Ingress NGINX 컨트롤러는 Kubernetes 클러스터로 트래픽을 라우팅하는 데 널리 사용되었습니다. 유연하고 널리 채택되었으며 수많은 애플리케이션의 표준 진입점 역할을 했습니다.

그러나 프로젝트를 유지 관리하는 것이 지속 불가능해졌습니다. 유지보수 담당자의 심각한 부족과 기술 부채 증가로 인해 커뮤니티는 최근 이를 중단하기로 어려운 결정을 내렸습니다. 이는 v1.35 릴리스의 엄격한 일부는 아니지만, 매우 중요한 변경 사항이므로 여기에 강조하고자 합니다.

결과적으로 Kubernetes 프로젝트는 Ingress NGINX가 2026년 3월까지 최선을 다하는 유지보수만 받을 것이라고 발표했습니다. 이 날짜 이후에는 더 이상 업데이트 없이 보관될 예정입니다. 권장되는 방법은 트래픽 관리를 위한 보다 현대적이고 안전하며 확장 가능한 표준을 제공하는 Gateway API로 마이그레이션하는 것입니다.

자세한 내용은 공식 블로그 게시물에서 확인할 수 있습니다.

cgroup v1 지원 제거

Linux 노드에서 리소스를 관리하는 데 있어 Kubernetes는 역사적으로 cgroups(컨트롤 그룹)에 의존해 왔습니다. 원래 cgroup v1은 기능적이었지만 종종 일관성이 없고 제한적이었습니다. 이것이 Kubernetes가 v1.25에서 cgroup v2 지원을 도입하여 훨씬 더 깨끗하고 통합된 계층 구조와 더 나은 리소스 격리를 제공한 이유입니다.

cgroup v2는 이제 현대 표준이므로 Kubernetes는 v1.35에서 레거시 cgroup v1 지원을 중단할 준비가 되었습니다. 이는 클러스터 관리자에게 중요한 공지입니다. cgroup v2를 지원하지 않는 이전 Linux 배포판에서 노드를 계속 실행하는 경우 kubelet이 시작되지 않을 것입니다. 가동 중지 시간을 피하려면 해당 노드를 cgroup v2가 활성화된 시스템으로 마이그레이션해야 합니다.

자세한 내용은 cgroup v2에 대해 읽어보십시오. 또한 KEP-5573: cgroup v1 지원 제거를 통해 전환 작업을 추적할 수 있습니다.

kube-proxy에서 ipvs 모드 폐지

수년 전 Kubernetes는 표준 iptables보다 더 빠른 로드 밸런싱을 제공하기 위해 kube-proxy에서 ipvs 모드를 채택했습니다. 성능 향상을 제공했지만, 진화하는 네트워킹 요구 사항과 동기화 상태를 유지하는 것이 너무 많은 기술 부채와 복잡성을 야기했습니다.

이러한 유지보수 부담 때문에 Kubernetes v1.35는 ipvs 모드를 폐지합니다. 이 모드는 이번 릴리스에서 계속 사용할 수 있지만, kube-proxy는 이제 이를 사용하도록 구성되면 시작 시 경고 메시지를 출력합니다. 목표는 코드베이스를 간소화하고 현대 표준에 집중하는 것입니다. Linux 노드의 경우 이제 권장되는 대체 방식인 nftables로 전환을 시작해야 합니다.

자세한 내용은 KEP-5495: kube-proxy의 ipvs 모드 폐지에서 확인할 수 있습니다.

containerd v1.X에 대한 최종 호출

Kubernetes v1.35는 containerd 1.7 및 기타 LTS 릴리스를 여전히 지원하지만, 이는 이러한 지원을 포함하는 마지막 버전입니다. SIG Node 커뮤니티는 v1.35를 containerd v1.X 시리즈를 지원하는 마지막 릴리스로 지정했습니다.

이는 중요한 알림입니다. 다음 Kubernetes 버전으로 업그레이드하기 전에 containerd 2.0 이상으로 전환해야 합니다. 어떤 노드에 주의가 필요한지 식별하는 데 도움이 되도록 클러스터 내에서 kubelet_cri_losing_support 메트릭을 모니터링할 수 있습니다.

자세한 내용은 공식 블로그 게시물 또는 KEP-4033: CRI에서 cgroup 드라이버 검색에서 확인할 수 있습니다.

kubelet 재시작 중 파드 안정성 향상

이전에는 kubelet 서비스를 다시 시작하면 종종 파드 상태에 일시적인 중단이 발생했습니다. 다시 시작하는 동안 kubelet은 컨테이너 상태를 재설정하여, 애플리케이션 자체가 여전히 올바르게 실행 중이더라도 정상적인 파드가 NotReady로 표시되고 로드 밸런서에서 제거되도록 했습니다.

이러한 안정성 문제를 해결하기 위해 이 동작이 수정되어 원활한 노드 유지보수를 보장합니다. kubelet은 이제 시작 시 런타임에서 기존 컨테이너의 상태를 올바르게 복원합니다. 이는 kubelet 재시작 또는 업그레이드 중에도 워크로드가 Ready 상태를 유지하고 트래픽이 중단 없이 계속 흐르도록 보장합니다.

자세한 내용은 KEP-4781: kubelet 재시작 후 컨테이너 준비 상태 불일치 수정에서 확인할 수 있습니다.

릴리스 노트

릴리스 노트에서 Kubernetes v1.35 릴리스의 전체 세부 정보를 확인하십시오.

가용성

Kubernetes v1.35는 GitHub 또는 Kubernetes 다운로드 페이지에서 다운로드할 수 있습니다.

Kubernetes를 시작하려면 대화형 튜토리얼을 확인하거나 minikube를 사용하여 로컬 Kubernetes 클러스터를 실행하십시오. kubeadm을 사용하여 v1.35를 쉽게 설치할 수도 있습니다.

릴리스 팀

Kubernetes는 커뮤니티의 지원, 헌신, 노고가 있어야만 가능합니다. 각 릴리스 팀은 여러분이 의존하는 Kubernetes 릴리스를 구성하는 많은 부분을 만들기 위해 함께 일하는 헌신적인 커뮤니티 자원봉사자들로 구성됩니다. 이는 코드 자체부터 문서화 및 프로젝트 관리에 이르기까지 커뮤니티의 모든 분야에서 온 사람들의 전문 기술을 필요로 합니다.

저희는 한강 님의 고귀한 정신을 기립니다. 한강 님은 오랫동안 기여하고 존경받는 엔지니어로서, 그의 기술적 우수성과 전염성 있는 열정은 Kubernetes 커뮤니티에 지속적인 영향을 미쳤습니다. 한강 님은 SIG Instrumentation과 SIG API 머시너리에서 중요한 역할을 담당했으며, 프로젝트의 핵심 안정성에 대한 그의 중요한 작업과 지속적인 헌신으로 2021년 Kubernetes 기여자상을 수상했습니다. 기술적 기여 외에도 한강 님은 멘토로서의 너그러움과 사람들 사이의 연결을 구축하려는 열정으로 깊이 존경받았습니다. 그는 새로운 기여자들이 첫 번째 풀 리퀘스트를 통해 안내하거나 인내와 친절로 동료들을 지원하는 등 다른 사람들에게 "기회의 문을 열어주는" 것으로 알려져 있었습니다. 한강 님의 유산은 그가 영감을 준 엔지니어들, 그가 구축을 도운 견고한 시스템, 그리고 그가 클라우드 네이티브 생태계 내에서 조성한 따뜻하고 협력적인 정신을 통해 계속 살아 숨 쉬고 있습니다.

릴리스 팀 전체에 이번 Kubernetes v1.35 릴리스를 저희 커뮤니티에 제공하기 위해 열심히 노력한 시간에 대해 감사드립니다. 릴리스 팀의 구성원은 첫 그림자(shadow)부터 여러 릴리스 주기 동안 경험을 쌓은 복귀 팀 리더에 이르기까지 다양합니다. 저희는 릴리스 리더인 드루 헤이건(Drew Hagen)에게 깊은 감사를 표합니다. 그의 실질적인 지도와 활기찬 에너지는 복잡한 과제를 헤쳐나갈 뿐만 아니라 이 성공적인 릴리스를 뒷받침하는 커뮤니티 정신에 불을 지폈습니다.

프로젝트 속도

CNCF K8s DevStats 프로젝트는 Kubernetes 및 다양한 서브 프로젝트의 속도와 관련된 여러 흥미로운 데이터 포인트를 집계합니다. 여기에는 개별 기여부터 기여하는 회사 수까지 모든 것이 포함되며, 이 생태계를 발전시키는 데 들어가는 노력의 깊이와 폭을 보여줍니다.

2025년 9월 15일부터 2025년 12월 17일까지 14주 동안 진행된 v1.35 릴리스 주기 동안 Kubernetes는 85개 회사와 419명의 개인으로부터 기여를 받았습니다. 더 넓은 클라우드 네이티브 생태계에서는 이 수치가 281개 회사, 총 1769명의 기여자로 증가합니다.

"기여"는 누군가가 커밋, 코드 검토, 댓글 작성, 이슈 또는 PR 생성, PR 검토(블로그 및 문서 포함) 또는 이슈 및 PR에 대한 댓글 작성을 할 때를 의미합니다. 기여에 관심이 있다면 기여자 웹사이트의 시작하기를 방문하십시오.

이 데이터의 출처:

이벤트 업데이트

KubeCon + CloudNativeCon, KCD 및 전 세계의 다른 주목할 만한 컨퍼런스를 포함하여 예정된 Kubernetes 및 클라우드 네이티브 이벤트를 살펴보십시오. 최신 정보를 얻고 Kubernetes 커뮤니티에 참여하십시오!

2026년 2월

2026년 3월

2026년 5월

2026년 6월

2026년 7월

최신 이벤트 세부 정보는 여기에서 확인할 수 있습니다. ​

예정된 릴리스 웨비나

**2026년 1월 14일 수요일 오후 5시 (UTC)**에 Kubernetes v1.35 릴리스 팀원들과 함께 이번 릴리스의 주요 내용을 알아보세요. 자세한 정보 및 등록은 CNCF 온라인 프로그램 사이트의 이벤트 페이지를 방문하십시오.

참여하기

Kubernetes에 참여하는 가장 간단한 방법은 관심사에 맞는 다양한 Special Interest Groups(SIGs) 중 하나에 가입하는 것입니다. Kubernetes 커뮤니티에 알리고 싶은 것이 있으신가요? 주간 커뮤니티 미팅과 아래 채널을 통해 여러분의 의견을 공유해 주세요. 지속적인 피드백과 지원에 감사드립니다.

  • 최신 업데이트를 받으려면 Bluesky @Kubernetesio를 팔로우하세요.
  • Discuss에서 커뮤니티 토론에 참여하세요.
  • Slack에서 커뮤니티에 참여하세요.
  • Stack Overflow에 질문을 게시하거나 질문에 답변하세요.
  • Kubernetes 이야기를 공유하세요.
  • 블로그에서 Kubernetes에 대한 더 많은 소식을 읽어보세요.
  • Kubernetes 릴리스 팀에 대해 자세히 알아보세요.