[kubernetes] externalTrafficPolicy란? (feat. AWS VPC CNI에서는 의미가 없다고?)

vinca·2024년 3월 2일

Introduction

externalTrafficPolicy라는 단어를 문득 잊고 살고 있다가, 👨🏻‍💻프로젝트를 진행하던 도중 이 옵션에 대해서 팀원과 짧게 토론(?)하게 되었다.

처음 쿠버네티스를 접하며 공부할 당시, kubeproxy에 의해서 서비스에서 파드로 트래픽이 전달될 때, externalTrafficPolicy의 옵션에 따라서 서비스에 도착한 트래픽이 들어왔던 노드와는 다른 노드의 파드로 전송될 수도 있고, 해당 노드의 파드로 그대로 전송될 수도 있다는 것을 어렴풋이 공부했다. 🤔

토론 내용

externalTrafficPolicy란?

externalTrafficPolicy란 쿠버네티스 클러스터에서 파드가 배포된 노드까지 트래픽이 들어왔을 때, 이 트래픽을 다른 노드로 전송할 수 있을지 없을지를 결정하는 옵션이다.

이러한 옵션은 쿠버네티스의 Service 리소스를 정의할때 사용한다.

쿠버네티스 LoadBalancer 서비스

그럼 각 두가지 특징에 대해서 살펴보자.

Local

⭐ 한번 들어온 트래픽은 다른 노드로 빠지지 않고, 해당 노드 내의 파드로만 전달된다.

externalTrafficPolicy : local 장점/단점

✅ 장점

트래픽이 해당 노드로 들어온 이상, 다른 노드로 다시 이동하지 않으므로 네트워크에서 추가적인 hop이 없다. 따라서, latency를 감소시킬 수 있다.

또한, A노드와 B노드의 가용영역이 다른 상황이라면 A노드에 도착한 트래픽이 B노드로 트래픽을 다시 전송할 때 Cross-AZ 비용이 발생하게 되는데, 노드가 변하지 않으므로 Cross-AZ에서 발생할 일 또한 없기에 Cross-AZ 비용문제 또한 해결할 수 있다.

마지막으로, 클라이언트의 IP주소가 변경되지 않고 고정된다. 따라서, IP 로그를 수집하기 수월하고, 특정 IP 접속만을 허용하는 등의 제어를 구현하기 편하다.

(반면에 Cluster인 경우, NAT되어 원본 IP가 가려져 특정 IP 접속만을 허용 한다거나, 로깅하기 힘들다.😢)

💡예시

무조건 한 파드로만 접속된다.

[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker1
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker1
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker1

☑️ 단점

해당 노드로 트래픽이 들어왔지만, 해당 노드에 배포된 파드가 죽어있는 경우 다른 노드로 트래픽이 이동하지 못하므로 요청에 대해 TimeOut이 발생하게 된다.

💡예시

해당 파드가 죽은 경우, 다른노드에 파드가 살아있어도 트래픽이 이동할 수 없기에 접속할 수 없다.

[host ~]# curl 172.20.22.238:35542
curl: (7) Failed connect to 172.20.22.238:35542; Connection timed out

🤔 노드로 트래픽이 고정되면 부하나 가용성 측면에서도 좋지않을 거 같은데?
물론 한 노드에 트래픽을 고정하는 것이므로, 부하가 증가하고 가용성이 낮아진다고 볼 수 있지만, 사실 local을 쓰는 이유가 다른 노드로 이동할 때의 hop에 따른 latency 및 Cross-AZ 비용 문제를 해결하기 위해 사용하기에 "local을 쓰면 부하가 증가된다!"라고 계산 하지는 않는다.

Cluster

⭐ 한번 들어온 트래픽은 다른 노드로 자유롭게 빠질 수 있다.

externalTrafficPolicy : Cluster 장점/단점

✅ 장점

Cluster로 설정할 경우, 들어온 트래픽이 다른 노드로 자유롭게 이동할 수 있다.
<노드IP>:<노드 포트 번호>로 특정 노드로 접속해도 다른 노드에 있는 파드에 트래픽이 접속되는 이유가 바로 이 이유 때문이다.

💡예시 1

172.20.22.238 1번 워커노드의 IP 주소로 접속했지만, 2번 노드에 배포된 파드에도 접속된다.

[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker1
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker2
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker1
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker2

💡예시 2

만일 파드하나가 죽어있더라도 자연스럽게 다른 파드로 접속할 수 있다.
1번 워커노드에 있는 파드가 죽었으므로, 자동으로 2번 워커노드의 파드로 접속된다.

[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker2
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker2
[host ~]# curl 172.20.22.238:35542
You've hit test-pod-worker2

☑️ 단점

어쨌거나 다른 노드로 트래픽이 이동하기에 노드와 노드 사이의 hop이 여러개라면 큰 latency를 초례할 수 있고, 서로 다른 가용영역에 있는 노드라면 다른 지역간 통신 비용인 Cross-AZ 비용이 발생한다.

AWS VPC CNI에서는 상관없다고?

그렇다!

우리 프로젝트에서는 AWS EKS를 사용했기에 AWS VPC CNI를 자연스레 사용했다. 그러므로 사실 externalTrafficPolicy를 고민하는 것은 큰 의미가 없었다.

그 이유는 바로 AWS VPC CNI의 IP모드💘 덕분이다.

IP모드란?

💡 더 효율적인 네트워크 경로 제공하는 모드

IP 모드를 사용하면 AWS 로드 밸런서가 파드 IP 주소로 직접 트래픽을 전달한다. 즉, 트래픽이 개별 EC2 워커 노드의 kube-proxy를 통해 전달되는 것이 아니라 서비스 백엔드의 IP 주소로 직접 전달된다.

이는 AWS VPC CNI의 특징으로, 직접적으로 트래픽이 파드에 바로 도착하므로 iptables와 같은 리눅스의 분산 룰을 사용하지 않아 보다 효율적이게 동작한다.

IP 모드 예시

apiVersion: v1
kind: Service
metadata:
  annotations:
    # 💡 IP 모드
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: your-app