[k8s] 외부 서비스 접근을 위한 Service(ClusterIP, NodePort, LoadBalancer) 알아보기

지난 포스팅에서는 쿠버네티스의 가장 기본 단위인 Pod와 이를 관리하는 Deployment에 대해 알아보았습니다. 하지만 Pod는 언제든 죽고 다시 살아날 수 있는 '유동적인' 존재죠. 이때마다 IP가 바뀌기 때문에 외부나 내부의 다른 서비스가 Pod에 안정적으로 접근하기 위해서는 고정된 엔드포인트가 필요합니다.

오늘은 쿠버네티스 네트워킹의 핵심이자, 외부로 서비스를 노출하는 관문인 **Service(ClusterIP, NodePort, LoadBalancer)**에 대해 알아보겠습니다.

 

이전 시간에 학습한 [Kubernetes] ReplicaSet과 Deployment, 대체 뭐가 다른 걸까? (차이점 명확히 알기) 바로가기

티스토리

 

---

1. 쿠버네티스 서비스(Service)란?

쿠버네티스에서 Service는 동일한 역할을 수행하는 Pod 그룹에 단일 진입점(가상 IP)을 제공하는 리소스입니다. Pod가 교체되어 IP가 변경되더라도 Service의 IP는 변하지 않으므로 클라이언트는 중단 없이 서비스에 접근할 수 있습니다.

---

2. 서비스 타입별 상세 분석 및 아키텍처

각 서비스 타입은 **"접근 범위"**에 따라 구분됩니다. 아래 구성도를 통해 전체적인 흐름을 먼저 파악해 보겠습니다.

① ClusterIP (클러스터 내부 통신)

가장 기본이 되는 서비스 타입입니다.

• 특징: 클러스터 내부의 다른 Pod들만 접근할 수 있는 가상 IP를 할당받습니다.
• 용도: 프론트엔드 Pod가 백엔드 Pod와 통신할 때, 혹은 DB Pod에 접근할 때 사용합니다.
• 흐름: Pod A → Service(ClusterIP) → Pod B

② NodePort (외부 접근의 기초)

클러스터 모든 노드의 특정 포트를 개방하여 외부 트래픽을 서비스로 전달합니다.

• 특징: ClusterIP 기능을 포함하며, 모든 노드에 동일한 포트(기본 30000-32767)를 엽니다.
• 용도: 클라우드 로드밸런서가 없는 환경에서 외부 접근을 테스트할 때 주로 사용합니다.
• 흐름: External Client → NodeIP:NodePort → Service(ClusterIP) → Pod

③ LoadBalancer (클라우드 운영 표준)

클라우드 공급자(AWS, GCP, Azure 등)에서 제공하는 로드밸런서를 자동으로 프로비저닝합니다.

• 특징: NodePort와 ClusterIP 기능을 모두 포함합니다. 클라우드 로드밸런서가 외부 IP를 할당받아 트래픽을 관리합니다.
• 용도: 실제 운영 환경에서 서비스를 외부에 노출하는 표준 방식입니다.
• 흐름: External Client → LoadBalancer IP → NodePort → Service(ClusterIP) → Pod

---

3. Hands-on: 서비스 생성 및 테스트

실제로 nginx 애플리케이션을 배포하고 서비스를 연결해 보겠습니다.

Step 1: Deployment 생성

YAML

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Step 2: 서비스(NodePort) 생성

테스트를 위해 외부 접근이 가능한 NodePort 타입으로 생성합니다.

YAML

 

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx # 위 Deployment의 라벨과 일치해야 함
  ports:
    - protocol: TCP
      port: 80         # 서비스의 포트
      targetPort: 80   # 컨테이너의 포트
      nodePort: 32000  # 노드에 개방할 포트

Step 3: 테스트 결과 확인 (Hands-on)

명령어를 통해 서비스가 정상적으로 생성되었는지 확인합니다.

Bash

 

$ kubectl get svc nginx-service
NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort   10.104.1.25     <none>        80:32000/TCP   1m

검증: 이제 브라우저에서 http://<Worker-Node-IP>:32000으로 접속하면 Nginx 환영 페이지가 나타납니다. kubectl describe svc 명령을 통해 Endpoints 항목에 3개 Pod의 IP가 잘 맵핑되어 있는지 확인하는 것이 핵심입니다.

---

4. 서비스 타입별 비교 한눈에 보기

구분	ClusterIP	NodePort	LoadBalancer
접근 범위	클러스터 내부 전용	외부 접근 가능 (Node IP 활용)	외부 접근 가능 (LB IP 활용)
용도	백엔드, DB 등 내부 연동	개발 환경, 테스트용	실제 운영 환경, 웹 서비스
포트 관리	자유로움	30000~32767 제한	클라우드 설정에 따름

 

---

5. 실무 관점의 인사이트 (Insight)

쿠버네티스 서비스를 설계할 때 다음 세 가지를 꼭 기억하세요.

1. 계층적 구조의 이해: LoadBalancer는 결국 내부적으로 NodePort를 쓰고, NodePort는 ClusterIP를 통해 Pod에 도달합니다. 즉, 외부 노출 서비스라도 내부 IP를 통한 통신은 항상 기저에 깔려 있습니다.
2. 보안과 격리: 모든 서비스를 외부로 노출할 필요는 없습니다. DB나 캐시 서버는 반드시 ClusterIP로 설정하여 외부 공격 지점을 최소화해야 합니다.
3. Ingress와의 시너지: LoadBalancer 타입은 서비스마다 IP가 생성되어 비용이 발생할 수 있습니다. 운영 환경에서는 하나의 로드밸런서 아래 여러 서비스를 묶어주는 Ingress를 함께 사용하는 것이 효율적입니다.

---

마치며

오늘은 쿠버네티스 서비스의 3가지 핵심 타입에 대해 알아보았습니다. 핵심은 **"서비스는 포드에게 변하지 않는 이름을 부여하고, 외부와 내부를 잇는 튼튼한 다리 역할을 한다"**는 점입니다.

쿠버네티스 네트워킹은 여기서 끝이 아닙니다. 여러 서비스를 효율적으로 관리하고 SSL/TLS 인증서 처리까지 담당하는 Ingress라는 더 강력한 개념이 남아있죠.

 

다음 포스팅에서는 이 서비스들을 스마트하게 관리해주는 "Ingress"에 대해 다뤄보겠습니다.