Kubernetes 네트워킹 - Service와 요청 처리 흐름

Service의 역할

Service는 Pod에 트래픽을 보내는 방식을 정의한다.

안정적인 IP/DNS 제공: ClusterIP를 통해 Pod IP가 바뀌어도 항상 같은 주소로 접근 가능
로드밸런싱: 여러 Pod에 트래픽을 분산
서비스 디스커버리: 다른 서비스가 이 서비스를 이름으로 찾을 수 있게 함

Service 타입 비교

타입	접근 범위	사용 사례
ClusterIP	클러스터 내부만	내부 마이크로서비스 통신
NodePort	노드 IP:Port	개발/테스트, 간단한 외부 노출
LoadBalancer	외부 LB	프로덕션 외부 노출 (클라우드 환경)

이 세 타입은 계층 구조로 되어있다.

LoadBalancer는 내부적으로 NodePort를 만들고, NodePort는 내부적으로 ClusterIP를 만든다.

외부 요청 처리 흐름

외부에서 요청이 들어오면 다음 경로로 처리된다.

[외부 인터넷]
↓
[LoadBalancer Service]  ← 클라우드 로드밸런서 (L4: IP/포트 레벨)
↓  "이 IP:443으로 오는 거 클러스터로 보내"
[Ingress Controller]  ← 실제 트래픽 처리 엔진 (nginx 등)
↓
[Ingress 규칙]  ← 도메인/경로 기반 라우팅 (L7: URL 레벨)
↓  "api.myapp.com → 백엔드 Service"
[Service]  ← 파드로 연결
↓
[Pod]

중요한 개념들

API Server는 실제 트래픽을 처리하지 않는다

컨트롤 플레인의 API Server가 모든 요청을 받아서 나눠준다고 오해하기 쉽다. 하지만 API Server의 역할은 클러스터 운영/조율을 위한 내부 관리다.

파드를 어디에 띄울지, 몇 개를 유지할지 같은 관리 명령이 API Server를 통한다
실제 사용자 요청은 API Server를 거치지 않고 Ingress → Service → Pod 경로로 처리된다

Ingress Controller와 Ingress 규칙은 다르다

Ingress 규칙은 설정 파일일 뿐이다. 컨트롤러가 없으면 그냥 텍스트 파일이다.

Ingress Controller(nginx 등)가 그 규칙을 읽고 실제 nginx 설정을 만들어야 라우팅이 수행된다.

LoadBalancer vs Ingress: L4 vs L7

	역할	레벨
LoadBalancer	외부 IP 부여, 트래픽 진입점	L4 (IP/포트)
Ingress Controller	실제 라우팅 엔진 (nginx 등)	L7 (HTTP)
Ingress 규칙	“어떤 도메인/경로를 어디로” 정의	설정

NodePort는 외부에서 서버IP:포트번호로 직접 접근할 때 쓰는 방식인데, Ingress를 쓰면 NodePort를 직접 노출할 필요가 없다.

서비스 디스커버리

파드가 다른 서비스를 어떻게 찾아서 통신하는가?

쿠버네티스는 클러스터 안에 CoreDNS라는 DNS 서버를 띄운다. 서비스를 만들면 자동으로 서비스 이름이 DNS에 등록된다.

같은 네임스페이스 내에서는 서비스 이름만으로 접근 가능
```
http://backend-service
```

다른 네임스페이스에서는 FQDN 사용

http://backend-service.my-namespace.svc.cluster.local

ClusterIP는 클러스터 내부에서만 쓰는 가상 IP로, 서비스를 만들면 자동으로 부여된다. 이 가상 IP와 DNS가 함께 동작하여 Pod IP가 바뀌어도 항상 안정적으로 접근할 수 있다.