RSS 쿠버네티스 블로그 - TheNote.app

RSS 쿠버네티스 블로그
팔로우

쿠버네티스의 공식 홈페이지, 컨테이너 오케스트레이션 시스템으로 컨테이너화된 애플리케이션의 배포, 크기 조정 및 관리를 자동화하는 데 사용됩니다. 클라우드 네이티브 컴퓨팅 재단에서 유지하는 프로젝트인 쿠버네티스에 대한 포괄적인 문서를 제공하는 플랫폼입니다. 상태가 없는 애플리케이션과 상태가 있는 애플리케이션, 배치 작업 및 CI/CD 워크플로우를 쿠버네티스를 사용하여 실행하는 방법에 대한 세부적인 정보를 포함합니다. 이 사이트에는 쿠버네티스를 시작하고 이를 통해 클라우드 기반 애플리케이션을 효율적으로 관리하는 데 필요한 기능을 최대한 활용하는 데 도움이 되는 자세한 가이드, 튜토리얼, 참조 자료, API 문서 및 커뮤니티 참여 이니셔티브가 포함되어 있습니다.

Kubernetes Blog kubernetes.io

RSS kubernetes.io

RSS Hunter • 2024년 8월 23일

노트 스레드

etcd v3.7.0 발표

SIG etcd는 분산 키-값 저장소의 중요한 업데이트인 etcd v3.7.0 릴리스를 발표합니다. 이 릴리스는 대규모 결과 세트의 효율적인 스트리밍을 가능하게 하는 많은 기대를 모았던 RangeStream 기능을 도입합니다. 또한 더 빠른 lease 작업 및 최적화된 keys-only range 요청을 포함한 다양한 성능 향상을 제공합니다. 레거시 v2 저장소 종속성이 완전히 제거되었으며, etcd는 이제 v3store에서만 부팅되어 운영이 간소화됩니다. 포괄적인 protobuf 개편을 통해 지원되는 버전으로 오래된 라이브러리를 교체하여 보안 및 유지보수성을 향상시켰습니다. 이 릴리스는 또한 핵심 종속성인 bbolt를 v1.5.1로, raft를 v3.7.0으로 업데이트합니다. 추가 개선 사항에는 로컬 개발 및 테스트를 위한 Unix 소켓 지원이 포함됩니다. etcdutl 명령에는 이제 무기한 차단을 방지하기 위한 timeout 인수가 포함됩니다. Client v3는 직접 JWT 설정 및 사전 인증 없이 AuthStatus를 검색하는 기능으로 더 많은 인증 유연성을 제공합니다. 향상된 관찰 가능성을 위해 새로운 watch 및 request duration 메트릭이 추가되었습니다. etcdctl 명령은 명확성을 위해 재구성되었으며, 더 이상 사용되지 않는 실험적 플래그가 제거되었습니다. 레거시 v2 API 패키지 및 코드에 대한 상당한 정리 작업도 수행되었습니다.

Announcing etcd v3.7.0 kubernetes.io

RSS Hunter • 7월 8일

AI 시대의 오픈 소스 유지보수

AI는 코드 생성을 통해 더 많은 기여자들을 가능하게 함으로써 소프트웨어 개발을 혁신하고 있습니다. 그러나 이러한 발전은 코드 유지보수 개선 속도를 앞지르고 있어 과제를 안겨주고 있습니다. 쿠버네티스 커뮤니티는 포괄적인 AI 정책을 수립하여 AI 지원 코딩에 선제적으로 적응하고 있습니다. 이 정책은 혁신과 책임성을 균형 있게 유지하여 코드 품질과 인간의 감독을 보장하는 것을 목표로 합니다. 핵심 원칙은 투명성이며, 기여자는 풀 리퀘스트에서 AI 사용을 공개해야 합니다.중요하게도, 인간의 책임성은 여전히 가장 중요하며, AI는 공동 저자나 공동 서명자로 등재될 수 없습니다. 기여자는 또한 AI 생성 코드에 대해 개인적으로 설명해야 하며, 이는 지식 격차를 방지합니다. 프로젝트는 AI 지원을 포함한 모든 공동 저자에 대해 기여자 라이선스 계약을 시행하고, 불완전한 PR을 플래그합니다. 코드 품질을 향상시키고 초기 피드백을 제공하기 위해 자동화된 AI 검토가 탐색되고 있습니다.GitHub Copilot 및 CodeRabbit과 같은 도구는 특정 쿠버네티스 프로젝트 내에서 평가 및 테스트되고 있습니다. 이러한 도구는 인간 검토 전에 신속한 현장 점검을 제공하는 품질 게이트 역할을 할 수 있습니다. 커뮤니티는 검토 도구를 조정하고, 새로운 AI 기술을 평가하며, 유지보수자의 번아웃을 줄이고 테스트 분류를 지원하는 데 AI의 잠재력을 탐색하는 데 적극적으로 도움을 구하고 있습니다.

Open source maintainership in the age of AI kubernetes.io

RSS Hunter • 6월 26일

헤드램프용 클러스터 API 플러그인 소개

Headlamp은 브라우저에서 클러스터 리소스를 관리하기 위한 오픈 소스 Kubernetes UI 프로젝트입니다. Cluster API(CAPI)는 클러스터 라이프사이클 관리를 위한 선언적, Kubernetes 스타일 API를 제공합니다. Headlamp Cluster API 플러그인은 CAPI 리소스 관리를 단순화하여 원시 kubectl 명령의 필요성을 없앱니다. 이 플러그인은 Headlamp에 전용 CAPI 섹션을 추가하여 일관된 목록 및 세부 정보 보기를 통해 핵심 CAPI 리소스에 대한 완전한 가시성을 제공합니다. 주요 기능에는 클러스터 개요, Machine 가시성 및 상태 모니터링을 위한 중앙 집중식 Cluster API 대시보드가 포함됩니다. 사용자는 KubeadmControlPlane 복제본을 추적하고, MachineDeployments 및 MachineSets를 확장하고, 소유한 리소스 계층 구조를 시각화할 수 있습니다. 이 플러그인을 사용하면 원시 YAML 없이 KubeadmConfig를 검사하고 토폴로지 인식을 제공할 수도 있습니다. 맵 보기는 Cluster, Control Plane 및 Worker 관계를 시각화하며 v1beta1 및 v1beta2 Cluster API 버전을 모두 지원합니다. Prometheus 메트릭은 세부 정보 페이지에 인라인으로 실시간 성능 데이터를 통합합니다. CNCF LFX Mentorship 프로그램 중에 개발된 이 플러그인은 Cluster API 관리 경험을 향상시키는 것을 목표로 합니다. 이것은 Alpha 릴리스이며 향후 개발을 위해 커뮤니티 피드백을 권장합니다.

Introducing the Cluster API plugin for Headlamp kubernetes.io

RSS Hunter • 6월 25일

헤드램프로 화산 작업 부하를 더 빠르게 점검하세요

Volcano는 고성능 컴퓨팅, AI/ML 및 기타 배치 워크로드를 위해 설계된 Kubernetes용 클라우드 네이티브 배치 스케줄러입니다. Kubernetes는 원래 장기 실행 서비스를 위해 구축되었지만, 배치 워크로드는 종종 동적 작업 도착, 리소스 경쟁 및 여러 워커의 동시 시작을 필요로 합니다. Volcano는 큐, 우선순위, 할당량 및 갱 스케줄링과 같은 개념으로 Kubernetes를 확장하여 독립적인 Pod가 아닌 전체로서 워크로드를 처리합니다. 확장 가능한 Kubernetes 웹 UI인 Headlamp용 Volcano 플러그인은 이러한 스케줄링 세부 정보를 단일 인터페이스로 가져옵니다.이 플러그인은 Volcano 작업, 큐 및 PodGroup에 대한 전용 보기를 제공하여 배치 워크로드의 운영 및 문제 해결을 더 쉽게 만듭니다. 작업 보기는 워크로드 상태, 작업 세부 정보, Pod 상태를 표시하고 일시 중지/재개 및 로그 액세스와 같은 직접적인 작업을 허용합니다. 큐 보기는 리소스 할당, 용량 및 예약 세부 정보에 대한 통찰력을 제공합니다. PodGroup 보기는 갱 스케줄링 상태 및 잠재적 차단 요소를 명확히 합니다.핵심 기능은 작업, 큐, PodGroup 및 Pod가 어떻게 상호 연결되어 있는지 시각적으로 나타내는 맵 보기로, 보류 중이거나 진행되지 않는 워크로드의 문제를 신속하게 식별하는 데 도움이 됩니다. 이 플러그인은 자동화를 위한 CLI 도구를 대체하지 않고 관련 리소스, 구조화된 세부 정보 및 런타임 출력을 중앙 집중화하여 대화형 문제 해결 경험을 향상시킵니다. 향후 개선 사항에는 Prometheus 통합 및 더 풍부한 스케줄링 통찰력이 포함될 수 있습니다. 사용자는 Headlamp의 플러그인 카탈로그를 통해 플러그인을 설치하고 개발에 영향을 미치기 위해 피드백을 제공할 수 있습니다.

Inspect Volcano workloads faster with Headlamp kubernetes.io

RSS Hunter • 6월 25일

서버리스를 확인하세요: Knative용 Headlamp 플러그인 소개

Headlamp은 Kubernetes 리소스를 관리하고 디버깅하기 위해 설계된 오픈 소스 프로젝트입니다. Knative는 Kubernetes에서 서버리스 워크로드를 가능하게 하지만, 여러 도구에 걸쳐 운영하기 복잡할 수 있습니다. 이를 해결하기 위해 Knative용 Headlamp 플러그인이 개발되었습니다. 이 플러그인을 통해 사용자는 Headlamp 내에서 Knative를 광범위하게 관리할 수 있습니다. Knative 리소스를 Headlamp의 리소스 매핑 보기에 통합하여 KService, Revision, DomainMapping 간의 관계를 보여줍니다. 이 플러그인은 KService에 대한 상세 보기를 제공하여 트래픽 분할 및 자동 확장 구성의 실시간 편집을 가능하게 합니다. 사용자는 KService 헤더에서 직접 파드를 다시 시작하고 로그에 액세스할 수도 있습니다. 이 플러그인은 단계적 롤아웃 및 A/B 테스트를 위해 Revision 전반에 걸쳐 세분화된 트래픽 분할을 용이하게 합니다. 각 Revision에 대한 트래픽 분포, 준비 상태 및 태그를 시각적으로 표시합니다. 자동 확장 구성은 명시적인지 또는 클러스터 기본값에서 상속되었는지 여부를 나타내며 명확하게 제시됩니다. Prometheus 플러그인과 결합하면 KService 및 Revision에 대한 요청 속도 및 지연 시간과 같은 메트릭을 제공합니다. 이 플러그인은 또한 Revision, DomainMapping 및 네트워킹 개요를 포함한 다른 Knative CRD에 대한 목록 및 상세 보기를 제공합니다. 설치는 Headlamp의 플러그인 카탈로그에서 Knative 플러그인을 검색하고 설치하는 것을 포함합니다. 피드백 및 버그 보고서는 GitHub 이슈 또는 Kubernetes Slack 채널을 통해 제출할 수 있습니다.

See your serverless: introducing the Headlamp plugin for Knative kubernetes.io

RSS Hunter • 6월 25일

WG 장치 관리 집중 조명

Device Management Working Group는 Kubernetes에서 전문화된 하드웨어 관리에 대한 증가하는 요구를 해결합니다. GPU, TPU 및 특정 네트워크 인터페이스를 요구하는 AI, Edge 및 Telecommunications 워크로드의 경우 기존 리소스 할당 방법으로는 불충분합니다. 그룹의 주요 프로젝트인 Dynamic Resource Allocation(DRA)이 General Availability에 도달하여 중요한 발전을 이루었습니다. DRA는 장치 관리를 위한 모델링, 요청, 스케줄링 및 작동의 구조화된 4단계 프레임워크를 제공합니다. 이 새로운 접근 방식은 공급업체가 세분화된 하드웨어 기능을 광고하고 사용자가 정확한 하드웨어 요구 사항을 지정할 수 있도록 합니다. 그런 다음 Kubernetes 스케줄러는 이러한 요구 사항을 사용 가능한 하드웨어와 지능적으로 일치시킵니다. DRA는 장치를 단순한 정수로 취급했던 레거시 Device Plugin API를 유연하고 선언적인 API로 대체합니다. 이 워킹 그룹은 Kubernetes 구성 요소 전반에 걸친 포괄적인 통합을 보장하기 위해 여러 SIG를 포함하는 크로스 SIG 노력입니다. 현재 이니셔티브는 DRA의 표현력 향상, 운영 가시성 지원 및 다중 노드 및 복잡한 하드웨어 토폴로지 관리에 중점을 두고 있습니다. 향후 작업에는 장치 상태 모니터링 및 그룹화된 장치 사용에 대한 더 나은 지원이 포함됩니다. 워킹 그룹은 Kubernetes를 위한 보다 프로그래밍 가능하고 하드웨어 인식적인 미래를 만드는 것을 목표로 합니다.

