korean-docs
Wave Diagnosis
유휴 노드 감지

Idle Node Detection

idle Node란 24시간 내내 비용을 내지만 어떤 워크로드도 쓰지 않는 Node입니다. Idle Node Detection은 이런 Node, 즉 Node 수준 DaemonSet만 돌거나 아예 아무것도 없는 Node를 찾아내고, 낭비되는 CPU와 메모리를 합산합니다. 그래서 빈 용량에 비용을 내는 대신 워크로드를 통합하거나 Node를 스케일 다운할 수 있습니다.

사이드바에서 Wave Diagnosis 아래 Idle Nodes를 여세요. 클러스터 선택기와 날짜 범위 선택기가 화면 범위를 정하고, 발견 배너는 "쓰지 않는 Node에 비용을 내고 있는가?"에 답합니다.

무엇을 idle로 보는가

Node에 애플리케이션 Pod가 하나도 없고 Node 수준 DaemonSet만 있으면 idle입니다. 이것이 Detected Reasons 컬럼이 보여주는 내용입니다: Node only contains DaemonSet pods.

Pod가 하나도 없는 것으로 읽히는 Node는 idle이 아니라 데이터 공백으로 처리됩니다(Wave 3.4.5+). 스케줄 가능한 Node라면 최소한 DaemonSet Pod는 돌고 있으므로, Pod 수가 0으로 읽혔다는 건 정말로 놀고 있는 Node라기보다 Wave의 Pod 캐시가 그 Node의 Pod를 잃어버렸다는 뜻입니다(메트릭이나 에이전트 공백 뒤 캐시 축출). 이런 Node는 판정 불가로 분류되어 idle 기록을 만들지도, 해제하지도 않습니다. 덕분에 일시적인 수집 공백이 idle Node를 깜빡이게 만들지 않습니다. 이전 버전은 이런 경우를 Node has no pods로 보고했습니다.

해제된 항목의 콘솔 상태 라벨도 3.4.5에서 active에서 resolved로 바뀌었습니다.

Pod 분류

Node가 idle인지 판단하기 위해, Wave는 먼저 그 위의 모든 Pod를 세 그룹으로 나눕니다.

  • 시스템 Pod는 핵심 Kubernetes와 플랫폼 서비스를 실행하며 모든 Node에 있는 것이 정상이므로, 사용률로 절대 잡히지 않습니다. 예: kube-proxy, coredns, etcd, kube-system이나 istio-system에 있는 것들.
  • DaemonSet Pod는 모니터링, 로깅, 네트워킹을 위해 Node마다 하나씩 뜨는 에이전트로, 쓰지 않는 Node에도 있는 것이 정상입니다. 예: node-exporter, fluentd, calico-node, 메트릭이나 로그 수집기.
  • 애플리케이션 Pod는 실제 작업입니다: Deployment, StatefulSet, Job. 이 중 하나라도 있으면 그 Node는 사용 중입니다.

규칙은 단순합니다: DaemonSet만 있거나 아무것도 없고, 애플리케이션 Pod가 0개면 idle입니다.

안전 기간(Safety period). Node는 순간이 아니라 일정 기간(기본값 약 1주일) 동안 계속 idle 상태여야 플래그가 붙습니다. 이렇게 하면 cluster-autoscaler의 scale-down 지연이나 배치 작업이 끝나는 짧은 순간 같은 것이 오탐(false positive)으로 잡히지 않습니다.

제외(Opt-out). 일부러 유지하는 Node(예약 용량이나 대기 용량)를 감지 대상에서 빼려면, annotation을 붙이면 감지에서 제외됩니다.

kubectl annotate node <node-name> waveautoscale.io/idle-node-detection="false"

Idle Nodes 페이지

Idle Nodes page with the finding banner, the cluster overview rollup, and the per-node details table with an expanded row

Idle Node Overview. 클러스터별 합산 정보입니다: Cluster Tag, Cluster Name, Total Nodes, Idle Node Count, Total Idle CPU, Total Idle Memory. Idle Node Count는 지금 idle 상태인 Node(가장 최근 감지 구간에서 확인됐고 아직 복구되지 않은 Node)를 반영하므로, 과거 이력이 아니라 현재의 낭비를 측정합니다.

