로드밸런싱
여러 서버(Pod들)에 트래픽을 골고루 분산시켜 주는 기술입니다. (부하 분산 목적)
로드밸런싱 주요 알고리즘
Round Robin : 그냥 순차적으로 차례대로 트래픽을 전달
Least Connections : 가장 접속이 적은 서버로 트래픽을 전달
Random : 말 그대로 랜덤한 서버에 보냄
IP Hash : Sticky Session / 접속한 사용자는 계속 요청을 보냈던 서버로 요청을 보냄
Weighted : 서버에 가중치를 부여해 더 좋은 서버는 트래픽 배정 순위가 높음
쿠버네티스 Service의 LoadBalancer 구동 방식 (AWS ELB 기준)
로드밸런서를 적용하기 위해서는 Service에서 네트워크 타입을 LoadBalancer로 설정해야합니다.
1. 전체 아키텍처 개요
기본적으로 LoadBalancer 타입은 NodePort 타입 위에 구축되며, 클라우드 공급자(AWS)의 로드밸런서를 프로비저닝 하여 외부 트래픽을 노드로 전달하는 역할을 합니다.
트래픽 흐름 요약:
외부 클라이언트 → AWS ELB(로드밸런서) → 워커 노드(NodePort) → Service Proxy(iptables/IPVS) → 타겟 Pod
2. 단계별 상세 트래픽 흐름
1단계: 프로비저닝 (Service 생성 시점)
사용자가 type: LoadBalancer인 Service 매니페스트를 적용하면 다음 과정이 일어납니다.
- Cloud Controller Manager: K8s의 컨트롤 플레인은 AWS API를 호출하여 실제 ELB(Classic LB 또는 Network LB)를 생성합니다.
- NodePort 할당: K8s는 해당 서비스를 위해 클러스터의 모든 노드에 고정된 포트(NodePort, 예: 30123)를 엽니다.
- Target 등록: 생성된 AWS ELB의 타겟 그룹(Target Group)에 모든 워커 노드(EC2 인스턴스)가 등록됩니다. 이때 포트는 위에서 할당된 NodePort가 사용됩니다.
2단계: 클라이언트 요청 (Client → ELB)
- 외부 클라이언트가 AWS ELB의 DNS 주소(예:
a1b2...elb.amazonaws.com)로 요청을 보냅니다. - ELB는 로드밸런싱 알고리즘(Round Robin, Hash 등)에 따라 등록된 워커 노드 중 하나를 선택하여 트래픽을 전달합니다.
3단계: 노드 진입 (ELB → NodePort)
- 패킷이 선택된 워커 노드의
NodePort(예: 30123)로 들어옵니다. - 중요: 기본적으로 ELB는 어떤 노드에 해당 Pod가 실제로 실행 중인지 모릅니다. 따라서 Pod가 없는 노드로 트래픽을 보낼 수도 있습니다.
4단계: 내부 라우팅 (Node → Pod)
여기서 kube-proxy와 iptables(또는 IPVS) 설정이 핵심 역할을 합니다.
- 패킷 캡처: 노드의 커널(iptables)이 해당 NodePort로 들어온 패킷을 감지합니다.
- DNAT (Destination NAT): 패킷의 목적지 IP를 노드의 IP에서 실제 타겟 Pod의 IP로 변환합니다.
- 로드밸런싱 (Cluster 내부): 만약 해당 서비스에 연결된 Pod가 여러 개라면, iptables 확률 규칙에 따라 랜덤 하게 Pod 하나가 선택됩니다.
- 참고: 선택된 Pod가 현재 노드에 있을 수도 있고, 다른 노드에 있을 수도 있습니다. 다른 노드에 있다면 네트워크 홉(Hop)이 한 번 더 발생합니다.
5단계: 응답 (Pod → Client)
- Pod가 응답을 보내면 역순으로 변환(SNAT 등)을 거쳐 ELB를 통해 클라이언트에게 전달됩니다.
3. 핵심 설정: externalTrafficPolicy
AWS ELB를 사용할 때 트래픽 경로와 Source IP 보존 여부를 결정하는 중요한 설정입니다.
A. externalTrafficPolicy: Cluster (기본값)
- 동작: ELB가 트래픽을 임의의 노드로 보냅니다. 해당 노드에 Pod가 없으면, Pod가 있는 다른 노드로 트래픽을 다시 보냅니다(Cross-node traffic).
- 장점: 트래픽이 모든 Pod에 균등하게 분산됩니다.
- 단점:
- 불필요한 홉(Hop): 노드 간 이동이 발생하여 지연시간(Latency)이 늘어날 수 있습니다.
- Source IP 손실: SNAT(Source NAT)가 발생하여 Pod 입장에서는 클라이언트의 실제 IP가 아닌 노드의 IP가 보입니다.
B. externalTrafficPolicy: Local
- 동작: ELB는 실제로 해당 Pod가 실행 중인 노드로만 트래픽을 보냅니다. (K8s가 AWS ELB의 헬스 체크를 조작하여 Pod가 없는 노드는 비정상 상태로 표시함)
- 장점:
- 직접 전달: 노드 간 점프가 없어 지연시간이 감소합니다.
- Source IP 보존: SNAT가 발생하지 않아 클라이언트의 실제 IP를 확인할 수 있습니다.
- 단점: 특정 노드에 Pod가 쏠려있다면 트래픽 불균형(Imbalance)이 발생할 수 있습니다.
4. AWS Load Balancer 종류에 따른 차이 (CLB vs NLB)
| 특징 | Classic Load Balancer (CLB) | Network Load Balancer (NLB) |
|---|---|---|
| 기본 설정 | 과거 K8s 버전의 기본값 | 최신 환경 권장 (Annotation 필요) |
| Layer | L4 / L7 | L4 (초고성능) |
| 성능 | 일반적 | 매우 높음 (수백만 요청/초) |
| IP 할당 | 유동 IP (DNS만 제공) | 고정 IP(Elastic IP) 할당 가능 |
| 설정 방법 | 별도 설정 없음 | service.beta.kubernetes.io/aws-load-balancer-type: nlb |
최신 트렌드 (IP Mode):
AWS Load Balancer Controller를 설치하여 "IP 모드"를 사용하면, ELB가 NodePort를 거치지 않고 Pod IP로 직접 트래픽을 전달하는 구조(AWS VPC CNI 필요)도 가능합니다. 이는 성능상 가장 큰 이점이 있습니다.
'Kubernetes' 카테고리의 다른 글
| 쿠버네티스 네트워크 (0) | 2025.12.12 |
|---|---|
| 쿠버네티스 볼륨 (0) | 2025.12.10 |
| 쿠버네티스 아키텍처 (0) | 2025.12.09 |
| 쿠버네티스 명령어 정리 (kubectl) 및 yaml (0) | 2025.12.08 |
| 쿠버네티스 개념 및 용어 정리 (0) | 2025.12.08 |