Spotlight on WG Device Management kubernetes.io

RSS Hunter • 6월 24일

SIG 저장소에 대한 스포트라이트

이 글은 영구 데이터 및 볼륨 관리를 담당하는 쿠버네티스 특별 관심 그룹인 SIG Storage를 조명합니다. SIG Storage의 공동 의장인 Xing Yang은 그룹이 기본적인 영구 볼륨 처리를 넘어 복잡한 스토리지 기능을 발전시키는 과정에 대해 논합니다. 원래 상태 비저장 워크로드를 위해 설계되었던 쿠버네티스는 이제 상태 저장 애플리케이션을 지원하며, 이는 전용 스토리지 솔루션을 필요로 합니다. SIG Storage는 이러한 과제를 해결하기 위해 형성되었으며, PersistentVolumes 및 PersistentVolumeClaims와 같은 기본 요소를 도입했습니다.중요한 발전은 컨테이너 스토리지 인터페이스(CSI)로, 이는 타사 스토리지 공급업체가 핵심 쿠버네티스 수정 없이 시스템을 통합할 수 있도록 합니다. 현재 작업에는 충돌 일관적인 다중 볼륨 스냅샷을 위한 Volume Group Snapshot과 효율적인 백업을 위한 Changed Block Tracking이 포함되며, 이 두 가지 모두 최근 안정 버전으로 졸업했습니다. 컨테이너 객체 스토리지 인터페이스(COSI) 또한 객체 스토리지 통합을 표준화하기 위해 진행 중입니다.사용자를 위한 최근의 성과에는 IOPS와 같은 스토리지 속성의 동적 조정을 가능하게 하는 VolumeAttributesClass의 일반 가용성 졸업이 포함됩니다. 향후 로드맵에는 운영 가시성 향상을 위한 Volume Health와 잠재적인 자동 복구가 포함됩니다. SIG Storage는 버그 수정, 테스트, 검토 및 Mutable PV Affinity 및 볼륨 복제와 같은 기능에 대한 피드백에 커뮤니티의 도움을 구합니다.상태 저장 워크로드의 과제에는 데이터 중력, Day-2 운영 복잡성 및 데이터 이동성이 포함됩니다. AI 워크로드가 증가함에 따라 쿠버네티스의 스토리지는 더욱 지능화될 것으로 예상되며, 객체 스토리지가 중요해질 것입니다. 고성능, 저지연 스토리지 및 데이터 인식 스케줄링 또한 예상되는 추세입니다. SIG Storage는 이러한 진화하는 스토리지 요구를 해결하기 위해 커뮤니티 참여를 초대합니다.

Spotlight on SIG Storage kubernetes.io

RSS Hunter • 6월 15일

쿠버네티스 대시보드에서 헤드램프로: 전환 이해하기

쿠버네티스 대시보드는 한때 쿠버네티스의 주요 시각적 인터페이스였으나, 현재는 보관 처리되었습니다. 이는 많은 사용자들에게 클러스터 가시성과 리소스 검사를 단순화하는 중요한 진입점 역할을 했습니다. Headlamp은 이제 대시보드의 기반 위에 구축하여 이러한 유산을 이어가고 있습니다. 현대적인 쿠버네티스 사용 패턴을 통합하면서 명확한 시각적 인터페이스를 제공합니다. Headlamp은 멀티 클러스터 가시성, 프로젝트를 통한 애플리케이션 중심 뷰, 플러그인을 통한 확장성을 제공합니다. 이 전환은 대시보드의 사용자 중심 유산을 존중하고 성장하는 UI 솔루션을 제공하는 것을 목표로 합니다. 쿠버네티스 대시보드의 많은 익숙한 워크플로우는 Headlamp에 유지되어 연속성과 사용 편의성을 보장합니다. Headlamp은 단일 인터페이스에서 멀티 클러스터 관리를 허용하여 분산 환경의 마찰을 줄임으로써 기능을 확장합니다. Headlamp 내의 프로젝트는 애플리케이션 중심 뷰를 제공하며, 관련 리소스를 그룹화하여 이해와 문제 해결을 개선합니다. 또한 GitOps 워크플로우를 위한 Flux 플러그인이나 안내를 위한 AI 어시스턴트와 같은 플러그인을 통해 플랫폼을 확장할 수 있습니다. Headlamp은 클러스터 내 도구 또는 데스크톱 애플리케이션으로 사용할 수 있는 유연한 배포 옵션을 제공합니다. 현재 대시보드 사용, 즉 클러스터, 네임스페이스 및 인증을 이해하는 것은 Headlamp으로의 원활한 전환에 도움이 됩니다.

From Kubernetes Dashboard to Headlamp: Understanding the Transition kubernetes.io

RSS Hunter • 6월 1일

과거의 화해: 수정되지 않은 Kubernetes CVE에 대한 기록 수정

Kubernetes는 더 나은 정확성을 위해 CVE 기록을 개선하여 투명성을 향상시키고 있습니다. 이전 CVE 기록에서 일부 고정 버전이 잘못 기재된 불일치를 발견했습니다. Kubernetes 보안 대응 위원회는 2026년 6월 1일에 이 기록을 수정할 예정입니다. 이로 인해 취약점 스캐너가 이전에 감지되지 않은 문제를 식별할 수 있습니다. 이 게시물은 수정되지 않은 세 가지 취약점인 CVE-2020-8561, CVE-2020-8562 및 CVE-2021-25740에 대한 기술적 세부 정보를 제공합니다. 업데이트는 올바른 취약점 스캔을 보장하고 지속적인 관리 완화 요구 사항을 명확히 합니다. 수정되지 않은 CVE-2020-8554도 표준화된 버전 번호 형식을 받게 됩니다. 식별된 취약점은 수정이 Kubernetes 핵심 기능을 방해할 수 있기 때문에 여전히 수정되지 않았습니다. 각 취약점에는 관리자가 클러스터를 보호하기 위해 구현해야 하는 특정 완화 조치가 있습니다. 이러한 조치는 취약점의 아키텍처 특성을 고려할 때 중요합니다. 프로젝트는 이러한 위험을 관리하기 위해 "구성으로 인한 보안" 접근 방식을 강조합니다. 이러한 기록을 업데이트하는 것은 투명성과 정확한 위험 평가를 촉진하는 성숙한 보안 생태계를 보여줍니다.

Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs kubernetes.io

RSS Hunter • 5월 26일

etcd 3.7.0-beta.0 발표

SIG-Etcd는 분산 데이터베이스의 중요한 업데이트인 etcd v3.7.0의 첫 번째 베타 버전을 출시했습니다. 이 버전은 대규모 결과 세트 처리를 개선하고 지연 시간 및 메모리 관리를 향상시키도록 설계된 기능인 RangeStream을 도입했습니다. 또한 레거시 구성 요소 및 인터페이스의 리팩토링 및 정리 작업을 포함하여 전반적인 성능을 향상시켰습니다. 개발자들은 사용자들이 베타 버전을 테스트하고 etcd 저장소에서 발견된 모든 문제를 보고하도록 권장합니다. 주요 특징은 etcd v2store의 마지막 흔적을 제거하여 v3store로의 전환을 완료한 것입니다. 이 전환은 특히 v3.6.11을 사용하지 않는 사용자에게 호환성이 깨지는 변경 사항을 초래할 수 있으므로, 발생하는 모든 문제에 대한 피드백을 요청합니다. 이 베타 릴리스에는 bbolt 및 raft 라이브러리 업데이트도 포함되어 있습니다. 또한, 릴리스 일정은 5월 이후 업데이트가 중단될 etcd v3.4의 지원 종료(EOL)와 연관되어 있습니다. 커뮤니티는 궁극적인 지원 중단 전에 필요한 경우 v3.4에 대한 추가 보안 패치를 릴리스할 준비가 되어 있습니다. 사용자들은 v3.4에서 업그레이드할 것을 강력히 권고합니다. 향후 베타 버전은 잠재적으로 추가적인 protobuf 리팩토링을 통해 릴리스 후보 버전과 6월 또는 7월 초의 최종 버전으로 이어질 예정입니다. GitHub 이슈, Kubernetes Slack 채널 및 etcd-dev 메일링 리스트를 통해 피드백을 적극적으로 수렴하고 있습니다.

Announcing etcd 3.7.0-beta.0 kubernetes.io

RSS Hunter • 5월 20일

쿠버네티스 v1.36: 클라우드 컨트롤러 매니저의 라우트 동기화에 대한 새로운 메트릭

이 기사는 원래 날짜가 잘못 기재되었으나, 이제 2026년 5월 15일 발행일로 반영됩니다. Kubernetes v1.36은 Cloud Controller Manager의 route controller를 위한 새로운 알파 메트릭인 route_controller_route_sync_total을 도입합니다. 이 메트릭은 클라우드 공급자와의 route sync 작업을 추적하여 CloudControllerManagerWatchBasedRoutesReconciliation 기능 게이트를 모니터링하는 데 도움을 줍니다. v1.35에서 도입된 이 기능은 route controller를 watch 기반 접근 방식으로 전환합니다. 이 변경으로 인해 노드가 변경될 때만 route를 조정하여 API 호출을 줄입니다. 새로운 기능을 테스트하려면 기능 게이트가 비활성화되었을 때와 활성화되었을 때의 메트릭 동작을 비교하십시오. 기능 게이트가 비활성화되면 카운터는 고정된 간격으로 증가합니다. 반대로, 기능이 활성화되면 카운터는 노드 변경 시에만 증가합니다. 이 차이는 노드 수정이 드문 안정적인 클러스터에서 가장 두드러집니다. 피드백은 Kubernetes Slack, GitHub 이슈 및 SIG Cloud Provider 커뮤니티 페이지를 통해 제공할 수 있습니다. 자세한 내용은 KEP-5237에서 확인할 수 있습니다.

Kubernetes v1.36: New Metric for Route Sync in the Cloud Controller Manager kubernetes.io

RSS Hunter • 5월 15일

쿠버네티스 v1.36: 혼합 버전 프록시, 베타로 승격

Mixed Version Proxy (MVP)는 알려지지 않은 리소스에 대한 요청을 최신 API 서버로 안전하게 라우팅하여 404 오류를 방지함으로써 Kubernetes 클러스터 업그레이드를 향상시킵니다. Kubernetes 1.28에서 Alpha 기능으로 처음 도입된 MVP는 이제 버전 1.36에서 Beta로 전환되며 기본적으로 활성화될 예정입니다. MVP는 업그레이드 중 API 서버 버전이 다른 문제점을 해결하며, 이 경우 새 리소스에 대한 요청이 이전 서버에서 실패할 수 있습니다. 잘못된 404 대신, 요청은 이를 처리할 수 있는 서버로 프록시됩니다. MVP의 Beta 버전은 피어 기능을 결정하기 위해 StorageVersion API 대신 집계된 디스커버리를 사용하여 기능을 개선합니다. 이 업데이트에는 피어 집계 디스커버리도 포함되어 클라이언트에게 사용 가능한 모든 API의 통합된 보기를 제공합니다. MVP를 활성화하려면 API 서버에 --peer-ca-file 플래그가 필요하며, 필요한 경우 --peer-advertise-ip 및 --peer-advertise-port도 함께 필요합니다. kubeadm을 사용하면 ClusterConfiguration 파일에 해당 플래그를 포함하여 프로세스를 간소화할 수 있습니다. 사용자는 스테이징 환경에서 MVP를 테스트하고 1.36 업그레이드의 일부로 SIG API Machinery에 피드백을 제공하도록 권장됩니다.

Kubernetes v1.36: Mixed Version Proxy Graduates to Beta kubernetes.io

RSS Hunter • 5월 15일

Kubernetes v1.36: Service ExternalIPs의 지원 중단 및 제거

Kubernetes 서비스의 .spec.externalIPs 필드는 원래 클라우드 외부 로드 밸런서 기능을 위해 설계되었으나, CVE-2020-8554에서 식별된 보안 취약점으로 인해 현재 사용 중단되었습니다. 이 필드는 서비스가 응답하는 추가 IP 주소를 지정할 수 있도록 하지만, 모든 사용자 간의 신뢰를 가정하기 때문에 내재된 보안 위험이 있습니다. Kubernetes 1.21에서는 이미 .spec.externalIPs 비활성화를 권장했으며, 이를 강제하기 위한 admission controller가 도입되었습니다. 대안으로는 수동으로 관리되는 LoadBalancer 서비스 또는 MetalLB와 같은 클라우드 외부 로드 밸런서 컨트롤러가 더 나은 보안과 제어를 제공합니다. MetalLB는 관리자가 IP 주소 할당을 제어할 수 있도록 하여 보안 문제를 완화합니다. Gateway API 또한 Gateway 리소스를 통해 관리자에게 IP에 대한 제어를 제공하는 안전한 솔루션을 제공합니다. Kubernetes 1.36에서는 .spec.externalIPs가 공식적으로 사용 중단되었으며, 사용에 대한 경고가 발급되기 시작했습니다. 향후 릴리스에서는 kube-proxy의 해당 기능 지원이 비활성화될 예정이며, 이후 버전에서는 완전히 제거될 계획입니다. 사용자들은 이 안전하지 않은 기능에서 마이그레이션하도록 권장됩니다.

