NodePort vs. LoadBalancer vs. Ingress: 최적의 서비스 노출 방법 선택

NodePort vs. LoadBalancer vs. Ingress: 최적의 서비스 노출 방식 선택

Kubernetes 서비스는 동적인 파드(Pod) 집합에 안정적인 네트워킹을 제공하는 기본 오브젝트입니다. 서비스가 내부 클러스터 통신을 처리하는 반면, 해당 서비스를 외부(사용자 또는 외부 애플리케이션이 상호 작용할 수 있도록)에 노출하는 것은 특정 구성이 필요합니다. 올바른 노출 방식을 선택하는 것은 보안, 비용 및 복잡성에 영향을 미치므로 매우 중요합니다.

이 글에서는 Kubernetes 서비스를 노출하는 세 가지 주요 방법인 NodePort, LoadBalancer, Ingress에 대한 전문가 비교를 제공합니다. 컨테이너화된 애플리케이션에 최적의 솔루션을 선택하는 데 도움이 되도록 각 방식의 작동 방식, 적합한 사용 사례 및 실제 고려 사항을 분석합니다.

1. 서비스 노출 유형: NodePort

NodePort 서비스 유형은 서비스를 외부에 노출하는 가장 간단하고 기본적인 방법입니다. 서비스를 NodePort로 정의하면 Kubernetes는 클러스터 내의 모든 노드에 특정 고정 포트를 엽니다. 해당 포트로 향하는 모든 트래픽은 노드에서 서비스로 직접 라우팅됩니다.

NodePort 작동 방식

지정된 범위(기본값: 30000-32767) 내의 임의 포트가 자동으로 선택됩니다.
이 포트는 모든 클러스터 노드에서 열립니다.
서비스는 이 NodePort에서 수신 대기하며, 적절한 파드로 트래픽을 전달합니다.

애플리케이션에 액세스하려면 http://<노드_IP>:<NodePort>를 사용합니다.

사용 사례 및 제한 사항

특징	설명
사용 사례	개발, 테스트 환경 또는 외부 로드 밸런싱이 외부 비클라우드 어플라이언스에 의해 처리되는 경우.
복잡성	매우 낮음.
비용	없음 (기본 VM 비용을 무시할 경우).
제한 사항	외부 방화벽 규칙을 수동으로 관리해야 합니다. 노드 IP는 종종 동적입니다. 포트 범위 제한 (30000-32767).

NodePort 예시

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Optional: specify a NodePort, otherwise one is chosen automatically
      # nodePort: 30001

⚠️ 경고: NodePort는 모든 노드를 통해 서비스를 노출합니다. 노드가 제거되거나 IP가 변경되면 외부 액세스가 중단됩니다. 안정성이 중요한 프로덕션 환경에는 일반적으로 권장되지 않습니다.

2. 서비스 노출 유형: LoadBalancer

LoadBalancer 서비스 유형은 클라우드 환경(AWS EKS, GCP GKE, Azure AKS)에서 애플리케이션을 공용 인터넷에 노출하는 표준 방법입니다.

서비스를 LoadBalancer로 정의하면 Kubernetes는 전용 Layer 4 (L4) 클라우드 로드 밸런서(예: AWS Classic ELB/NLB, Azure Load Balancer, GCP Network Load Balancer)를 자동으로 프로비저닝합니다. 이는 서비스 파드로 트래픽을 직접 라우팅하는 안정적이고 고가용성 외부 IP 주소를 제공합니다.

클라우드 공급자 통합

LoadBalancer의 주요 차별점은 기본 클라우드 인프라와의 긴밀한 통합입니다. 클라우드 공급자가 로드 밸런서의 수명 주기, 상태 확인 및 라우팅을 처리합니다.

사용 사례 및 비용 영향

특징	설명
사용 사례	전용의 안정적인 IP 주소가 필요한 간단한 공용 애플리케이션. 비-HTTP/S 프로토콜(TCP/UDP)에 적합합니다.
복잡성	낮음 (구성 측면에서).
비용	높음. 각 LoadBalancer 서비스는 전용 클라우드 리소스를 프로비저닝하며, 종종 시간당 요금이 발생합니다.
이점	즉각적인 고가용성과 자동 상태 확인을 제공합니다.

LoadBalancer 예시

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: my-api-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

생성 시 클러스터는 클라우드 공급자가 관리하는 외부 IP 주소(서비스 상태에서 확인 가능)를 할당합니다.

3. Kubernetes Ingress: Layer 7 라우팅