Idle Node Details. 선택한 범위 안에서 한 번이라도 idle이었던 Node마다 한 행씩, 최신순으로 정렬됩니다: Last Detection Time, Node Name, Node CPU, Node Memory, Detected Reasons, Current Status, Pod Count, First Detected.

  • Current Status: Active(초록색)는 그 이후 워크로드가 올라와서 더 이상 idle이 아니라는 뜻이고, Idle(빨간색)은 지금도 idle이라는 뜻입니다. 둘 중 하나로 필터링할 수 있습니다.
  • Pod Count는 total, daemonset, deployment, statefulset, other로 나뉘어 있어서, DaemonSet만 남아 있는지 한눈에 확인할 수 있습니다.

행을 펼치면 Node 스냅샷을 볼 수 있습니다: capacity 대비 CPU와 메모리 사용량을 보여주는 Mini / Large 카드와, 감지 시점에 그 위에 있던 Pod 목록입니다. 이 정보만으로 Node를 제거할지, 재배치할지, 유지할지 판단할 수 있습니다.

Node가 플래그됐을 때 할 일

  • 앞으로도 필요 없는 Node라면 제거하세요. DaemonSet은 남긴 채로 drain하고, Node를 삭제한 뒤 밑에 있는 인스턴스를 종료합니다.

    kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
    kubectl delete node <node-name>
    # then terminate the VM/instance in your cloud provider
  • 삭제보다 사용률을 높이고 싶다면 통합하세요. idle Node에서 워크로드를 막고 있는 taint나 라벨을 완화해서 스케줄러가 그 위에 채우게 하고, 다른 곳에서 비워진 Node를 삭제합니다. 이렇게 하면 비용 없이 용량을 되찾을 수 있고, Cluster Resource Forecast가 부족을 경고할 때 특히 유용합니다.

  • 일부러 idle 상태인 Node라면 유지하세요. 위의 opt-out annotation을 추가하면 리포트에 더 이상 나타나지 않습니다.

⚠️

삭제 전에 반드시 확인하세요. Node가 전체 idle 기간을 다 채웠는지 확인하고, 라벨과 taint, annotation에 예약된 용도가 있는지 확인하고, 애매하다면 담당 팀에 소유권을 확인하세요. 엉뚱한 Node를 삭제하면 프로덕션 장애로 이어질 수 있습니다.

idle이 정당한 경우

일부 idle Node는 의도된 것입니다. 삭제하는 대신 감지 대상에서 제외하세요.

  • 트래픽 급증에 대비한 예약 용량이나 버스트 용량.
  • 예약된 배치 작업: 야간 ETL이나 cron 작업을 위해 유지하는 Node.
  • 다음 배포 교체를 기다리는 블루그린 대기(standby) Node.
  • 학습 작업 사이의 GPU Node. 실수로 놀리면 가장 비용이 큰 경우입니다(p3.8xlarge 하나가 idle 상태여도 시간당 약 12달러가 나갑니다). 명확하게 태그를 달거나, 쓰지 않을 때는 0으로 스케일하세요.

활용 사례

쓰지 않는 Node에 대한 지출 줄이기

용량 순으로 상세 목록을 정렬해서, 가장 큰 Node가 전체 idle 기간을 채웠는지 확인한 뒤 drain하고 삭제하세요. idle m5.xlarge Node 10개를 제거하면 실행 중인 워크로드에 영향 없이 월 약 1,500달러를 아낄 수 있습니다.

사지 않고 용량 되찾기

Cluster Resource Forecast가 Node가 idle인데도 용량 부족을 경고한다면, 먼저 idle 용량에 통합하세요. 배치를 막고 있는 taint나 라벨을 완화해서 워크로드가 채워지게 하고, 다른 곳에서 비워진 Node를 삭제합니다. 이는 비용 없는 용량 증가입니다.

큰 변경 후 남은 흔적 찾기

마이그레이션, 대규모 워크로드 삭제, 실패한 오토스케일링은 모두 Node를 남깁니다. Idle Node Detection이 이런 잔여물을 자동으로 찾아내므로, 클러스터 정리가 누군가 수동으로 감사하는 것을 기억하는 데 의존하지 않습니다.

관련 문서

  • Wave Diagnosis 개요
  • Cluster Resource Forecast: idle Node가 있는데 용량 부족이 예측된다면 먼저 그쪽에 통합하세요.
  • Smart Sizing: 워크로드를 적정 사이징해서 더 적은 Node에 채우면, 더 많은 Node가 idle이 되어 되찾을 수 있습니다.
  • Pod Scheduling Delay: idle Node와 함께 스케줄링 실패가 나타난다면 대개 taint, 라벨, affinity가 배치를 막고 있는 경우입니다.