Kubernetes v1.36: Deprecation and removal of Service ExternalIPs kubernetes.io

RSS Hunter • 5월 14일

쿠버네티스 v1.36: 워크로드 인식 스케줄링의 발전

Kubernetes v1.35는 Workload API와 동일한 Pod에 대한 기본적인 gang scheduling을 포함한 워크로드 인식 스케줄링 개선 사항을 도입했습니다. Kubernetes v1.36은 Workload API(정적 템플릿)를 새로운 PodGroup API(런타임 상태)와 분리하여 이 아키텍처를 개선합니다. 이 분리는 kube-scheduler를 간소화하여 향상된 성능을 위해 PodGroup 정보를 직접 읽을 수 있도록 합니다.새로운 PodGroup 스케줄링 사이클은 워크로드의 원자적 처리를 허용하여 전체 그룹을 단일 작업으로 평가하여 교착 상태를 방지합니다. 유효한 배치 위치가 발견되고 그룹 제약 조건이 충족되면 Pod가 함께 바인딩됩니다. 그렇지 않으면 전체 그룹이 스케줄링할 수 없는 것으로 간주되고 나중에 다시 시도됩니다. 이는 엄격한 워크로드 요구 사항에 대한 올인원 배치를 보장하는 gang scheduling의 기반을 형성합니다.v1.36의 토폴로지 인식 스케줄링은 PodGroups에 토폴로지 제약 조건을 정의하여 특정 물리적 또는 논리적 도메인 내에 Pod를 공동 배치하여 네트워크 지연 시간을 줄일 수 있도록 합니다. 여기에는 스케줄링 제약 조건을 기반으로 후보 배치 위치를 생성, 평가 및 점수 매기기가 포함됩니다.워크로드 인식 선점은 PodGroup 스케줄링 사이클을 지원하기 위해 도입되었으며, 전체 PodGroup을 위한 공간을 확보하기 위해 여러 노드에서 동시에 Pod를 선점합니다. PodGroup을 단일 선점 단위로 취급하며, PodGroup 우선순위 및 disruptionMode 필드가 선점 동작을 제어합니다.마지막으로 v1.36은 동적 리소스 할당(DRA)을 Workload API와 통합하여 PodGroups가 ResourceClaims를 통해 특수 하드웨어 리소스를 요청하고 공유할 수 있도록 합니다. 이러한 발전은 향후 Kubernetes 릴리스에서 고급 워크로드 스케줄링 기능을 구축하기 위한 강력한 기반을 마련합니다.

Kubernetes v1.36: Advancing Workload-Aware Scheduling kubernetes.io

RSS Hunter • 5월 13일

쿠버네티스 v1.36: PSI 메트릭, 쿠버네티스에서 GA로 졸업

Pressure Stall Information (PSI)는 2018년부터 Linux 커널에 통합되어, 장애로 이어지기 전에 리소스 포화를 식별하기 위한 고충실도 신호를 제공합니다. 전통적인 사용률 지표와 달리, PSI는 CPU, 메모리, I/O 전반에 걸쳐 지연된 작업과 손실된 시간을 정량화합니다. Kubernetes v1.36에서는 노드, 파드, 컨테이너 수준에서 리소스 경합을 관찰하기 위한 안정적인 인터페이스가 제공됩니다. PSI는 일시적인 급증과 지속적인 리소스 긴장을 구분하기 위해 지연 시간의 누적 합계와 이동 평균(10초, 60초, 300초)을 제공합니다.SIG Node의 광범위한 성능 테스트는 고밀도 워크로드(80개 이상의 파드)에서 PSI의 프로덕션 준비 상태를 입증했습니다. Kubelet 오버헤드는 KubeletPSI 기능 게이트를 토글하여 측정되었으며, 리소스 사용에 미미한 영향을 미쳤습니다. Kubelet의 수집 로직은 가벼운 것으로 입증되었으며, 표준 하우스키핑 주기와 원활하게 통합되어 0.1 코어 미만 또는 전체 노드 용량의 2.5% 미만을 소비했습니다.커널 오버헤드와 관련하여, Linux 커널에서 PSI를 활성화하면(psi=1 대 psi=0) 높은 부하에서 0.037 ~ 0.125 코어(노드 용량의 0.925% ~ 3.125%)의 일관된 차이가 발생했습니다. 주요 수집자인 kubelet 프로세스 또한 눈에 띄게 낮은 CPU 사용량을 유지했으며, 스파이크는 1초 이상 0.25 코어(6.25%)를 초과하지 않았습니다.v1.36의 개선 사항에는 더 스마트한 지표 방출이 포함됩니다. Kubelet은 이제 보고 전에 cgroup 구성을 통해 OS 수준 PSI 지원을 감지하여 오해의 소지가 있는 0 값 지표를 방지합니다. PSI를 사용하려면 노드는 Linux 커널 4.20 이상을 실행하고, cgroup v2를 사용하며, OS 수준에서 PSI가 활성화되어야 합니다(CONFIG_PSI=y, psi=0 부팅 매개변수 없음).PSI 지표는 v1.36에서 일반적으로 사용 가능하며 기능 게이트 옵트인이 필요하지 않습니다. 사용자는 /metrics/cadvisor 엔드포인트를 스크랩하거나 Summary API를 쿼리할 수 있습니다. PSI는 Linux 커널 기능이며 Windows 노드에서는 사용할 수 없습니다. 컨트롤 플레인의 API 서버를 통해 Kubelet의 HTTP API로 프록시하면 Summary API에서 실시간 압력 데이터를 얻을 수 있지만, 이는 권한이 필요한 작업입니다.

Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA kubernetes.io

RSS Hunter • 5월 12일

Kubernetes v1.36: 볼륨 그룹 스냅샷을 GA로 이동

Kubernetes v1.36은 이전에 Alpha 및 Beta 기능이었던 볼륨 그룹 스냅샷의 General Availability(GA)를 도입합니다. 이 기능은 확장 API를 활용하여 여러 볼륨의 충돌 일관성 스냅샷을 동시에 가능하게 합니다. 시스템은 레이블 선택기를 사용하여 PersistentVolumeClaim 객체를 그룹화하여 워크로드를 일관된 복구 지점으로 복원할 수 있습니다. 이 기능은 CSI 볼륨 드라이버에 대해서만 지원되며, 쓰기 순서 일관성이 필요한 여러 볼륨을 활용하는 애플리케이션에 상당한 이점을 제공합니다.이전에는 개별 볼륨 스냅샷이 다른 시간에 촬영될 경우, 특히 다중 볼륨 애플리케이션의 경우 불일치를 초래할 수 있었습니다. 그룹 스냅샷은 수동 애플리케이션 중단을 제거하여, 번거로운 순차적 개별 스냅샷 없이 그룹 내 모든 볼륨에 걸쳐 충돌 일관성을 제공합니다. Kubernetes는 세 가지 사용자 정의 API 종류인 VolumeGroupSnapshot, VolumeGroupSnapshotContent, VolumeGroupSnapshotClass를 통해 그룹 스냅샷을 관리합니다. GA 릴리스에서 v1로 승격된 이 CRD를 통해 사용자는 그룹 스냅샷을 요청하고, 프로비저닝된 리소스를 추적하며, 각각 생성 정책을 정의할 수 있습니다.GA 릴리스는 이전 베타 버전의 피드백을 기반으로 안정성 향상, 버그 수정 및 복원 크기 보고 개선을 제공합니다. 이 기능을 사용하려면 사용자는 그룹화할 PersistentVolumeClaim에 레이블을 지정한 다음, 이러한 레이블과 일치하는 선택기와 VolumeGroupSnapshotClass를 가진 VolumeGroupSnapshot 객체를 정의해야 합니다. 복원을 위해 새로운 PersistentVolumeClaim은 더 큰 VolumeGroupSnapshot의 일부인 개별 VolumeSnapshot 객체에서 생성됩니다. 스토리지 공급업체는 CSI 드라이버 내에서 새로운 그룹 컨트롤러 서비스 및 RPC를 구현하여 지원을 추가할 수 있습니다.

Kubernetes v1.36: Moving Volume Group Snapshots to GA kubernetes.io

RSS Hunter • 5월 8일

쿠버네티스 v1.36: 더 많은 드라이버, 새로운 기능, 그리고 DRA의 다음 시대

쿠버네티스 v1.36의 동적 리소스 할당(DRA)은 CPU 및 메모리와 같은 네이티브 리소스를 넘어 특수 하드웨어까지 기능을 확장하는 상당한 발전을 도입했습니다. 네트워킹을 포함한 다양한 하드웨어 유형에 대한 드라이버 지원이 확장되어 DRA가 보다 하드웨어에 구애받지 않는 솔루션이 되고 있습니다. 여러 핵심 기능이 졸업하여 스케줄링 유연성과 클러스터 활용도를 향상시켰습니다. 우선순위 목록 기능은 장치 요청에 대한 대체 기본 설정을 가능하게 하여 리소스 할당 효율성을 개선합니다. 확장된 리소스 지원은 기존 확장 리소스를 통한 리소스 요청을 가능하게 하여 DRA로의 점진적인 전환을 허용합니다. 분할 가능한 장치는 물리적 하드웨어를 더 작고 논리적인 인스턴스로 동적으로 분할하기 위한 네이티브 DRA 지원을 제공합니다. 장치 테인트는 관리자가 결함이 있는 장치의 할당을 방지하거나 특정 하드웨어를 예약함으로써 하드웨어를 보다 효과적으로 관리할 수 있도록 합니다. 장치 바인딩 조건은 외부 리소스가 완전히 준비될 때까지 Pod 커밋을 지연시켜 스케줄링 안정성을 향상시킵니다. 리소스 상태는 Pod 상태에 장치 상태 정보를 직접 노출하여 하드웨어 장애에 대한 신속한 식별 및 대응을 지원합니다. 새로운 알파 기능에는 PodGroups 전반의 공유 리소스를 관리하여 대규모 AI/ML을 최적화하는 워크로드를 위한 ResourceClaim 지원이 포함됩니다. 노드 할당 가능 리소스는 DRA 우산 아래 CPU 및 메모리 할당을 통합하여 세분화된 성능 조정을 가능하게 합니다. DRA 리소스 가용성 가시성은 관리자에게 실시간 장치 용량 정보를 제공하여 더 나은 계획을 지원합니다. 결정론적 장치 선택은 드라이버가 사전순 정렬을 통해 스케줄링에 영향을 미칠 수 있도록 합니다. 컨테이너의 검색 가능한 장치 메타데이터는 드라이버가 장치 속성을 컨테이너에 노출하기 위한 표준 프로토콜을 제공합니다. 향후 로드맵은 기존 기능의 성숙, 성능 및 확장성 향상, 워크로드 인식 및 토폴로지 인식 스케줄링과의 통합에 중점을 두고 있으며, 장치 플러그인에서 DRA로의 사용자 마이그레이션에 중점을 두고 있습니다.

Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA kubernetes.io

RSS Hunter • 5월 7일

Kubernetes v1.36: 서버 사이드 샤디드 리스트 및 워치

클러스터 크기가 증가함에 따라 Kubernetes 컨트롤러는 특히 높은 카디널리티 리소스를 감시할 때 확장성 문제에 직면합니다. 클라이언트 측 샤딩은 기능적이지만 API 서버의 데이터 볼륨을 줄이지 않아 비효율성을 야기합니다. Kubernetes v1.36에서 알파 기능(KEP-5866)으로 도입된 서버 측 샤드 목록 및 감시는 이러한 비효율성을 해결합니다. API 서버는 컨트롤러가 지정한 해시 범위를 기반으로 이벤트를 필터링하여 각 복제본에 관련 데이터만 보냅니다. 컨트롤러는 인포머를 사용하여 리소스를 나열하고 감시하며, WithTweakListOptions를 통해 shardSelector를 통합합니다. shard selector는 객체의 metadata.uid 또는 metadata.namespace를 기반으로 리소스를 필터링하는 데 사용됩니다. API 서버는 샤드 선택기가 올바르게 적용되었는지 확인하기 위해 목록 응답 메타데이터에 shardInfo 필드를 반환합니다. 누락된 경우 클라이언트는 전체 필터링되지 않은 컬렉션을 처리해야 하며, 잠재적으로 클라이언트 측 필터링에 의존해야 합니다. 이 기능은 ShardedListAndWatch 기능 게이트를 활성화해야 합니다. Kubernetes 커뮤니티는 특히 대규모 클러스터를 관리하는 컨트롤러 작성자 및 운영자로부터 피드백을 구합니다. 이 접근 방식은 까다로운 Kubernetes 환경에서 컨트롤러 성능 및 확장성을 개선하도록 설계되었습니다.

