[Kubernetes] Basic Resource

IT/Kubernetes

[Kubernetes] Basic Resource - Part 2

물통꿀꿀이 2019. 3. 30. 00:36

Service

Service는 아래의 그림 1에서 확인 할 수 있듯이 Pod를 논리적으로 묶은 것이다. 특히 Service는 Pod의 논리적인 묶음이기 때문에 여러 Node에 걸쳐서 Pod를 묶을 수 있다.

이렇게 논리적으로 묶는 이유는 k8s에서 Pod는 lifecycle (scaling out-in 등등에 의해서)이 존재하기 때문에 항상 Pod가 고정적이지 않다. 더욱이 IP를 내부적으로 공유하는 Pod의 특성상 외부에서는 항상 IP만 확인 할 수 없다. (Pod가 다시 생성되면 IP가 재할당되기 때문에) 그래서 Service라는 리소스*를 통해 Pod를 관리한다.

* 일반적으로 Label Selector를 통해 서비스를 구분한다.

그림 2를 보면 각 Pod가 nginx라는 label name으로 묶인 것을 확인 할 수 있다. 만약 name이 다르다면 해당 Pod는 다른 Service에 속하게 된다. 그럼 매니페스트 파일을 사용하여 Service를 생성하고 알아보자.

apiVersion: apps/v1

kind: Deployment

metadata:

name: echo-spring

labels:

app: echo

release: spring

spec:

...

---

apiVersion: apps/v1

kind: Deployment

metadata:

name: echo-summer

labels:

app: echo

release: summer

spec:

...

먼저 위의 매니페스트 파일은 Service를 보여주기 위해 2개의 Deployment가 포함되어 있는 매니페스트 파일이다. 해당 파일을 실행시켜 보면 아래와 같다.

그림 3을 보면 현재 생성된 각각의 Deployment를 확인 할 수 있다. (위의 매니페이스 파일에서 언급한것 처럼 Deployment를 2개로 정의했고 각각 1개, 2개의 Pod를 생성하게 한다.) 그리고 Labels을 보면 각 Deployment의 release 이름이 다른 것을 확인 할 수 있다. 이를 바탕으로 Service 매니페스트 파일을 만들면 다음과 같다.

apiVersion: v1

kind: Service // Service 리소스 설정

metadata:

spec:

selector: // Service에 정의하는 Selector 값

app: echo

release: summer

ports:

- name: http

port: 80

해당 Service는 Pod를 app: echo와 release: summer로서 구분한다는 정의를 담고있다.

매니페스트 파일을 실행하면 그림 4와 같이 echo 이름은 가진 Service 리소스가 생성된 것을 확인 할 수 있다. 해당 Service를 약간 더 들어가보면 Service 리소스가 정말 Deployment에서 생성한 Pod와 Label selector가 같은 것만 연결되었는지 알 수 있다.

생성된 Service를 확인해보면 각 Service의 앤드포인트가 10.1.0.50과 10.1.0.49를 가지고 있는 것을 알 수 있다. 그리고 각 Pod의 할당된 IP를 보면 Service의 앤드포인트와 같다는 것을 알 수 있다. 물론 k8s cluster 내부에서 임시 컨테이터를 생성하여 Service의 name을 curl로명령*을 보내고 각 Pod에서 로그만 봐도 알 수 있다.

* k8s cluster의 DNS는 Service를 서비스명.네임스페이스명.svc.local로 연결한다.

curl http://echo.default.svc.local - Full Path
curl http://echo.default - svc.locald은 생략 가능 (다른 네임스페이스 접근할 때)
curl http://echo - 가장 많이 사용 (같은 네임스페이스 접근할 때)

이렇듯 IP의 상관 없이 이름으로만 Service를 찾을 수 있는 것을 Service Discovery라고 하는데 k8s Service의 주요 특징 중 하나이다.

ClusterIP

ClusterIP는 위의 그림 4에서도 확인 할 수 있듯이 Service를 만들때 할당받는 IP이다.

해당 IP는 Service에 의존적이기 때문에 Service의 lifecycle과 생사를 같이한다. 즉, Service가 만들어질 때 같이 할당 받고 Service가 내려가면 IP 또한 다른 곳에서 재사용 될 수 있다. (또한 할당된 IP는 Service가 running 하는 동안에는 변경 할 수 없다.)

사실 위의 Service 매니페스트 파일을 보면 따로 적어준 부분은 없는데 Service는 따로 지정해주지 않으면 default type을 ClusterIP로 사용한다.

이와 같이 ClusterIP를 통해서 k8s Cluster의 내부 IP 주소에 Service를 공개 할 수 있다. ClusterIP는 k8s Cluster 내부에서만 사용하는 주소로 Service에 접근 할 때 Service Name으로 접근을 가능하도록 하게 한다. (내부 DNS를 통해 ClusterIP와 Service Name을 매핑)