본문으로 건너뛰기

로드밸런싱과 서비스 노출

13분 읽기
AI용 문서 안내

개요​

하이브리드 노드에서 실행되는 워크로드를 클러스터 외부에 노출하는 방식은 클라우드 전용 클러스터와 다른 판단이 필요합니다. AWS는 Service type LoadBalancer에 대해 NLB(Network Load Balancer)와 Cilium 두 가지를 공식 지원하며, 선택 기준은 애플리케이션 트래픽의 발원지입니다. 본 문서는 이 결정 원칙과 경로별 구성 요건(NLB + AWS Load Balancer Controller, Cilium 내장 LB), MetalLB 등 커뮤니티 옵션, 그리고 L7 Ingress 경로를 다룹니다.

결정 원칙: 트래픽 발원지​

"The decision to use NLB or Cilium is based on the source of application traffic. If application traffic originates from an AWS Region, AWS recommends using AWS NLB and the AWS Load Balancer Controller. If application traffic originates from the local on-premises or edge environment, AWS recommends using Cilium's built-in load balancing capabilities." — Configure Services of type LoadBalancer for hybrid nodes

트래픽 발원지권장 경로전제 조건
AWS 리전 (또는 인터넷 → 리전 경유)NLB/ALB + AWS Load Balancer Controller (IP 타겟)Pod CIDR이 AWS에서 도달 가능 (BGP 풀 라우팅 또는 Gateway)
온프레미스·엣지 로컬Cilium 내장 LB (LB IPAM + BGP)Cilium BGP Control Plane 또는 LB IP의 온프렘 라우팅
온프레미스 로컬 (기존 장비·운영 관성)MetalLB 등 커뮤니티 옵션업스트림 Kubernetes 호환 — 자체 운영

온프레미스에서 발생해 온프레미스에서 소비되는 트래픽을 리전의 LB로 우회시키면 DX/VPN 왕복 지연과 대역폭 소비가 추가됩니다. 발원지 원칙은 이 헤어핀(hairpin) 경로를 방지하는 설계 기준입니다.

경로 1: NLB + AWS Load Balancer Controller (리전 발원)​

리전에서 발원하는 트래픽은 AWS Load Balancer Controller와 NLB를 IP 타겟 모드로 사용합니다. IP 타겟 모드에서 NLB는 Service 계층을 우회해 Pod IP로 직접 포워딩하므로, 하이브리드 Pod CIDR이 AWS에서 라우팅 가능해야 합니다 — 이는 Pod 레벨 inbound 요건이므로 BGP 풀 라우팅 또는 Hybrid Nodes Gateway가 전제입니다 (기능표).

아래는 각 리소스에 적용하는 어노테이션 발췌입니다. Service와 Ingress는 서로 다른 리소스이므로 별도 매니페스트로 작성합니다. 전체 매니페스트와 적용 절차는 LoadBalancer 서비스 구성과 Ingress 구성을 참조합니다.

Service type LoadBalancer(NLB)의 metadata.annotations 발췌:

# apiVersion: v1 / kind: Service 의 metadata.annotations
service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"

Ingress(ALB, L7 노출 시)의 metadata.annotations 발췌:

# apiVersion: networking.k8s.io/v1 / kind: Ingress 의 metadata.annotations
alb.ingress.kubernetes.io/target-type: "ip"

구성 시 주의 사항은 세 가지입니다.

  • 컨트롤러 배치: AWS Load Balancer Controller는 웹훅을 사용합니다. 하이브리드 노드에서 실행하려면 RemotePodNetwork 구성과 Pod CIDR 라우팅이 필요하므로, mixed mode 클러스터에서는 클라우드 노드 배치가 권장 패턴입니다 (Mixed Mode 배치 전략).
  • 인스턴스 타겟 미사용: 하이브리드 노드는 EC2 인스턴스가 아니므로 instance 타겟 모드를 사용할 수 없습니다. IP 타겟이 유일한 경로입니다.
  • 방화벽 경로: NLB → 하이브리드 Pod 트래픽은 DX/VPN을 경유하므로, 온프레미스 방화벽에서 서비스 포트·헬스 체크 포트의 VPC → Pod CIDR 방향 허용이 필요합니다 (방화벽 사전 등록).

경로 2: Cilium 내장 LB (온프렘 발원)​

온프레미스 로컬 트래픽은 별도 LB 인프라 없이 Cilium의 내장 기능으로 처리할 수 있습니다. 세 기능이 역할을 분담합니다.