Kubernetes v1.36: Server-Side Sharded List and Watch kubernetes.io

RSS Hunter • 5월 6일

Kubernetes v1.36: 선언적 검증이 GA로 넘어가다

Kubernetes v1.36은 네이티브 타입에 대한 선언적 검증(Declarative Validation)을 도입하여 이제 일반적으로 사용 가능합니다. 이는 검증 규칙 정의를 위해 직접 작성한 Go 코드에서 IDL 태그로 전환하여 API의 신뢰성과 예측 가능성을 향상시킵니다. 이전에는 직접 작성한 코드에 의존하여 기술 부채, 불일치 및 불투명한 API를 초래했습니다. 이 솔루션은 태그를 파싱하여 Go 검증 함수를 자동으로 생성하는 코드 생성기인 validation-gen을 활용합니다. 이 프레임워크는 존재, 제약 조건, 컬렉션, 유니온 및 불변성을 위한 다양한 마커 태그를 포함합니다. 주요 이점 중 하나는 "ambient ratcheting"으로, 기존 객체를 중단하지 않고 검증을 즉시 강화하거나 완화할 수 있습니다. 선언적 검증은 kube-api-linter와 같은 도구를 사용하여 API 검토를 더 쉽고 일관되게 만듭니다. 이 프로젝트는 나머지 레거시 코드를 마이그레이션하고 새로운 API에 대해 선언적 검증을 의무화할 계획입니다. 또한 kubectl과 같은 도구의 클라이언트 측 검증 및 Kubebuilder와 같은 도구와의 통합과 같은 향후 생태계 이점을 제공합니다. 마이그레이션은 진행 중이며 Kubernetes 코드베이스에 기여할 기회가 있습니다. 이 문서는 기여자들에 대한 감사를 표하며 Kubernetes 검증의 선언적 미래를 환영하며 마무리됩니다.

Kubernetes v1.36: Declarative Validation Graduates to GA kubernetes.io

RSS Hunter • 5월 5일

Kubernetes v1.36: 삭제할 수 없는 입학 정책

Kubernetes의 v1.36에 도입된 매니페스트 기반 Admission Control은 클러스터 부트스트랩 중 보안 정책 시행의 격차를 해결합니다. 기존 API 기반 Admission Control은 취약점이 있습니다. 정책은 API 객체이며 제거될 수 있어 보안 창이 발생합니다. 이 새로운 기능은 API 서버가 시작 시 로드하는 파일로 Admission Webhook 및 CEL 기반 정책을 정의할 수 있도록 합니다. 이를 통해 정책이 어떤 요청이 처리되기 전에 활성화되어 무단 수정을 방지합니다. 이는 AdmissionConfiguration 파일의 staticManifestsDir 필드를 사용하여 정책 YAML 파일이 포함된 디렉토리를 지정합니다. 이 파일들은 API 기반 구성과 구별하기 위해 .static.k8s.io로 끝나는 이름을 가져야 합니다. 이 기능은 Admission 구성 자체를 삭제 또는 수정으로부터 보호할 수 있습니다. 매니페스트 파일의 변경 사항은 런타임에 자동으로 업데이트됩니다. API 서버는 시작 시 엄격한 유효성 검사를 시행하고 런타임 업데이트를 원자적으로 처리합니다. 이를 구현하려면 ManifestBasedAdmissionControlConfig 기능 게이트를 활성화해야 합니다.

Kubernetes v1.36: Admission Policies That Can't Be Deleted kubernetes.io

RSS Hunter • 5월 4일

Kubernetes v1.36: 포드 레벨 자원 관리자 (알파)

Kubernetes v1.36은 알파 기능으로 Pod-Level Resource Managers를 도입하여 성능에 민감한 워크로드의 리소스 관리를 향상시킵니다. 이는 kubelet의 Topology, CPU, Memory Managers를 컨테이너별 사양을 넘어선 포드 중심의 리소스 할당 모델로 확장합니다. 이를 통해 주요 애플리케이션 컨테이너에 대한 독점적이고 NUMA 정렬된 리소스를 제공하는 동시에 경량 사이드카를 효율적으로 지원하는 과제를 해결합니다. 이전에는 예측 가능한 성능을 달성하기 위해 종종 모든 컨테이너에 독점 리소스를 할당해야 했지만, 이는 사이드카에 비효율적이었습니다. 그렇지 않으면 포드의 Guaranteed QoS를 희생해야 했습니다. Pod-level resource managers는 하이브리드 할당을 가능하게 하여 고성능 워크로드가 리소스를 낭비하지 않고 NUMA 정렬을 달성할 수 있도록 합니다. 예를 들어, 지연 시간에 민감한 데이터베이스 포드는 메인 컨테이너가 독점 CPU 및 메모리를 받고, 사이드카는 다른 노드 리소스와 격리된 별도의 포드 공유 풀을 공유할 수 있습니다. 또 다른 사용 사례는 ML 워크로드로, 학습 컨테이너가 독점적인 NUMA 정렬 리소스를 받고, 서비스 메시 사이드카가 일반적인 노드 전체 공유 풀에서 실행됩니다. CPU 격리는 독점 컨테이너에 대한 CFS 쿼터 적용을 비활성화하고 공유 풀 컨테이너에 대해 포드 수준에서 적용함으로써 관리됩니다. 활성화하려면 특정 kubelet 기능 게이트, Topology Manager 정책 및 정적 CPU 및 Memory Manager 구성이 필요합니다. 새로운 kubelet 메트릭은 리소스 할당 및 컨테이너 할당에 대한 관찰 가능성을 제공합니다. 이 기능은 현재 알파 단계이며 알려진 제한 사항과 주의 사항이 있으며, Kubernetes 커뮤니티 채널을 통해 사용자 피드백을 권장합니다.

Kubernetes v1.36: Pod-Level Resource Managers (Alpha) kubernetes.io

RSS Hunter • 5월 1일

쿠버네티스 v1.36: Pod 수준 리소스의 인플레이스 수직 스케일링, 베타 버전으로 승격

Kubernetes v1.36은 In-Place Pod-Level Resources Vertical Scaling을 도입했으며, 현재 Beta이며 기본적으로 활성화되어 있습니다. 이 기능은 사용자가 실행 중인 Pod의 집계 리소스 제한을 동적으로 조정할 수 있도록 합니다. 이는 공유 리소스를 사용하고 컨테이너별 제한이 없는 Pod에 특히 유용합니다. Kubelet은 각 컨테이너의 resizePolicy에 따라 업데이트 방법을 결정하여, 즉시 업데이트 또는 재시작 중에서 선택합니다. 리사이즈가 발생하면 Kubelet은 먼저 노드에 충분한 리소스가 있는지 확인합니다. 그런 다음 리소스 초과를 방지하기 위해 cgroup 업데이트를 순차적으로 진행하며, 개별 컨테이너 cgroup이 확장되기 전에 pod-level cgroup을 확장합니다. PodResizeInProgress와 같은 Pod 조건은 리사이즈의 진행 상황과 상태를 추적합니다. 이 기능은 cgroup v2, CRI 지원, 특정 기능 게이트 및 Linux 기반 노드를 필요로 합니다. 다음 단계는 이를 Vertical Pod Autoscaler (VPA)와 통합하는 것입니다. 사용자들은 이 기능을 테스트하고 커뮤니티 채널을 통해 피드백을 제공하도록 권장됩니다.

Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta kubernetes.io

RSS Hunter • 4월 30일

Kubernetes v1.36: 메모리 QoS를 통한 계층형 메모리 보호

Kubernetes v1.36은 컨테이너 메모리 관리를 개선하기 위해 cgroup v2를 사용하는 Memory QoS 기능에 대한 업데이트를 도입합니다. v1.36의 주요 업데이트에는 계층화된 보호를 제공하는 옵트인 메모리 예약이 포함되며, 이는 Pod QoS 클래스를 기반으로 합니다. Guaranteed Pod는 이제 하드 메모리 보호(memory.min)를 받고, Burstable Pod는 소프트 보호(memory.low)를 받습니다. BestEffort Pod는 특별한 보호 없이 완전히 회수 가능한 상태로 유지됩니다. 새로운 memoryReservationPolicy는 스로틀링과 예약의 별도 제어를 허용합니다. 노드 전반의 memory.min 및 memory.low 사용량을 모니터링하기 위한 관찰 가능성 메트릭이 제공됩니다. 커널 버전 확인은 잠재적인 라이브락 문제로 인해 커널이 5.9보다 오래된 경우 사용자에게 경고합니다. 이 구현은 memory.max, memory.min, memory.low, memory.high cgroup v2 인터페이스를 활용합니다. 노드 메모리 할당은 kubelet에 의해 관리되며, 각 pod와 QoS 클래스에 대한 적절한 보호를 보장합니다. 이 기능은 kubelet 구성을 통해 활성화할 수 있으며, TieredReservation이 핵심 설정입니다. 권장되는 사전 요구 사항은 Kubernetes v1.36 이상, cgroup v2 및 커널 5.9 이상을 갖춘 Linux입니다. 사용자는 피드백 및 기여를 위해 SIG Node 커뮤니티와 참여할 수 있습니다.

Kubernetes v1.36: Tiered Memory Protection with Memory QoS kubernetes.io

RSS Hunter • 4월 29일

Kubernetes v1.36: 컨트롤러의 정체 완화 및 가시성

쿠버네티스 컨트롤러는 오래된 캐시 데이터로 인해 부정확하거나 지연된 동작으로 이어질 수 있는 스탤런트 문제를 겪을 수 있습니다. 부실 상태는 컨트롤러의 로컬 캐시가 클러스터의 실제 상태와 동기화되지 않아서 발생합니다. 쿠버네티스 v1.36에는 부실 상태를 완화하고 컨트롤러 동작을 개선하는 기능이 도입되었습니다. 이러한 개선 사항에는 클라이언트-고에서 원자 FIFO 처리, 큐 일관성 향상 등이 포함됩니다. kube-controller-manager는 이러한 클라이언트-고 개선 사항을 데몬셋과 레플리카셋과 같은 여러 주요 컨트롤러에 통합했습니다. 이러한 컨트롤러는 이제 작동하기 전에 캐시 리소스 버전을 확인하여 오래된 데이터에 대한 작업을 방지합니다. 인포머 작성자는 일관성 저장소를 사용하여 리소스 버전을 추적하고 관리하여 컨트롤러의 부실함을 완화할 수 있습니다. 컨시스턴시스토어는 쓰기 기록, 캐시 준비 상태 확인, 오래된 오브젝트 항목 지우기 기능을 제공합니다. 또한 쿠버네티스 v1.36은 부실로 인해 건너뛴 동기화 횟수를 포함하여 컨트롤러 상태를 모니터링하기 위한 새로운 메트릭을 제공합니다. Client-go는 이제 공유된 정보 제공자의 최신 리소스 버전을 노출하는 메트릭도 생성합니다. 쿠버네티스 팀은 이러한 부실함 완화 기능을 더 많은 컨트롤러로 확장하고 컨트롤러 런타임에 통합할 계획입니다. 사용자 피드백과 향후 개발을 장려합니다.

Kubernetes v1.36: Staleness Mitigation and Observability for Controllers kubernetes.io

RSS Hunter • 4월 28일

쿠버네티스 v1.36: 일시 중단된 Job의 변경 가능한 Pod 리소스 (베타)

Kubernetes v1.36에서는 일시 중지된 Job의 Pod 템플릿에서 컨테이너 리소스 요청 및 제한을 수정하는 기능이 베타로 승격되었습니다. v1.35에서 알파로 도입된 이 기능은 큐 컨트롤러와 관리자가 Job이 실행되기 전에 일시 중지된 상태에서 CPU, 메모리, GPU와 같은 리소스 사양을 조정할 수 있도록 합니다. 이전에는 리소스 요구 사항이 설정되면 변경할 수 없었기 때문에 Job을 삭제하고 다시 생성해야 했으며, 이 과정에서 중요한 메타데이터를 잃게 되었습니다. 이 새로운 기능은 Job 생성 시 리소스 요구 사항을 정확히 알 수 없거나 클러스터 용량이 변동하는 상황을 해결합니다. 예를 들어, 큐 컨트롤러는 이제 머신 러닝 Job의 GPU 요청을 4개에서 2개로 줄일 수 있습니다. Kubernetes API 서버는 일시 중지된 Job에 대해 특정 리소스 필드의 불변성 제약을 완화하며, Job의 spec.suspend가 true여야 하고 이전에 실행 중이었다면 모든 활성 Pod가 종료되어야 합니다. 베타 버전에서는 MutablePodResourcesForSuspendedJobs 기능 게이트가 v1.36에서 기본적으로 활성화됩니다. 사용자는 일시 중지된 Job을 생성하고, 리소스를 편집한 다음, 다시 시작하여 이 기능을 테스트할 수 있습니다. 일시 중지된 실행 중인 Job의 리소스를 수정하기 전에 모든 활성 Pod가 종료되도록 하는 것이 불일치를 방지하는 데 중요합니다.

