Topology Aware Routing은 Kubernetes Service의 트래픽을 가능한 한 같은 Zone(가용 영역) 내의 엔드포인트로 라우팅하는 기능이다. 클러스터가 여러 Zone에 걸쳐 배포되어 있을 때, 이 기능을 활성화하면 네트워크 지연 시간을 줄이고 Zone 간 데이터 전송 비용을 절감할 수 있다.
멀티 Zone 클러스터에서 Service로 요청이 들어오면, 기본적으로 kube-proxy는 모든 엔드포인트 중 하나를 무작위로 선택한다. 이 말은 Zone A에 있는 Pod가 Zone B나 Zone C에 있는 엔드포인트로 트래픽을 보낼 수도 있다는 것이다.
┌─────────────────────────────────────────────────────────────┐│ Cluster ││ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ││ │ Zone A │ │ Zone B │ │ Zone C │ ││ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ ││ │ │ Client │──┼──┼──│Endpoint │ │ │ │Endpoint │ │ ││ │ │ Pod │ │ │ │ Pod │ │ │ │ Pod │ │ ││ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ ││ │ ┌─────────┐ │ │ │ │ │ ││ │ │Endpoint │ │ │ │ │ │ ││ │ │ Pod │ │ │ │ │ │ ││ │ └─────────┘ │ │ │ │ │ ││ └───────────────┘ └───────────────┘ └───────────────┘ │└─────────────────────────────────────────────────────────────┘왜 이것이 문제가 될까?
- 네트워크 지연: Zone 간 통신은 같은 Zone 내 통신보다 지연 시간이 길다
- 비용: 클라우드 환경에서 Zone 간 데이터 전송은 추가 비용이 발생한다 (AWS의 경우 GB당 $0.01)
- 대역폭: Zone 간 네트워크 대역폭은 제한될 수 있다
Topology Aware Routing을 활성화하면, kube-proxy가 가능한 한 같은 Zone 내의 엔드포인트로 트래픽을 라우팅한다.
활성화 방법
Service에 service.kubernetes.io/topology-mode 어노테이션을 설정하면 된다.
apiVersion: v1kind: Servicemetadata: name: my-service annotations: service.kubernetes.io/topology-mode: Autospec: selector: app: my-app ports: - port: 80 targetPort: 8080모드 설정
- Auto: Kubernetes가 자동으로 토폴로지 힌트를 계산한다. 엔드포인트가 충분하면 Zone 인식 라우팅이 활성화된다.
- Disabled: 토폴로지 인식 라우팅을 비활성화한다 (기본값).
이전 버전(v1.21~v1.26)에서는
service.kubernetes.io/topology-aware-hints: auto어노테이션을 사용했다. 현재도 호환되지만 새로운topology-mode어노테이션 사용을 권장한다.
동작 원리
그렇다면 Topology Aware Routing은 어떻게 작동할까?
EndpointSlice 컨트롤러가 핵심 역할을 한다. 이 컨트롤러는 각 엔드포인트에 “hints”를 할당하여, 해당 엔드포인트가 어느 Zone에서 소비되어야 하는지 알려준다.
apiVersion: discovery.k8s.io/v1kind: EndpointSlicemetadata: name: my-service-abc labels: kubernetes.io/service-name: my-serviceaddressType: IPv4endpoints: - addresses: - "10.0.1.5" conditions: ready: true zone: zone-a hints: forZones: - name: zone-a - addresses: - "10.0.2.10" conditions: ready: true zone: zone-b hints: forZones: - name: zone-bkube-proxy는 이 hints를 읽어서, 자신이 실행 중인 노드의 Zone과 일치하는 엔드포인트만 iptables/ipvs 규칙에 포함시킨다.
힌트 계산 과정
EndpointSlice 컨트롤러는 다음 과정을 거쳐 힌트를 계산한다:
- 각 Zone에 있는 노드의 CPU 코어 수를 기반으로 Zone의 “용량 비율”을 계산한다
- 각 Zone에 있는 ready 상태의 엔드포인트 수를 파악한다
- Zone 용량 비율에 맞게 엔드포인트를 각 Zone에 할당한다
예를 들어, 3개의 Zone이 있고 각각 CPU 코어가 100개, 100개, 200개라면:
- Zone A: 25% 비율
- Zone B: 25% 비율
- Zone C: 50% 비율
12개의 엔드포인트가 있다면, Zone A에 3개, Zone B에 3개, Zone C에 6개가 할당된다.
Safeguards
Topology Aware Routing은 몇 가지 안전 장치(safeguard)가 있어서, 특정 조건에서는 자동으로 비활성화된다.
비활성화되는 조건:
- 엔드포인트 수가 Zone 수보다 적은 경우
- 하나 이상의 Zone에 노드가 없는 경우
- 힌트 할당으로 인해 특정 Zone에 과도한 부하가 예상되는 경우 (150% 초과)
- 특정 Zone에 ready 상태의 엔드포인트가 없는 경우
이런 조건에서 hints가 비워지면, kube-proxy는 클러스터의 모든 엔드포인트를 사용하게 된다.
주의사항
Topology Aware Routing을 사용할 때 고려해야 할 점들이 있다.
엔드포인트 분산
각 Zone에 충분한 엔드포인트가 있어야 한다. 만약 Zone A에만 엔드포인트가 몰려있다면, Zone B와 Zone C의 클라이언트는 결국 Zone A로 트래픽을 보내야 한다.
불균등한 트래픽
Zone별 트래픽 양이 다를 수 있다. CPU 코어 기반 용량 비율이 실제 트래픽 패턴과 맞지 않으면, 일부 엔드포인트에 과부하가 걸릴 수 있다.
Headless Service 미지원
ClusterIP가 None인 Headless Service에서는 Topology Aware Routing이 동작하지 않는다.
externalTrafficPolicy와의 관계
externalTrafficPolicy: Local이 설정된 Service에서는 Topology Aware Routing이 무시된다. 이 정책은 이미 노드 로컬 엔드포인트만 사용하도록 제한하기 때문이다.
정리
Topology Aware Routing은 멀티 Zone 클러스터에서:
- Zone 간 네트워크 지연을 줄인다
- Zone 간 데이터 전송 비용을 절감한다
- 간단한 어노테이션 하나로 활성화할 수 있다
다만, 각 Zone에 충분한 엔드포인트가 분산되어 있어야 효과적으로 동작하며, 여러 safeguard 조건에 의해 자동으로 비활성화될 수 있다는 점을 기억해야 한다.
참고