기능역할비고
kube-proxy replacementService 트래픽의 백엔드 Pod 분배이 기능 자체는 커널 v4.19.57 / v5.1.16 / v5.2.0 이상을 요구합니다. 다만 Cilium 설치 가능 여부는 아래 "지원 버전과 OS·커널" 설명을 따릅니다
Load Balancer IPAMService type LoadBalancer에 외부 IP 할당CiliumLoadBalancerIPPool로 IP 풀 정의
BGP Control Plane할당된 LB IP를 온프렘 네트워크에 광고BGP 구성 선행 필요

kube-proxy replacement 없이도 LB IPAM과 BGP 광고는 사용할 수 있으며, 이 경우 백엔드 분배는 EKS 기본인 kube-proxy(iptables)가 담당합니다.

지원 버전과 OS·커널 (확인 시점: 2026-10-13) EKS Hybrid Nodes에서 AWS가 지원하는 Cilium은 v1.17.x와 v1.18.x 계열이며, AWS가 유지관리하는 빌드(Amazon ECR Public: eks/cilium/cilium)를 사용해야 지원 대상이 됩니다. 위 표의 커널 v4.19.57 / v5.1.16 / v5.2.0 값은 kube-proxy replacement 기능이 요구하는 최소 커널로, 기능별 요건입니다.

이와 별개로 Cilium 패치 버전 자체의 설치 가능 여부는 다른 기준을 따릅니다. 예를 들어 Cilium v1.18.3은 Linux 커널 5.10 이상을 요구하므로 Ubuntu 20.04와 RHEL 8에서는 설치가 지원되지 않습니다. 즉 kube-proxy replacement 기능만 보면 RHEL 8.x가 미충족이지만, 설치하려는 Cilium 패치 버전에 따라 제외되는 OS 범위가 더 넓어질 수 있습니다. 사용하려는 정확한 패치 버전과 노드 OS·커널 조합은 Configure CNI for hybrid nodes의 버전 호환성 표와 Cilium system requirements로 확인해야 합니다.

# LB IP 풀 정의
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: tcp-service-pool
spec:
  blocks:
    - cidr: "LB_IP_CIDR"          # /32로 단일 IP 지정 가능
  serviceSelector:
    matchLabels:
      io.kubernetes.service.name: tcp-sample-service
---
# LB IP를 BGP로 온프렘에 광고
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: bgp-advertisement-tcp-service
  labels:
    advertise: bgp
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - LoadBalancerIP
      selector:
        matchLabels:
          io.kubernetes.service.name: tcp-sample-service
---
# Service — loadBalancerClass 필수
apiVersion: v1
kind: Service
metadata:
  name: tcp-sample-service
  annotations:
    lbipam.cilium.io/ips: "LB_IP_ADDRESS"   # 특정 IP 요청 (선택)
spec:
  loadBalancerClass: io.cilium/bgp-control-plane
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: nginx
  • loadBalancerClass는 레거시 AWS Cloud Provider가 해당 Service에 Classic Load Balancer를 생성하는 것을 방지하기 위해 필수입니다. BGP 광고에는 io.cilium/bgp-control-plane을 사용합니다.
  • io.cilium/l2-announcer(L2 Announcements)는 베타 기능으로 AWS 공식 지원 대상이 아닙니다.
  • BGP 광고 시 각 하이브리드 노드가 LB IP를 /32로 광고하며, 백엔드 분배는 클러스터 내부에서 수행됩니다. cilium-dbg service list로 LB IP → 백엔드 Pod 매핑을 확인할 수 있습니다.

커뮤니티 옵션: MetalLB 외​

하이브리드 노드는 업스트림 Kubernetes와 완전 호환되므로, 온프레미스에서 통용되는 LB·Ingress 솔루션 대부분을 사용할 수 있습니다. 공식 블로그가 언급하는 옵션은 Cilium(BGP·L2), Calico(BGP), MetalLB, NGINX, HAProxy, Apache APISIX, Emissary Ingress, Istio 등입니다.

MetalLB는 두 모드를 제공합니다.

  • L2 모드 (ARP): 노드 서브넷에서 예약한 IP 풀을 사용하고, 선출된 노드 1대가 해당 LB IP의 ARP 요청에 응답합니다. BGP 운영 없이 시작할 수 있어 엣지·소규모 환경에 적합하지만, LB IP당 트래픽 인입이 단일 노드로 수렴하는 특성을 용량 계획에 반영해야 합니다.
  • BGP 모드 (L3): LB IP를 BGP로 광고합니다. 다만 Cilium을 CNI로 사용하는 환경이라면 별도 컴포넌트를 추가하기보다 Cilium BGP Control Plane + LB IPAM으로 통합하는 것이 관리 지점을 줄입니다.