Kubernetes v1.36: Mutable Pod Resources for Suspended Jobs (beta) kubernetes.io

RSS Hunter • 4월 27일

쿠버네티스 v1.36: 세분화된 Kubelet API 권한 부여, 정식 출시 (GA)

세분화된 kubelet API 권한 부여가 Kubernetes v1.36에서 정식 버전으로 출시되었습니다. 이 기능은 지나치게 광범위한 노드/프록시 권한을 대체하여 kubelet의 HTTPS API 액세스에 대한 보안을 개선합니다. 이 이니셔티브는 모니터링 도구에 과도한 권한을 부여하는 데 따른 보안 위험을 해결합니다. 이전에는 명령 실행을 허용하는 노드/프록시가 자주 사용되었습니다. 세분화된 권한 부여는 특정 kubelet API 경로를 보다 전용화된 하위 리소스에 매핑합니다. 시스템은 이전 버전과의 호환성을 위해 이중 권한 검사를 수행합니다. 노드/프록시 권한이 있는 기존 워크로드는 이전처럼 계속 작동합니다. 기본 제공 system:kubelet-api-admin 클러스터 역할이 자동으로 업데이트됩니다. 이제 모니터링 도구가 노드/메트릭과 같은 특정 리소스를 활용하여 최소 권한 액세스를 개선할 수 있습니다. 이 업그레이드는 대부분의 클러스터에 대해 변경이 필요하지 않습니다. 기능을 확인하려면 curl을 사용하여 기능 플래그를 확인하는 파드를 실행하면 됩니다. 다음 단계에서는 더 많은 에코시스템 적응이 필요하며, 노드/프록시의 사용 중단이 발생할 수도 있습니다.

Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA kubernetes.io

RSS Hunter • 4월 24일

쿠버네티스 v1.36: 쿠버네티스 사용자 네임스페이스가 드디어 GA(정식 출시)됩니다.

"Kubernetes v1.36은 컨테이너화된 워크로드에 대한 향상된 보안 격리를 지원하는 Linux 전용 기능인 사용자 네임스페이스에 대한 일반 공급(General Availability) 지원을 도입했습니다. 이 오랫동안 기다려온 이정표는 Kubernetes 애플리케이션에 대한 "루트 없는(rootless)" 보안 격리를 가능하게 합니다.중요한 기능은 hostUsers: false를 설정하여 사용자 네임스페이스 내에 격리된 상태로 권한을 가진 워크로드를 실행하는 것입니다. 이를 통해 CAP_NET_ADMIN과 같은 특정 기능이 네임스페이스화되어 로컬 컨테이너 리소스에 대한 관리자 권한만 부여됩니다. 이전에는 컨테이너 내에서 루트 권한을 가진 프로세스가 호스트에서도 루트 권한을 가졌기 때문에 탈출 시 상당한 보안 위험을 초래했습니다.이 기능의 핵심적인 지원 기술은 ID 매핑 마운트(ID-mapped mounts)로, 디스크 소유권을 변경하지 않고 마운트 시점에 UID 및 GID를 투명하게 다시 매핑합니다. 이는 초기 개발 단계에서 문제가 되었던 볼륨 소유권 업데이트와 관련된 성능 문제를 해결합니다.사용자 네임스페이스 구현은 간단합니다. Pod 사양에서 hostUsers: false를 설정하기만 하면 되며, 컨테이너 이미지나 복잡한 구성 변경이 필요하지 않습니다. 이 기능은 알파 단계에서 도입된 것과 동일한 인터페이스를 활용합니다. 이러한 발전은 Kubernetes SIG Node, 컨테이너 런타임 및 Linux 커널 간의 수년간의 프로젝트 간 협업을 대표합니다."

Kubernetes v1.36: User Namespaces in Kubernetes are finally GA kubernetes.io

RSS Hunter • 4월 23일

SELinux 볼륨 레이블 변경 기능이 GA(General Availability)로 출시됩니다(그리고 v1.37에서 예상되는 영향).

Kubernetes v1.37에서는 볼륨 설정 속도를 향상시키는 SELinuxMount 기능 게이트를 기본적으로 활성화할 계획입니다. 이 변경 사항은 특히 권한 있는 파드와 권한 없는 파드 간에 볼륨을 공유하는 애플리케이션의 경우, 이전의 재귀적 레이블 재지정 방식에 의존하는 애플리케이션을 손상시킬 수 있습니다. 이 기사에서는 v1.36 클러스터를 감사하여 SELinux 관련 잠재적 충돌을 식별하고 해결하도록 권장합니다. SELinux가 활성화되면 kubelet은 접근 제어를 위해 볼륨에 SELinux 레이블을 적용하며, 새로운 접근 방식은 더 빠른 레이블 재지정을 위해 마운트 옵션을 사용합니다. SELinuxChangePolicy 필드와 Recursive 옵션은 이러한 성능 가속화 방법을 선택적으로 사용하지 않도록 하기 위해 만들어졌습니다. 조건이 충족되면 kubelet은 이제 적절한 SELinux 레이블로 볼륨을 직접 마운트할 수 있으므로 재귀적 레이블 재지정이 필요하지 않습니다. selinux-warning-controller는 새로운 구성으로 인해 손상될 수 있는 충돌하는 파드를 식별하여 이벤트와 메트릭을 내보냅니다. 제공된 메트릭을 사용하여 클러스터 관리자는 잠재적인 문제를 감지하고 적절한 조정을 할 수 있습니다. 권장되는 업그레이드 경로는 컨트롤러를 활성화하고, 충돌을 해결한 다음, 오류를 모니터링하면서 SELinuxMount가 활성화된 버전으로 업그레이드하는 것을 포함합니다. 관리자는 특정 파드에 대해 옵트아웃을 적용하기 위해 다양한 방법을 사용할 수 있습니다. 새로운 동작은 더 빠른 성능을 제공하지만 서로 다른 파드 간의 볼륨 공유 방식을 변경합니다.

SELinux Volume Label Changes goes GA (and likely implications in v1.37) kubernetes.io

RSS Hunter • 4월 22일

쿠버네티스 v1.36: 하루 (Haru)

"쿠버네티스 v1.36이 출시되었습니다. 이번 릴리스에는 70개의 기능 개선이 포함되었으며, 그중 18개는 안정화되었고 25개는 베타 버전으로 출시되었습니다. 이번 릴리스의 테마인 "하루(Haru)"는 봄, 맑은 하늘, 그리고 먼 지평선을 상징하며, 로고는 호쿠사이의 "붉은 후지"에서 영감을 받았습니다. 이번 릴리스는 많은 개인과 팀의 성공적인 기여를 통해 커뮤니티 협업을 강조합니다.주요 안정화 기능에는 최소 권한 액세스 제어를 개선하기 위한 세분화된 kubelet API 권한 부여가 포함됩니다. 할당된 장치의 리소스 상태가 베타 버전으로 출시되어 하드웨어 장애에 대한 통합 보고 기능을 제공합니다. 알파 버전에는 관련 파드를 단일 논리적 엔티티로 취급하여 리소스 관리를 개선하는 워크로드 인식 스케줄링이 도입되었습니다.볼륨 그룹 스냅샷이 안정화되어 여러 PersistentVolumeClaim에 걸쳐 충돌 없는 스냅샷을 생성할 수 있습니다. 변경 가능한 CSI 노드 할당 가능 제한도 안정화되어 노드 볼륨 용량을 동적으로 업데이트할 수 있습니다. 외부 ServiceAccount 토큰 서명자 기능이 안정화되어 토큰 서명을 외부 시스템으로 오프로드할 수 있습니다.동적 리소스 할당(DRA) 관리자 액세스 및 우선순위 목록이 안정화되어 리소스 관리를 위한 안전한 프레임워크를 제공합니다. 선언적 변경 가능 Admission 정책이 안정화되어 리소스 변경에 대한 웹훅의 네이티브 대안을 제공합니다. validation-gen을 사용한 쿠버네티스 네이티브 타입에 대한 선언적 유효성 검사도 안정화되어 사용자 정의 리소스 개발을 간소화합니다. 쿠버네티스 API 타입에 대한 gogo protobuf 종속성 제거는 보안 및 유지 관리성 측면에서 중요한 진전을 이루었습니다."

Kubernetes v1.36: ハル (Haru) kubernetes.io

RSS Hunter • 4월 22일

게이트웨이 API v1.5: 기능 안정화

Gateway API v1.5는 2026년 3월 14일에 출시되었으며, 지금까지 가장 중요한 릴리스입니다. 이 버전은 이전에 실험적이었던 여러 기능을 안정 채널로 승격하는 데 중점을 둡니다. 주요 승격 기능에는 ListenerSet, TLSRoute, HTTPRoute CORS 필터, 클라이언트 인증서 유효성 검사, Gateway TLS 오리진을 위한 인증서 선택, ReferenceGrant가 포함됩니다. 이 프로젝트는 Kubernetes SIG Release와 동기화하여 보다 예측 가능한 업데이트를 위해 릴리스 트레인 모델을 채택했습니다. 이 새로운 프로세스에는 전담 릴리스 관리자 및 릴리스 섀도우 역할이 포함됩니다. ListenerSet을 사용하면 리스너를 독립적으로 정의하고 게이트웨이에 병합하여 확장성과 멀티 테넌시를 향상시킬 수 있습니다. TLSRoute는 TLS 연결에 대한 SNI를 기반으로 라우팅을 가능하게 하며, Passthrough 및 Terminate 모드를 모두 지원합니다. HTTPRoute CORS 필터는 교차 출처 리소스 공유 설정에 대한 세분화된 제어를 제공합니다. 클라이언트 인증서 유효성 검사 또는 상호 TLS(mTLS)를 사용하면 게이트웨이가 신뢰할 수 있는 CA에 대한 인증서를 확인하여 클라이언트 ID를 확인할 수 있습니다. 이 기능은 향상된 보안을 위해 전역적으로 또는 포별로 구성할 수 있습니다.

Gateway API v1.5: Moving features to Stable kubernetes.io

RSS Hunter • 4월 21일

Kubernetes v1.36 Sneak Peek

2026년 4월 말에 출시될 예정인 Kubernetes v1.36은 상당한 제거, 사용 중단, 그리고 수많은 개선 사항을 도입할 예정입니다. 이 프로젝트는 엄격한 사용 중단 정책을 준수하며, 안정적인 API는 더 새로운 안정 버전이 출시되고 최소 수명이 보장된 후에만 제거됩니다. 이 정책의 최근 예시로는 2026년 3월 24일을 기점으로 Ingress NGINX 프로젝트가 더 이상 지원이나 보안 업데이트 없이 종료된 것입니다. v1.36에서는 보안 문제(CVE-2020-8554)로 인해 Service의 .spec.externalIPs 필드가 사용 중단될 예정이며, v1.43에서 완전히 제거될 예정이므로 LoadBalancer, NodePort 또는 Gateway API로의 마이그레이션을 권장합니다. v1.11부터 사용 중단된 gitRepo 볼륨 드라이버는 루트 코드 실행을 허용하는 치명적인 보안 취약점으로 인해 v1.36에서 영구적으로 비활성화될 예정입니다. 현재 gitRepo를 사용하는 워크로드는 init 컨테이너 또는 외부 git-sync 도구와 같은 대안으로 마이그레이션해야 합니다.v1.36의 주요 개선 사항으로는 볼륨에 대한 더 빠른 SELinux 레이블링의 일반 출시(GA)가 있습니다. 이는 일관된 성능과 Pod 시작 지연 감소를 위해 마운트 옵션을 사용합니다. v1.28에서 베타로 도입된 이 기능은 이제 spec.SELinuxMount를 지정하는 Pod가 있는 모든 볼륨에 기본적으로 적용됩니다. ServiceAccount 토큰의 외부 서명은 베타 기능으로, v1.36에서 안정화될 예정이며, 클러스터가 향상된 보안을 위해 외부 키 관리 시스템과 통합할 수 있도록 합니다. 동적 리소스 할당(DRA) 또한 발전하여, Device taint 및 toleration이 베타로 전환되어 특수 하드웨어 리소스를 특정 워크로드로 제한할 수 있게 됩니다. 또한 DRA는 분할 가능한 장치를 지원하여 단일 하드웨어 가속기를 여러 논리 단위로 분할하여 GPU와 같은 고가의 리소스의 리소스 활용률을 향상시킬 것입니다. 이러한 변경 사항은 Kubernetes 내에서 보안, 효율성 및 고급 리소스 관리에 대한 지속적인 초점을 강조합니다.

