피드로 돌아가기
Introducing Node Readiness Controller
Kubernetes BlogKubernetes Blog
DevOps

Google이 Node Readiness Controller를 도입해 Kubernetes 노드의 복잡한 인프라 의존성을 선언적으로 관리하고 미준비 노드로의 Pod 배치 방지

Introducing Node Readiness Controller

2026년 2월 3일7intermediate

Context

표준 Kubernetes 모델에서 노드의 Ready 조건은 단일 이진값으로만 판단되어, 네트워크 에이전트, 스토리지 드라이버, GPU 펌웨어, 커스텀 헬스 체크 등 현대적 클러스터의 복잡한 인프라 의존성을 반영하지 못한다. 운영자들은 특정 DaemonSet이나 로컬 서비스가 정상 상태인지 확인한 후 노드를 스케줄링 풀에 포함시키도록 강제하려는 요구사항을 충족시키기 어렵다.

Technical Solution

  • NodeReadinessRule(NRR) API를 통한 선언적 게이트 정의: 플랫폼별로 "준비됨"의 의미를 커스텀하게 정의
  • 조건 기반 Taint 자동 관리: 컨트롤러가 노드 조건 상태에 따라 Taint를 동적으로 적용/제거해 미준비 노드로의 Pod 배치 차단
  • 두 가지 Enforcement Mode 제공: Continuous enforcement로 노드 라이프사이클 전체에서 준비 상태 유지, Bootstrap-only enforcement로 일회성 초기화 단계(이미지 사전 로드, 하드웨어 프로비저닝)만 모니터링
  • 기존 에코시스템과의 통합: Node Problem Detector, Readiness Condition Reporter 등 기존 도구와 커스텀 솔루션을 통해 노드 조건 수집
  • Dry-run 모드를 통한 안전한 배포: 클러스터 전체에 새 규칙을 적용하기 전에 영향받을 노드를 로그와 상태에서 확인 후 실제 Taint 적용

Key Takeaway

선언적 게이트와 자동 Taint 관리를 결합하면 다양한 인프라 요구사항을 가진 이기종 클러스터에서 노드별 준비 요구사항을 안전하게 강제할 수 있다.


GPU 장착 노드, CNI 플러그인, 스토리지 드라이버 등 초기화 요구사항이 다른 Kubernetes 클러스터 운영 시 NodeReadinessRule로 노드 그룹별 커스텀 조건을 정의하고 Dry-run 모드로 먼저 검증하면, 미준비 노드로의 Pod 배치로 인한 배포 실패와 운영자의 수동 확인 작업을 제거할 수 있다.

원문 읽기