Ingress와 Service 비교
Service (L4 관점) #
Service는 Pod 집합 앞에 높이는 안정적인 네트워크 엔드포인트다.
pod가 죽고 다시 떠도 ip가 바뀌기 때문에, 이를 추상화하기 위해 Service가 필요하다.
핵심 역할
- pod ip 변경을 숨김
- 로드 밸런싱 (L4 TCP UDP)
- 서비스 디스커버리 (DNS 이름 제공)
Service 타입별 의미
- ClusterIP: 클러스터 내부 전용 접근, 기본값
- NodePort: 각 노드의 고정 포트로 외부 접근 가능, 실제로는 보안/운영상 사용 x
- LoadBalancer: 클라우드 Provider L4, LB 생성, AWS NLB, GCP TCP LB등
내부적으로 일어나는 방식
kube-proxy가 Service를 감시한다.- iptables 또는 IPVS 규칙 생성
- Service IP -> Pod IP로 L4 트래픽 포워딩
즉, Service는 ip:port -> pod 라는 규칙 집합.
Ingress (L7 관점) #
Ingress는 http/https 트래픽을 라우팅하는 규칙의 집합으로 실제 네트워크를 처리하는것은 Ingress Controller이며 Ingress는 설정 객체다.
- URL / Host 기반 라우팅 담당
- HTTP 레벨 처리
- path writer
- header 조작
- TLS 종료 (HTTPS -> HTTP)
여기서 짚고갈점은 Ingress 자체는 트래픽을 받지 않고 Ingress Controller가 있어야 의미가 있다 예를들어 NGINX Ingress, ALB Ingress Controller, Traefik 등
동작 흐름 #
- 외부 요청 도착 (LB, NodePort)
- Ingress Controller Pod가 요청 수신
- Host / Path 규칙 매칭
- Service로 트래픽 전달
- Service가 파드에 분산
즉, Ingress는 서비스 위에서 동작하는 상위 라우터다.
| 구분 | Service | Ingress |
|---|---|---|
| OSI 계층 | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
| 대상 | Pod | Service |
| 라우팅 기준 | IP / Port | Host / Path / Header |
| TLS 처리 | 불가능 | 가능 |
| 필수 여부 | Pod 노출 시 필수 | HTTP 외부 노출 시 선택 |
eks 기준 트래픽 흐름
Client
↓
AWS ALB / NLB
↓
Ingress Controller (NGINX Pod)
↓
Service (ClusterIP)
↓
Application Pod
왜 Service와 Ingress는 분리했는가 #
쿠버네티스의 핵심 설계 철학 때문인데
- 네트워크 단순화: Service 연결 Ingress 규칙
- 프로토콜 분리: 모든 트래픽이 HTTP는 아님
- 컨트롤러 확장성: Ingress는 구현체 교체 가능이며 Service는 클러스터 공통 추상화
이러한 구조 덕분에 tcp는 ingress없이 운영 가능하며 http는 ingress로 고급 제어가 가능하다 인프라와 애플리케이션 관심사 분리가 가능하단 말씀.