Kubernetes v1.36 Sneak Peek kubernetes.io

RSS Hunter • 3월 30일

Ingress2Gateway 1.0 발표: 게이트웨이 API로 가는 길

Ingress-NGINX는 2026년 3월에 퇴역할 예정이며, 이로 인해 게이트웨이 API로의 마이그레이션이 필요합니다. Ingress에서 Gateway API로의 마이그레이션은 확장 주석에서 모듈적이고 확장 가능한 API로의 전환이라는 중요한 변화입니다. Ingress2Gateway 도구는 Ingress 리소스와 주석을 번역하여 팀이 이 전환을 돕습니다. SIG 네트워크는 안정적인 마이그레이션 어시스턴트인 Ingress2Gateway 버전 1.0을 출시했습니다. 이번 새 릴리스는 Ingress-NGINX 주석 지원을 크게 개선하여 30개 이상의 일반 주석을 포함합니다. 포괄적인 통합 테스트를 통해 Ingress-NGINX 구성과 생성된 게이트웨이 API 매니페스트의 동작 동등성을 보장합니다. Ingress2Gateway는 번역 불가능한 구성에 대한 명확한 알림과 수동 개입 제안도 제공합니다. 이 도구는 지원되는 구성을 마이그레이션하고, 지원되지 않는 구성을 식별하며, 기존 설정의 재평가를 유도하는 것을 목표로 합니다. 사용자는 Ingress 매니페스트를 제공하거나 클러스터에 연결하여 Ingress2Gateway를 설치하고 실행합니다. 특히 사용자는 생성된 출력과 경고를 검토하여 정확한 번역을 확인하고 잠재적 문제를 식별해야 합니다. Ingress2Gateway는 대부분의 과정을 자동화하지만, Gateway API 매니페스트의 수동 검증과 조정이 필수적입니다.

Announcing Ingress2Gateway 1.0: Your Path to Gateway API kubernetes.io

RSS Hunter • 3월 20일

에이전트 샌드박스를 이용한 쿠버네티스에서 에이전트 실행

생성형 AI는 상태 비저장 함수 호출에서 지속적으로 실행되고 조정되는 AI 에이전트 시스템으로 진화하고 있습니다. 이러한 에이전트는 지속적인 컨텍스트, 도구 사용, 코드 실행, 그리고 장기간에 걸친 에이전트 간 통신을 필요로 합니다. Kubernetes는 이러한 워크로드에 이상적인 인프라이지만, 기존의 기본 요소들은 이러한 상태 저장, 싱글톤 에이전트의 요구 사항에 완벽하게 부합하지 않습니다. SIG Apps에서 개발 중인 새로운 Kubernetes Agent Sandbox 프로젝트는 이러한 격차를 해소하는 것을 목표로 합니다. 이 프로젝트는 AI 에이전트 런타임을 관리하기 위한 사용자 정의 리소스 정의(CRD)를 도입합니다. Sandbox CRD는 gVisor 또는 Kata Containers와 같은 런타임을 사용하여 신뢰할 수 없는 코드 실행에 대한 강력한 격리를 제공합니다. 또한 유휴 상태일 때 에이전트를 0으로 축소하고 즉시 재개할 수 있는 강력한 라이프사이클 관리를 제공합니다. 더 나아가, 각 Sandbox는 원활한 에이전트 간 통신을 위해 안정적인 ID를 할당받습니다. 빠르게 변화하는 AI 분야의 개발을 가속화하기 위해 Extensions API 레이어가 제공됩니다. SandboxWarmPool 확장은 즉시 사용할 준비가 된 사전 프로비저닝된 Sandbox pod 풀을 유지하여 콜드 스타트를 제거합니다. 사용자는 핵심 및 확장 구성 요소를 Kubernetes 클러스터에 설치할 수 있습니다. Agent Sandbox 프로젝트는 오픈 소스이며, 클라우드 네이티브 AI 에이전트의 미래를 구축하기 위한 커뮤니티 참여를 환영합니다.

Running Agents on Kubernetes with Agent Sandbox kubernetes.io

RSS Hunter • 3월 20일

쿠버네티스에서 프로덕션 디버깅 보안

생산 디버깅은 종종 광범위한 접근에 의존하며, 이는 감사 및 보안 위험을 초래합니다. 이 게시물에서는 Kubernetes에서 안전한 디버깅 방식을 구현하는 것을 권장합니다. 주요 전략으로는 역할 기반 접근 제어(RBAC)를 활용하여 최소 권한을 사용하는 것입니다. 세션 보안 및 책임성을 위해 단기적이고 ID에 바인딩된 자격 증명이 중요합니다. SSH 스타일의 게이트웨이는 "정문" 역할을 하며, 접근을 일시적으로 만듭니다. 접근 브로커는 RBAC를 강화하여 명령을 제어하고 승인을 요구할 수 있습니다. Kubernetes RBAC는 허용된 작업을 정의하며, 일반적으로 개인보다는 그룹에 접근 권한을 부여합니다. OIDC 토큰이나 클라이언트 인증서와 같은 단기 자격 증명은 세션을 사용자와 연결하고 만료됩니다. 이러한 자격 증명은 이상적으로 정기적으로 순환되는 인증 기관(CA)에 의해 서명됩니다. SSH를 통해 제공되는 Just-In-Time 접근 게이트웨이는 안전한 디버깅 세션을 제공합니다. 게이트웨이는 자격 증명을 사용하여 사용자를 인증한 다음, Kubernetes API와 상호 작용하기 전에 정책을 적용합니다. 세션의 범위는 특정 클러스터 및 네임스페이스로 제한될 수 있습니다.

Securing Production Debugging in Kubernetes kubernetes.io

RSS Hunter • 3월 18일

보이지 않는 재작성: 쿠버네티스 이미지 프로모터 현대화

Kubernetes 이미지 프로모터인 kpromo가 성능과 유지보수성을 향상시키기 위해 완전히 재작성되었습니다. 핵심 기능은 컨테이너 이미지를 스테이징 레지스트리에서 프로덕션 레지스트리로 복사하고, 서명하며, 서명을 복제하고, Kubernetes 릴리스에 필수적인 증명을 생성하는 것입니다. 재작성은 기존 코드베이스의 복잡성, 느린 성능, 잦은 속도 제한 오류로 인해 시작되었습니다. 프로젝트는 속도 제한, 인터페이스, 파이프라인 엔진 및 보안 기능을 해결하는 단계적 접근 방식을 따랐습니다. 주요 개선 사항으로는 파이프라인 엔진 간소화, 레지스트리 읽기 병렬화, 타임아웃 및 연결 재사용 구현 등이 있습니다. 재작성 결과 코드베이스가 20% 작아졌으며 성능, 견고성, 그리고 프로비넌스와 같은 새로운 기능이 향상되었습니다. 광범위한 변경에도 불구하고 재작성 팀은 사용자 워크플로우를 깨뜨리지 않기 위해 노력했습니다. 팀은 단계적 릴리스 동안 사소한 회귀를 식별하고 빠르게 수정했습니다. 향후 계획에는 서명 복제를 제거하여 더욱 간소화하고, 라우팅을 위해 archeio를 사용하거나 서명을 레지스트리 인프라에 더 가깝게 통합하는 것이 포함됩니다. 이 프로젝트는 오랜 커뮤니티 노력의 결과였습니다.

The Invisible Rewrite: Modernizing the Kubernetes Image Promoter kubernetes.io

RSS Hunter • 3월 17일

AI 게이트웨이 워킹 그룹 발표

쿠버네티스 커뮤니티는 AI 워크로드 네트워킹에 중점을 둔 AI 게이트웨이 워킹 그룹의 결성으로 확장되고 있습니다. AI 게이트웨이는 Gateway API를 사용하여 AI 워크로드에 맞게 향상된 네트워크 인프라입니다. 여기에는 토큰 기반 속도 제한, 접근 제어 및 페이로드 검사와 같은 기능이 포함됩니다. 이 워킹 그룹은 쿠버네티스에서 AI 인프라를 위한 표준 및 모범 사례를 만드는 것을 목표로 합니다. 그들의 목표는 API를 만들고, 협업을 촉진하며, AI 특정 게이트웨이 확장을 위한 확장성을 보장하는 것입니다. 활발한 제안은 보안 및 최적화를 위한 페이로드 처리와 이그레스 게이트웨이 정의를 다룹니다. 이러한 제안은 안전한 외부 AI 서비스 통합 및 고급 트래픽 관리를 가능하게 합니다. 이 그룹은 플랫폼 운영자, 개발자 및 규정 준수 엔지니어의 요구 사항을 다룹니다. 워킹 그룹은 KubeCon + CloudNativeCon Europe 2026에서 그들의 연구 결과를 발표할 예정입니다. AI 게이트웨이 워킹 그룹은 쿠버네티스 내에서 AI 인식 게이트웨이 기능의 미래를 형성하기 위해 다양한 이해 관계자의 기여를 환영합니다. 관심 있는 개인은 제안을 검토하고, 회의에 참여하며, 토론에 참여할 수 있습니다. 이 그룹은 AI 워크로드 네트워킹을 위한 표준을 개발하기 위해 개방형 기여 모델로 운영됩니다.

Announcing the AI Gateway Working Group kubernetes.io

RSS Hunter • 3월 9일

이주하기 전에: 알고 있어야 할 다섯 가지 놀라운 Ingress-NGINX 동작

2026년 3월에 Kubernetes는 Ingress-NGINX를 폐기할 예정이며, 사용자는 Gateway API와 같은 다른 솔루션으로 마이그레이션해야 합니다. Ingress-NGINX는 마이그레이션 과정에서 고려하지 않으면 장애를 유발할 수 있는 몇 가지 놀라운 기본값과 부작용을 가지고 있습니다. 이 블로그 게시물은 사용자가 안전하게 마이그레이션하고 어떤 동작을 유지할지 신중하게 결정할 수 있도록 이러한 동작을 강조합니다. 주요 문제 중 하나는 Ingress-NGINX가 정규식 패턴을 접두사 및 대소문자를 구분하지 않는 일치로 처리하여 예기치 않은 라우팅을 초래할 수 있다는 것입니다. 반면, Gateway API는 구현별 정규식 일치를 사용하며, 사용자는 정규식 일치의 의미를 확인하기 위해 해당 구현을 확인해야 합니다. 이 게시물은 또한 RegularExpression 유형의 HTTP 경로 일치를 사용하고 HTTP 요청 리디렉션 필터를 사용하여 리디렉션을 구성하는 등 Gateway API에서 Ingress-NGINX 동작을 유지하는 방법에 대해 논의합니다. 또한 이 게시물은 Ingress-NGINX와 NGINX Ingress가 두 개의 별도 Ingress 컨트롤러이며, 이 블로그 게시물에서는 Ingress-NGINX만 다룬다는 점을 언급합니다. nginx.ingress.kubernetes.io/use-regex 주석은 모든 Ingress-NGINX Ingress의 호스트에 있는 모든 경로에 적용되며, nginx.ingress.kubernetes.io/rewrite-target 주석은 모든 부작용과 함께 nginx.ingress.kubernetes.io/use-regex 주석을 자동으로 추가합니다. Ingress-NGINX는 또한 후행 슬래시가 없는 요청을 후행 슬래시가 있는 동일한 경로로 리디렉션하는데, 이는 Gateway API에서 명시적으로 구성되지 않으면 장애를 유발할 수 있습니다. 전반적으로 이 게시물은 사용자가 Ingress-NGINX의 특성을 이해하고 Gateway API로 안전하게 마이그레이션할 수 있도록 돕는 것을 목표로 합니다. 사용자는 이러한 동작을 인식하고 장애를 방지하기 위해 Gateway API에서 이를 유지하기 위한 조치를 취해야 합니다.

Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know kubernetes.io

RSS Hunter • 2월 27일

SIG 아키텍처에 대한 스포트라이트: API 거버넌스

