🧱 배경

Kubernetes 환경에서 vector는 DaemonSet으로 배포되어 모든 노드에 하나씩 상주하며, 로그 및 메트릭 수집을 수행한다. 반면, kube-state-metrics는 클러스터의 상태 정보를 제공하는 단일 Pod로 배포된다.
현재 구성에서는 각 노드의 vector 인스턴스가 동일한 kube-state-metrics 데이터를 모두 수집하고 있어, 중복된 메트릭 전송 및 저장 문제가 발생하고 있다.
이를 해결하기 위해 Node Affinity와 Pod Affinitiy가 언급되어 해당 기능에 대해 공부하고자 한다.

⚠️ 문제 사항

vector DaemonSet → 모든 노드에 존재
kube-state-metrics → 1개의 노드에만 존재

모든 vector가 동일한 kube-state-metrics 엔드포인트를 scrape
→ 데이터 중복 수집, 스토리지 낭비, 리소스 과소비 발생

---

🔍 Pod Affinity란?

Pod Affinity는 Kubernetes 스케줄링 기능 중 하나로,
특정 조건을 만족하는 다른 Pod가 존재하는 노드에만 새로운 Pod을 배포하도록 지정할 수 있다.

✳️ 주요 용도

같은 노드에 앱과 사이드카 또는 로깅 에이전트 등을 공존시키고자 할 때,
데이터 로컬리티가 중요한 경우 (예: 캐시 활용, 동일 디스크 접근)

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
          - key: app
            operator: In
            values:
              - kube-state-metrics
      topologyKey: "kubernetes.io/hostname"

→ 위 설정은 kube-state-metrics Pod이 있는 노드에만 새로운 Pod을 배치하게 함

⚙️ Node Affinity란?

Node Affinity는 노드에 정의된 label을 기준으로, 특정 Pod이 배포될 노드를 제어하는 스케줄링 기능.
DaemonSet과 같이 모든 노드에 배포되는 리소스에 대해서도 적용 가능하며, 특정 노드에만 제한적으로 배포되도록 구성할 수 있다.

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
          - key: ksm-node
            operator: In
            values:
              - "true"

→ ksm-node=true label이 설정된 노드에만 해당 Pod이 배포됨

---

하지만 해당 기능은 부적합할 수 있다고 판단.

✅ Pod Affinity 방식의 한계

1. DaemonSet과 Pod Affinity는 근본적으로 충돌

Pod Affinity는 “다른 Pod가 있는 노드에 배치된다”

만약, kube-state-metrics가 있는 노드에만 vector를 배치하려고 할 경우:

podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: kube-state-metrics
      topologyKey: "kubernetes.io/hostname"

그러나 DaemonSet은 모든 노드에 무조건 배포된다.

-> kube-state-metrics가 없는 노드에도 배포되려 하기 때문에, affinity 조건과 충돌하게 된다. 이렇게되면 나머지 노드에는 affinity 조건이 맞지 않아 배포되지 않음 → vector의 다른 기능 (예: 로그 수집)도 사라짐

🔎 즉, Pod Affinity는 Deployment에는 유용하지만, DaemonSet에는 적절하지 않다.

2. Pod Affinity는 스케줄링 시점 기준이며, 동적 환경에 취약

Pod Affinity는 "이 노드에 kube-state-metrics가 있어야만 배포됨"이라는 조건을 요구한다.
하지만 현실에서는 kube-state-metrics Pod이 재시작하거나 다른 노드로 옮겨질 수 있다.
이럴 경우 vector Pod이 사라지거나 생성되지 않을 수 있다. → 불안정한 배포

3. ⚠️ DaemonSet + Pod Affinity의 제약사항

DaemonSet의 특성:

• 모든 노드에 1개씩: DaemonSet은 기본적으로 모든 노드에 배포
• Affinity 무시: Pod Affinity는 DaemonSet에서 제한적으로 동작
• NodeSelector 우선: DaemonSet은 nodeSelector, tolerations만 주로 사용

kube-state-metrics의 특성:

• 단일 파드: 일반적으로 Deployment로 1개 파드만 실행
• 유동적 배치: Kubernetes가 적절한 노드에 스케줄링
• 재시작 시 이동: 파드 재시작/재스케줄링 시 다른 노드로 이동 가능

🤔 Pod Affinity 방식의 문제점

1. kube-state-metrics 이동 시 문제:

1. kube-state-metrics가 worker001에 있음
2. worker001의 Vector만 수집 중
3. kube-state-metrics가 worker002로 이동
4. worker001 Vector는 계속 시도하지만 실패
5. worker002 Vector는 아직 수집 안함
→ 데이터 수집 중단!

2. 동적 감지의 복잡성:

• 실시간 감지 어려움: initContainer는 파드 시작 시에만 실행
• 지속적 모니터링 필요: kube-state-metrics 이동을 실시간 감지 어려움
• 복잡한 로직: Kubernetes API 지속적 호출 필요

3. 성능 오버헤드:

• API 호출 부담: 모든 Vector가 지속적으로 kube-state-metrics 위치 확인
  ⚡ 지연 시간: 동적 감지로 인한 수집 지연

---

Pod Affinity vs 라벨 기반 비교

방식	장점	단점	추천도
Pod Affinity	🔄 다른 Pod 위치에 따라 자동 추적 가능	❌ 스케줄링 복잡성, 지연, DaemonSet과 비호환	⭐⭐
라벨 기반	✅ 단순하고 안정적, 제어 용이	⚠️ 라벨 수동 관리 필요	⭐⭐⭐⭐⭐
고정 배치	✅ 예측 가능한 수집 노드 제어	⚠️ kube-state-metrics HA 구성 어려움	⭐⭐⭐⭐