토폴로지 인지 라우팅

토폴로지 인지 라우팅 (Topology Aware Routing)

토폴로지 인지 라우팅은 네트워크 트래픽을 원래 발생한 zone 안에 유지하도록 돕는 메커니즘이에요. 클러스터의 Pod 간 같은-zone 트래픽을 선호하면 신뢰성, 성능(네트워크 지연·처리량), 비용 면에서 도움이 될 수 있어요.

FEATURE STATE: Kubernetes v1.23 [beta]

참고: Kubernetes 1.27 이전에는 이 기능을 Topology Aware Hints라고 불렀어요.

동기 (Motivation)

Kubernetes 클러스터는 점점 더 멀티-zone 환경에 배포돼요. Service의 엔드포인트를 계산할 때 EndpointSlice controller가 각 엔드포인트의 토폴로지(region과 zone)를 고려하고 hints 필드를 채워 zone에 할당해요. kube-proxy 같은 클러스터 컴포넌트가 그 hints를 소비해 트래픽이 라우팅되는 방식에 영향을 주도록 해요.

토폴로지 인지 라우팅 활성화

Service에 service.kubernetes.io/topology-mode annotation을 Auto로 설정하면 활성화할 수 있어요. 각 zone에 충분한 엔드포인트가 있으면 EndpointSlices에 Topology Hints가 채워져 트래픽이 발생 지점과 가까운 곳으로 라우팅돼요.

언제 가장 잘 동작하나?

  1. 들어오는 트래픽이 고르게 분산될 때: 트래픽의 큰 비율이 단일 zone에서 발생하면 그 zone에 할당된 엔드포인트 부분집합이 과부하될 수 있어요. 트래픽이 단일 zone에서 발생할 것으로 예상되면 권장하지 않아요.
  2. Service가 zone당 3개 이상의 엔드포인트를 가질 때: 3-zone 클러스터에서 9개 이상을 의미해요. zone당 3개 미만이면 EndpointSlice controller가 고르게 할당하지 못할 확률이 높아(≈50%) 기본 클러스터 전체 라우팅으로 폴백해요.

동작 방식

"Auto" 휴리스틱은 각 zone에 비례적으로 엔드포인트를 할당하려고 해요. EndpointSlice controller는 그 zone에서 실행되는 노드의 할당 가능한(allocatable) CPU 코어 수에 기반해 비율을 정해요. 예를 들어 한 zone이 2 CPU 코어이고 다른 zone이 1 CPU 코어라면, 2 코어 zone에 2배 많은 엔드포인트를 할당해요.

hints가 채워진 EndpointSlice 예시:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: example-hints
  labels:
    kubernetes.io/service-name: example-svc
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    zone: zone-a
    hints:
      forZones:
        - name: "zone-a"

kube-proxy는 EndpointSlice controller가 설정한 hints를 기반으로 라우팅할 엔드포인트를 필터링해요. 대부분 같은 zone의 엔드포인트로 트래픽을 라우팅하지만, zone 간 균형을 위해 다른 zone의 엔드포인트를 할당하면 일부 트래픽이 다른 zone으로 갈 수 있어요.

안전장치 (Safeguards)

컨트롤 플레인과 각 노드의 kube-proxy는 Topology Aware Hints를 사용하기 전에 안전장치 규칙을 적용해요. 확인이 안 되면 kube-proxy는 zone과 무관하게 클러스터 어디서든 엔드포인트를 선택해요.

  1. 엔드포인트 수 부족: 클러스터의 zone 수보다 엔드포인트가 적으면 hints를 할당하지 않아요.
  2. 균형 할당 불가능: zone 간 균형 할당이 불가능하면("expected overload"가 허용 가능한 임계값 이하로 못 내려가면) hints를 할당하지 않아요. 이는 실시간 피드백에 기반하지 않으므로 개별 엔드포인트가 여전히 과부하될 수 있어요.
  3. 노드 정보 부족: 어떤 노드가 topology.kubernetes.io/zone 라벨이 없거나 할당 가능한 CPU 값을 보고하지 않으면 hints를 설정하지 않아요.
  4. 일부 엔드포인트에 zone hint 없음: 전환 중이라고 가정하고 모든 엔드포인트를 사용해요.
  5. hints에 zone이 없음: kube-proxy가 실행 중인 zone을 대상으로 하는 hint를 가진 엔드포인트를 찾지 못하면 모든 zone의 엔드포인트를 사용해요. 새 zone을 추가할 때 흔히 발생해요.

제약 사항

  • Service에 internalTrafficPolicy가 Local이면 Topology Aware Hints를 사용하지 않아요. 같은 클러스터의 다른 Service에서는 둘 다 사용할 수 있어요.
  • 트래픽의 큰 비율이 일부 zone 부분집합에서 발생하는 Service에는 잘 동작하지 않아요.
  • EndpointSlice controller는 각 zone의 비율을 계산할 때 준비되지 않은(unready) 노드를 무시해요.
  • 컨트롤 플레인 노드(node-role.kubernetes.io/control-plane 라벨)를 무시해요. 워크로드도 그 노드에서 실행 중이면 문제가 될 수 있어요.
  • toleration을 고려하지 않아요.
  • Horizontal Pod Autoscaler와 잘 맞지 않을 수 있어요.

커스텀 휴리스틱

내장 휴리스틱이 사용 사례에 맞지 않으면 커스텀 휴리스틱을 개발할 수 있어요. 1.27 릴리스에 첫 단계가 포함됐어요.

더 알아보기 (Learn more)