조던 리깃은 혁신과 API 안정성의 균형을 맞추는 것을 목표로 하는 Kubernetes API 거버넌스 하위 프로젝트를 이끌고 있습니다. 이 프로젝트는 REST API뿐만 아니라 명령줄 플래그 및 구성 파일을 포함한 모든 Kubernetes API를 감독합니다. 일관성과 품질을 보장하기 위해 가이드라인, 규칙, 린터와 같은 자동화된 도구를 사용합니다. API 거버넌스는 특히 KEP 프로세스를 통해 API 설계 및 구현 과정 모두에 의견을 제시합니다. Custom Resources의 도입은 API 가능성을 확장하고 향상된 유효성 검사를 필요로 하는 전환점이었습니다. API 거버넌스는 SIG 아키텍처 및 API Machinery와 협력하여 규칙을 정의하고 API Machinery의 일관된 사용을 보장합니다. 프로젝트 참여는 릴리스 주기의 개선 및 코드 동결 전에 증가합니다. 새로운 기여자는 API 변경 사항을 따르고 검토 프로세스를 관찰하는 것으로 시작해야 합니다. 이 프로젝트는 추가적인 노력이 필요하더라도 사용자의 호환성 및 안정성을 최우선으로 생각합니다. API 거버넌스의 목표는 호환성 파괴를 최소화하면서 미래의 API 진화를 계획하는 것입니다. 그들은 실수가 발생할 수 있음을 고려하고, 호환성 약속을 지키면서 개선할 준비를 합니다.

Spotlight on SIG Architecture: API Governance kubernetes.io

RSS Hunter • 2월 12일

노드 준비 컨트롤러 소개

"쿠버네티스는 표준 "Ready" 상태 외에도 노드 준비 상태와 관련하여 종종 복잡한 문제에 직면합니다. Node Readiness Controller (NRC)는 노드 테인트를 관리하기 위한 선언적 시스템을 제공하여 이러한 문제를 해결합니다. NRC는 사용자 지정 상태 신호를 사용하여 특정 인프라 요구 사항을 충족하는 노드에만 워크로드가 스케줄링되도록 보장합니다. 이는 운영자가 특정 노드 그룹에 맞게 사용자 지정 스케줄링 게이트를 정의할 수 있도록 하여 중요한 격차를 메웁니다. 이를 통해 사용자 지정 준비 상태 정의, 자동 테인트 관리 및 선언적 노드 부트스트래핑 기능을 제공합니다. 컨트롤러는 NodeReadinessRule (NRR) API를 사용하여 이러한 게이트를 정의하며, 지속적인 적용 모드와 부트스트랩 전용 적용 모드를 모두 지원합니다. 또한 Node Conditions에 반응하며 Node Problem Detector와 같은 기존 도구와 원활하게 통합됩니다. 드라이 런 모드를 통해 운영자는 실제 테인트를 적용하기 전에 영향을 시뮬레이션하여 안전성을 향상시킬 수 있습니다. 예시에서는 NRC가 사용자 지정 상태 및 테인트를 사용하여 CNI 에이전트 기능을 보장하는 방법을 보여줍니다. 이 프로젝트는 커뮤니티의 피드백을 적극적으로 구하고 있으며, GitHub, Slack 및 문서 채널을 통해 기여를 장려합니다. NRC는 노드 준비 상태 프로세스를 개선하고 쿠버네티스의 스케줄링 기능을 발전시키는 것을 목표로 합니다. 다가오는 KubeCon Europe 2026에서는 이 주제에 초점을 맞춘 유지 관리자 트랙 세션이 열릴 예정입니다."

Introducing Node Readiness Controller kubernetes.io

RSS Hunter • 2월 3일

cgroup v1 CPU Shares에서 v2 CPU Weight로의 새로운 변환

이 문서는 cgroup v1의 CPU shares를 cgroup v2의 CPU weight로 매핑하는 개선된 변환 공식을 발표합니다. 기존의 선형 공식은 Kubernetes 워크로드의 성능을 제한하는 두 가지 주요 문제를 야기했습니다. 첫 번째 문제는 cgroup v2에서 Kubernetes 워크로드의 CPU 우선순위가 비 Kubernetes 프로세스보다 낮아지는 것이었습니다. 두 번째 문제는 컨테이너 내에서 리소스를 분배하는 데 세분성이 부족하다는 것이었습니다.새로운 접근 방식은 이러한 문제를 해결하기 위해 더 복잡한 이차 공식을 사용합니다. 새로운 변환 공식은 특히 1개의 CPU를 요청하는 컨테이너에 대해 더 나은 우선순위 정렬을 제공하는 것을 목표로 합니다. 또한 새로운 공식은 컨테이너 내에서 리소스를 분배하는 데 향상된 세분성을 제공하여 미세 조정된 CPU 리소스 분배를 더 잘 지원합니다.이 개선 사항은 OCI 레이어에서 구현되므로 OCI 런타임에 의존합니다. Runc 버전 1.3.2 이상 및 crun 버전 1.23 이상은 새로운 공식을 지원합니다. 기존의 선형 공식에 의존하는 도구나 모니터링 시스템을 사용하는 배포는 업데이트가 필요할 수 있습니다. Kubernetes 프로젝트는 호환성을 보장하기 위해 비 프로덕션 환경에서 업데이트된 공식을 테스트할 것을 권장합니다. 사용자는 제공된 링크에서 더 자세한 내용을 확인할 수 있습니다. Kubernetes 노드 특별 관심 그룹은 관련 문제에 대한 새로운 기여자를 환영합니다.

New Conversion from cgroup v1 CPU Shares to v2 CPU Weight kubernetes.io

RSS Hunter • 1월 30일

Ingress NGINX: 쿠버네티스 운영 및 보안 대응 위원회 성명

쿠버네티스 운영위원회와 보안 대응 위원회는 클라우드 네이티브 환경의 약 절반에서 사용되는 핵심 인프라 구성 요소인 Ingress NGINX의 은퇴를 2026년 3월부터 시행한다고 발표했습니다. 이 프로젝트는 수년 동안 기여자와 유지 관리자가 절실히 필요했지만, 공개적인 경고에도 불구하고 필요한 지원을 받지 못했습니다. 은퇴 후에는 버그 수정, 보안 패치 또는 업데이트가 더 이상 제공되지 않아, 사용자는 대체 솔루션으로 마이그레이션하지 않으면 공격에 취약해집니다. 위원회는 상황의 심각성과 Gateway API 또는 타사 Ingress 컨트롤러와 같은 대안으로 즉시 마이그레이션을 시작하는 것의 중요성을 강조합니다. Ingress NGINX 은퇴 후에도 계속 사용하는 것은 사용자를 공격에 취약하게 만들 것이며, 사용 가능한 대안 중 직접적인 드롭인 교체는 없으므로 계획과 엔지니어링 시간이 필요합니다. 기존 배포는 계속 작동하지만, 사용자는 공격을 받기 전까지는 영향을 받고 있다는 사실을 알지 못할 수 있으며, 클러스터 관리자 권한으로 특정 명령을 실행하여 Ingress NGINX에 대한 의존도를 확인할 수 있습니다. Ingress NGINX 프로젝트는 단 한두 명의 사람들이 여가 시간에 유지 관리해 왔으며, 광범위하게 사용됨에도 불구하고 안전하게 유지 관리하는 데 필요한 기여자를 받지 못했습니다. 위원회는 Ingress NGINX의 은퇴 결정을 가볍게 내린 것이 아니지만, 보안 결함을 악화시키는 기술적 부채와 근본적인 설계 결정 때문에 모든 사용자와 생태계 전체의 안전을 위해 필요합니다. 위원회는 사용자가 지금 클러스터를 확인하고 Ingress NGINX에 의존하는 경우 심각한 위험을 피하기 위해 마이그레이션을 계획하기 시작할 것을 촉구합니다. Ingress NGINX의 은퇴는 쿠버네티스 사용자의 상당 부분에 영향을 미치는 중요한 변화이며, 사용자는 이 문제를 해결하기 위해 즉각적인 조치를 취해야 합니다.

Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees kubernetes.io

RSS Hunter • 1월 29일

Kind 이용한 게이트웨이 API 실험

이 문서는 kind를 사용하여 Gateway API 개념을 학습하기 위한 로컬 실험 환경을 설정하는 가이드를 제공합니다. 이 설정은 프로덕션 환경에서 사용하기 위한 것이 아님을 강조합니다. 이 과정에는 kind Kubernetes 클러스터를 생성하고, LoadBalancer 서비스와 Gateway API 컨트롤러를 제공하는 cloud-provider-kind를 배포하는 작업이 포함됩니다. 사용자는 Gateway를 생성하고, 데모 에코 애플리케이션을 배포하며, 이 애플리케이션으로 트래픽을 라우팅하기 위해 HTTPRoute를 구성합니다. 가이드에는 Gateway API 구성을 테스트하는 단계가 포함되어 있으며, 일반적인 문제에 대한 문제 해결 팁을 제공합니다. 마지막으로, 생성된 모든 리소스를 제거하는 정리 프로세스를 설명하고, 프로덕션 준비가 된 구현 및 고급 Gateway API 기능을 탐색하기 위한 다음 단계를 제안합니다. 이 로컬 설정은 프로덕션 복잡성 없이 Gateway API 원리를 이해하도록 특별히 설계되었습니다. Docker, kubectl, kind, 그리고 curl이 설치되어 있어야 합니다. cloud-provider-kind 구성 요소는 필요한 컨트롤러와 CRD를 제공하여 클라우드 환경을 시뮬레이션합니다. Gateway를 생성하려면 특정 호스트 이름과 프로토콜을 허용하는 GatewayClass 및 리스너 구성을 정의해야 합니다. 에코 애플리케이션을 배포하려면 네임스페이스, 서비스 및 배포를 생성해야 합니다. HTTPRoute를 구성하면 특정 호스트 이름에 대해 Gateway가 에코 애플리케이션에 연결됩니다. 테스트에는 정의된 호스트 이름으로 Gateway의 IP 주소에 요청을 보내기 위해 curl을 사용하는 작업이 포함됩니다. 문제 해결을 위해 리소스 상태 및 컨트롤러 로그를 확인하는 것이 좋습니다. 정리 작업에는 네임스페이스 삭제, cloud-provider-kind 컨테이너 중지, kind 클러스터 삭제가 포함됩니다.

Experimenting with Gateway API using kind kubernetes.io

RSS Hunter • 1월 28일

클러스터 API v1.12: 인플레이스 업데이트 및 체인 업그레이드 소개

Cluster API는 쿠버네티스 클러스터의 라이프사이클을 선언적으로 관리합니다. 쿠버네티스가 배포(Deployment)를 통해 파드를 관리하는 방식과 유사하게, 컨트롤러를 사용하여 클러스터 상태를 조정합니다. v1.12.0 릴리스는 일반적인 작업을 간소화하기 위해, 특히 인플레이스 업데이트와 체인 업그레이드에서 상당한 개선 사항을 도입했습니다. 인플레이스 업데이트는 전체 재구축 없이 머신을 수정할 수 있도록 하여, 단순성과 예측 가능성을 위해 불변 인프라 원칙을 채택합니다. 이 새로운 기능을 통해 Cluster API는 변경 사항의 특성에 따라 불변 롤아웃과 인플레이스 업데이트 중에서 지능적으로 선택할 수 있습니다. Cluster API는 자격 증명 업데이트와 같이 노드 드레인이 필요하지 않은 변경 사항에 대해 인플레이스 업데이트가 가장 유용하다고 간주합니다. 반면, 체인 업그레이드는 사용자가 단일 작업으로 여러 쿠버네티스 마이너 버전을 건너뛸 수 있도록 합니다. 이 기능은 업그레이드 계획을 계산하고 실행하여, 컨트롤 플레인 및 워커 머신 업데이트를 순차적으로 조정합니다. 워커 머신은 쿠버네티스 버전 불일치 정책이 허용하는 경우 중간 버전을 지능적으로 건너띕니다. 업데이트 확장 및 업그레이드 계획 런타임 확장을 통한 확장성은 유연성을 보장합니다. Cluster API는 쿠버네티스를 대규모로 관리하기 위해, 더 안전한 업그레이드와 중단을 줄이는 데 중점을 두고 지속적으로 발전하고 있습니다.

Cluster API v1.12: Introducing In-place Updates and Chained Upgrades kubernetes.io

RSS Hunter • 1월 27일

2025년의 헤드램프: 프로젝트 하이라이트

2025년 한 해 동안 Headlamp는 커뮤니티 참여, 플랫폼 도달 범위, 플러그인 통합 측면에서 크게 발전했습니다. 이제 이 프로젝트는 공식적으로 Kubernetes SIG UI의 일원이 되어 핵심 Kubernetes 커뮤니티 내에서 그 역할을 강화했습니다. Headlamp 개발의 중요한 측면은 Linux Foundation 멘토십 프로그램 참가자들과의 협업이었으며, 이를 통해 여러 유용한 플러그인이 개발되었습니다. 멀티 클러스터 뷰 및 프로젝트와 같은 새로운 기능이 추가되어 리소스 관리를 간소화하고 문제 해결 효율성을 향상시켰습니다. 활동 모델을 통한 향상된 탐색, 개선된 검색 및 맵 기능도 구현되었습니다. OIDC 및 인증 기능은 특히 클러스터 내 배포 환경에서 더욱 강력해졌습니다. 앱 카탈로그 및 Helm 지원이 확장되었습니다. 성능, 접근성 및 사용자 경험이 우선시되어 로딩 시간이 빨라지고 개선되었습니다. Headlamp는 또한 Kubernetes 관리를 단순화하기 위해 AI 어시스턴트를 도입했습니다. 플러그인 생태계가 확대되었으며, 향상된 플러그인 개발 도구와 더 나은 보안 업그레이드가 제공됩니다. 또한 플러그인 발견을 원활하게 하기 위해 플러그인 페이지가 생성되었습니다.

