DevOps 지식 허브
DevOps 지식 허브

올바른 Kubernetes 서비스 유형 선택: ClusterIP 대 NodePort 대 LoadBalancer

Kubernetes 서비스 유형인 ClusterIP, NodePort, LoadBalancer 간의 중요한 차이점을 해독합니다. 이 가이드는 핵심 메커니즘, 이상적인 사용 사례(내부 마이크로서비스 통신부터 프로덕션 준비 완료된 클라우드 노출까지), 그리고 모든 Kubernetes 배포에 적합한 네트워킹 추상화를 선택하는 데 도움이 되는 실용적인 YAML 예제를 설명합니다.

34 조회수

올바른 Kubernetes 서비스 유형 선택: ClusterIP vs NodePort vs LoadBalancer

Kubernetes 서비스는 Pod의 논리적 집합과 해당 Pod에 액세스하는 정책을 정의하는 필수적인 추상화입니다. Kubernetes에서 애플리케이션을 배포할 때 올바른 서비스 유형을 선택하는 것은 네트워크 접근성을 결정하는 데 중요합니다. 즉, 서비스가 클러스터 내부에서만 접근 가능해야 하는지, 특정 포트를 통해 외부 세계에 노출되어야 하는지, 또는 클라우드 제공업체의 로드 밸런싱 인프라와 직접 통합되어야 하는지에 따라 달라집니다. 이 설정을 잘못 구성하면 애플리케이션에 액세스할 수 없거나 불필요한 인프라 비용이 발생할 수 있습니다.

이 가이드에서는 세 가지 기본 Kubernetes 서비스 유형인 ClusterIP, NodePort, LoadBalancer에 대한 포괄적인 비교를 제공합니다. 각 유형의 사용 사례, 구현 메커니즘 및 관련 절충점을 이해함으로써 애플리케이션의 네트워킹 요구 사항에 완벽하게 부합하는 정보에 입각한 결정을 내릴 수 있으며, 내부 통신과 외부 접근성이 모두 효과적으로 관리되도록 보장할 수 있습니다.

Kubernetes 서비스 이해하기

특정 유형으로 넘어가기 전에 Kubernetes 서비스의 역할을 기억하는 것이 중요합니다. Pod는 일시적이므로 IP 주소는 생성, 삭제 또는 재스케줄링에 따라 변경됩니다. 서비스는 동적으로 변경되는 Pod 집합에 대해 안정적인 엔드포인트(고정 IP 주소 및 DNS 이름)를 제공하여 클러스터 내에서 안정적인 통신을 가능하게 합니다.

서비스는 일반적으로 관련 Pod를 찾기 위한 selector와 해당 서비스가 노출되는 방식을 정의하는 type을 지정하는 Service 객체 매니페스트를 사용하여 정의됩니다.

1. ClusterIP: 내부 통신

ClusterIP는 기본적이고 가장 기본적인 서비스 유형입니다. 클러스터 내부의 내부 IP 주소로 서비스를 노출합니다. 이 서비스는 클러스터 내부에서만 접근할 수 있습니다.

ClusterIP의 사용 사례

  • 백엔드 서비스: 동일한 Kubernetes 클러스터 내에서 실행되는 다른 서비스 또는 프런트엔드 애플리케이션과만 통신하면 되는 데이터베이스, 내부 API, 캐싱 계층 또는 마이크로서비스에 이상적입니다.
  • 내부 검색: Kubernetes의 내부 DNS를 활용하여 안정적인 서비스 검색 이름(예: my-database.namespace.svc.cluster.local)을 제공합니다.

구현 세부 정보

ClusterIP 서비스가 생성되면 Kubernetes는 클러스터 네트워크 패브릭 내부에서만 라우팅 가능한 가상 IP 주소를 할당합니다. 외부 트래픽은 이 IP에 직접 액세스할 수 없습니다.

예제 매니페스트 (ClusterIP):

apiVersion: v1
kind: Service
metadata:
  name: internal-api
spec:
  selector:
    app: backend-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

팁: 모든 구성 요소가 클러스터 내에 있는 분산 시스템만 구축하는 경우, ClusterIP는 불필요한 외부 노출을 피할 수 있으므로 가장 안전하고 효율적인 선택입니다.

2. NodePort: 특정 클러스터 노드를 통한 서비스 노출

NodePort는 서비스를 외부로 노출하는 가장 간단한 방법입니다. 클러스터의 모든 노드(VM 또는 물리적 머신)에서 특정 포트를 열고 해당 포트로 들어오는 외부 트래픽을 서비스로 라우팅합니다.

NodePort의 사용 사례

  • 개발 및 테스트: 완전한 클라우드 로드 밸런서 설정이 과도할 때 개발 중에 외부에서 액세스 가능한 서비스를 신속하게 테스트하는 데 유용합니다.
  • 클라우드 이외 환경: 기본 클라우드 로드 밸런싱 통합을 사용할 수 없는 베어메탈 또는 온프레미스 Kubernetes 설치에서 필수적입니다.

