93. LoadBalancer - 퍼블릭 클라우드 연동 K8s 외부 진입점

핵심 인사이트 (3줄 요약)

본질: K8s (Kubernetes)의 LoadBalancer 서비스는 클러스터 내부의 네트워크를 퍼블릭 클라우드 벤더의 L4 로드밸런서와 자동으로 연동해 주는 외부 진입점이다.

가치: 인프라 관리자가 직접 퍼블릭 클라우드 콘솔에서 로드밸런서를 생성하고 노드 포트를 연결하는 수동 프로비저닝 (Provisioning) 작업을 완전히 자동화한다.

판단 포인트: 서비스마다 로드밸런서를 개별 생성하므로 비용이 급증할 수 있으며, L7 (HTTP/HTTPS) 경로 기반 라우팅이 필요할 때는 Ingress (인그레스)로 전환을 고려해야 한다.

Ⅰ. 개요 및 필요성

K8s 서비스 (Service) 타입 중 LoadBalancer는 클러스터 외부의 사용자 트래픽을 내부 파드 (Pod)로 연결하기 위해 클라우드 사업자의 실제 로드밸런서를 동적으로 생성하는 기술이다.

기존의 NodePort (노드포트) 방식은 모든 노드의 특정 포트(30000~32767)를 열어야 했고, 사용자가 직접 특정 노드의 IP를 알고 접속해야 하는 한계가 있었다. 상용 서비스에서는 고객에게 고정된 단일 공인 IP와 표준 포트(80, 443)를 제공해야 하며, 특정 노드가 다운되더라도 트래픽이 우회될 수 있는 진정한 의미의 부하 분산이 필수적이다. LoadBalancer는 K8s의 CCM (Cloud Controller Manager)이 AWS, GCP 등의 API를 호출하여 이 모든 구성을 코드로 자동화 (IaC)한다.

📢 섹션 요약 비유: NodePort가 아파트 담벼락에 뚫어 놓은 여러 개의 쪽문이라면, LoadBalancer는 외부 도로와 연결된 거대하고 깔끔한 아파트 단지의 공식 정문 건물이다.

Ⅱ. 아키텍처 및 핵심 원리

LoadBalancer 서비스는 단독으로 동작하는 것이 아니라, 외부 LB 인프라 -> NodePort -> ClusterIP -> Pod로 이어지는 4단계 계층 라우팅 구조를 감싸는 형태다.

구성 요소	역할 및 동작 방식
Cloud Provider API	CCM이 클라우드 벤더의 API를 호출하여 L4 로드밸런서 인스턴스(예: AWS NLB)를 프로비저닝
NodePort	클라우드 로드밸런서가 트래픽을 꽂아 넣을 수 있도록 클러스터의 모든 워커 노드에 동일한 포트 개방
kube-proxy	노드에 도달한 트래픽을 목적지 파드로 포워딩하는 iptables/IPVS 룰 적용
External Traffic Policy	`Local` 설정 시, 파드가 없는 노드를 거치지 않고 직접 목적지 노드로 트래픽을 보내 SNAT 핑퐁 최소화

┌──────────────────────────────────────────────────────────────┐
│        LoadBalancer 트래픽 인입 및 계층적 라우팅 흐름        │
├──────────────────────────────────────────────────────────────┤
│ [클라이언트] ──▶ (포트 80/443, 공인 IP)                      │
│                                                              │
│       ▼ AWS NLB / GCP TCP LB (외부 클라우드 로드밸런서)      │
│                                                              │
│       ├──▶ [노드 A] (포트 31000) ──▶ 파드 없음 (핑퐁 발생)   │
│       │                                                      │
│       └──▶ [노드 B] (포트 31000) ──▶ (kube-proxy) ──▶ [파드] │
└──────────────────────────────────────────────────────────────┘

서비스 생성 시 K8s는 내부적으로 NodePort와 ClusterIP를 함께 할당한다. 이후 클라우드 LB는 노드의 IP와 해당 NodePort를 백엔드 타겟 그룹으로 묶어, 외부 트래픽을 클러스터 내부로 밀어 넣는다.

📢 섹션 요약 비유: 로드밸런서는 거대한 깔때기와 같다. 넓은 외부 공인 IP로 쏟아지는 트래픽을 모아, 클러스터라는 체를 거쳐 정확한 파드라는 유리병 안으로 흘려보낸다.

Ⅲ. 비교 및 연결

외부로 서비스를 노출하는 K8s의 세 가지 방식은 노출 범위와 지능(L4 vs L7)에서 명확한 경계를 가진다.

항목	NodePort	LoadBalancer	Ingress
라우팅 계층	L4 (IP, Port)	L4 (IP, Port)	L7 (HTTP, URL 패스)
외부 진입점	각 노드의 공인 IP + 비표준 포트	클라우드 LB의 단일 공인 IP + 표준 포트	클라우드 LB (1개) + Ingress Controller
비용 구조	클라우드 LB 비용 없음	서비스 1개당 LB 1대 비용 발생	여러 서비스가 1대의 LB 공유 (비용 절감)
주요 한계	상용 서비스용으로 부적합	서비스 개수 비례 인프라 비용 폭증	초기 설정 복잡, 컨트롤러 추가 필요