Headlamp in 2025: Project Highlights kubernetes.io

RSS Hunter • 1월 22일

체크포인트/복원 작업 그룹 발표

새로운 쿠버네티스 워킹 그룹(WG)이 쿠버네티스에 체크포인트/복원 기능을 통합하는 데 중점을 두기 위해 구성되었습니다. 이 이니셔티브는 커뮤니티 논의를 통해 다양한 사용 사례를 탐색하는 것을 목표로 합니다. 이러한 사용 사례에는 주피터 노트북 및 AI 챗봇과 같은 대화형 워크로드의 리소스 사용량 최적화가 포함됩니다. 또한 초기화 시간이 긴 애플리케이션의 시작을 가속화하는 문제도 다룹니다. 또한 WG는 주기적인 체크포인트를 통해 장기 실행 작업의 내결함성을 조사할 것입니다. 애플리케이션 상태를 보존하면서 우선순위가 낮은 파드의 선점을 허용하는 중단 인식 스케줄링도 또 다른 핵심 영역입니다. 서비스 중단 없이 로드 밸런싱 및 유지 관리를 위한 노드 간 파드 마이그레이션도 목표입니다. 또한 보안 사고 분석을 위한 포렌식 체크포인트 활성화도 고려되고 있습니다. 워킹 그룹은 쿠버네티스 커뮤니티와 CRIU(Checkpoint/Restore in Userspace) 생태계 간의 논의를 연결하고자 합니다. CRIU, checkpointctl, criu-coordinator 및 checkpoint-restore-operator와 같은 프로젝트는 이러한 사용 사례와 관련이 있습니다. 관심 있는 기여자는 회의에 참여하거나 Slack에서 참여하거나 메일링 리스트를 사용하여 WG와 소통할 수 있습니다.

Announcing the Checkpoint/Restore Working Group kubernetes.io

RSS Hunter • 1월 21일

clientcmd를 이용한 균일한 API 서버 접근

이 텍스트는 Go 언어에서 clientcmd 라이브러리를 사용하여 Kubernetes API용 명령줄 클라이언트를 만드는 방법을 설명합니다. 이 라이브러리는 kubectl의 동작을 모방합니다. clientcmd는 ~/.kube/config 및 KUBECONFIG 환경 변수와 같은 다양한 소스에서 설정을 로드하는 것을 처리합니다. kubectl과 유사하게 명령줄 플래그를 통해 설정을 재정의할 수 있습니다. 이 라이브러리는 kubeconfig 선택, 컨텍스트 및 네임스페이스 선택, 사용자 인증과 같은 기능을 지원합니다. 설정 병합은 맵에서 첫 번째 정의를 우선하고 비맵에서는 마지막 정의를 우선합니다. 사용법에는 규칙 로드, 재정의 구성, pflag를 사용한 플래그 빌드 및 바인딩, 자체 구성 빌드, 마지막으로 Kubernetes API 클라이언트 가져오기가 포함됩니다. clientcmd 패키지는 이 프로세스를 위한 함수를 제공하며, 여기에는 명령줄 인수를 설정하고 선택한 네임스페이스를 검색하는 함수가 포함됩니다. 완전한 예제가 코드 구현을 보여줍니다. 이 예제는 플래그를 사용하여 명령줄 인수를 구문 분석하고, 클라이언트를 구성하고, Kubernetes API와 상호 작용하는 방법을 보여줍니다. 텍스트는 빈 구성 오류를 확인하고 이를 우아하게 처리할 것을 권장합니다.

Uniform API server access using clientcmd kubernetes.io

RSS Hunter • 1월 19일

쿠버네티스 v1.35: kubeconfig를 통해 호출되는 실행 파일에 대한 exec 플러그인 허용 목록이 kuberc에 추가됨

kubectl은 인증을 위해 kubeconfig 파일에 지정된 실행 파일인 자격 증명 플러그인을 사용합니다. 이 기능은 유용하지만, 이러한 플러그인이 사용자 권한으로 실행되기 때문에 보안 문제를 야기합니다. 공격자는 손상된 kubeconfig 생성 파이프라인을 악용하여 악성 코드를 실행할 수 있습니다. Kubernetes 1.35는 이러한 플러그인을 자격 증명 플러그인 정책을 통해 관리하는 베타 기능을 도입합니다. 사용자는 실행 가능한 플러그인을 제어하기 위해 kuberc 구성 파일에 정책을 설정할 수 있습니다. credentialPluginPolicy는 AllowAll, DenyAll, 또는 Allowlist로 설정할 수 있습니다. Allowlist 옵션은 전체 경로 또는 기본 이름으로 특정 플러그인을 허용합니다. 보안 강화를 위해 와일드카드 및 globbing 사용을 제외하고 전체 경로를 사용하는 것이 좋습니다. 향후 개선 사항으로는 보안 강화를 위한 체크섬 검증 및 디지털 서명 확인이 포함될 예정입니다. Kubernetes 커뮤니티는 이 보안 기능을 더욱 개선하기 위한 피드백과 기여를 환영합니다. 사용자는 sig-cli 및 sig-auth 채널 내에서 토론에 참여하도록 권장됩니다. 이 보안 추가 기능은 사용자가 환경 내에서 자격 증명 플러그인의 실행을 제한하고 제어할 수 있는 방법을 제공합니다.

Kubernetes v1.35: Restricting executables invoked by kubeconfigs via exec plugin allowList added to kuberc kubernetes.io

RSS Hunter • 1월 9일

쿠버네티스 v1.35: 가변 PersistentVolume 노드 선호도 (알파)

Kubernetes v1.35에서는 변경 가능한 PersistentVolume (PV) 노드 어피니티가 도입되어, 생성 후에도 볼륨 접근성을 변경할 수 있게 되었습니다. 이전에는 변경 불가능했던 이 기능은 온라인 볼륨 관리를 용이하게 하여 진화하는 스토리지 제공업체의 역량에 대응합니다. 주요 동기는 지역 디스크 마이그레이션 및 디스크 업그레이드와 같이 노드 접근 방식이 변경되는 시나리오에서 비롯됩니다. 예를 들어, 영역 디스크에서 지역 디스크로 마이그레이션하려면 새로운 지역을 반영하도록 PV 노드 어피니티를 조정해야 합니다. 마찬가지로, 디스크를 업그레이드하려면 최신 노드 세대를 지정해야 할 수 있습니다. 이 기능을 활성화하는 동안 관리자는 PV 노드 어피니티를 수정하기 전에 기본 볼륨이 업데이트되었는지 확인해야 합니다. 스케줄러가 변경 사항을 즉시 반영하지 않으면 노드 어피니티를 강화하는 동안 경합 조건이 발생할 수 있습니다. 현재 노드 어피니티 위반 시 Kubelet이 Pod 시작에 실패하는 것을 가능한 완화 방법으로 논의하고 있습니다. 목표는 이를 VolumeAttributesClass와 통합하여 PersistentVolumeClaim을 통해 자동 업데이트를 가능하게 하는 것입니다. 이 알파 기능은 기능 게이트 활성화와 적절한 RBAC 권한이 필요합니다. Kubernetes 커뮤니티는 구현 및 사용성에 대한 사용자 및 CSI 드라이버 개발자의 피드백을 장려합니다. 이는 보다 유연하고 동적인 볼륨 관리를 위한 첫 번째 단계로 간주됩니다.

Kubernetes v1.35: Mutable PersistentVolume Node Affinity (alpha) kubernetes.io

RSS Hunter • 1월 8일

Kubernetes v1.35: CSI 드라이버에 서비스 계정 토큰을 전달하는 더 나은 방법

쿠버네티스 v1.35는 베타 기능인 CSI 드라이버를 위한 서비스 계정 토큰을 시크릿 필드를 통해 전달하는 기능을 도입했습니다. 이전에는 CSI 드라이버의 서비스 계정 토큰이 volume_context 필드를 통해 전달되었는데, 이는 민감한 데이터에 적합하지 않으며 토큰이 실수로 로깅되는 문제를 일으켰습니다. 이 새로운 기능을 사용하면 CSI 드라이버가 NodePublishVolumeRequest의 secrets 필드를 통해 이러한 토큰을 받을 수 있습니다. 이는 CSI 사양에서 민감한 정보를 위한 지정된 장소입니다. 기존의 CSI 드라이버는 기본적으로 volume_context를 통해 토큰을 계속 받게 됩니다. 이는 CSIDriver 사양의 새로운 serviceAccountTokenInSecrets 필드가 기본적으로 false로 설정되어 있기 때문입니다.이 기능을 채택하려면 CSI 드라이버 작성자는 먼저 드라이버 코드에 폴백 로직을 구현해야 합니다. 이 로직은 토큰을 위해 secrets 필드와 volume_context를 모두 확인하여, 이전 버전과 최신 버전의 쿠버네티스와의 호환성을 보장합니다. 이 업데이트된 드라이버를 배포한 후, 클러스터는 쿠버네티스 v1.35 이상으로 업그레이드되어야 하며, 이는 kube-apiserver와 kubelet 모두에 적용됩니다. 클러스터와 드라이버가 업그레이드된 후, CSIDriver 매니페스트를 업데이트하여 serviceAccountTokenInSecrets: true를 설정할 수 있습니다.기존 볼륨을 깨지지 않도록 특정 롤아웃 순서를 따라야 합니다. 폴백 로직이 포함된 드라이버 업데이트는 CSIDriver 개체를 업데이트하여 새로운 동작을 활성화하기 전에 완전히 롤아웃되어야 합니다. 이 옵트인 메커니즘은 실수로 토큰을 로깅하는 위험을 제거하고, CSI 사양의 올바른 필드를 사용하여 민감한 데이터를 처리하며, protosanitizer 툴을 사용하여 드라이버별 워크어라운드가 필요하지 않습니다. CSI 드라이버 작성자는 이 기능을 채택하고 피드백을 제공할 것을 권장합니다.

Kubernetes v1.35: A Better Way to Pass Service Account Tokens to CSI Drivers kubernetes.io

RSS Hunter • 1월 7일

쿠버네티스 v1.35: 숫자 비교를 지원하도록 Toleration 연산자 확장 (알파)

Kubernetes v1.35에서는 확장된 톨러레이션 연산자가 도입되어, 더욱 유연한 스케줄링을 위해 톨러레이션에 Gt (보다 큼) 및 Lt (보다 작음) 연산자가 추가되었습니다. 이 개선 사항은 taint와 톨러레이션의 정확한 일치를 넘어 임계값 기반 배치 기능을 제공합니다. 새로운 연산자를 통해 파드는 실패 확률 또는 시간당 비용과 같은 숫자 임계값을 지정할 수 있습니다. 이를 통해 SLA 기반 워크로드 배치가 가능해져 중요한 애플리케이션이 고위험 노드를 피할 수 있습니다. 노드는 숫자 값으로 taint되고, 파드는 톨러레이션에서 Lt 또는 Gt 연산자를 사용하여 선호도를 표현합니다. 이러한 접근 방식은 이러한 사용 사례에 대해 NodeAffinity보다 정책 지향성, 축출 및 인체 공학적 이점을 제공합니다. 예를 들어, 스팟 인스턴스에서 내결함성 작업을 스케줄링하는 동시에 중요한 워크로드를 제한할 수 있습니다. AI 워크로드는 컴퓨팅 점수를 기반으로 GPU 티어를 활용할 수 있습니다. 또한 비용 최적화가 용이해져 배치 작업이 더 저렴한 노드를 선호할 수 있습니다. 충분한 디스크 IOPS를 가진 노드에 파드를 스케줄링하는 것과 같이 성능 기반 배치도 가능합니다. 이 기능을 사용하려면 기능 게이트를 활성화하고 노드를 숫자 값으로 taint하십시오. 그런 다음 파드는 새로운 연산자를 사용하여 톨러레이션을 정의하여 노드 taint와 일치시킵니다. SIG Scheduling 커뮤니티에서 주도하는 이 알파 기능은 아직 진화하고 있습니다. 향후 계획에는 CEL(Common Expression Language) 지원 및 클러스터 자동 스케일링 통합 개선이 포함됩니다.

Kubernetes v1.35: Extended Toleration Operators to Support Numeric Comparisons (Alpha) kubernetes.io

RSS Hunter • 1월 5일