Ingress는 NodePort 및 LoadBalancer와 근본적으로 다릅니다. Ingress는 서비스 유형이 아니라, 일반적으로 HTTP 및 HTTPS(Layer 7)와 같은 외부 액세스 규칙을 정의하는 API 오브젝트입니다.

Ingress는 호스트 이름 및 URL 경로를 기반으로 정교한 라우팅을 허용하는 중앙 진입점 역할을 합니다. 이 접근 방식은 단일 IP 주소 뒤에서 여러 서비스를 관리하는 데 필수적입니다.

Ingress Controller의 역할

Ingress 규칙이 작동하려면 먼저 Ingress Controller (예: Nginx, Traefik, Istio)를 배포해야 합니다. 컨트롤러는 Ingress 리소스 정의를 감시하고 해당 규칙에 따라 기본 리버스 프록시/L7 로드 밸런서를 구성합니다.

결정적으로, Ingress Controller 자체는 일반적으로 단일 LoadBalancer 또는 NodePort 서비스를 사용하여 노출됩니다.

Ingress의 고급 기능

Ingress는 고급 트래픽 관리 기능이 필요할 때 빛을 발합니다:

비용 최적화: 애플리케이션 서비스당 하나의 LoadBalancer 대신 (컨트롤러를 노출하기 위해) 단일 클라우드 LoadBalancer를 사용합니다.
가상 호스팅: 호스트 이름(api.example.com은 서비스 A로, www.example.com은 서비스 B로)을 기반으로 트래픽을 라우팅합니다.
경로 기반 라우팅: URL 경로(/v1/users는 서비스 A로, /v2/posts는 서비스 B로)를 기반으로 트래픽을 라우팅합니다.
SSL/TLS 터미네이션: 인증서 관리 및 암호 해독을 중앙에서 처리합니다.

Ingress 리소스 예시

이 예시는 api.example.com/v1에 대한 트래픽을 my-api-v1 서비스로 라우팅합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Specify the controller in use
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... other rules for different services/hosts

4. 비교 및 선택 가이드

최적의 방법을 선택하는 것은 환경, 복잡성, 기능 세트 및 운영 비용과 같은 요소를 고려하는 것을 포함합니다.

기능 비교표

특징	NodePort	LoadBalancer	Ingress
계층	L4 (TCP/UDP)	L4 (TCP/UDP)	L7 (HTTP/S)
안정성 (IP)	불안정 (노드 IP 사용)	안정적 (전용 클라우드 IP)	안정적 (컨트롤러 IP 사용)
비용	낮음 (운영 오버헤드 높음)	높음 (서비스당 리소스 비용)	중간 (컨트롤러용 LoadBalancer 하나)
라우팅 로직	단순 포트 포워딩	단순 포트 포워딩	호스트 이름, 경로, SSL 터미네이션
클라우드 종속성	없음	높음	높음 (LoadBalancer로 노출된 컨트롤러 필요)
프로덕션 준비 완료	아니요	예 (단순 앱)	예 (복잡한 앱)

결정 기준: 노출 방식 선택

내부 또는 테스트 전용: 클러스터 내에서 연결을 테스트하기만 하면 되거나, 외부 네트워킹을 직접 관리하는 경우(예: 베어메탈 환경) NodePort를 사용하세요.
간단하고 전용 L4 노출: 애플리케이션이 비-HTTP 프로토콜(예: 사용자 지정 TCP 프로토콜 또는 UDP)을 사용하거나, 즉각적인 전용 L4 액세스가 필요한 단일 공용 애플리케이션만 있는 경우 LoadBalancer를 사용하세요.
복잡한 다중 서비스 L7 노출: 노출할 서비스가 여러 개 있고, 경로 기반 또는 호스트 이름 라우팅이 필요하며, 중앙 집중식 SSL 터미네이션이 필요하거나, 단일 외부 IP를 공유하여 클라우드 비용을 최소화하려는 경우 Ingress를 사용하세요.

모범 사례: 관리형 클라우드 환경의 프로덕션 배포에서는 일반적으로 Ingress가 선호되는 선택입니다. 이는 증가하는 마이크로서비스를 관리하는 데 필요한 정교함, 보안 중앙 집중화 및 비용 효율성을 제공합니다.

결론

Kubernetes는 기본 L4 NodePort부터 클라우드 통합 L4 LoadBalancer, 그리고 Ingress의 정교한 L7 라우팅 기능에 이르기까지 다양한 서비스 노출 솔루션을 제공합니다. 각 방법의 운영 계층, 비용 모델 및 필요한 라우팅 로직을 이해함으로써 엔지니어는 프로덕션 워크로드에 대해 확장 가능하고 안전하며 비용 효율적인 네트워크 아키텍처를 설계할 수 있습니다.