Kubernetes v1.35 릴리스가 다가옴에 따라, Kubernetes 프로젝트는 계속해서 발전하고 있습니다. 프로젝트의 전반적인 건전성을 개선하기 위해 기능이 더 이상 사용되지 않거나(deprecated), 제거되거나, 교체될 수 있습니다. 이 블로그 게시물은 Kubernetes 클러스터의 지속적인 원활한 운영을 보장하고 최신 개발 상황을 파악하기 위해 릴리스 팀이 알아두어야 한다고 생각하는 v1.35 릴리스의 예정된 변경 사항을 간략하게 설명합니다. 아래 정보는 v1.35 릴리스의 현재 상태를 기반으로 하며 최종 릴리스 날짜 이전에 변경될 수 있습니다.
Kubernetes v1.35의 사용 중단 및 제거 사항
cgroup v1 지원
Linux 노드에서 컨테이너 런타임은 일반적으로 cgroup(‘컨트롤 그룹’의 약자)에 의존합니다. cgroup v2 사용에 대한 지원은 Kubernetes v1.25부터 안정화되어, 기존 v1 cgroup 지원에 대한 대안을 제공했습니다. cgroup v1은 초기 리소스 제어 메커니즘을 제공했지만, 잘 알려진 불일치와 한계가 있었습니다. cgroup v2 지원 추가는 통합된 컨트롤 그룹 계층 구조를 사용하고, 리소스 격리를 개선하며, 최신 기능의 기반이 되어 레거시 cgroup v1 지원을 제거할 준비를 마쳤습니다. cgroup v1 지원 제거는 cgroup v2를 지원하지 않는 오래된 Linux 배포판에서 노드를 실행하는 클러스터 관리자에게만 영향을 미치며, 해당 노드에서는 kubelet이 시작되지 않습니다. 관리자는 노드를 cgroup v2가 활성화된 시스템으로 마이그레이션해야 합니다. 호환성 요구 사항에 대한 자세한 내용은 v1.35 릴리스 직후 블로그 게시물에서 확인할 수 있습니다.
더 자세한 내용은 cgroup v2에 대해 읽어보세요;
KEP-5573: cgroup v1 지원 제거를 통해 전환 작업을 추적할 수도 있습니다.
kube-proxy의 ipvs 모드 사용 중단
오래 전 릴리스에서 Kubernetes 프로젝트는 kube-proxy에 ipvs 모드를 구현했습니다. 이는 기존 iptables 모드보다 더 나은 성능으로 고성능 서비스 로드 밸런싱을 제공하는 방법으로 채택되었습니다. 그러나 기술적 복잡성과 요구 사항의 차이로 인해 ipvs와 다른 kube-proxy 모드 간의 기능 동등성을 유지하는 것이 어려워졌습니다. 이로 인해 상당한 기술 부채가 발생했으며 ipvs 백엔드는 최신 네트워킹 기능과 함께 지원하기에 비실용적이 되었습니다.
Kubernetes 프로젝트는 kube-proxy 코드베이스를 간소화하기 위해 v1.35 릴리스에서 kube-proxy ipvs 모드를 사용 중단할 예정입니다. Linux 노드의 경우 권장되는 kube-proxy 모드는 이미 nftables입니다.
KEP-5495: kube-proxy에서 ipvs 모드 사용 중단에서 더 많은 정보를 찾을 수 있습니다.
Kubernetes가 containerd v1.y 지원을 중단합니다
Kubernetes v1.35는 containerd 1.7 및 기타 containerd LTS 릴리스를 여전히 지원하지만, 자동 cgroup 드라이버 감지의 결과로 Kubernetes SIG Node 커뮤니티는 containerd v1.X에 대한 최종 지원 타임라인에 공식적으로 동의했습니다. Kubernetes v1.35는 (containerd 1.7 EOL에 맞춰) 이 지원을 제공하는 마지막 릴리스입니다.
이는 containerd 1.X를 사용하고 있다면 다음 버전으로 Kubernetes를 업그레이드하기 전에 2.0 이상으로 전환해야 한다는 최종 경고입니다. 클러스터의 노드 중 지원이 곧 중단될 containerd 버전을 사용하는 노드가 있는지 확인하려면 kubelet_cri_losing_support 메트릭을 모니터링할 수 있습니다.
공식 블로그 게시물 또는 KEP-4033: CRI에서 cgroup 드라이버 감지에서 더 많은 정보를 찾을 수 있습니다.
Kubernetes v1.35의 주요 개선 사항
다음 개선 사항은 v1.35 릴리스에 포함될 가능성이 있는 일부입니다. 이는 확정된 것이 아니며 릴리스 내용은 변경될 수 있습니다.
노드 선언 기능
Pod를 스케줄링할 때 Kubernetes는 노드 레이블, 테인트, 톨러레이션을 사용하여 워크로드 요구 사항과 노드 기능을 일치시킵니다. 그러나 컨트롤 플레인과 노드 간의 버전 불일치로 인해 클러스터 업그레이드 중에 기능 호환성을 관리하는 것이 어려워집니다. 이로 인해 Pod가 필요한 기능이 없는 노드에 스케줄링되어 런타임 오류가 발생할 수 있습니다.
노드 선언 기능 프레임워크는 노드가 지원하는 Kubernetes 기능을 선언하는 표준 메커니즘을 도입할 것입니다. 새로운 알파 기능이 활성화되면 노드는 지원할 수 있는 기능을 보고하고, 새로운 .status.declaredFeatures 필드를 통해 이 정보를 컨트롤 플레인에 게시합니다. 그러면 kube-scheduler, 어드미션 컨트롤러 및 서드파티 구성 요소가 이러한 선언을 사용할 수 있습니다. 예를 들어, Pod가 호환되는 노드에서만 실행되도록 스케줄링 및 API 유효성 검사 제약을 적용할 수 있습니다.
이 접근 방식은 수동 노드 레이블링을 줄이고, 스케줄링 정확도를 개선하며, 호환되지 않는 Pod 배치를 사전에 방지합니다. 또한 Cluster Autoscaler와 통합되어 정보에 기반한 스케일업 결정을 내릴 수 있습니다. 기능 선언은 임시적이며 Kubernetes 기능 게이트와 연결되어 안전한 롤아웃 및 정리를 가능하게 합니다.
v1.35에서 알파 버전을 목표로 하는 노드 선언 기능은 노드 기능을 명시적으로 만들어 버전 불일치 스케줄링 문제를 해결하고, 이기종 버전 환경에서 안정성과 클러스터 안정성을 향상시키는 것을 목표로 합니다.
공식 문서가 게시되기 전에 이에 대해 더 자세히 알아보려면 KEP-5328을 읽어보세요.
Pod 리소스의 인플레이스 업데이트
Kubernetes는 Pod 리소스에 대한 인플레이스 업데이트를 GA(General Availability)로 전환합니다. 이 기능을 통해 사용자는 Pod나 컨테이너를 다시 시작하지 않고도 cpu 및 memory 리소스를 조정할 수 있습니다. 이전에는 이러한 수정 사항을 적용하려면 Pod를 다시 생성해야 했으며, 이는 특히 스테이트풀(stateful) 또는 배치(batch) 애플리케이션의 워크로드에 지장을 줄 수 있었습니다.
이전 Kubernetes 릴리스에서는 이미 기존 Pod의 인프라 리소스 설정(요청 및 제한)을 변경할 수 있었습니다. 이를 통해 수직 스케일링이 더욱 원활해지고 효율성이 향상되며 솔루션 개발도 간소화될 수 있습니다.
컨테이너 런타임 인터페이스(CRI)도 개선되어 Windows 및 향후 런타임을 위한 UpdateContainerResources API를 확장하고 ContainerStatus가 실시간 리소스 구성을 보고할 수 있도록 했습니다. 이러한 변경 사항은 Kubernetes에서 스케일링을 더 빠르고 유연하며 중단 없이 만듭니다. 이 기능은 v1.27에서 알파로 도입되었고, v1.33에서 베타로 승격되었으며, v1.35에서 안정화 버전으로 전환될 예정입니다.
KEP-1287: Pod 리소스의 인플레이스 업데이트에서 더 많은 정보를 찾을 수 있습니다.
Pod 인증서
마이크로서비스를 실행할 때 Pod는 상호 TLS(mTLS)를 사용하여 서로 인증하기 위해 강력한 암호화 신원이 필요한 경우가 많습니다. Kubernetes는 서비스 어카운트 토큰을 제공하지만, 이는 API 서버에 인증하기 위해 설계된 것이지 일반적인 워크로드 신원을 위한 것은 아닙니다.
이 개선 사항이 있기 전에는 운영자들이 워크로드에 대한 인증서를 프로비저닝하고 로테이션하기 위해 SPIFFE/SPIRE 또는 cert-manager와 같은 복잡한 외부 프로젝트에 의존해야 했습니다. 하지만 Pod에 고유하고 짧은 수명의 인증서를 기본적으로 자동으로 발급할 수 있다면 어떨까요? KEP-4317은 이러한 네이티브 워크로드 ID를 활성화하도록 설계되었습니다. kubelet이 프로젝티드 볼륨을 통해 Pod용 인증서를 요청하고 마운트할 수 있도록 하여 Pod 간 통신을 보호하기 위한 다양한 가능성을 열어줍니다.
이는 자동화된 인증서 로테이션과 함께 워크로드 ID를 위한 내장 메커니즘을 제공하여 서비스 메시 및 기타 제로 트러스트 네트워크 정책 설정을 크게 단순화합니다. 이 기능은 v1.34에서 알파로 도입되었고 v1.35에서 베타를 목표로 합니다.
KEP-4317: Pod 인증서에서 더 많은 정보를 찾을 수 있습니다.
테인트의 숫자 값
Kubernetes는 Gt(보다 큼) 및 Lt(보다 작음)와 같은 숫자 비교 연산자를 추가하여 테인트 및 톨러레이션을 개선하고 있습니다.
이전에는 톨러레이션이 정확 일치(Equal) 또는 존재 일치(Exists)만 지원하여 안정성 SLA와 같은 숫자 속성에는 적합하지 않았습니다.
이 변경으로 Pod는 톨러레이션을 사용하여 특정 숫자 임계값을 충족하는 노드를 "옵트인"할 수 있습니다. 예를 들어, Pod는 SLA 테인트 값이 950보다 큰 노드를 요구할 수 있습니다(operator: Gt, value: "950").
이 접근 방식은 노드의 숫자 값이 허용된 임계값 아래로 떨어질 경우 Pod가 자동으로 축출될 수 있도록 NoExecute 효과를 지원하기 때문에 Node Affinity보다 더 강력합니다.
KEP-5471: SLA 기반 스케줄링 활성화에서 더 많은 정보를 찾을 수 있습니다.
사용자 네임스페이스
Pod를 실행할 때 securityContext를 사용하여 권한을 낮출 수 있지만, Pod 내부의 컨테이너는 종종 여전히 root(UID 0)로 실행됩니다. 이 단순성은 컨테이너 UID 0이 호스트의 root 사용자에 직접 매핑되기 때문에 심각한 문제를 야기합니다.
이 개선 사항이 있기 전에는 컨테이너 탈출 취약점이 공격자에게 노드에 대한 완전한 root 액세스 권한을 부여할 수 있었습니다. 하지만 컨테이너의 root 사용자를 호스트의 안전하고 비특권 사용자에게 동적으로 재매핑할 수 있다면 어떨까요? KEP-127은 Linux 사용자 네임스페이스에 대한 이러한 네이티브 지원을 특별히 허용합니다. 컨테이너와 호스트 사용자/그룹 ID를 격리하여 Pod 보안을 위한 다양한 가능성을 열어줍니다. 이를 통해 프로세스는 자체 네임스페이스 내에서 root 권한(UID 0)을 가지면서도 호스트에서는 비특권의 높은 번호의 UID로 실행될 수 있습니다.
v1.25에서 알파로, v1.30에서 베타로 릴리스된 이 기능은 베타 단계를 거쳐 성숙도를 높이고 있으며, 한 종류의 보안 취약점에 대한 공격 표면을 크게 줄이는 진정한 "루트리스(rootless)" 컨테이너를 위한 길을 열고 있습니다.
KEP-127: 사용자 네임스페이스에서 더 많은 정보를 찾을 수 있습니다.
OCI 이미지를 볼륨으로 마운트하는 기능 지원
Pod를 프로비저닝할 때 컨테이너에 필요한 데이터, 바이너리 또는 구성 파일을 번들로 묶어야 하는 경우가 많습니다. 이 개선 사항이 있기 전에는 사람들이 이러한 종류의 데이터를 주 컨테이너 이미지에 직접 포함하거나, 사용자 지정 init 컨테이너를 사용하여 파일을 다운로드하고 emptyDir에 압축을 풀어야 했습니다. 물론 여전히 이 두 가지 접근 방식 중 하나를 취할 수 있습니다.
하지만 컨테이너 이미지를 풀링하는 것과 마찬가지로 OCI 레지스트리에 있는 데이터 전용 아티팩트에서 직접 볼륨을 채울 수 있다면 어떨까요? Kubernetes v1.31은 image 볼륨 유형에 대한 지원을 추가하여 Pod가 OCI 컨테이너 이미지 아티팩트를 선언적으로 볼륨으로 풀링하고 압축을 풀 수 있도록 했습니다.
이를 통해 표준 레지스트리 도구를 사용하여 데이터, 바이너리 또는 ML 모델을 원활하게 배포할 수 있으며, 데이터를 컨테이너 이미지에서 완전히 분리하고 복잡한 init 컨테이너나 시작 스크립트의 필요성을 없앱니다. 이 볼륨 유형은 v1.33부터 베타 상태였으며 v1.35에서 기본적으로 활성화될 가능성이 높습니다.
image 볼륨의 베타 버전을 사용해 볼 수 있으며, KEP-4639: OCI 볼륨 소스에서 계획에 대해 더 자세히 알아볼 수 있습니다.
더 자세히 알고 싶으신가요?
새로운 기능과 사용 중단 사항은 Kubernetes 릴리스 노트에도 공지됩니다. 해당 릴리스의 CHANGELOG의 일부로 Kubernetes v1.35의 새로운 기능을 공식적으로 발표할 예정입니다.
Kubernetes v1.35 릴리스는 2025년 12월 17일로 예정되어 있습니다. 업데이트에 주목해 주세요!
다음 릴리스 노트에서도 변경 사항 공지를 확인할 수 있습니다:
참여하기
Kubernetes에 참여하는 가장 간단한 방법은 관심사에 맞는 다양한 특별 관심 그룹(SIG) 중 하나에 가입하는 것입니다. Kubernetes 커뮤니티에 알리고 싶은 것이 있으신가요? 매주 커뮤니티 회의와 아래 채널을 통해 의견을 공유해 주세요. 지속적인 피드백과 지원에 감사드립니다.
- Bluesky에서
@kubernetes.io를 팔로우하여 최신 업데이트를 받아보세요 - Discuss에서 커뮤니티 토론에 참여하세요
- Slack에서 커뮤니티에 참여하세요
- Server Fault 또는 Stack Overflow에 질문을 게시하거나 답변하세요
- 여러분의 Kubernetes 이야기를 공유하세요
- 블로그에서 Kubernetes에 대한 최신 소식을 더 읽어보세요
- Kubernetes 릴리스 팀에 대해 더 자세히 알아보세요