구현 세부 정보

NodePort 서비스가 생성되면 Kubernetes는 모든 노드에서 구성된 범위(기본값은 30000–32767)의 정적 포트를 선택합니다. 서비스는 다음을 통해 애플리케이션을 노출합니다.

http://<NodeIP>:<NodePort>

IP가 10.0.0.1, 10.0.0.2, 10.0.0.3인 세 개의 노드가 있고 NodePort가 30080인 경우, 세 IP 중 하나에서 30080 포트를 통해 서비스에 액세스할 수 있습니다.

예제 매니페스트 (NodePort):

apiVersion: v1
kind: Service
metadata:
  name: test-web-app
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30080 # 선택 사항: 외부 포트를 지정하거나 Kubernetes가 선택하도록 합니다.
  type: NodePort

경고: 서비스가 모든 노드에서 노출되므로 노드가 실패하면 트래픽이 해당 노드로 전달되지 않도록 해야 합니다. 또한 포트 범위(30000-32767)가 다른 서비스 또는 호스트 구성과 충돌할 수 있습니다.

3. LoadBalancer: 클라우드 네이티브 외부 노출

LoadBalancer는 지원되는 클라우드 제공업체(AWS, GCP, Azure 등)에서 실행할 때 프로덕션 애플리케이션을 외부로 노출하는 데 선호되는 방법입니다.

LoadBalancer의 사용 사례

  • 프로덕션 배포: 클라우드 제공업체의 인프라와 원활하게 통합되는 강력하고 고가용성의 외부 액세스를 제공합니다.
  • 자동 IP 관리: 개별 노드 IP를 알거나 포트 충돌을 관리할 필요성을 추상화합니다.

구현 세부 정보

클라우드 환경에서 LoadBalancer 유형의 서비스가 생성되면 해당 클라우드 컨트롤러 관리자가 외부 로드 밸런서(예: AWS ELB 또는 GCP Load Balancer)를 프로비저닝하고 지정된 NodePort로 클러스터 노드에 트래픽을 라우팅하도록 구성합니다(클라우드 LB는 일반적으로 내부적으로 관리)..

이 외부 로드 밸런서는 전용의 고정 외부 IP 주소를 받습니다.

예제 매니페스트 (LoadBalancer):

apiVersion: v1
kind: Service
metadata:
  name: public-web-service
spec:
  selector:
    app: public-facing
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

이것이 생성되면 출력(kubectl get svc 사용)에 할당된 외부 IP가 표시됩니다.

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
public-web-service    LoadBalancer   10.96.45.11   34.120.200.55    80:30021/TCP   1m

이제 애플리케이션은 http://34.120.200.55를 통해 액세스할 수 있습니다.

모범 사례: HTTPS/SSL 종료가 필요한 서비스의 경우, Kubernetes Pod 내에서 종료 로직을 실행하는 것보다 클라우드 제공업체에 특정한 주석을 사용하여 외부 클라우드 로드 밸런서를 구성하여 TLS를 처리하는 것이 좋습니다.

요약 비교표

기능 ClusterIP NodePort LoadBalancer
주요 용도 내부 서비스 통신 간단한 외부 액세스 (테스트/베어메탈) 프로덕션, 클라우드 네이티브 외부 액세스
접근성 클러스터 내부에서만 고정 포트(30000-32767)의 모든 노드 클라우드 제공업체가 관리하는 외부 IP
IP 안정성 안정적인 내부 IP 안정적인 노드 IP이지만 포트 알아야 함
클라우드 종속성 없음 없음 높음 (클라우드 컨트롤러 관리자 필요)
비용 무료 (외부 인프라 없음) 최소 (노드 리소스 사용) 상당함 (외부 LB 리소스에 대한 요금 부과)
구성 복잡성 최저 낮음 중간 (클라우드 구성 필요)

결론: 현명한 선택

올바른 서비스 유형을 선택하는 것은 Kubernetes 네트워킹의 기본 단계입니다.

  1. 내부부터 시작 (ClusterIP): 서비스가 클러스터 외부에서 액세스할 필요가 전혀 없다면 항상 ClusterIP를 사용하세요. 이렇게 하면 공격 표면과 오버헤드가 최소화됩니다.
  2. 테스트/베어메탈 (NodePort): 기본적인 외부 테스트가 필요하거나 주요 클라우드 환경 외부에서 Kubernetes를 실행하는 경우, NodePort는 즉각적이지만 덜 강력한 외부 액세스를 제공합니다.
  3. 프로덕션 클라우드 (LoadBalancer): AWS, GCP 또는 Azure에서 호스팅되는 프로덕션 애플리케이션 중 내구성 있고 안정적이며 전용된 외부 진입점이 필요한 경우, LoadBalancer가 올바른 선택이며 복원력을 위해 클라우드 인프라를 활용합니다.

서비스 유형을 필요한 접근성 및 배포 환경과 일치시킴으로써 컨테이너 오케스트레이션 아키텍처 내에서 최적의 성능, 보안 및 통합을 보장할 수 있습니다.