05 Service/ingress
05 Service/ingress
1. Note
1. Note
- POD만으로는 혼자서 뭔가 하기에 약간 애매함
- IP도 동적으로 변경되고, 상황에따라서 죽었다 살아났다 할수도 있기 때문에
- 따라서 POD를 묶어줬던 Deployment가 있었고
- Deployment에 접근할 수 있도록 도와주는 Service
- 그보다 앞단에서 ingress가 Service 연결까지 지원함.
2. Service
1. Service
- 여러개 파드에 접근할 수 있는 하나의 IP를 제공하고, 본질적으로 로드밸런서 역할
- 파드(Pod)와 네트워크를 안정적으로 연결해주는 핵심 구성요소
- 파드가 재생성되거나 스케줄링될 때마다 IP가 계속 바뀔 수 있는데, Service가 그 중간에서 고정된 접근 지점을 제공
2. 주요 역할
- 계속 바뀌는 Pod IP를 추상화해서 안정적인 접근 경로 제공
- 여러 Pod로 트래픽 분산(load balancing)
- 내부 공개인지 외부 공개인지 접근 범위 결정
3. 서비스 생성 명령어
1
2
# 동일하게 Yaml로 생성
kubectl apply -f clusterip.yaml
3. 서비스 타입
1. ClusterIP (기본)
1. ClusterIp
- 가장 기본이 되는 Service 타입이며, 별도로 지정하지 않으면 기본값으로 사용
- 클러스터 내부에서만 접근 가능함
- 외부 인터넷이나 브라우저에서는 직접 접근할 수 없고,
- 쿠버네티스 내부에 존재하는 다른 파드나 서비스만 접근할 수 있음
- 흐름
1 2 3 4 5 6
[외부] ↓ Service(ClusterIP) # 내부 네트워크로 전달 ↓ # 파드는 내부 order-service / user-service 등 [Pod] <-> [Pod] <-> [Pod]
2. Yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: Service
metadata:
name: spring-service
spec:
type: ClusterIP # 기본값이라 생략해도 됨.
selector:
app: spring-app
ports:
- port: 80
targetPort: 8080
2. NodePort
1. NodePort
- 외부에서 접근 가능하도록 노드(Node)에 특정 포트를 직접 개방하는 Service 타입
- 모든 워커 노드에 동일한 포트가 열리게 되며, 외부에서는 해당 노드 IP와 포트를 통해 접근 가능
- 주로 개발 환경이나 테스트 환경에서 사용됨
- 운영 환경에서는 포트 관리와 보안 문제 때문에 잘 사용하지 않음
- 흐름
1 2 3 4 5 6 7
브라우저 ↓ NodeIP:30080 ↓ Service ↓ Pod
2. Yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Service
metadata:
name: spring-service
spec:
type: NodePort # 타입설정
selector:
app: spring-app
ports:
- port: 80
targetPort: 8080
nodePort: 30080 # 외부에서 접근할 포트 (30000~32767 범위)
3. LoadBalancer
1. LoadBalancer
- 클라우드 환경에서 외부 트래픽을 안정적으로 받아주기 위한 Service 타입
- AWS, GCP, Azure 같은 클라우드와 연동되어 자동으로 외부 로드밸런서를 생성
- 사용자는 자동 생성된 외부 IP(또는 DNS)를 통해 접근 가능
- NodePort처럼 직접 노드 IP를 알 필요가 없고, 운영 환경에서 가장 일반적으로 사용됨
2.Yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
name: spring-service
spec:
type: LoadBalancer
selector:
app: spring-app
ports:
- port: 80
targetPort: 8080
4. ingress
1. ingress
- 외부 HTTP/HTTPS 요청을 “어떤 Service로 보낼지” 라우팅해주는 리소스
- Service처럼 Pod로 직접 연결하는 것이 아니라, URL 기반으로 여러 Service를 분기 처리하는 역할
- 예: /api → user-service, /admin → admin-service
- 보통 외부 노출의 최종 진입점 역할을 담당함
- 실제 트래픽 흐름은 Ingress → Service → Pod 구조로 이어짐
- 장점
- 하나의 외부 도메인으로 여러 서비스 관리 가능
- SSL(HTTPS) 처리, 라우팅 규칙을 중앙에서 관리 가능
- NodePort나 LoadBalancer를 직접 여러 개 만들 필요가 없음
2. 흐름
1
2
3
4
5
6
7
Ingress YAML
↓
NGINX Ingress Controller # Ingress 가 있는 부분
↓
Service (ClusterIP)
↓
Pod
5. ingress 생성
1. 종류
| 종류 | 특징 | 장점 | 단점 | 주 사용 환경 |
|---|---|---|---|---|
| NGINX Ingress Controller | 가장 널리 사용되는 기본 Ingress 구현체 | 안정적, 자료 많음, 커뮤니티 큼 | 기능 확장 한계, 고급 트래픽 제어는 약함 | 대부분 일반 Kubernetes, 온프레미스, 초기 운영 |
| Traefik Ingress Controller | 동적 설정에 강한 Ingress | 설정 간단, 자동 discovery, 현대적인 구조 | 대규모 트래픽 튜닝은 NGINX보다 약한 경우 있음 | 마이크로서비스, DevOps 환경 |
| HAProxy Ingress Controller | 고성능 L4/L7 프록시 기반 | 성능 좋고 안정적, 트래픽 처리 강함 | 설정이 상대적으로 복잡 | 트래픽 많은 서비스, 금융/고성능 환경 |
| AWS ALB Ingress Controller | AWS Application Load Balancer 연동 | AWS 네이티브, 관리형 LB 사용 | AWS 종속, 다른 환경 이동 어려움 | AWS 기반 서비스 |
| GCP Ingress (GCE) | Google Cloud Load Balancer 기반 | 완전 관리형, 설정 거의 없음 | GCP 종속 | GCP 기반 서비스 |
| Azure Application Gateway Ingress | Azure WAF + LB 통합 | 보안 기능 강력 (WAF) | Azure 종속, 설정 복잡 | Azure 기반 서비스 |
| Kong Ingress Controller | API Gateway 기반 Ingress | API 관리 기능 강력 (Auth, Rate limit 등) | 리소스 무거움 | API Gateway 중심 아키텍처 |
| Istio Ingress Gateway | Service Mesh 기반 Ingress | 트래픽 제어, mTLS, observability 강력 | 복잡도 매우 높음 | MSA + Service Mesh 환경 |
2. 명령어
1
2
3
4
5
6
7
# 종류마다 생성법이 다름.
# Nginx ingress 생성 (주로 사용함)
# 2026.03 기준.
# - Ingress-NGINX 컨트롤러가 EOF(종료)됨.
# - 과도기
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
3. Yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: spring-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: user-service
port:
number: 80
- path: /order
pathType: Prefix
backend:
service:
name: order-service
port:
number: 80
This post is licensed under CC BY 4.0 by the author.