설명 (Description): 쿠버네티스(Kubernetes) 노드포트(NodePort) 서비스의 개념과 핵심 동작 원리를 알아봅니다. ClusterIP, LoadBalancer와의 차이점을 비교하고, 명확한 YAML 예제를 통해 실무 사용법과 주의사항까지 실무자 수준에서 상세히 설명합니다.
TL;DR: 쿠버네티스 노드포트(NodePort)는 클러스터 외부에서 내부 애플리케이션에 접근할 수 있도록 각 노드(Node)의 특정 포트를 개방하는 서비스 타입입니다. 모든 노드는 동일한 포트 번호(기본 범위: 30000-32767)를 사용하며, 사용자는 <노드 IP>:<노드 포트> 주소로 서비스에 접근할 수 있습니다. 노드포트는 주로 개발, 테스트, 데모 환경에서 서비스를 외부에 빠르고 간단하게 노출시킬 목적으로 사용됩니다. 프로덕션 환경에서는 보안 및 관리상의 이유로 인그레스(Ingress)나 로드밸런서(LoadBalancer) 타입 사용이 권장됩니다.
1. 쿠버네티스 서비스와 노드포트(NodePort)의 기본 개념
쿠버네티스 환경에서 파드(Pod)는 동적으로 생성되고 삭제되며 고유한 IP를 가지지만, 이 IP는 영구적이지 않습니다. 파드가 재시작되면 IP 주소가 변경될 수 있기 때문에, 애플리케이션의 안정적인 엔드포인트를 제공하기 위해 '서비스(Service)'라는 오브젝트가 필요합니다. 서비스는 여러 파드를 논리적인 단위로 묶고, 이들에게 고정적인 접근 포인트를 부여하는 역할을 합니다.
쿠버네티스 서비스에는 여러 타입이 있으며, 노드포트(NodePort)는 그중 외부 노출을 위한 가장 기본적인 방법 중 하나입니다. 노드포트 서비스를 생성하면, 쿠버네티스는 클러스터의 모든 워커 노드(Worker Node)에 특정 포트(기본적으로 30000-32767 사이의 임의의 포트)를 할당하여 개방합니다. 외부 트래픽이 어느 노드의 해당 포트로 들어오든, 쿠버네티스 내부의 kube-proxy 컴포넌트가 이를 서비스에 연결된 적절한 파드로 전달(forwarding)합니다.
Why it matters: 노드포트는 복잡한 클라우드 인프라나 별도의 로드밸런서 설정 없이, 클러스터 외부에서 실행 중인 애플리케이션에 직접 접근할 수 있는 간단한 통로를 제공합니다. 이는 개발 및 테스트 단계에서 빠른 접근성 확보에 매우 유용합니다.
2. 노드포트(NodePort)의 동작 방식과 구성 요소
노드포트 서비스는 내부 통신을 담당하는 ClusterIP 서비스의 확장된 형태입니다. 즉, 노드포트 서비스를 생성하면 내부적으로 ClusterIP 서비스가 먼저 생성되고, 그 위에 외부 접근 기능이 추가되는 구조입니다.
노드포트 서비스의 트래픽 흐름은 다음과 같습니다.
- 외부 요청: 사용자가 http://<특정 노드의 공인 IP>:<노드 포트>로 요청을 보냅니다.
- 노드 수신: 요청을 받은 노드는 해당 포트가 노드포트 서비스와 연결된 것을 인지합니다.
- kube-proxy 전달: 각 노드에서 실행 중인 kube-proxy는 이 요청을 서비스의 ClusterIP와 포트로 전달합니다.
- 파드 라우팅: 서비스는 자신에게 연결된(일반적으로 레이블 셀렉터 기준) 파드 중 하나를 선택하여 최종적으로 요청을 전달합니다. 이때 간단한 로드 밸런싱(기본적으로 랜덤 분산)이 이루어집니다.
이 과정에서 세 가지 중요한 포트가 관여합니다.
포트 종류 | 설명 | 예시 |
targetPort | 파드 내의 컨테이너가 리스닝하는 실제 포트입니다. | 80 (웹서버) |
port | 서비스 자체(ClusterIP)가 클러스터 내부에서 노출하는 포트입니다. | 8080 |
nodePort | 클러스터 외부로 노출되는, 각 노드의 물리적인 포트입니다. | 30080 |
Why it matters: 노드포트는 외부 요청을 내부 서비스로 연결하는 다리 역할을 합니다. nodePort, port, targetPort 세 가지 포트의 관계를 이해하는 것은 쿠버네티스 네트워크 흐름을 파악하는 데 핵심적입니다.
3. 노드포트 YAML 예제 및 설정
아래는 간단한 Nginx 배포(Deployment)를 생성하고 이를 노드포트 서비스로 외부에 노출하는 예제 YAML 파일입니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: my-nginx
template:
metadata:
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-nginx-service
spec:
type: NodePort # 서비스 타입을 NodePort로 지정
selector:
app: my-nginx # 위 Deployment의 파드 레이블과 일치해야 함
ports:
- protocol: TCP
port: 8080 # 서비스의 ClusterIP에 할당될 포트
targetPort: 80 # 파드 컨테이너가 리스닝하는 포트
# nodePort: 30007 # 이 라인을 주석 해제하면 특정 포트를 지정할 수 있음. 생략 시 자동 할당.
위 YAML 파일을 kubectl apply -f <파일명>.yaml 명령으로 클러스터에 적용하면 다음 리소스가 생성됩니다.
- my-nginx-deployment: Nginx 파드 2개를 실행하는 디플로이먼트
- my-nginx-service: app: my-nginx 레이블을 가진 파드들을 외부로 노출하는 노드포트 서비스
서비스 생성 후 kubectl get services 또는 kubectl get svc 명령을 실행하면 할당된 nodePort 번호를 확인할 수 있습니다. 예를 들어 31234번 포트가 할당되었다면, 클러스터 내 아무 노드의 IP 주소와 이 포트 번호(<노드 IP>:31234)를 조합하여 웹 브라우저로 Nginx 시작 페이지에 접속할 수 있습니다.
Why it matters: YAML 정의에서 spec.type을 NodePort로 명시하는 것이 핵심입니다. selector를 통해 어떤 파드 그룹을 노출시킬지 정확히 지정해야 하며, 각 포트의 역할을 명확히 구분하여 설정해야 합니다.
4. 노드포트의 한계와 사용 시 주의사항
노드포트는 사용이 간편하지만 프로덕션 환경에서는 다음과 같은 한계 때문에 사용을 지양하는 경우가 많습니다.
- 보안 문제: 클러스터의 모든 노드에 포트가 열리므로 공격 표면(attack surface)이 넓어집니다. 방화벽 규칙 관리도 복잡해집니다.
- 포트 관리의 어려움: 사용할 수 있는 포트 범위가 제한적(기본 30000-32767)이며, 포트 충돌이 발생할 수 있습니다. 또한 80, 443과 같은 잘 알려진(well-known) 포트는 직접 사용할 수 없습니다.
- 노드 IP 의존성: 노드의 IP 주소가 변경되거나 노드 장애가 발생하면 해당 IP를 통한 접근이 불가능해집니다. 별도의 로드밸런서 없이는 고가용성(High Availability)을 보장하기 어렵습니다.
- 단일 진입점 부재: 여러 노드가 있다면 어떤 노드 IP를 사용해야 할지 애매하며, 모든 노드 IP를 클라이언트에게 제공하고 관리하는 것은 비효율적입니다.
이러한 단점 때문에 실제 상용 환경에서는 클라우드 플랫폼이 제공하는 로드밸런서(LoadBalancer) 타입 서비스를 사용하거나, L7 라우팅, SSL/TLS 종료 등 고급 기능을 제공하는 인그레스 컨트롤러(Ingress Controller)를 노드포트와 함께 구성하여 사용하는 것이 일반적입니다.
Why it matters: 노드포트의 본질적인 한계를 명확히 인지해야 합니다. 개발, 테스트 목적을 넘어 프로덕션 환경에서는 트래픽 관리, 보안, 고가용성을 위해 반드시 로드밸런서나 인그레스 같은 상위 레벨의 추상화를 도입해야 합니다.
결론 (요약 정리)
쿠버네티스 노드포트는 클러스터 외부에서 내부 서비스로 접근하는 가장 기본적인 방법을 제공합니다. 각 노드의 특정 포트를 열어 외부 트래픽을 해당 서비스에 연결된 파드로 전달하는 직관적인 구조를 가집니다. 설정이 간단하여 개발 및 테스트 환경에서 유용하지만, 보안, 포트 관리, 고가용성 측면의 한계로 인해 프로덕션 환경에서는 단독으로 사용하는 것을 권장하지 않습니다.
References:
- Connecting Applications with Services | Kubernetes | 2025-08-01 | https://kubernetes.io/docs/tutorials/services/connect-applications-service/
- Service | Kubernetes | 2025-06-05 | https://kubernetes.io/docs/concepts/services-networking/service/
- Kubernetes - NodePort Service | GeeksforGeeks | 2025-07-23 | https://www.geeksforgeeks.org/devops/kubernetes-nodeport-service/
- [kubernetes]서비스 타입 비교(ClusterIP/NodePort/LoadBalancer) | kim.dragon - 티스토리 | N/A | https://kim-dragon.tistory.com/52
- Kubernetes Service Types: ClusterIP vs. NodePort vs. LoadBalancer vs. Headless | Edge Delta | 2024-03-27 | https://edgedelta.com/company/blog/kubernetes-services-types
- Think Before you NodePort in Kubernetes | Oteemo | 2017-12-12 | https://oteemo.com/blog/think-nodeport-kubernetes/
'개발 창고 > Server' 카테고리의 다른 글
도커(Docker)란 무엇인가: 컨테이너 가상화 기술 완벽 입문 (1) | 2025.09.27 |
---|---|
쿠버네티스 인그레스(Ingress): 완벽 가이드 (NGINX 예제 포함) (1) | 2025.09.23 |
쿠버네티스 동적 프로비저닝(Dynamic Provisioning) 쉽게 이해하기 (0) | 2025.09.20 |
쿠버네티스 레이블(Labels) 완벽 가이드: 개념부터 실전 베스트 프랙티스까지 (1) | 2025.09.19 |
쿠버네티스 컨트롤러 매니저: 클러스터 상태를 지키는 자동화의 핵심 (1) | 2025.09.17 |