📮 내 Pod는 어디있을까? 쿠버네티스 Service로 안정적으로 연결하기

안녕하세요, 쿠버네티스 세계를 탐험하는 여러분! 🚀 오늘은 우리 애플리케이션의 집합인 Pod(파드)들을 세상과, 그리고 서로와 연결해 주는 아주 중요한 우편배달부이자 교통경찰, 바로 쿠버네티스 서비스(Service)에 대해 알아보려 합니다.

 

파드는 언제든지 죽고 다시 태어날 수 있는 '휘발성' 존재입니다. 파드가 새로 생길 때마다 IP 주소가 바뀌죠. 만약 프론트엔드 파드가 백엔드 파드의 IP 주소를 직접 저장해두고 통신한다면, 백엔드 파드가 재시작되는 순간 모든 연결은 끊어지고 말 겁니다. 😱

 

이런 혼란 속에서 질서를 잡아주는 것이 바로 서비스입니다. 서비스는 절대 변하지 않는 고정된 주소를 제공하여, 파드가 몇 번을 다시 태어나든 상관없이 안정적인 통신을 보장해 줍니다.

 

---

🤔 서비스는 왜 필요하고, 어떻게 Pod를 찾을까?

서비스의 핵심은 느슨한 결합(Loose Coupling)에 있습니다. 서비스는 특정 파드에 직접 연결되는 것이 아니라, 특정 조건을 만족하는 파드 그룹에 연결됩니다. 이 마법 같은 연결을 가능하게 하는 것이 바로 레이블(Label)과 셀렉터(Selector) 메커니즘입니다.

• 레이블 (Label) 🏷️: 파드를 만들 때 붙여주는 '이름표'입니다. key: value 형태의 간단한 꼬리표죠. 예를 들어, app: my-backend, tier: api 와 같이 파드의 역할이나 속성을 자유롭게 정의할 수 있습니다.
• 셀렉터 (Selector) 🔍: 서비스가 어떤 이름표를 가진 파드들을 찾아갈지 정의하는 '조건'입니다. 서비스의 셀렉터에 app: my-backend라고 정의해두면, 쿠버네티스는 app: my-backend라는 레이블을 가진 모든 파드를 자동으로 찾아내어 서비스의 연결 대상 목록(Endpoints)에 추가합니다.

이 덕분에 파드가 새로 생기거나 없어져도, 셀렉터 조건만 맞으면 서비스가 알아서 연결 목록을 최신 상태로 유지해 줍니다. 우리는 더 이상 파드의 IP 주소를 신경 쓸 필요 없이, 서비스의 고정된 주소만 바라보면 되는 것이죠!

---

🚦 목적에 따라 골라 쓰는 세 가지 Service 타입

쿠버네티스는 사용 목적에 따라 세 가지 주요 서비스 타입을 제공합니다.

1. ClusterIP: 클러스터 내부 전용 통신 🏢

ClusterIP는 가장 기본적이고 흔하게 사용되는 서비스 타입입니다. 이름 그대로 클러스터 내부에서만 접근할 수 있는 고유한 IP 주소(가상 IP)를 생성합니다.

• 역할: 클러스터 내의 다른 파드, 서비스, 디플로이먼트 간의 안전하고 격리된 통신을 담당합니다.
• 사용 예시: 사용자가 직접 접근할 필요 없는 백엔드 API 서버나 데이터베이스 서비스에 적합합니다. 프론트엔드 파드가 이 ClusterIP 주소를 통해 백엔드 서비스와 통신하는 구조가 일반적입니다.
• 비유: 회사의 내선 전화번호와 같습니다. ☎️ 외부에서는 직접 걸 수 없지만, 회사 내부 직원들끼리는 이 번호로 자유롭게 소통할 수 있죠.

apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  type: ClusterIP # (기본값이므로 생략 가능)
  selector:
    app: my-backend
  ports:
    - protocol: TCP
      port: 80         # 서비스가 사용할 포트
      targetPort: 8080 # 파드 컨테이너가 리스닝하는 포트

2. NodePort: 외부 테스트 및 개발용 창구 🚪

NodePort는 ClusterIP의 기능을 확장하여, 클러스터를 구성하는 모든 노드(Node)의 특정 포트를 외부에 개방합니다. 외부에서 [아무 노드의 IP]:[지정된 NodePort]로 접속하면 해당 서비스에 연결된 파드로 트래픽이 전달됩니다.

• 역할: 개발이나 테스트 목적으로 서비스를 클러스터 외부로 간단하게 노출시킬 때 사용합니다.
• 주의사항: 운영 환경에서는 잘 사용하지 않습니다. 노드의 IP가 변경될 수 있고, 포트 관리도 번거로우며, 보안에도 취약하기 때문입니다.
• 비유: 아파트(클러스터)의 모든 동(Node) 1층에 있는 특정 창문(NodePort)을 열어두는 것과 같습니다. 어느 동으로 찾아가든 그 창문을 통해 안에 있는 사람(Pod)에게 물건을 전달할 수 있죠.

apiVersion: v1
kind: Service
metadata:
  name: my-dev-service
spec:
  type: NodePort
  selector:
    app: my-frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30007 # 30000-32767 사이의 포트. 지정 안하면 랜덤 할당.

3. LoadBalancer: 클라우드를 위한 정식 출입구 🌐

LoadBalancer는 클라우드 환경에서 서비스를 외부에 노출하는 표준적이고 가장 권장되는 방법입니다. 이 타입을 사용하면 쿠버네티스가 클라우드 제공업체(AWS, GCP, Azure 등)의 실제 외부 로드 밸런서를 자동으로 생성하고 설정해 줍니다.

• 역할: 인터넷에서 들어오는 트래픽을 받아 클러스터 내의 적절한 파드들에게 분산시켜 줍니다. 고가용성과 안정적인 외부 서비스 제공을 위해 필수적입니다.
• 작동 원리: 클라우드 로드 밸런서는 생성된 후, 각 노드의 NodePort로 트래픽을 전달하는 방식으로 동작합니다. (NodePort는 이 과정에서 자동으로 생성됩니다)
• 비유: 대형 쇼핑몰(클러스터)의 정문 안내 데스크와 같습니다. 🛍️ 방문객(트래픽)들은 쇼핑몰의 유일하고 잘 알려진 주소(로드 밸런서 IP)로 찾아오면, 안내 데스크가 알아서 방문객을 원하는 매장(Pod)으로 안내해 줍니다.

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

---

🎉 결론: 서비스로 Pod의 길을 열어주세요

쿠버네티스 서비스는 동적으로 변하는 파드 세계에 안정성이라는 질서를 부여하는 핵심 요소입니다.

• 내부 통신이 필요하면 ClusterIP
• 간단한 외부 테스트가 필요하면 NodePort
• 안정적인 외부 서비스가 필요하면 LoadBalancer

이 세 가지 서비스 타입의 역할과 차이점을 정확히 이해하고 상황에 맞게 사용한다면, 여러분의 애플리케이션은 쿠버네티스 위에서 더욱 견고하고 유연하게 동작할 것입니다!

 

 

Tags: 쿠버네티스, Kubernetes, Service, ClusterIP, NodePort, LoadBalancer, DevOps, Pod, MSA, 네트워킹