쿠버네티스 LoadBalancer Service란?｜외부 IP와 트래픽 유입 원리

LoadBanlancer

저번 시간에는 Ingress Controller 구현체에 대해 알아보았습니다.

Ingress는 Host와 Path를 기준으로 요청을 어떤 Service에 전달할지 정의하고, 대표적인 NGINX / Traefik / HAProxy와 같은 Ingress Controller 구현체가 해당 규칙을 실제 HTTP/HTTPS 라우팅으로 구현합니다.

그렇다면 여기서 한 가지 의문이 생깁니다.

외부 사용자의 요청은 처음부터 어떻게 Ingress Controller까지 유입 될까?

 

 

NGINX Ingress Controller를 설치했다고 해서 외부 네트워크의 패킷이 자동으로 해당 Pod까지 전달되는 것은 아닙니다. 외부에서 접근할 수 있는 IP 주소와 클러스터로 진입하는 네트워크 경로가 먼저 구성되어야 합니다.

이 역할을 이해하기 위해서는 Kubernetes의 LoadBalancer 구현체를 알아야 합니다.


Kubernetes에서는 Service의 타입을 LoadBalancer로 지정할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
spec:
  type: LoadBalancer
  selector:
    app: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: 80

    - name: https
      port: 443
      targetPort: 443

 

이 설정을 처음 보면 Kubernetes가 내부적으로 로드밸런서를 직접 생성한다고 생각하시겠지만, type: LoadBalancer는 실제 로드밸런서 엔진이 아니고 Kubernetes에 다음과 같이 요청하는 선언에 가깝습니다.

"이 Service를 외부에서 접근할 수 있도록 External IP 또는 VIP를 할당하고, 외부 트래픽이 이 Service까지 도달할 수 있는 경로를 구성해 주세요."

즉, Kubernetes는 LoadBalancer라는 공통 인터페이스를 정의할 뿐입니다.

Service type: LoadBalancer -> 외부 IP와 트래픽 진입 경로가 필요하다는 선언

 

 

 

해당 선언을 실제 네트워크 구성으로 만들어 주는 것이 LoadBalancer 구현체입니다.

결국 이 구조는 Kubernetes에서 Service를 외부에 노출하고 네트워크를 구성하는 전체 흐름을 담고 있는 아키텍처입니다. 따라서 각 계층의 역할과 트래픽이 전달되는 과정을 이해하는 것은 안정적인 Kubernetes 운영을 위해 반드시 필요한 핵심 개념이라고 할 수 있습니다.

 

 

Kubernetes 인프라 환경별 Load Balancer 구현 방식 

 

Kubernetes는 컨테이너 오케스트레이션의 표준이지만, 실제로 어떤 인프라 위에서 실행되느냐에 따라 외부 트래픽을 처리하는 방식이 완전히 다릅니다.

 

AWS에서 실행될 수도 있고, Azure나 Google Cloud에서 실행될 수도 있습니다. 또는 자체 데이터센터의 물리 서버나 가상머신 위에 구축할 수도 있죠. 환경마다 외부 IP를 할당하고 트래픽을 전달하는 방식이 다르기 때문에, Kubernetes 자체가 하나의 방식만 제공할 수는 없습니다.

 

이 글에서는 대표적인 4가지 인프라 환경(AWS, Azure, GCP, On-premise)에서 Service (AWS, Azure, GCP, On-premise)에서 Service type: LoadBalancer와 Ingress가 각각 어떻게 실제 로드밸런서로 연결되는지 알아봅니다.

AWS EKS

 

 

Service type: LoadBalancer

Service type: LoadBalancer
   ↓
AWS Load Balancer Controller
   ↓
Network Load Balancer (NLB) 생성

 

Ingress

Ingress
   ↓
AWS Load Balancer Controller
   ↓
Application Load Balancer (ALB) 생성

💡 AWS는 동일한 컨트롤러(AWS Load Balancer Controller)가 요청 타입에 따라 NLB(L4) 또는 ALB(L7)를 각각 생성해줍니다.

 

Microsoft Azure AKS

Service type: LoadBalancer

Service type: LoadBalancer
   ↓
AKS의 Azure 클라우드 연동
   ↓
Azure Standard Load Balancer 생성

Ingress

Ingress
   ↓
Application Gateway Ingress Controller (AGIC)
   ↓
Azure Application Gateway

💡 Azure는 L4는 Standard Load Balancer, L7은 Application Gateway로 역할이 명확히 분리되어 있고, 이를 연결해주는 것이 AGIC입니다.

 

Google Kubernetes Engine (GKE)

 

Service type: LoadBalancer