LoadBalancer는 외부 L4 장비와의 단순 연결을 담당하지만, URL 패스 기반의 스마트한 트래픽 분배를 원한다면 이 LoadBalancer 뒤에 Ingress Controller를 배치하는 아키텍처로 진화하게 된다.

📢 섹션 요약 비유: NodePort는 각 식당 주인이 직접 밖에서 손님을 부르는 것이고, LoadBalancer는 식당마다 전용 발렛파킹 직원을 고용하는 것이며, Ingress는 쇼핑몰 통합 안내 데스크를 두는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 LoadBalancer를 사용할 때는 "트래픽 최적화"와 "비용 통제"가 핵심 판단 기준이다.

실무 체크리스트

SNAT 및 레이턴시 문제: externalTrafficPolicy: Cluster (기본값)는 트래픽이 무작위 노드로 가면서 홉 (Hop)이 추가된다. 클라이언트의 원본 IP를 보존하고 네트워크 지연을 줄이려면 Local로 설정해야 한다. 단, 이 경우 트래픽 불균형이 발생할 수 있어 파드의 분산 배치 (Anti-Affinity) 설계가 수반되어야 한다.
비용 폭탄 (Cost Explosion): 마이크로서비스 아키텍처 (MSA)에서 50개의 서비스를 모두 LoadBalancer로 열면 50대의 클라우드 LB가 과금된다.
온프레미스 (On-Premise) 한계: 베어메탈 (Bare Metal) 환경에서는 AWS/GCP의 API가 없으므로 type: LoadBalancer가 동작하지 않는다. 이 경우 MetalLB 같은 소프트웨어 기반 L2/BGP 라우팅 솔루션을 별도로 구축해야 한다.

기술사적 의사결정

채택: 트래픽 분리 격리가 엄격히 필요한 소수의 핵심 진입점 API나, L4 수준의 TCP/UDP 스트리밍 서비스에 적용한다.
회피: 수십 개의 웹/API 서비스(L7)를 띄우는 환경에서는 LoadBalancer 타입 직접 사용을 피하고, 단일 LoadBalancer와 연결된 Ingress 아키텍처로 전환해야 한다.
📢 섹션 요약 비유: 회삿돈을 아끼려면 직원(서비스)마다 개별 법인차량(LoadBalancer)을 지급하지 말고, 대형 버스(Ingress) 한 대를 렌트해 나눠 타게 만들어야 한다.

Ⅴ. 기대효과 및 결론

LoadBalancer는 복잡한 인프라 생성 작업을 K8s 매니페스트 (Manifest) 한 줄로 통합하여 진정한 의미의 클라우드 네이티브 (Cloud Native) 자동화를 완성했다. 이를 통해 개발자는 네트워크 장비의 CLI를 몰라도 글로벌 스케일의 부하 분산기를 즉시 확보할 수 있다.

하지만 1:1 결합 구조가 낳는 비용과 확장성 한계는 분명하다. 따라서 LoadBalancer는 "K8s와 퍼블릭 클라우드가 만나는 최초의 물리적 접점"으로 이해해야 하며, 이 접점을 어떻게 효율적으로 공유 (Ingress, API Gateway)할 것인지가 아키텍트의 최종 과제로 남게 된다.

📢 섹션 요약 비유: 훌륭한 자동문(LoadBalancer)은 설치하기 쉽고 손님을 잘 맞이하지만, 문이 너무 많으면 유지보수비가 건물 렌트비를 넘어선다.

📌 관련 개념 맵

개념	연결 포인트
CCM (Cloud Controller Manager)	K8s와 클라우드 벤더(AWS, GCP 등) API를 연결하는 브리지 컴포넌트
NodePort (노드포트)	LoadBalancer가 외부 트래픽을 노드 내부로 밀어 넣기 위해 의존하는 하위 기술
Ingress (인그레스)	LoadBalancer의 1:1 비용 문제를 해결하는 L7 라우팅 및 호스트 기반 트래픽 제어기
MetalLB	클라우드 벤더가 없는 온프레미스 환경에서 LoadBalancer 기능을 구현하는 솔루션

📈 관련 키워드 및 발전 흐름도

서비스 노출의 기초 
    │
    ▼
NodePort (노드포트) · 단일 노드 IP 의존
    │
    ▼
LoadBalancer (로드밸런서) · 외부 L4 장비 연동 및 공인 IP 자동화
    │
    ▼
externalTrafficPolicy: Local · SNAT 방지 및 최적화
    │
    ▼
Ingress (인그레스) · L7 통합 라우팅으로 비용 및 효율성 극대화

👶 어린이를 위한 3줄 비유 설명

학교 운동장에 텐트(파드)를 치고 친구들을 초대하려고 해요.
하지만 텐트가 어디 있는지 아무도 모르니까, 학교 정문(LoadBalancer)에 큰 간판을 세우고 안내원 아저씨를 불렀어요.
이제 밖에서 온 친구들은 텐트 주소를 몰라도 안내원 아저씨가 정확하게 안내해 준답니다!