선택 기준은 기존 온프레미스 환경의 운영 기술과 애플리케이션 요구 사항입니다. 이미 검증된 LB 운영 체계가 있다면 유지하고, 신규 구축이라면 AWS 지원 범위인 Cilium 내장 LB를 우선 검토합니다.

L7 Ingress​

  • 리전 발원: ALB + AWS Load Balancer Controller(target-type: ip)를 사용합니다. 전제 조건은 경로 1과 동일합니다.

  • 온프렘 발원: Cilium Ingress 또는 Cilium Gateway(Kubernetes Gateway API)를 사용합니다. 여기서 "Cilium Gateway"는 Gateway API 리소스를 처리하는 Cilium의 L7 기능으로, VPC와 하이브리드 노드 간 VXLAN 연결을 담당하는 EKS Hybrid Nodes Gateway(별도 제품)와는 다른 것입니다. Ingress/Gateway가 받는 LoadBalancer IP는 Cilium LB IPAM으로 할당되므로, BGP 광고 또는 대체 라우팅으로 해당 IP가 온프레미스에서 도달 가능해야 합니다. 구성 절차는 Configure Kubernetes Ingress for hybrid nodes를 참조합니다.

    Cilium L7 Ingress/Gateway를 사용할 때는 다음 두 가지 호환성 제약을 확인합니다.

    • L7 프록시(Envoy) 활성화 필요 — Hybrid Nodes Gateway의 CNI 설정과 충돌: Cilium Ingress/Gateway는 노드의 Envoy 프록시가 L7 트래픽을 처리하므로 envoy.enabled=true가 필요합니다. 반면 EKS Hybrid Nodes Gateway는 VTEP(VXLAN Tunnel Endpoint)를 활성화하기 위해 l7Proxy=false를 요구합니다(Configure CNI for the Hybrid Nodes gateway). 따라서 동일 클러스터에서 Hybrid Nodes Gateway용 CNI 구성(vtep.enabled=true, l7Proxy=false)과 Cilium L7 Ingress/Gateway를 함께 쓰면 L7 프록시가 꺼져 Ingress/Gateway가 동작하지 않습니다. Pod CIDR 도달성을 Hybrid Nodes Gateway로 확보한 환경에서 L7 라우팅이 필요하면, L7 처리를 별도 경로로 분리하는 것(예: 리전 발원 트래픽은 ALB + AWS Load Balancer Controller 사용)을 검토합니다.
    • AWS Load Balancer Controller + NLB와 병용 불가: 공식 문서는 EKS Hybrid Nodes에서 Cilium Ingress/Gateway를 AWS Load Balancer Controller 및 NLB와 함께 사용할 수 없다고 명시합니다. NLB의 target-type: ip(하이브리드 노드에서 NLB 사용 시 필수)가 Service를 받치는 Pod IP로 직접 연결을 시도하므로 타겟이 등록되지 않습니다(LoadBalancer 서비스 구성).

반대 방향인 온프레미스 LB → 클라우드 Pod(DR) 경로 설계는 방화벽·TGW 토폴로지에서 다룹니다.

권장 사항 요약​

  • 트래픽 발원지를 먼저 판정합니다 — 리전 발원은 NLB/ALB + IP 타겟, 온프렘 로컬은 Cilium 내장 LB가 기본 경로입니다.
  • 온프렘 로컬 트래픽을 리전 LB로 우회시키는 헤어핀 구조는 DX/VPN 지연·대역폭 비용을 유발하므로 피합니다.
  • NLB/ALB IP 타겟은 Pod CIDR 라우팅(BGP 또는 Gateway)이 전제임을 설계 초기에 확정합니다.
  • AWS Load Balancer Controller는 mixed mode에서 클라우드 노드에 배치합니다.
  • Cilium 내장 LB 사용 시 Service에 loadBalancerClass: io.cilium/bgp-control-plane을 명시합니다. kube-proxy replacement 기능은 RHEL 8.x에서 사용할 수 없고, 설치하려는 Cilium 패치 버전에 따라 지원 OS 범위가 더 좁아질 수 있으므로(예: v1.18.3은 Ubuntu 20.04·RHEL 8 미지원), 노드 OS·커널과 Cilium 버전 조합을 설치 전에 확인합니다.
  • MetalLB L2 모드는 LB IP당 단일 노드 인입 특성을 용량 계획에 반영합니다.

참고 자료​

공식 문서​

기술 블로그​

관련 문서 (내부)​