4. Service

Pod는 언제든 죽고 다시 생성될 수 있는 것이 Kubernetes 환경이다.

 

즉 Pod가 죽게되면,

- Pod의 IP가 바뀔 수 있다.

- Pod의 이름도 바뀔 수 있다.

- Deployment 재배포 시 새 Pod 가 생성된다.

 

그러나 가변적인 Pod와는 달리, 평범한 애플리케이션 운영/이용자가 원하는건 아래와 같다.

- 항상 같은 주소로 접속하고 싶다.

- 여러 Pod에 트래픽을 분산하고 싶다.

- 특정 역할만을(web/db 등) 담당하는 Pod만 묶고 싶음.

 

이럴 때 사용하는 것이 Service이다.

Service 는 특정 Label을 가진 Pod들을 하나의 고정된 네트워크 엔드포인트로 묶어주는 객체

apiVersion: v1
kind: Service
metadata:
  name: svc-for-web

#k8s의 Service 정의 시작
spec:
  #가장 핵심이 되는 요소 selector!
  selector:
    # label에 type=web 이 있는 Pod를 찾아서 연결해라
    type: web
  ports:
  - port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-for-production
spec:
  selector:
    lo: production 
  ports:
  - port: 8080

 

Service의 역할

1. 고정 주소 제공

Pod의 IP는 계속 바뀌지만, Service의 이름은 바뀌지 않는다.

아래와 같은 방식으로도 호출이 가능하다.

curl svc-for-web:8080

 

2. 로드밸런싱

Service 뒤에 Pod가 여러 개 있으면 Service로 묶인 Pod에게 요청이 분산된다.

 

3. Pod 자동 발견

Pod를 정의 할 때, 

labels:

  type: web

만 정의되어 있어도 자동 포함된다.

즉, Service는 Pod를 동적으로 추적한다.

 

ports 부분에 대해서,

ports:
- port: 8080 #이렇게 port만 선언하면,
  targetPort: 8080 # targetPort는 port 값을 default로 따라간다. 즉, targetPort는 8080이 된다.

※ port -> client가 붙기 위한 Port
※ targetPort -> Pod의 Port

 

이런 구조에서는 client가 8080 포트를 사용하여 애플리케이션에 접근하면, 8080 Port를 갖는 Pod의 Service에 붙는다.

 

Service의 흐름

curl svc-for-web:8080 호출하면,

Service(svc-for-web)
        ↓
label type=web Pod 검색
        ↓
pod-1 / pod-4 발견
        ↓
둘 중 하나로 전달

 

잊지 말아햐 할 것

Service는 Pod를 "생성"하지 않는다.

Service는 오로지 이미 존재하는 Pod에 대해서 "연결"만 해준다.

[대략적인 흐름도]

사용자
 ↓
Ingress / LB
 ↓
Service
 ↓
Deployment
 ↓
Pod

Deployment → Pod 생성 관리
Service → Pod 연결/로드밸런싱
Ingress → 외부 URL 연결