Service type: LoadBalancer
   ↓
GKE Service Controller
   ↓
External 또는 Internal Passthrough Network Load Balancer 생성

Ingress

Ingress
   ↓
GKE Ingress Controller
   ↓
External 또는 Internal Application Load Balancer 생성

💡 GKE는 Internal/External 옵션을 통해 사설 네트워크 전용 또는 외부 공개용을 유연하게 선택할 수 있는 게 특징입니다.

 

On-premise (바닐라 Kubernetes)

온프레미스 환경은 클라우드 사업자가 제공하는 관리형 Load Balancer 상품이 없기 때문에, 별도의 구현체를 직접 구축해야 합니다.

 

Service type: LoadBalancer
   ↓
MetalLB / kube-vip / Cilium
   ↓
External IP 또는 VIP 할당
   ↓
L2 또는 BGP 방식으로 네트워크에 광고

온프레미스에서 선택 가능한 구현체

• MetalLB — 가장 널리 쓰이는 오픈소스 구현체 (L2 / BGP 모드 지원)
• kube-vip — 컨트롤 플레인 HA와 LoadBalancer 기능을 함께 제공
• Cilium LB IPAM + L2 Announcement — Cilium CNI 기반 L2 방식
• Cilium LB IPAM + BGP Control Plane — Cilium CNI 기반 BGP 방식
• F5 · A10 등 외부 L4/ADC 장비 — 하드웨어 어플라이언스 기반 로드밸런싱

💡 온프레미스는 클라우드처럼 자동으로 IP가 할당 되는 구조가 아니기 때문에, L2(ARP 기반) 또는 BGP(라우팅 프로토콜 기반)로 네트워크에 직접 IP를 광고하는 방식을 선택해야 합니다.

각 인프라 플랫폼마다 구현 방식과 사용되는 제품은 다를 수 있습니다. 하지만 큰 관점에서 핵심적인 기술 메커니즘만 이해하고 있다면 플랫폼은 결국 하나의 도구에 불과합니다. 기본 원리를 이해한 상태에서는 각 플랫폼의 사용법만 익히면 AWS, Azure, Google Cloud, OpenShift, 온프레미스 등 어떤 환경에서도 유연하게 적용하고 운영할 수 있습니다.



이 부분을 살펴보다 보면 인프라 아키텍처에 익숙한 분들은 자연스럽게 이런 생각을 할 수 있습니다.

                                        "결국 Kubernetes가 네트워크부터 미들웨어 영역까지 모두 핸들링하는 것 아닌가?

맞습니다. 바로 그 점이 Kubernetes가 어려운 가장 큰 이유 중 하나입니다. Kubernetes는 단순히 컨테이너를 실행하는 도구가 아니라, 과거 엔터프라이즈 환경에서 여러 조직과 담당자가 나누어 관리하던 영역을 하나의 플랫폼 안에 통합한 거대한 생태계입니다.

기존 엔터프라이즈 환경에서는 일반적으로 각 영역의 역할이 비교적 명확하게 구분되어 있었습니다.

L4/L7 네트워크 구간 담당 : 네트워크 엔지니어
Web/WAS 등 미들웨어 구간 담당 : 미들웨어 엔지니어
애플리케이션 아키텍처 구간 담당 : AA(Application Architect)
운영체제 및 서버 구간 : TA 혹은 서버 엔지니어
데이터베이스 구간 : DBA
보안 : 보안 담당자

반면 Kubernetes 환경에서는 이러한 개별 영역들이 하나의 플랫폼 안에서 서로 긴밀하게 연결됩니다.

네트워크, 서비스 디스커버리, 로드밸런싱, Ingress, 스토리지, 스케줄링, 보안, 인증서, 배포, 확장, 장애 복구까지 애플리케이션이 실행되는 전체 환경을 플랫폼 차원에서 통합적으로 다룹니다.

즉, Kubernetes는 단순한 컨테이너 오케스트레이션 도구라기보다 다음과 같은 목적에 가까운 플랫폼입니다.

애플리케이션이 실행되기 위해 필요한 인프라와 운영 환경을 하나의 PaaS 형태로 추상화하고 통합한다.

이 때문에 Kubernetes를 제대로 이해하려면 어느 한 영역의 지식만으로는 부족합니다.

네트워크를 알아야 Ingress와 Service를 이해할 수 있고, 미들웨어를 알아야 애플리케이션의 트래픽 처리 구조를 이해할 수 있습니다. 서버와 운영체제를 알아야 리소스 관리와 장애 원인을 파악할 수 있으며, 스토리지를 알아야 Stateful Workload를 제대로 운영할 수 있습니다.